Speicherleck (bei Programmende) finden
-
EDIT: Was bedeutet eigentlich der Wert in geschweiften Klammern?
Das ist die Allokations Nr.
-
Schreib das hier oben in Deine .cpp Files
#ifdef _DEBUG #define new DEBUG_NEW #endifdann bekommst Du in Deinem Dump zusätzlich Name des .cpp Files und Zeilennummer des new Aufrufes angezeigt, zu dem kein delete ausgeführt wurde.
-
@_matze: Indem du eine dieser Nummern in eine spezielle Variable schreibst kannst du erreichen dass das Programm bei genau dieser Allokation auf einen Breakpoint läuft -- dann kannst du ganz einfach sehen wo und wann dieser Speicher angefordert wird.
Voraussetzung dass das funktioniert ist natürlich dass die Allokationen bei jedem Programmstart in der selben Reihenfolge passieren -- zumindest bis dorthin wo das Leak ist. Kannst du aber leicht kontrollieren indem du ein paar Testläufe machst, und guckst ob die Nummern sich ändern.
Wie diese Variable heisst weiss ich nimmer auswendig, aber guck einfach in der MSDN zum Thema Debug-Heap.
-
hustbaer schrieb:
...Wie diese Variable heisst weiss ich nimmer auswendig, aber guck einfach in der MSDN zum Thema Debug-Heap.
Die Funktion _CrtSetBreakAlloc(...) (aus crtdbg.h) macht genau das.
Gruss Simon
-
Upps...
OK, dann war's eine Funktion und keine Variable, gebe mich geschlagen
-
Ok, danke für die Tipps. "#define new DEBUG_NEW" hatte ich bereits verwendet, jedoch wurde mir, wie gesagt, keine Zeilenangabe angezeigt.
Dass _CrtSetBreakAlloc(101) das Programm nicht anhält, am Ende jedoch trotzdem ein Leck mit der Allokations-Nr. 101 angezeigt wird, bedeutet wahrscheinlich, dass der Fehler nicht in meinem OCX zu finden ist. Der Speicher wird vermutlich vorher alloziert, in einem Modul, dass ich als Release kompiliert habe (deswegen wohl keine Zeilen- und Dateiangabe). Somit ist das nicht mehr mein Problem...
-
hustbaer schrieb:
Upps...
OK, dann war's eine Funktion und keine Variable, gebe mich geschlagenBrauchst du nicht, ihr habt beide Recht:
http://msdn.microsoft.com/de-de/library/w2fhc9a3(VS.80).aspx
-
_matze schrieb:
http://msdn.microsoft.com/de-de/library/w2fhc9a3(VS.80).aspx
Diese Methode kostet aber bei komplexen Programmen einiges an Perfomance, Data-Breakpoints sind immer teuer!
-
Martin Richter schrieb:
_matze schrieb:
http://msdn.microsoft.com/de-de/library/w2fhc9a3(VS.80).aspx
Diese Methode kostet aber bei komplexen Programmen einiges an Perfomance, Data-Breakpoints sind immer teuer!
Das war auch eher für den einmaligen Gebrauch gedacht. Aber gut zu wissen. Alles, was Zeit kostet, ist bei uns tödlich...
-
Martin Richter schrieb:
_matze schrieb:
http://msdn.microsoft.com/de-de/library/w2fhc9a3(VS.80).aspx
Diese Methode kostet aber bei komplexen Programmen einiges an Perfomance, Data-Breakpoints sind immer teuer!
lol, Martin
Die BPs werden doch nicht mit ausgeliefertIch hätte gerne eine Flasche Pommes und 2 kg Data Breakpoints bitte
-
hustbaer schrieb:
lol, Martin
Die BPs werden doch nicht mit ausgeliefertNe! Das nicht, aber wnen ich auf die 13456 Allokation warte und man bedenkt, dass hier für jede Allokation ein Data-BP ausgelöst wird, dann ist es bei weitem schneller die Break-Variable im Code zu setzen.
Und auch das geht per Watch Window zur Not.
-
Wo ist da ein Data-BP?
Du guckst bloss nicht richtig
-
hustbaer schrieb:
Du guckst bloss nicht richtig
Du hast recht... Ich bin urlaubsreif...
-
Martin Richter schrieb:
Du hast recht... Ich bin urlaubsreif...
Jo ich auch
