ReportMemoryLeaksOnShutdown:= True – Deutung der Speicherleck-Meldung

[Rolf Frei]

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.

[haentschman]

Hallöle...

Zitat:

Zur Fehlersuche reicht mir FastMM4 völlig aus

...einen Callstack per Mail geschickt vom User ist nicht notwendig?

[Rolf Frei]

Nein. Bei mir teste ich das Programm, nicht der Kunde. Wenn da mal was ist, sind das übersehene Kleinigkeiten, die mit einer genauen Anleitung wie es zum Fehler kommt, immer schnell behoben sind. Habe all die Jahre, seit denen ich mit Delphi programmiere (seit Delphi 1), noch nie einen Callstack benötigt.

Memoryleaks gibt es generell keine bei dem Kunden, dafür sorge ich schon zur Programmierzeit mit sauberem Coden (immer abgesichertes Erstellen und Freigeben von Objekten, etc.). Eine Anwendung die Memoryleaks produziert, wird garnicht erst an Kunden ausgeliefert, sondern vorher gründlich getestet und bereinigt.

[himitsu]

Nutzt du kein INDY/DataSnap? Da sind Speicherlecks drin.

Aber die bekam man nicht weg, also wurden sie einfach auf die Blacklist (RegisterExpectedMemoryLeak) gesetzt, damit sie niemanden stören.

[Rolf Frei]

Nein nutze weder DataSnap noch Indy. Für beides nutze ich 3rd Party Software.

Es geht ja nicht um die Leaks die man wissentlich drin hat und vom MM ignoriert werden. Es geht um eigene Leaks, die man durch unsauberes programmieren verursacht. Und für sonstige Fehler wie AV's bekomme ich vom Kunden genaue Anweisungen und kann das in der Regel problemlos reproduzieren und beheben.

[generic]

In diesem Video erkläre ich auch noch die eine oder andere Funktion vom FastMM:
https://youtu.be/o0yZgQoV8MA

[Andreas13]

@Generic
Danke, Bernd!
Gruß, Andreas