[C++] Visual Studio 2010: Wie checkt ihr auf Memory-Leaks?

[ponx]

hallo Leute,
ich versuche gerade meinen Code unter Visual Studio 2010 auf memleaks zu checken, so wie's hier auf MSDN beschrieben ist. Das klappt leider nur so halb. Dieser Thread hier im Forum hat mir schonmal sehr geholfen, weil ich jetzt die Zeilennummern angezeigt bekomme. Jedenfalls solange ich die entsprechenden #defines in der jeweiligen .cpp Datei definiert habe.
Allerdings hab ich das Problem, dass der Aufruf bei mir keine Auswirkung hat, mit dem man die Memleak-Ausgabe bei Programmende aktivieren soll:
_CrtSetDbgFlag ( _CRTDBG_ALLOC_MEM_DF | _CRTDBG_LEAK_CHECK_DF );

Ich bin also im Moment auf den manuellen Aufruf der Ausgabe angewiesen, also per _CrtDumpMemoryLeaks();
Wenn ich den allerdings in einer Klasse als letzten Aufruf innerhalb des Destruktors aufrufe, dann hat er mir z.B. meine SmartPointer noch nicht gelöscht. Ich krieg also gerade hunderte von Memory Leaks angezeigt, von denen ich nicht weiß, ob's tatsächlich welche sind, oder nicht. Wenn ich den Aufruf außerhalb der Klasse setze, krieg ich wieder keine Zeilennummern angezeigt.
Hat jemand einen Workaround dazu? Oder gibt's noch ne bezahlbare Alternative, um auf memleaks zu checken? Was benutzt ihr? Ich hab früher den Visual Leak Detector benutzt und war immer happy damit, aber der führt zu Fehlern, sobald ich meien Code dann über einen CLR-Wrappers einbinde.

danke und viele Grüße,
ponx

edit: CLR meinte ich, nicht CRT.. herrje.. (blush)

[odenter]

Wollte gerade auf den Visual Leak Detector verweisen, den verwende ich und bin zufrieden.
Was ist denn Dein "CRT-Wrapper" kann damit nix anfangen?

[ponx]

oje, vertippt, entschuldige! CLR-Wrapper meinte ich, also ein Wrapper für .NET. Ich weiß nicht mehr genau welche kryptischen Fehler ich da bekommen hatte, aber ich weiß noch wie happy ich war, als alles wieder ging, sobald ich das "#include vld.h" rausgenommen hatte. Also Notlösung wäre, jeweils eine neue Configuration zu machen, um den VLD zu deaktivieren. Ich hab nur schon so viele und muss die dann immer parallel verwalten, die Fehlerquelle würd ich gern vermeiden.

[odenter]

Also Du rufst aus managed code heraus unmanaged code auf?

Welche Version der VLD Libs bindest Du denn ein? 32Bit oder 64Bit?
Wenn Du die 32Bit *.lib einbindest, das entsprechend übersetzt, Dein managed code (.NET) auf any CPU steht und das ganze unter einem 64 Bit OS läuft dann könnte das schon das Problem sein.
In dem Fall könnte helfen den managed code einfach auf x86 zu stellen, oder alles auf 64 Bit umbiegen.

EDIT:
Ansonsten poste doch mal die Fehlermeldung.

[odenter]

Ist die Fehlermeldung:
Eine von "xxx.dll" importierte Prozedur konnte nicht geladen werden. ?

[ponx]

es klappt! (party)
ich habs nochmal probiert über .NET, und diesmal ging alles glatt. Ich rufe nur nativen Code von managed code aus auf, nicht umgekehrt. Das Problem waren vorher wahrscheinlich abhängige dlls, die er nicht gefunden hatte. Ich hatte zwar im VisualLeakDetector-Ordner zwar die beiden .dlls kopiert, aber nicht die .manifest-Datei. Weil unter .NET leider nicht der Dependency Walker funktioniert, war da etwas Blindflug angesagt. Na, jetzt klappt alles, vielen Dank nochmal! Bin wieder versöhnt mit Visual Leak Detector! <3

[odenter]

Ja diese *.manifest Dateien haben mich auch schon ganz schön genervt. :)

[dot]

Weil unter .NET leider nicht der Dependency Walker funktioniert, war da etwas Blindflug angesagt.

ildasm ;)

[ponx]

danke, dot, ildasm kannte ich nich nicht. Wenn der Leidensdruck groß genug ist, guck ich mir den mal an! :)