FastMM Memory Leaks : Lesen und verstehen von Stacktrace

[Zacherl]

Zitat von taveuni:

Dann könnten es höchstens Windows DLL's sein. Andererseits - wohl kaum? Hmhh.. Ich bin ratlos.

Wäre für mich aber auch die einzige Erklärung. Gibt, selbst wenn man von den direkten Varianten (VirtualAlloc, LocalAlloc, GlobalAlloc, HeapAlloc, etc.) absieht, enorm viele WinAPIs, die Speicher alloziieren können.

Bei FormatMessage mit dem FORMAT_MESSAGE_ALLOCATE_BUFFER Flag muss man am Ende beispielsweise selbst einmal LocalFree callen.

Wenn du mit Inline Hooks vertraut bist, könntest du einfach mal die genannten APIs hooken und dann jeweils auch die Rücksprungadresse vom Stack loggen. Eventuell findest du ja darüber den Übeltäter.

[Der schöne Günther]

Inwiefern können denn einem hier Profiler wie AqTime weiterhelfen? Sich mal ein paar Methoden rauspicken und schauen, wie viel Speicher bei Methodeneintritt und wie viel nach Verlassen noch da ist?

(Inwiefern das bei starkem Multithreading aussagekräftig sein kann?)

[pertzschc]

Zitat von taveuni:

Einverstanden. Aber dann müsste die Anzahl Instanzen im memory.log von FastMM doch hochgezählt werden. Und das ist eben nicht der Fall!

Kannst Du den Quellcode Deines Service posten? Irgendwo passiert es dort, auch wenn der FastMM es nicht mitbekommt. Oder wie vermutet ausserhalb (DLL)...
Christoph

[taveuni]

Zitat von pertzschc:

Kannst Du den Quellcode Deines Service posten? Irgendwo passiert es dort, auch wenn der FastMM es nicht mitbekommt. Oder wie vermutet ausserhalb (DLL)...
Christoph

Leider nein. Auszüge davon ja - aber das ist sowieso sinnfrei. Glaubst Du - Du könntest nur durch Code Review das Problem erkennen? Ich habe schon mehrere meiner Meinung nach kritische Vorgänge isoliert (so a la Unittest) und diese unabhängig getestet. Ohne Ergebnis. Grob umrissen läuft es so:
- Es gibt einige Threadpools
- Ein Pool holt einzelne Images von Netzwerkkameras via HttpRequest
- Beim beenden des Jobs wird ein Objekt erzeugt in welchem ein TJpegImage und ein TBitmap32 erzeugt wird diese beiden Assignen das OriginalImage des HttpRequests.
- Das Originalimage wird freigegeben.
- Im Workerthread der Objekterkennung werden nun wilde Sachen gemacht. Am Ende werden die beiden erzeugten Objekte auch wieder freigegeben.

Da kann es sowieso nicht liegen da es HD Bilder sind und der Effekt nur mit 64 Kameras im 3 Sekunden Intervall überhaupt in nützlicher Zeit erkennbar ist. In einem anderen Service logge ich den Gesamtspeicherverbrauch des betroffenen Services. Ich sehe das ein steigen des Memorys Z.B in fünf Minuten schrittweise von 86 auf 89MB. Dann nächste Messung 87 - nach 5 Minuten schrittweise auf 92. Nächste Messung 89.... So geht das rauf und runter. Nur in der Tendenz leider rauf.

Zitat von Zacherl:

Wenn du mit Inline Hooks vertraut bist, könntest du einfach mal die genannten APIs hooken und dann jeweils auch die Rücksprungadresse vom Stack loggen. Eventuell findest du ja darüber den Übeltäter.

Leider momentan (noch) nicht. Kann es sein dass ich mit AQ Time weiterkäme? Wobei das ja preislich für dieses eine Ding.. Andererseits wenn ich Tage und Wochen aufwende....

[Zacherl]

FastMM kann ja logischerweise nur Memory Manager interne Speicherreservierungen loggen, sprich: GetMem, FreeMem, New, Dispose und so weiter. Deshalb bin ich mir zu 99% sicher, dass irgendwo per WinAPI direkt Speicher alloziiert wird.

Es gibt doch bestimmt noch massenhaft "externe" Tools, welche die genannten WinAPIs überwachen und profilen können (Das vielleicht: http://winleak.sourceforge.net/).

[Dejan Vu]

Welche Windows Resourcen werden alloziiert? Google mal nach MemProof 0.948, das ist noch umsonst und könnte diesbezüglich Fragen beantworten (wenn FastMem das nicht macht)

Wäre es denkbar, das die Threads abbrechen und deshalb 'am Ende' keine Bilder freigegeben werden. Manchmal zumindest. Natürlich müsste man das in FastMem sehen, aber ....

[taveuni]

Leider scheinen weder WinLeak noch memproof mit dem 64bit Betriebssystem klarzukommen.

[Dejan Vu]

Immer dieses 64bit

[Der schöne Günther]

Und jetzt?

[taveuni]

Ich habe per Zufall (vielleicht) etwas gefunden. Der Service läuft jetzt beim Kunden. Ich melde mich morgen wieder. Wenn es das war möchte ich dann von Euch wissen weshalb.