Speicher freigegeben?

[MicMic]

Hallo,

gibt es eigentlich eine Möglichkeit in Delphi (habe Delphi 10) oder evtl. ein Tool um zu überprüfen, ob man korrekt alles an Speicher wieder freigegeben hat, wenn die programmierte Anwendung wieder beendet wird? Gruß Michael

[DieDolly]

Beispielsweise das hier in die dpr-Datei packen

Delphi-Quellcode:

{$IFDEF DEBUG}
 ReportMemoryLeaksOnShutdown := True;
{$ENDIF}

Ich persönlich packe das in IFDEF DEBUG denn dann brauche ich mir beim Wechsel von Debug auf Release keine Gedanken zu machen, ob ich diese Zeile kommentiert habe oder nicht.
Es gibt aber auch bessere Möglichkeiten. Ich glaube eine davon heißt MadExcept. Die delphieigene Variante mit ReportMemoryLeaksOnShutdown ist aber auch gut und für Amateure absolut ausreichend.

[hoika]

Hallo,
du verwechselst MadExcept mit FastMM4.

[API]

madExcept erkennt auch Memory Leaks etc.

Zitat:

madExcept is also able to find memory leaks, resource leaks and buffer overruns for you.

[MicMic]

Zitat:

Zitat von DieDolly (Beitrag 1407457)

...Die delphieigene Variante mit ReportMemoryLeaksOnShutdown ist aber auch gut und für Amateure absolut ausreichend.

Ich bin doch Profi aber ich versteh trotzdem nix :)
Inzwischen hab ich gelesen, dass mit diesem "ReportMemoryLeaksOnShutdown" vieles nichts gefunden wird... z.B. so Sachen wie API Zeugs.

Ich dacht, dass ist alles einfacher. So auf die Art...bei Programmstart hab ich 4000 Byte Speicher frei und nach Programmende 3999 Byte. Also ist irgendwo 1 Byte nicht freigegeben worden. So in der Art hab ich's mir vorgestellt :)
MadExcept in Google = Englisch... ne, ich will nicht wieder neues lernen :)

Ich geh mal schön mein Programm durch... ist wohl die beste Variante :) Danke für die Infos von Euch.

Michael

[Aviator]

Du kannst auch das große FastMM4 benutzen und FullDebugMode setzen. Dann erhälst du eine Log-Datei mit StackTrace wo du genau siehst wo der Speicher angefordert wurde.

Und mir hat ReportMemoryLeaksOnShutdown bisher in 99% der Fälle ausgereicht. Nur zweimal musste ich auf die große Variante umsteigen weil ich einen Fehler absolut nicht gefunden hatte.

[Bernhard Geyer]

