Hallo Community,
wegen einer Verständnisfrage wende ich mich diesmal an Euch:

Ein mysteriöser Speicherleck (tritt merkwürdigerweise nur auf, wenn ich einige Vektoren und Matrizen mit der Länge n = 4 bzw. 4 x 4 dimensioniere, nicht jedoch, wenn n = 6 oder höher ist. ) liefert die Meldung (s. Bild), wenn: ReportMemoryLeaksOnShutdown:= True; .
Auch madExcept hilft mir leider nicht beim Finden meines Fehlers: Seine Meldungen kann ich noch weniger deuten und auswerten.

Daher die Frage:
Was bedeuten die Zahlen in der Fehlermeldung konkret?

- Habe ich Speicherlecks in Höhe von 61 bis 68 Bytes insgesamt 24-mal?
- Oder etwas ganz anderes?

Ich möchte eigentlich wissen, um wieviel Bytes es sich insgesamt handelt, um für das Projekt eventuell eine "vorläufige Bagatellgrenze" zu definieren, da ich nicht noch mehr Zeit mit der Speicherleck-Suche verplempern möchte...

Danke & viele Grüße
Andreas

Ja zumindest ich habe das auch immer so interperetiert. Du hast 24 nicht freigegebene Memoryblöcke mit einer Grösse von 61-68 Bytes. Für die genauere Fehlersuche nutze ich dann die Vollverison des FastMM4 und habe da diverse Debug Optionen aktiviert, mit dene alles viel detailierter in ein Logfile geschrieben wird.

Die Vollversion findest du hier und beachte dabei insbesondere die Datei FastMM4Options.inc: https://github.com/pleriche/FastMM4

Als Ergänzung dazu:

Schau mal bitte in die FastMM4Options.inc, sie enthält diverse Schalter, die bei der Fehlersuche durchaus hilfreich sein können.

Da wäre u. a.

{$define FullDebugMode}

und desweiteren

{$define LogErrorsToFile}

Damit bekommst Du etwas ausführlichere Informationen in eine Datei geschrieben.

Ein Auszug aus 'nem Programm von mir:

markieren

Code:

A memory block has been leaked. The size is: 12

This block was allocated by thread 0x6E0, and the stack trace (return addresses) at the time was:
402EAC [IdCharsets][IdCharsets][@GetMem]
4045EF [IdGlobalProtocols][IdGlobalProtocols][QuoteSpecials]
40498A [IdHeaderCoder2022JP][IdHeaderCoder2022JP][@ClassCreate]
4A59D6 [..\Indy10\Lib\Core\IdThreadSafe.pas][IdThreadSafe][TIdThreadSafe.Create][251]
49750B [..\Indy10\Lib\Protocols\IdAuthentication.pas][IdAuthentication][RegisterAuthenticationMethod][157]
4A5B65 [..\Indy10\Lib\Core\IdThread.pas][IdThread][IdThread][730]
4050EB [IdSSLOpenSSLHeaders][IdSSLOpenSSLHeaders][EVP_PKEY_meth_free]
405153 [IdSSLOpenSSLHeaders][IdSSLOpenSSLHeaders][EVP_PKEY_decrypt]
407CD7 [SysInit][SysInit][..]
683A14 [lw:\Verzeichnis\Programmname.dpr][Programmname][Programmname][142]
7C92B084 [Unknown function at RtlUnicodeStringToInteger]

The block is currently used for an object of class: TIdThreadSafeInteger

The allocation number is: 297

Current memory dump of 256 bytes starting at pointer address 7FAA4750:
(* hier folgt dann ein Hex-Dump *)

Die Zahlen rechts in den eckigen Klammen dürften die Zeilenzahl in der Quelltextdatei sein, an der das von FastMM festgestellte Speicherleck seinen Ursprung hat.

Bei dem Progamm handelt es sich um 'ne olle Klamotte mit Delphi 7 und Indy10 erstellt.

Hallo,
vielen Dank für Eure Tipps!
Ich glaube mit FastMM4 bereits eine heiße Spur gefunden zu haben.
Viele Grüße
Andreas

An der Stelle auch für spätere Leser noch ein Hinweis:
Zum Beispiel bei anonymen Methoden ist es manchmal nicht möglich ein (sehr kleines) Speicherleck zu verhindern. In solch einem Fall kannst du mit RegisterExpectedMemoryLeak das Speicherleck ausblenden, so dass es nicht mehr in der Liste auftaucht.

Danke, Sebastian!
Es stellt sich für mich die neue Frage, ob FastMM4 alleine genügt und ob ich daher madExcept deinstallieren sollte? Dessen umfangreiche "leak reports" konnte ich leider weder deuten, noch haben sie mich auf eine heiße Spur gebracht.

Grüße, Andreas

Ich nehme immer madExcept, da bekomme gleich einen "schönen" Callstack.
Was davon kannst Du nicht deuten?

Zitat von jaenicke:

(..)Zum Beispiel bei anonymen Methoden ist es manchmal nicht möglich ein (sehr kleines) Speicherleck zu verhindern.(..)

Kann ich mir grad nicht vorstellen. Was wäre da ein Beispiel?

@Freimatz
Hallo,
FastMM4 sagte mir direkt, welche Routine den Speicherleck verursacht hat. Der viele Seiten lange Callstack von madExcept war für mich leider eher verwirrend. Auch war dort kein konkreter Hinweis für die eigentliche Ursache, oder ich habe diese vor lauter Bäumen nicht sehen können...

Die zwei madExcept Uralt-Videos auf der Homepage passen überhaupt nicht zur jetzigen Version und sind leider überhaupt keine Hilfe. Auch vermisse ich eine Art Tutorium für madExcept-Anfänger.

Grüße, Andreas

Ich habe vor langer Zeit auch mal MadExcept genutzt, aber heute nutze ich den nicht mehr. Zur Fehlersuche reicht mir FastMM4 völlig aus. Das fertige Programm kompiliere ich dann mit dem Delphi internen FastMM4.