Ursache für Memory Leaks feststellen (bei wxWidgets-Anwendung)

[PL1994]

Hallo,

seit ich meine wxWidgets-Anwendung zu einer statischen Bibliothek gemacht habe , bekomme ich Memory Leaks. Die Fehlermeldung war sehr unspezifisch, ich bin auf diese Seite gestoßen: Suchen von Arbeitsspeicherverlusten mit der CRT-Bibliothek.

Dort wird beschrieben, wie man eine Ausgabe erzeugt, die Datei und Zeilennummer enthält. So könnte ich wenigstens feststellen, wo die Memory Leaks verursacht werden (habe schon etliche möglicherweise ursächliche Anweisungen auskommentiert, war aber nicht aufschlussreich). Das Problem: Ich bekomme einfach keine vernünftige Ausgabe. Ich habe mich an die Anweisungen auf der verlinkten Seite gehalten, aber was ich erhalte sieht so aus (Auszug):

{187} normal block at 0x00B2DB78, 36 bytes long.

 Data: < <D             > 8C 3C 44 01 00 00 00 00 E8 03 00 00 0C 01 00 00 

{164} normal block at 0x00B25850, 12 bytes long.

 Data: < 5D         > E4 35 44 01 E4 04 00 00 00 00 00 00 

{145} normal block at 0x00B2F140, 772 bytes long.

 Data: <                > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 

{140} normal block at 0x00B2EE00, 772 bytes long.

 Data: <                > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 

Sagt mir gar nichts.

Sollte das, wie es auf der Seite beschrieben ist, funktionieren, wenn ich die entsprechenden Anweisungen in das Hauptprogramm einbaue, die Memory Leaks aber durch eine Klasse einer Bibliothek verursacht werden? Oder muss ich auch in den Bibliotheksklassen Änderungen vornehmen?

__

Andere Überlegung: Kann ich das IMPLEMENT_APP-Makro von wxWidgets überhaupt innerhalb der Klasse einer statischen Bibliothek verwenden oder führt das zu Problemen?

Gruß

PL1994

[mfk'); DROP TABLE Users;--]

Offenbar hast du _CRTDBG_MAP_ALLOC nicht (oder nicht richtig) definiert.

[PL1994]

Das habe ich in der Headerdatei vom Hauptprogramm getan:

#define _CRTDBG_MAP_ALLOC

#include <stdlib.h>

#include <crtdbg.h>

Reicht das nicht?

[mfk'); DROP TABLE Users;--]

Du solltest _CRTDBG_MAP_ALLOC in den Projekteinstellungen sowohl für das Hauptprogramm als auch für die Bibliothek definieren.

[PL1994]

Wo genau soll ich das definieren? Bei den Präprozessordefinitionen?

[mfk'); DROP TABLE Users;--]

Genau da.

[PL1994]

Das funktioniert schon mal. Danke dafür. Ich habe jetzt auch ein paar Zeilennummern. Dazu eine Frage: Ist es normal, dass bei einigen Meldungen die Datei- und Zeilenangabe fehlt, während sie bei anderen dabeisteht?

Sieht dann so aus:

c:[...]\wxwidgets\include\wx\hashmap.h(121) : {949} normal block at 0x008E2658, 772 bytes long.

 Data: <                > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 

{948} normal block at 0x008E2458, 28 bytes long.

 Data: <X&              > 58 26 8E 00 C1 00 00 00 00 00 00 00 CD CD CD CD 

{947} normal block at 0x008E25F8, 32 bytes long.

 Data: <w x V a r i a n > 77 00 78 00 56 00 61 00 72 00 69 00 61 00 6E 00 

{946} normal block at 0x008E25B0, 8 bytes long.

 Data: <P%      > 50 25 8E 00 00 00 00 00 

{945} normal block at 0x008E2550, 36 bytes long.

 Data: < %   %          > B0 25 8E 00 F8 25 8E 00 CD CD CD CD CD CD CD CD 

Denkbar ungünstig ist auch, dass sich die Meldung auf eine Datei der wxWidgets bezieht; an der werde ich jetzt nicht rumpfuschen. Kann ich irgendwie feststellen, an welcher Stelle meines Quellcodes der Ablauf genau scheitert?

[mfk'); DROP TABLE Users;--]

Ist es normal, dass bei einigen Meldungen die Datei- und Zeilenangabe fehlt, während sie bei anderen dabeisteht?

Das passiert dann, wenn die Speicherallokation in einer DLL stattfand, die ohne _CRTDBG_MAP_ALLOC erstellt wurde.

Kann ich irgendwie feststellen, an welcher Stelle meines Quellcodes der Ablauf genau scheitert?

Es ist nicht so, dass da etwas scheitert. Das ist Speicher, der angefordert, aber nicht wieder freigegeben wurde. Wenn das mit längerer Laufzeit des Programms immer mehr wird, ist das ein Problem. Wenn das immer dieselben Blöcke mit derselben Größe sind, ist das theoretisch auch ein Problem, praktisch jedoch nicht.

Es ist auch durchaus möglich, dass der Leck-Detektor hier anschlägt, obwohl gar nichts ist.