Am besten die aktuelle Version von FastMM ziehen (https://github.com/pleriche/FastMM4).
Ist ihr "Geld" wert. Die in Delphi eingebaute Version ist etwas "abgespeckt".

[Maekkelrajter]

Ich habe mir jetzt auch mal FastMM vonhttps://github.com/pleriche/FastMM4 installiert bzw. in mein aktuelles Projekt integriert. Es läßt sich zwar auch mit der Option

Delphi-Quellcode:

{$define FullDebugMode}

fehlerfrei compilieren, aber leider bekomme sofort nach dem Start ich eine seltsame Fehlermeldung, obwohl die Unit FastMM4.pas an erster Stelle der Uses-Liste steht (s. Screenshot) :(
Was mache ich da falsch??

[Stevie]

Stoppunkt in SysGetMem und SysAllocMem setzen (zu finden in GetMem.inc) und schauen, wer da rein stiefelt bevor die Meldung kommt.

[Maekkelrajter]

Zitat:

Zitat von Stevie (Beitrag 1407707)

Stoppunkt in SysGetMem und SysAllocMem setzen (zu finden in GetMem.inc) und schauen, wer da rein stiefelt bevor die Meldung kommt.

Diesem Vorschlag hätte ich vor ein paar Tagen noch nicht folgen können, alldieweil ich nur die 'Starter' - Edition besaß, mit der Debuggen im Quelltext von 'System' mangels desselben nicht möglich war. Mit der Community-Edition, die ich natürlich sofort am 18.7. heruntergeladen und installiert habe, klappt das natürlich. Dabei zeigte sich, dass 'System' (vermutlich bei der Initialisierung) Speicher alloziert, bevor die Initialisierung der Units in der .dpr beginnt.(s. Grafik)
Das führt eben dazu, dass FastMM sich sofort mit einer Fehlermeldung verabschiedet.
Hier https://www.delphipraxis.net/194755-...elphi-7-a.html ist genau dieses Problem beschrieben. Die dort gefundene Lösung kommt ja leider für mich nicht in Betracht, da ich die Quelltexte ja nicht verändern darf :(
Im Grunde genommen benötige ich das 'große' FastMM auch nicht so dringend, solange ich mit der 'ReportMemoryLeaksOnShutdown' - Option überhaupt keine Memory - Leaks gemeldet bekomme.
BTW, die Community-Edition ist wirklich eine feine Sache! So komme ich endlich mal zu einem 'richtigen' Delphi, obwohl ich vermutlich auch in Zukunft nur einen kleinen Teil der Features nutzen werde. Aber schon allein die Verfügbarkeit der Sources ist ein enormer Gewinn!

Gruß Maekkelrajter

[Stevie]

Der callstack sieht nach dem Laden von Resourcestrings aus, das sollte aber weit nach dem initialization Block von FastMM4.pas passieren.

Mehr kann ich ohne genauere Informationen nicht sagen.

[Maekkelrajter]

Zitat:

Zitat von Stevie (Beitrag 1408388)

Der callstack sieht nach dem Laden von Resourcestrings aus, das sollte aber weit nach dem initialization Block von FastMM4.pas passieren.

Genau das ist aber offensichtlich nicht der Fall. Es wird noch munter weiter alloziert, bevor die Abarbeitung des 'initialization' - Blocks von FastMM beginnt.
Da werden z.B. von System.SysUtils.GetFormatSettings TFormatSettings.GetEraInformation, TFormatSettings.GetDayNames, TFormatSettings.GetMonthNames usw. aufgerufen. Das kann also überhaupt nicht funktionieren. Womöglich gibt es eine neuere Version von FastMM, die das berücksichtigt (ich habe V4.992).

[Stevie]

Zitat:

Zitat von Maekkelrajter (Beitrag 1408409)

Zitat:

Zitat von Stevie (Beitrag 1408388)

Der callstack sieht nach dem Laden von Resourcestrings aus, das sollte aber weit nach dem initialization Block von FastMM4.pas passieren.

Genau das ist aber offensichtlich nicht der Fall. Es wird noch munter weiter alloziert, bevor die Abarbeitung des 'initialization' - Blocks von FastMM beginnt.
Da werden z.B. von System.SysUtils.GetFormatSettings TFormatSettings.GetEraInformation, TFormatSettings.GetDayNames, TFormatSettings.GetMonthNames usw. aufgerufen. Das kann also überhaupt nicht funktionieren. Womöglich gibt es eine neuere Version von FastMM, die das berücksichtigt (ich habe V4.992).

Wenn das der Fall ist, dann ist FastMM4 nicht die erste Unit, die initialisiert wird.
Setz mal nen Haltepunkt in System._StartExe, InitUnits und FastMM4.initialization. Da muss er vor der Meldung vorbei kommen.

Außerdem kann ein Haltepunkt in InitUnits an der Stelle wo

Delphi-Quellcode:

TProc(P)();

steht, helfen, zu sehen, welches die Units sind, die gerade initialisiert werden, dort einfach dann mit F7 reinspringen.

Dann lies dir nochmal den letzten Paragraph in der Meldung aus deinem ersten Screenshot durch und mach dir Gedanken, ob das nicht der Fall ist bei dir - alles andere ist :glaskugel:

[Maekkelrajter]

Zitat:

Zitat von Stevie (Beitrag 1408388)

Außerdem kann ein Haltepunkt in InitUnits an der Stelle wo

Delphi-Quellcode:

TProc(P)();

steht, helfen, zu sehen, welches die Units sind, die gerade initialisiert werden, dort einfach dann mit F7 reinspringen.

Das war der entscheidende Tip. :thumb:
So konnte ich feststellen, dass vor dem 'initialize' von FasMM4.pas noch SHFolder.pas initialisiert wurde, weil SHfolder in der uses-Klausel im 'implementation'-Teil von FasMM4 aufgeführt ist. Da war es relativ leicht, (vorläufige) Abhilfe zu schaffen. Die 3 Deklarationen, die FastMM4 aus SHFolder benötigt, habe ich kurzerhand in FastMM4.pas eingefügt und SHFolder aus der uses - Liste entfernt. Schon war die Fehlermeldung verschwunden und FastMM lief, was sich auch (erwartungsgemäß) durch einen erheblichen Performanceverlust in der IDE bemerkbar machte.
Es ist mir allerdings ein Rätsel, wie FastMM in der Original-Fassung überhaupt irgendwo funktionieren kann??

Edit:
Die Lösung des Rätsels: FastMM4 hatte eine zufällig im Suchpfad liegende uralte Version von SHFolder.pas eingebunden. Nachdem ich den alten Mist samt .dcu entsorgt hatte, klappte alles ohne Änderung. Nunmehr wird die aktuelle WinAPI.ShFolder.pas eingebunden, und damit läuft's nun! :-D