memory leaks

Artchi

LordJaxom schrieb:

@Artchi: malloc/free?

malloc/free? Kann man das essen? Wir sind im C++ Forum!

groovemaster

asr schrieb:

wie sucht ihr denn eure memory leaks?

Ich nutze dafür überladene Operator new/delete Funktionen beim Debug Build. Dort wird in einer Liste jede Speicherallokierung und -freigabe registriert. Dementsprechend kannst du feststellen, ob überhaupt Memory Leaks vorhanden sind.
Zusätzlich kannst du noch solche new #defines nutzen, um mehr Infos zu bekommen. ZB wo denn die Memory Leaks sich genau befinden. DEBUG_NEW macht das auch nicht anders. Nur ist das mit Vorsicht zu geniessen, da du bestimmte Einschränkungen in Kauf nehmen musst. So funktioniert dann zB placement new nicht mehr.

Vertexwahn

placement new

was ist placement new?

miller_m

Vertexwahn schrieb:

was ist placement new?

die operatoren new und delete für einzelne klassen überladen.

Caipi

Vertexwahn schrieb:

placement new

was ist placement new?

Placement new konstruiert ein Objekt in einen vorgegebenen Speicherbereich und hat die folgende Syntax:

new (der_speicherbereich_in_den_das_objekt_konstruiert_werden_soll) Ctor_des_objektes

Gruß Caipi

groovemaster

miller_m schrieb:

die operatoren new und delete für einzelne klassen überladen.

Nope.

Grob gesagt, die Speicherallokierung fällt weg und es wird nur konstruiert. Dazu muss man allerdings einen vorhandenen Speicherbereich angeben. Siehe dazu ISO/IEC 14882:2003(E), 5.3.4.

edit:
Man bin ich heute wieder langsam.

asr

Vertexwahn schrieb:

placement new

was ist placement new?

danke, wollt ich auch schon fragen

gut. danke erstmal für die zahlreichen tips. ich habe nun folgendes in mein programm eingebaut.

in stdafx.h

#define CRTDBG_MAP_ALLOC
#include <stdlib.h>
#include <crtdbg.h>
#define new new(_NORMAL_BLOCK, __FILE__, __LINE__)

und in meiner main methode ganz zum ende vor dem return

_CrtDumpMemoryLeaks();

hat mich auch prompt auf einige "vergessene" deletes aufmerksam gemacht.
allerdings auch an einige stellen die ich nicht verstehe.

so meckert er mir einen 78bytes block an, den ich hier anlege

wchar_t*						AttrId;
AttrId							= new wchar_t[38];

und einige zeilen weiter unter wieder freigebe

delete [] AttrId;

und bei manchen objekten meckert er zwar, sagt mir aber nicht in welcher datei diese zu finden sind.
also einfach so etwas in der art

Dumping objects ->
{1322} normal block at 0x0094C518, 256 bytes long.
 Data: <blablabla> 4E 65 74 2D 57 2F 53 4D 57 20 54 65 73 74 5A 6F

¿¿jemand hierzu noch nen hinweis??

CStoll

@"AttrId": Schau mal nach, was zwischen den beiden Codezeilen mit deiner Variablen gemacht wird, ist da möglicherweise ein "AttrId=...;" dabei?

@unbekannte Zeilen: Ich tippe auf Lecks in einer Funktion, die außerhalb der überwachten Quelltext-Datei "lebt".

asr

CStoll schrieb:

@"AttrId": Schau mal nach, was zwischen den beiden Codezeilen mit deiner Variablen gemacht wird, ist da möglicherweise ein "AttrId=...;" dabei?

zwischen den codezeilen hab ich nur sowas.

StringFromGUID2( GetId(), AttrId, 38);

aber darum benutz ich ja dann auch das delete.

CStoll schrieb:

@unbekannte Zeilen: Ich tippe auf Lecks in einer Funktion, die außerhalb der überwachten Quelltext-Datei "lebt".

¿¿kann man das noch irgendwie anderweitig eingrenzen??

asr

AttrId hat sich mittlerweile erledigt. ich hatte das delete nach der abbruch-bedingung in einer schleife, und beim letzten durchlauf wurde diese nicht mehr erreicht!

CStoll

asr schrieb:

CStoll schrieb:

@unbekannte Zeilen: Ich tippe auf Lecks in einer Funktion, die außerhalb der überwachten Quelltext-Datei "lebt".

¿¿kann man das noch irgendwie anderweitig eingrenzen??

Du kannst es nur auf die Dateien eingrenzen, die du selber beeinflussen kannst. Wenn im Memory-Dump etwas lesbares steht, könnte das allerdings auch ein char* Pointer sein, der verlorengegangen ist - dann müßtest du nur aufpassen, wo ein String mit diesem Inhalt herumgereicht wurde. (bei anderen Datentypen dürfte es schwieriger sein, den Inhalt richtig zu interpretieren)

adsci

zu jedem new ein delete kann aber schiefgehen, wenn man sowas hier in der art hat:

char *bla = new char[20];
.
.
.
bla = NULL; // <- die stelle muss man erstmal finden. die kann sich gut verstecken. muss nicht so auffällig sein wie in diesem bsp.
.
.
.
delete bla;

groovemaster

Deshalb stimmt das mit new und delete trotzdem, man sollte sich halt immer dazudenken, dass dazwischen der Zeiger nicht geändert werden darf.

Tc++H

http://www.flipcode.com/articles/article_memoryleaks.shtml