ReportMemoryLeaksOnShutdown:= True – Deutung der Speicherleck-Meldung

[Andreas13]

Habe den Fehler gefunden! :-D
Eine MPAF-Variable (Multi Precision Arithmetic Float) hatte ich versehentlich zweimal initialisiert: Einmal "normal", und ein weiteres Mal bedingungsabhängig mit einer höheren Bit-Präzision… :wall:

Allerdings habe ich (erneut) eine für mich fatale Beobachtung gemacht: FastMM4 korrumpiert mehrere Inhalte meiner zahlreichen MPAF-Variablen. Aus numerischen Werten werden manchmal string-ähnliche Hieroglyphen und die Berechnung stürzt im besten Fall ab, im schlimmeren Fall sind "nur" die Ergebnisse völlig falsch. Deshalb hatte ich FastMM4 bereits 2019 aus meinen Projekten "verbannt", wie ich es gerade feststellen konnte. :(

Mein Fazit:
Geholfen hat mir in diesem letzten mühseligen Schritt der Speicherleck-Suche leider weder FastMM4 noch madExcept so richtig.

Danke für Eure Hilfe & Beiträge ! :thumb:

Viele Grüße
Andreas

[himitsu]

Eigentlich sollte das nicht passieren.

Könnte eher sein, dass diese Komponente außerhalb/hinter den reservierten Speicher schreibt (Bufferoverrun)
und es sich dabei mit FastMM in die Quere kommt, welches davon ausgeht, dass jeder nur in seinen Speicher schreibt. :angle:

[mjustin]

Zitat:

Zitat von Andreas13 (Beitrag 1508594)

Geholfen hat mir in diesem letzten mühseligen Schritt der Speicherleck-Suche leider weder FastMM4 noch madExcept so richtig.

Vielleicht hat sich das inzwischen gebessert, da es eine neue Version gibt: FastMM5

https://github.com/pleriche/FastMM5

Delphi XE3 and later

[Andreas13]

Hallo,

Zitat:

Zitat von mjustin (Beitrag 1508599)

Vielleicht hat sich das inzwischen gebessert, da es eine neue Version gibt: FastMM5 https://github.com/pleriche/FastMM5

Lieder ist FastMM5 auch nicht besser, s. Beispiel:

Code:

  ?ÏÑ♥    ?ÏÑ♥    ?ÏÑ♥    ?ÏÑ♥    ?ÏÑ♥    ?ÏÑ♥    ?ÏÑ♥  
  x = ?ÏÑ♥62543041E+199999903
  t =  ?ÏÑ♥
  a[1] =  ?ÏÑ♥3997329E+199999951
  a[2] = ?ÏÑ♥23997329E+199999951
  a[3] =  ?ÏÑ♥3983403E+199999904

Zitat:

Zitat von himitsu (Beitrag 1508597)

Eigentlich sollte das nicht passieren.
Könnte eher sein, dass diese Komponente außerhalb/hinter den reservierten Speicher schreibt (Bufferoverrun) und es sich dabei mit FastMM in die Quere kommt, welches davon ausgeht, dass jeder nur in seinen Speicher schreibt.

Unser Gammatester war ein wahrer Pointer-Akrobat und trickst den Speichermanager von FastMM auch noch posthum aus... :)

Grüße
Andreas