Wie kann man ein "halbes" Memory-Leak finden?

[Phoenix]

Genau das wollte ich eigentlich nicht lesen :pale:

[Sherlock]

Ich habe aber bestimmt unrecht :) Ist fast immer so, vor allem wenn ich mir absolut sicher bin, daß ich recht habe ;)

Sherlock

[alzaimar]

Ich mache z.B. Folgendes:
1. Jedes Objekt einer Klasse bekommt eine bestimmte ID (Zähler), die ID ist ein privates Feld.
2. Ich schreibe die ID in eine TList (oder das Objekt selbst, egal).
3. Im Destruktur entferne ich das Object/ID wieder aus dieser Liste.
4. Im IOnitikalization-Abschnitt der Unit wird die Liste instantiiert
5. Im Finalization-Abschnitt schaue ich nach, ob die Liste leer ist....
6. Wenn die Liste nicht leer ist, dann ....
7. Nehme ich mir die erste ID, die nicht freigegeben wurde und ...
8. Setze nun im Konstruktor einen Breakpoint mit der Bedingung (ID=12345, 12345=ID des nicht freigegeben Objektes)
9. Nun warte ich, bis dieses Objekt erzeugt wird und kann im Stack nachschauen, wieso ich so blöd war, und dieses Objekt nicht freigegeben habe.
10. Das Das mache ich bis die Liste leer ist. FERTIG.

So, damit Du das aber nicht für jede Klasse machen musst, patchst Du einfach die Classes.Pas (da ist doch TObject drin, oder?) und bohrst kurz mal TObjects.Create und TObjects.Destroy auf.

[shmia]

Das scheint mir eher ein Speicher Fragmentierungsproblem zu sein.
Die Anwendung fragt beim Memory Manager nach Speicher in mehr oder weniger kleinen Blöcken.
Der Memory Manager holt sich den Speicher in grossen Blöcken (~ 1 MByte) mit VirtualAlloc() bei Windows
und verwaltet diese dann, indem er kleinere Blöcke der Anwendung zuteilt.

Angenommen, du hast folgenden Code:

Delphi-Quellcode:

for i := 1 to 1000 do
   astring := astring +'*';

dann wird der String immer länger und benötigt immer mehr Speicher.
Es wird immer wieder neuer Speicher angefordert und es bleiben jede Menge unbenützte Speicherblöckchen zurück.
Ein intelligenter Memory-Manager könnte die kleinen Blöckchen zu einem grossen Block zusammenfassen (Stichwort: Garbage collection ).
Der Delphi MM ist nicht so schlau und gibt Blöcke, die er in kleine Häpchen aufgeteilt hat nicht mehr an Windows zurück.

Man sollete also:
* Objekte in umgekehrter Reihenfolge freigeben als wie man sie erzeugt hat
* AnsiStrings und dynamische Arrays nicht Elementweise vergrössern
* statt dynamische Arrays, die häufig in der Grösse verändert werden die Klasse TList und deren Nachkommen verwenden.

Delphi-Quellcode:

// das wäre ein Beispiel, wie man es nicht machen sollte
SetLength(dynamic_array, Length(dynamic_array)+1);

[himitsu]

Und sicher, daß dieses MML im Memorymanager liegt?

Wenn ich z.B. am Memorymanager vorbei direkt bei Windows Speicher anfordere, dann gibt es nette Nebenwirkungen.

Viele MML-Test schlagen dann fehl, da sie vorzugsweise nur den Memorymanager überwachen, aber z.B. nicht VirtualAlloc ... wobei dann zwar ein MML vorhanden sein kann, aber es nicht erkannt wird.


Und dann gibt es noch das Problem der Speicherdefragmentierung ... da hat der Memorymanager dann viel Speicher zur Verwaltung angefordert, aber es wird nur ein Teil vom Programm verwendet ... der Rest liegt ungenutzt rum, was aber laut Definition kein Speicherleak ist.

[Dax]

Zitat:

Zitat von Phoenix

Hast Du irgendwie einen Ansatz, was für ein Aufwand das wäre sowas zu schreiben? Insbesondere wenn man (wie ich) keinen Plan davon hat wie man sich in das Memory-Management einhängt?

