Speicher aufräumen

[photor]

Hallo Forum,

ich habe die letzte Zeit ein neues Programm erstellt und dabei (um was neues zu lernen) ausgiebig mit Klassen, Listen und Generics hantiert. Das Programm ist relative schnell gewachsen und ich habe sicherlich an einigen Ecken noch schludrigen Code stehen (Funktion ging erstmal vor).

Nun braucht das Programm (aus der IDE gestartet) recht lange (ca. 7 bis 20 sek) vom Quit-Button-Press bis ich wieder in der IDE bin. Meine Vermutung ist, dass da noch einiges im Speicher aufgeräumt werden muss.

Meine Frage: gibt es eine Option oder ein Tool, dass mir hilft, Speicherlecks zu lokalisieren? Oder bleibt mir nur übrig, händisch zu schauen, wo eventuell Speicher händisch freigegeben werden muss und Speicher-Schutz-Blöcke drum rum zu bauen (werde ich sowieso noch machen).

Danke für Eure Tipps.

Ciao,
Photor

[m.fuchs]

Na klaro gibt es das. Schau mal hier: https://wiki.freepascal.org/heaptrc

[photor]

Danke. Das sieht doch schon mal ganz gut aus.

Ciao,
Photor

[Socke]

Nun braucht das Programm (aus der IDE gestartet) recht lange (ca. 7 bis 20 sek) vom Quit-Button-Press bis ich wieder in der IDE bin. Meine Vermutung ist, dass da noch einiges im Speicher aufgeräumt werden muss.

Spricht das nicht eher dafür, dass der Speicher (allgemeiner: Ressourcen) ordnungsgemäß aufgeräumt wird? Wenn du den Speicher nicht selbst frei gibst, wird das der Memory Manager auch nicht für dich tun.

[photor]

Spricht das nicht eher dafür, dass der Speicher (allgemeiner: Ressourcen) ordnungsgemäß aufgeräumt wird? Wenn du den Speicher nicht selbst frei gibst, wird das der Memory Manager auch nicht für dich tun.

Das spricht - meiner Meinung nach - dafür, dass da irgendwer den Speicher aufräumt, ja.

ich fürchte aber, dass das jemand tun muss (weil ich ja in der IDE weiter mache; vermutung Debugger), weil ich es nicht ordnungsgemäß getan habe (den Freiland-Test ohne IDE habe ich noch nicht gemacht).

Also von anderen Programmen kenne ich das so jedenfalls nicht.

Ciao,
Photor

[af0815]

Ich kenne diese verzögerung wenn Heaptrace eingeschalten ist. Das muss beim Beenden den Speicherbereich untersuchen. Faustregel bei mir ist, je schneller die IDE wieder bereit ist, umso weniger Probleme gibt es mit dem Speicher.

Bekommst du Meldungen von Heaptrace oder in die Kommandozeile oder lässt du in eine Datei schreiben ?!

[photor]

Moin,

ich habe jetzt mal heaptrc (nach Wiki) eingeschaltet/aktiviert. Im leakview zeigt sich auch was:

Code: Alles auswählen

Total Mem allocated: 4016928
Leaking Mem Size: 33423
Leaking Blocks Count: 699

ich denke, mein Verdacht war begründet: da muss ich noch kräftig suchen.

Genauer: die option -gh war sogar schon aktiviert, was vielleicht auch das verzögerte Beenden erklärt. Bloß in eine Datei wurde die Info noch nicht geschrieben. Dazu war dann noch der zusätzliche Code in der .LPR nötig. Die Ausgaben in der Datei bzw. die von heapview muss ich noch zu interpretieren lernen.

Vielen Dank bis hierher. wenn noch Fragen auftauchen, melde ich mich.

Ciao,
Photor

[Winni]

Hi!

Wenn heaptrace ne Menge Fehler findet, kann das echt dauern.

Besonders, wenn der Fehler tief im Source liegt, und so durch die rufenden Funktionen "durchgeschleppt" wird. Da kann es durchaus passieren, dass einem von heaptrc 10 Mal oder öfter eine Code-Zeile für ein und denselben Fehler angezeigt wird, die auf Schlag verschwinden, wenn man den Fehler beseitigt hat.

Bei dem ganzen Gehacke hat man dann endlich Zeit, sich ne Zigarette zu drehen ...

Winni

[Ich934]

Bei dem ganzen Gehacke hat man dann endlich Zeit, sich ne Zigarette zu drehen ...

Und wenn man nicht raucht?

Allerdings hab ich manchmal den Fehler auch nicht gefunden. In der Arbeit hab ich so ein Programm wo ich so einen Fehler habe. Mir wird zwar die Zeile im Hauptprogramm angezeigt, aber dort befindet sich ein Free. Manchmal wäre ich echt froh, wenn Pascal einfach etwas gesprächiger wäre.

[Winni]

Hi!

Ja - indeed. Ich hab mich manchmal auch schon blöd gesucht.

Wenn heaptrc auf "free" verweist:

Kann es sein dass Du das Object zweimal created hast??
Das war es mal bei mir mit einer BGRAbitmap.

Winni

[Ich934]

Kann es sein dass Du das Object zweimal created hast??
Das war es mal bei mir mit einer BGRAbitmap

Leider nicht. Nächste Woche noch mal genauer suchen...

[fliegermichl]

Normalerweise zeigt heaptrc doch an wo der Speicher allokiert wurde?

[Winni]

Hi!

