Wie zuverlässig ist der MemoryLeak-Report von FastMM?

[Nuclear-Ping]

Grüße,

folgende Situation in unserer Anwendung:

- FastMM 4.78 mit FullDebugMode, LogMemoryLeakDetailToFile
- TaskManager zum überprüfen
- 17MB Speicherauslastung wenn der Sende-Assistent angeworfen wird
- Zum Testen hab ich die Sende-Listen (die auf dem Bildschirm angezeigt werden) mal schön vollgepackt mit 300-600 Einträgen, fast alle mit Bildern und anderen Symbolen
- Je nach Liste steigt die Auslastung während der Sendung auf 170MB bis 440MB
- Nach der Liste gibt er allerdings nur bis auf 24-28MB wieder frei, das schaukelt sich auch weiter hoch bis 38MB, von Anfangs 17MB beim Start.

Ich hab nun das meiste was aus der Log-Datei vom FastMM nachvollziehbar ist bereinigt. Jetzt sind nur noch die Meldungen da, die ich nicht nachvollziehen kann und die ich auch bekomme, wenn ich die Software nur starte und gleich wieder schließe. Also eher irrelevant:

Zitat:

Ein Speicherblock hat Speicher verloren. Die Größe ist: 20

Aufrufstack, von wem der Block momentan belegt wird (Rücksprungadressen):
402A9F [System][@GetMem]
4041CF [System][TObject.NewInstance]
404596 [System][@ClassCreate]
404204 [System][TObject.Create]
40AD20 [FastMM4][DebugFreeMem]
5AD508 [DesignEditors.pas][DesignEditors][RegisterPropertyEditor][1804]
5A9E83 [DesignIntf.pas][DesignIntf][RegisterPropertyEditor][1088]
5AF995 [CompInfo.pas][CompInfo][CompInfo][349]
404CD8 [System][InitUnits]
404D3F [System][@StartExe]

Der Block wird momentan für eine Objektklasse benutzt TList

Wenn ich den Sende-Assistent eine Weile laufen lasse, schaukelt er sich beim freigegebenen Speicher halt immer weiter hoch. Wie weit hab ich jetzt noch nicht festgestellt, da ich bei den 38MB zuletzt abgebrochen und weiter rumgesucht hab. Im Code kann ich aber nichts mehr finden - und FastMM zeigt mir auch keine weiteren Leaks an.

Meine Frage nun: Wie zuverlässig ist FastMM in dieser Hinsicht? "Übersieht" er irgendwas? Oder warum zeigt mir der TaskManager nach jeder Liste mehr Speicherverbrauch an? :gruebel:

[Bernhard Geyer]

Guckst du hier.
Best FullDebugMode kann er nicht alles freigeben da er sonst die verwendung von freigegebenen Speicherbereichen nicht erkennen könnte.

[Nuclear-Ping]

Ah, danke. Mal testen. :coder2:

[Nuclear-Ping]

Hab die Schalter entfernt, die DCUs und die .exe gelöscht, Projekt neu erzeugt.

Start der Sendung mit 14MB, paar Listen laufen lassen, Stop gedrückt, 20MB. FastMM sagt das übliche.

Ist das "Overhead", "Cache" oder wo kommen die 6MB her? Und vorallem wie erklär ichs dem Chef? :mrgreen:

[edit]
Ups, sry für Doppelpost. :stupid:
[/edit]

[xaromz]

Hallo,

auch eine Frage: warum kompilierst Du "DesignEditors" in ein Programm, obwohl das die Lizenz verbietet? Oder war das unter D6 noch nicht so?

Gruß
xaromz

[Nuclear-Ping]

Wat? :gruebel:

[Nuclear-Ping]

So ... Hab das Senden jetzt die ganze Nacht mit diesen großen Listen und dem ausgestellten Debug-Mode vom FastMM laufen lassen. Zwischendurch hab ich im Task-Manager immer mal wieder reingeschaut und gesehen, dass er sich kontinuierlich hochschaukelt. Irgendwann gegen 22°° warens dann bei über 300MB - von Anfangs 12MB - die er nach jeder Liste an Speicherauslastung hinterlassen hatte.
Und heute früh - bzw grad eben - rief Chef an und er meinte die Software sei einfach aus. Keine Fehlermeldung, kein garnix, einfach aus.

Und FastMM schweigt ... er meint tatsächlich da seien keine Memory Leaks. Was ist da los?! :gruebel:

[Bernhard Geyer]

Hast du evtl. GDI-Ressourcen-Lecks? Da kann FastMM und die dortigen Checkmöglichkeiten nix ausrichten da die dortigen Ressourcen nicht unter seiner Kontrolle liegen. Hier wäre z.B. AQTime angesagt. Dort gibt es einen entsprechenden Ressource-Profiler.

[Nuclear-Ping]

Sorry für die Frage, aber wie find ich das raus, ob ich GDI-Resource-Leaks hab?

Saug mir grad die Trial von AQTime.

[Dax]

Zitat:

Zitat von Nuclear-Ping

Sorry für die Frage, aber wie find ich das raus, ob ich GDI-Resource-Leaks hab?

Der Taskmanager hat eine Anzeige für GDI-Handles - wenn die immer steigt, hast du ganz sicher Leaks.