Memory Leak bei virtuellem Speicher

[Pittus]

Hallo,

ich habe folgendes Problem:
meine Anwendung verbraucht sowohl physikalischen als auch virtuellen Speicher. Der physikalische wird immer in einem Block wieder freigegeben während der virtuelle Verbrauch irgendwann zum Absturz führt.
Ich hatte das Problem früher auch schon, konnte aber dann durch ordentliches Leeren von strings dieses Leak wieder schließen. Damals hat es genügt, bei allen Records und Objekten, die freigegeben werden, die strings auf '' zu setzten.

Jetzt wohl nicht mehr. Und deswegen bin ich im Moment ziemlich ratlos.

Gibt es sonst noch bekannte Ursachen für diesen Effekt?

Gruß
Pittus

[sirius]

Zitat:

Zitat von Pittus

meine Anwendung verbraucht sowohl physikalischen als auch virtuellen Speicher.

:gruebel:

Zitat:

Zitat von Pittus

Der physikalische wird immer in einem Block wieder freigegeben während der virtuelle Verbrauch irgendwann zum Absturz führt.

:gruebel: :gruebel:

Zitat:

Und deswegen bin ich im Moment ziemlich ratlos.

Ich grad auch. Aber ich würde mal behaupten, dass du irgendwelche Objekte nicht freigibst. I.A. wird hier zu FastMM geraten.

Und den Unterschied zwischen physikalischem und virtuellen und linearen usw. usf. Speicher solltest du dir nochmal ansehen.

[Sherlock]

Gegenfrage: Wie kann man eigentlich unter Programmkontrolle angeben, welche Speicherart man gerne hätte?

:gruebel:

Sherlock

[OldGrumpy]

Zitat:

Zitat von Sherlock

Gegenfrage: Wie kann man eigentlich unter Programmkontrolle angeben, welche Speicherart man gerne hätte?

:gruebel:

Sherlock

Nur in begrenztem Umfang und es ist auch in den allermeisten Fällen nicht sinnvoll, sich da explizit drum zu kümmern. Windows hält immer möglichst viel realen Speicher frei indem gerade nicht benutzte Speicherseiten in den virtuellen Speicher (Swapfile) ausgelagert werden. Wenn eine Anwendung also ein Speicherleck hat und große Mengen "toter" Objekte anlegt, dann fängt Windows früher oder später an, die nie benutzten Speicherbereiche in denen diese Objekte liegen, auszulagern. FastMM im Full Debug Mode nutzen und rausfinden wo die Lecks sind.

[nicodex]

Zitat:

Zitat von Sherlock

Gegenfrage: Wie kann man eigentlich unter Programmkontrolle angeben, welche Speicherart man gerne hätte?

Nur indem man es selbst implementiert, oder eine Speicherverwaltung verwendet, die selbiges unterstützt.

Notwendig/interessant ist dies nur in wenigen Fällen... Um ein praktisches Beispiel zu nennen: Eine Klasse in einer Anwendung fordert mehrere hunderttausend kleine Speicherbereiche an (zum Beispiel Dateinamen). Nutzt diese Klasse den Standard-Heap der Anwendung, dann wird es - trotz Freigabe aller Speicherbereiche - zur Heap-Fragmentierung kommen. Diese ungenutzten "Lücken" im Heap können im Laufe der Zeit dazu führen, dass für eine Anforderung eines größeren Blocks kein zusammenhängender freier Speicherbereich gefunden wird. Es steht also theoretisch genug freier Speicher zur Verfügung, aber nicht genug für große Blöcke. Wenn dies alles zutrifft, dann kann man darüber nachdenken, für diese "Liste" einen eigenen Heap zu verwenden, der anschließend komplett freigegeben werden kann.

Topic: Für records gibt es Finalize (System.pas).

[Pittus]

Hallo,
vielen Dank für eure Antworten und Anregungen.

Das Problem scheint gelöst :dancer: und die Lösung könnte für andere auch interessant sein.

Die Ursache lag in der Komponente TIdTCPServer, die ich auf einem Datenmodul hatte. Ich arbeite viel mit den Indy-TCP-Komponenten und hatte bisher keine Probleme damit (im Gegenteil!). Diese Komponente hatte jedoch offensichtlich einen "Schuss". Nachdem ich die Komponente gelöscht habe und sie beim Programmstart als Objekt erzeuge (und eben nicht auf dem Datenmodul platziere) ist mein Speicher stabil. Das war die einzige Änderung. :!:

Ich kann mir das zwar nicht erklären aber ich hatte bereits solche Effekte beim TdxTreeList und anderen komplexeren Komponenten. Da hat es aber meist genügt, die Komponente runterzuschmeißen und neu abzulegen. Diesmal nicht, wahrscheinlich hätte ich das Datenmodul neu erzeugen müssen.