Wie fies die Suche sein kann, zeige ich hier mal am Beispiel.

Ich hab eine selbst geschriebene Function BGRArotate90, die eine Spielkarte um 90 Grad dreht.
In der Function wird eine temporäre Bitmap namens tmp benutzt. Die gebe ich jetzt mal vorsätzlich nicht frei, um ein Leck zu erzeugen.

Der erste Verweis zeigt auf Zeile 325, die da lautet:

Code: Alles auswählen

back90 := BGRArotate90(back,true);

Dass nun der Fehler in BGRArotate90 steckt, geht aus dem Log von heaptrc nicht hervor.
Im Gegenteil: er zeigt auch noch die "unschuldigen" function an, die das Leck mit durchschleppen:

LOADKDEDECK, line 325 of skat1.pas
FORMCREATE, line 974 of skat1.pas
DOCREATE, line 939 of include/customform.inc
AFTERCONSTRUCTION, line 149 of include/customform.inc


Und hier nun der ganze Salat, der durch ein einziges vergessenes tmp.free von heaptrc erzeugt wird

Heap dump by heaptrc unit of /home/winni/skat/skat
3986 memory blocks allocated : 13037921/13045544
3983 memory blocks freed : 13000433/13008056
3 unfreed memory blocks : 37488
True heap size : 1376256
True free heap : 1338112
Should be : 1338192
Call trace for block $00007F0FB12A0D50 size 36864
$0000000000824EDD
$00000000007D2552
$00000000007DF035
$00000000007AF095
$00000000007D2006
$00000000007DEA7D
$00000000007AED7D
$00000000007AD9BA
$00000000007DE9E4
$00000000007AECE4
$00000000007AD97A
$00000000007AE12A
$00000000004646A6 LOADKDEDECK, line 325 of skat1.pas
$00000000004674AD FORMCREATE, line 974 of skat1.pas
$000000000044EE47 DOCREATE, line 939 of include/customform.inc
$000000000044CABD AFTERCONSTRUCTION, line 149 of include/customform.inc
Call trace for block $00007F0FB51489E0 size 144
$00000000007B56A9
$00000000007D1FEB
$00000000007DEA7D
$00000000007AED7D
$00000000007AD9BA
$00000000007DE9E4
$00000000007AECE4
$00000000007AD97A
$00000000007AE12A
$00000000004646A6 LOADKDEDECK, line 325 of skat1.pas
$00000000004674AD FORMCREATE, line 974 of skat1.pas
$000000000044EE47 DOCREATE, line 939 of include/customform.inc
$000000000044CABD AFTERCONSTRUCTION, line 149 of include/customform.inc
$0000000000455634 CREATE, line 3184 of include/customform.inc
$000000000045F955 CREATEFORM, line 2239 of include/application.inc
$000000000041F05E main, line 19 of skat.lpr
Call trace for block $00007F0FB134EA70 size 480
$00000000007B56A9
$00000000007D1FEB
$00000000007DEA7D
$00000000007AED7D
$00000000007AD9BA
$00000000007DE9E4
$00000000007AECE4
$00000000007AD97A
$00000000007AE12A
$00000000004646A6 LOADKDEDECK, line 325 of skat1.pas
$00000000004674AD FORMCREATE, line 974 of skat1.pas
$000000000044EE47 DOCREATE, line 939 of include/customform.inc
$000000000044CABD AFTERCONSTRUCTION, line 149 of include/customform.inc
$0000000000455634 CREATE, line 3184 of include/customform.inc
$000000000045F955 CREATEFORM, line 2239 of include/application.inc
$000000000041F05E main, line 19 of skat.lpr



Winni

[Epcop]

Gibt es in der Entwicklungsumgebung ein Tool, dass auf fehlende ".free" hinweißt? (o.ä.)
Damit könnte man doch einfacher solche lecks finden oder?!

[af0815]

Woher sollte ein Tool wissen, wo ein .Free benötigt wird ?

Das wäre nur eine Raterei, weil Objekte können an allen Stellen erzeugt bzw. ge-freed werden. Auch Kopien und Referenzen sind zulässig. Das würde dann so wie bei SQL funktionieren, einfache Sachen (wo ich das ganze nicht brauche) würden funktionieren. Wenn es komplizierter wird, so funktioniert die automatische Logik nicht.

Nein Heaptrace ist schon in Ordnung. NUR die meisten fangen OHNE die richtigen Debugeinstellungen an. Wenn ich ein Projekt hochziehe so gibt es ein paar fixe Sachen. Und dazu gehört, das ich einen Debug und einen Release Modus habe. Im Debug wird programmiert und dort auch gnadenlos heaptrace und die anderen Debugeinstellungen verwendet. Jedes Warning wird entweder im Code lokal deaktiviert (wenn ich genau weis warum) oder behoben. Damit schleicht sich schon mal kein schlechter Stil ein und kleine Fahrlässigkeiten fallen auf. Release ist dann vorbehalten, wenn es wirklich raus geht. Dort wird alles auf ein nötiges Mass zurückgefahren. Generell verwende ich auch den LazLogger und jede Exception (ob geplant oder ungeplant) lässt sich so zumindest erkennen, wenn die Kommandozeilenoption verwendet wird. Damit kann ich dann den Kunden mal ersuchen, das ganze mit der option LazLogger zu starten und kann erkennen, warum da ev. was schief läuft.

Konklusio: Wenn man am Anfang gleich konsequent ist, braucht man später weniger suchen