Nein, leider nicht. Allerdings sollte in der Hilfe etwas zu TMemoryManager (oder so ähnlich) stehen - das Ding ist ein Record mit mehreren Funktionszeigern, die Delphi intern für GetMem, FreeMem usw verwendet.

[himitsu]

und um eigene Funktionen zu setzen:

- mit GetMemoryManager die aktuellen Adressen auslesen und speichern
- mit SetMemoryManager die eigenen Funktionen übergeben

und in den eigenen Funktionen dann irgendwas machen und die Aufrufe an die alten (gespeicherten) Funktionen übergeben.

[hewy]

Hallo
Benutze doch mal FastMM. Kostet nichts und bringt dich ganz sicher weiter.
Dann poste den Log, und ich sage dir in welcher Zeile was aloziert wird das nicht wieder freigegeben wird.

Und so geht es:
In Datei FastMM4Options.inc von FastMM folgende Flags setzen:
{$define CheckHeapForCorruption}
{$define ClearLogFileOnStartup}
{$define EnableMemoryLeakReporting}

Im Delphi: in der dpr deiner Applikation.
program MeinProgramm;


uses
// >>>>>> Dies muss hier an erster stelle stehen
FastMM4,
idGlobal, IdThreadSafe, // for FastMM: registering expected leaks

Forms,
SysUtils,
Windows,
Classes,
Registry,

…

Im Delphi die Option vom Linker Include TD32 debug Info setzen und vollständig kompilieren. Die Applikation in der Delphi Umgebung betreiben, ein bischen überal hinklicken. Beim beenden wird eine Log Datei geschrieben.

Übrigens Memory leaks gibt es keine halben. In deinem falle handelt es sich ebenfalls um ein ganzes.

[Phoenix]

Zitat:

Zitat von shmia

Das scheint mir eher ein Speicher Fragmentierungsproblem zu sein.
[...]
Man sollete also:
[..]
* AnsiStrings und dynamische Arrays nicht Elementweise vergrössern
* statt dynamische Arrays, die häufig in der Grösse verändert werden die Klasse TList und deren Nachkommen verwenden.

Delphi-Quellcode:

// das wäre ein Beispiel, wie man es nicht machen sollte
SetLength(dynamic_array, Length(dynamic_array)+1);

Oha. :-(
Davon wird (in diesem Fall leider) an manchen Stellen exzessiver Gebrauch gemacht.

Also sollte ich vielleicht erstmal hier auf TList umstellen... Puuh.. das wird viel Arbeit.

Edit Nachtrag:
Nochmal @Hewy: Es gibt kein Leak. Alle Objekte, die irgendwann mal allokiert werden, werden auch wieder Freigegeben.
Blöderweise halt erst beim Beenden der Anwendung und nicht schon dann, wenn sie einfach nicht mehr benötigt werden.

Ergo: Es wird alles aufgeräumt. Sämtliche Tools wie FastMM & Eurekalog können kein Leak entdecken, weil eben im technischen Sinne keines existiert. Und ich denke nicht, dass FastMM meinen Code analysiert und mir aufzeigt, wo ich ein Objekt optimalerweise freigeben müsste, damit das nicht unnötig rumliegt.

Man.. ich würd mir so sehr eine Garbage-Collection wünschen.

Edit Nachtrag 2:

Würde sich das Fragmentierungs-Problem mit dem FastMM lösen?

[alzaimar]

Zitat:

Zitat von Phoenix

Würde sich das Fragmentierungs-Problem mit dem FastMM lösen?

Ein wenig. Verwendest Du COM? Ich hatte einmal mit einer komplexen COM-Library ähnliche Probleme und sie nicht in den Griff bekommen.

[klugscheiss]
Du kannst Deine dynamischen Arrays ruhig behalten, aber hier sieht man mal wieder, wie gut ordendliche OOP ist: So ein Array gehört gekapselt, damit man logische Operationen ('Einfügen eines Datensatzes mit eventueller Vergrößerung des Speichers') zentral implementieren kann. Dann hättest du einfach die Strategie des Speichervergrößerns ändern können. So musst du leider durch Deinen gesamten Code.
[/klugscheiss]
Das nicht als Verarsche für Dich, sondern als Beispiel, wieso OOP und Zentralisierung so wichtig ist.