Anwendung frisst auf Windows 7 Arbeitsspeicher

[TUX_der_Pinguin]

Hallo,

ich habe eine 32 Bit Anwendung mit Delphi 11.0 kompiliert und wenn ich die Anwendung laufen lassen verbraucht sie mit laufe der Zeit immer mehr Speicher. Jedoch ist das Verhalten unter Windows 10 ein anderes als unter Windows 7. Während bei Windows 10 der Speicher irgendwann freigeben wird, wächst die Anwendung unter Windows 7 ununterbrochen weiter, bis irgendwann das Limit erreicht wird und dann die Anwendung abstürzt. Bei Windows 10 wächst die Anwendung von 3,5 MB auf über 60 MB an und dann wird auf einmal alles wieder freigeben und die Anwendung ist wieder nur wenige MB groß.

Die Anwendung ist ein kleines Tool was im System-Tray läuft und die ganze Zeit im Hintergrund ein Verzeichnis überwacht ob dort neue Dateien liegen, sind Dateien vorhanden werden die Dateien eingelesen und verarbeitet. In der Anwendung wird mit verschiedenen Threads gearbeitet.

Ich habe den gesamten Quelltext überprüft als auch mit FastMM4 versucht herauszufinden, ob und wo das Problem ist. Es kam nur einmal vor das ich nachdem Beenden der Abwendung in der Entwicklungsumgebung eine Meldung von FastMM4 kam, das es ein Speicherleck geben würde. Jedoch ohne Hinweis wo und an welcher Stelle das passiert ist.

Code:

This application has leaked memory. The small block leaks are (excluding expected leaks registered by pointer):

21 - 36 bytes: System.SysUtils.EListError x 5
101 - 116 bytes: UnicodeString x 5

Ich weiß natürlich das man heutzutage kein Windows 7 mehr einsetzen sollte, aber es handelt sich hier bei um einen speziellen Rechner bei einem Kunden. Das aber auch unter Windows 10 der Speicherverbrauch so "hoch" ist, verstehe ich nicht ganz.

Vielleicht hat hier jemand einen Tipp, mit welchen Methoden man der Ursache auf den Grund gehen könnte. Leider kann ich aus Gründen hier nicht den gesamten Quelltext der Anwendung einstellen.

Die Anwendung ist über viele Jahre weiter entwickelt worden und daher auch mit unterschiedlichen Delphi Versionen kompiliert worden und plötzlich zeigt sich dieses Merkwürdige Verhalten.

[taveuni]

Es fehlt ein Try-Finally Block. Vermutlich erzeugst Du irgendwo eine Liste und gibst diese nicht frei wenn eine Exception auftritt

[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

[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.


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.


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