Hallo again,
vom ursprünglichen Speicherleck (24 x 68 Bytes) konnte ich mit FastMM4 auf Anhieb 21 Fragmente beheben. Die restlichen 3 x 68 Bytes sind aber sehr hartnäckig:
This application has leaked memory. The small block leaks are (excluding expected leaks registered by pointer): 53 - 68 bytes: Unknown x 3
und ich kann sie leider immer noch nicht genau aufspüren.
Mir kommt bereits die erste (s.
Bild-1.jpg) der drei Meldungen etwas merkwürdig vor:
1):
415802 [FastMM4.pas][FastMM4][CalculateHeaderCheckSum$qqrp29Fastmm4.TFullDebugBl ockHeader][9143]
Wieso erscheint auch FastMM4 in dieser Liste? FastMM4 steht bei mir in meiner uses-Liste an der ersten Stelle:
Delphi-Quellcode:
uses
{$IfDef DEBUG}
FastMM4,
{$EndIf }
System.SysUtils,
Winapi.MMSystem,
PDBiA_Type,
PDBiA_Mathe
Hat etwa auch FastMM4 einen "eigenen" Speicherleck?
2):
5D3A35 [MP_Real.pas][mp_real][mpf_initp3$qqrr17Mp_types.mp_floatt1t1i][3756]
MP_Real.pas steht gar nicht in der uses-Liste des Projektes, sondern in der von PDBiA_Mathe.pas.
Im ersten der drei Abschnitte der Fehlerberichte fehlt die Zeile
5FDC1D [PDBiA_Mathe.pas][PDBiA_Mathe][MPAF_Init$qqrr17Mp_types.mp_floatt1t1i][19140], in den darauffolgenden zwei ist sie bereits (korrekterweise) vorhanden (s.
Bild-2.jpg). Den „memory dump” habe ich hier weggelassen: Ich kann damit leider gar nichts anfangen, genau so wie mit der allocation number.
Allerdings bemängelt auch
madExcept 3 gleichgroße Speicherlecks, nur mit einer viel längeren Liste von Procedure-Aufrufen.
3):
Merkwürdig ist auch, daß in der Übersichtsmeldung stets von "53 - 68 bytes" die Rede ist, im Detail-Bericht es aber immer genau 68 Bytes sind. Was stimmt jetzt? (Die vermutliche Speicherleck-verursachende Routine
mpf_initp3(..) belegt eigentlich nur 3-mal 24 = 72 Bytes.)
Vielleicht hat jemand von Euch noch eine weitere rettende Idee?
Danke & Grüße
Andreas