Anwendung frisst auf Windows 7 Arbeitsspeicher

[TUX_der_Pinguin]

Zitat von jaenicke:

Es gibt zwei Möglichkeiten:
Speicher wird immer weiter reserviert und gar nicht mehr freigegeben. Das sieht man dann in den FastMM-Logs. Die muss man nur aktivieren, dann bekommt man ein Log mit Stacktrace usw., so dass man die Speicherlecks leicht findet.

Die andere Möglichkeit ist, dass der Speicher beim Beenden durchaus wieder freigegeben wird, aber zur Laufzeit nicht. Das siehst du dann nicht in solchen Logs. Da helfen dann Speicheranalyse-Tools wie TMS MemInsight:
https://www.tmssoftware.com/site/tmsmeminsight.asp

Danke für den Tipp mit MemInsight von TMS, ich habe mir mal die Testversion heruntergeladen und geschaut ob ich da etwas finden kann.

Ein Speicherleck scheint mir nicht vorzuliegen, sonst müssten die Werte in der Spalte "Diff" ja immer weiter ansteigen und das tun sie nicht.
TMSMemInsight_Screenshot1.png

Was mich jedoch stutzig macht, ist das in der "Memory" Übersicht unten Links die Zahlen "blocks" und "bytes" immer weiter steigen. Während die Zahlen in den Klammern, also Objekte, Strings etc., gleich bleiben.
TMSMemInsight_Screenshot2.png

Kann es sein das die Software ständig neuen Speicher belegt und kurz drauf wieder frei gibt. Dieser freigegebene Speicher jedoch nicht bzw. nicht sofort an das Betriebssystem zurückgegeben wird? Bzw. Windows 7 das überhaupt nicht macht, weshalb der Speicher bei Windows 7 immer weiter anwächst. Die Frage wäre dann wie verhindere ich das bzw. wie teile ich dem Betriebssystem mit das der Speicher wieder frei ist?

[jaenicke]

Zitat von TUX_der_Pinguin:

Kann es sein das die Software ständig neuen Speicher belegt und kurz drauf wieder frei gibt. Dieser freigegebene Speicher jedoch nicht bzw. nicht sofort an das Betriebssystem zurückgegeben wird? Bzw. Windows 7 das überhaupt nicht macht, weshalb der Speicher bei Windows 7 immer weiter anwächst.

Das ist so und das ist völlig normal. Darum kümmert sich aber nicht Windows, sondern der Speichermanager der Delphi-Anwendung, der also nicht abhängig von der Windowsversion ist.

Dieser Effekt führt aber weder dazu, dass die Anwendung zu viel Speicher verbraucht, noch dass sie abstürzt. Wie viel Speicher hat die Anwendung denn, wenn sie abstürzt und mit welchem Fehler stürzt sie ab?

[himitsu]

Beispiel:

Erzeue immer wieder viele TEdit.Create(nil) oder TEdit.Create(Self) und vergiss sie freizugeben.

Bei Letzterem würden die Edits aber an der Form hängen
und somit beim Beenden freigegeben,
bevor der Speichermanager seine Leck-Kontrolle durchführt.

Zur Laufzeit würde aber in beiden Fällen der Speicher sich füllen.

[TUX_der_Pinguin]

Zitat von jaenicke:

Dieser Effekt führt aber weder dazu, dass die Anwendung zu viel Speicher verbraucht, noch dass sie abstürzt. Wie viel Speicher hat die Anwendung denn, wenn sie abstürzt und mit welchem Fehler stürzt sie ab?

Da das bei einem Kunden passiert ist, kann ich das gar nicht genau sagen. Ich vermute aber das es 2GB waren. Die Meldung war "zu wenig Speicher" und eine 32 Bit Anwendung kann ja maximal 2GB im Speicher belegen.

Ich weiß nicht ob das möglich ist, dem Speichermanager irgendwie zur Laufzeit ab und an mitzuteilen das er "aufräumen" soll.

Und irgendein Unterschied muss die Windows Version ja machen, warum sonst verhält sich die gleiche Software auf unterschiedlichen Versionen anders.

Zitat von himitsu:

Beispiel:

Erzeue immer wieder viele TEdit.Create(nil) oder TEdit.Create(Self) und vergiss sie freizugeben.

Bei Letzterem würden die Edits aber an der Form hängen
und somit beim Beenden freigegeben,
bevor der Speichermanager seine Leck-Kontrolle durchführt.

Zur Laufzeit würde aber in beiden Fällen der Speicher sich füllen.

Aber genau das müsste sich mit TMS Memory Insight ja anzeigen lassen, das immer mehr Objekte erzeugt aber nicht freigegeben werden. Und das passiert hier ja nicht. ES wären zwar zig Objekte erzeugt aber immer auch wieder freigegeben.

[himitsu]

Zitat von TUX_der_Pinguin:

eine 32 Bit Anwendung kann ja maximal 2GB im Speicher belegen.

4 GB, wenn man es im PE-Header aktiviert,

(bzw. 3 GB, in einem 32-Bit-Windows)


aber ist es wirklich ein Speicherleck, dann wird das Knallen so nur verzögert, aber nicht verhindert.

[jaenicke]

Zitat von TUX_der_Pinguin:

Ein Speicherleck scheint mir nicht vorzuliegen, sonst müssten die Werte in der Spalte "Diff" ja immer weiter ansteigen und das tun sie nicht.

Ich kenne das Tool nicht so genau, nur den Vorgänger, den TMS gekauft hat, aber relevant sollte die Spalte Live sein.

[TurboMagic]

Hallo,

es gibt auch eine Möglichkeit vom integrierten FastMM4 Statistikdaten abzurufen.
Ich weiß nur nicht mehr auswendig wie.

Und um dem FastMM4 das verbesserte Melden von Speicherlecks beizubringen brauchst
du die freie komplette Variante von FastMM4 die du im Internet findest.

Die in Delphi integrierte Variante liefert da nicht alles benötigte mit.

Grüße
TurboMagic

[jaenicke]

Für detaillierte Infos gibt es bei FastMM eine Demo, die man auch in die eigene Applikation integrieren kann.