Hi Leute!

Leider habe ich im WWW nichts gefunden, was mich vollends zufriedenstellt, daher dieser Thread.

Ich habe ein sehr umfangreiches Programm geschrieben (einen Decklisteneditor für ein Sammelkartenspiel) und würde gern wissen, ob ich, wenn das Programm geschlossen wird, den Speicher, den es innerhalb von Windows für sich beansprucht, wieder freigeben muss und wenn ja, wie ich das tun kann.

Ich habe gestern das Programm ein paar Mal starten müssen um gewisse Funktionen zu testen und hatte das Gefühl, dass mein PC, nachdem ich ihn heute aus dem Standby-Modus geholt hatte (also beim Laptop den Deckel wieder geöffnet), dass er total langsam ist und ein Neustart brachte dann die erhoffte (gefühlte) Verbesserung.
Es kann natürlich auch sein, dass es daran liegt, dass der Laptop schon 6-7 Jahre auf dem Buckel hat und so langsam den Geist aufgibt.

Ich habe, während mein Programm läuft, keine Speicherauslastung oder dergleichen im Task-Manager feststellen können und Dinge wie MemoryStreams, die ich im laufenden Programm erzeuge, werden auch ordnungsgemäß wieder freigegeben. Objekte erzeuge ich während des Programms eigentlich keine.

Ich wäre euch dankbar, wenn mir jemand kurz mitteilen könnte, ob und wie ich Speicher beim Beenden des Programms freiegeben kann / muss.

Gruß,

Terra


Moderiert von Narses: Topic aus Sonstiges (Delphi) verschoben am Do 11.10.2012 um 18:40

Wenn du das Programm beendest wird der gesamte RAM den das Programm belegt hatte freigegeben. Dafür sorgt Windows

Zitat:

Dinge wie MemoryStreams, die ich im laufenden Programm erzeuge, werden auch ordnungsgemäß wieder freigegeben. Objekte erzeuge ich während des Programms eigentlich keine.

Jaa neee, ist klar ^^
Also auch wenn du die nicht freigeben würdest - wenn dein Programm beendet wird, wird der Speicher wieder frei.

Moderiert von Narses: Komplett-Zitat des letzten Beitrags entfernt.

Danke für deine Antwort. Ich fürchte, dann wird es doch Zeit für nen neuen Laptop.

Was meinst du mit deiner Bemerkung "Jaa neee, ist klar"? Das check ich grad nicht.

Moin!

Ein TMemoryStream ist auch ein Objekt.

cu
Narses

jfheins hat folgendes geschrieben :

Wenn du das Programm beendest wird der gesamte RAM den das Programm belegt hatte freigegeben. Dafür sorgt Windows

Ist das wirklich ganz sicher? Warum sucht man dann, z.B. mit FastMM4, nach Speicherlecks?
Irgendwie bin ich jetzt verwirrt. Ich dachte, man muss stets Alles, was man erzeugt, auch selbst wieder löschen, insbesondere die Streams.

Etwas ratlos mit besten Grüßen
Mathematiker

Wenn das Progr. beendet wird gibt Windows den belegten Speicher frei.

Natürlich sollten die Teile des Programms bereits vorher den von ihnen belegten und nicht mehr benötigten Speicher freigeben. Einerseits ist sowas ja guter Ton andererseits ist eine Funktion die nicht mehr benötigten Speicher nicht freigibt ein Problem spätestens wenn sie öfter aufgerufen wird.

FastMM hilft dabei, derartige "Unterlassungs-Sünden" zu finden.

jfheins hat folgendes geschrieben :

Wenn du das Programm beendest wird der gesamte RAM den das Programm belegt hatte freigegeben. Dafür sorgt Windows

Das war aber nicht immer so. Im Internet geistert(e) der Hinweis, dem mit "alwaysunloaddll" abzuhelfen. Das soll aber seit Windows 2000 überflüssig sein, da es ab jenem Windows ohnehin immer geschieht. Dennoch ist dieser Hinweis ein nicht zu tötender Dauerbrenner. Ich fand ihn vor Jahren sogar in einem PC-Sonderheft (PC intern oder Windows intern), von dem ich bis dato Seriösität annahm. Den Chefredakteur (ein sogar promovierter Herr) angeschrieben, doch der arrogante Heini schwieg darauf nur. War mithin mein letzter Kauf....

Speicherlecks versucht man zu vermeiden, damit der nicht mehr benötigte Speicher freigegeben wird. Der wird bei Delphi zwar dann nicht direkt an Windows zurückgegeben (afaik), kann aber "recycled" werden, um darin neue Objekte zu speichern. Bei Speicherlecks bleibt der Speicher "belegt", und das Programm muss von Windows immer mehr Speicher anfordern, bis irgendwann nichts mehr geht.

Beim Beenden des Programms wird der Speicher aber auf jeden Fall freigegeben.

Hallo,

Das was Gausi beschreibt ist Grishnak zu Beginn bei seinem Soduko Generator/Löser mal passiert:
www.entwickler-ecke....rder=asc&start=6
Dort wurden dann soviele Objekte erzeugt und nicht wieder freigegeben, dass die Daten plötzlich auf die Festplatte ausgelagert wurden.
Mit einer möglichen Lösung, die Objekte frühest möglich wieder frei zu geben:
www.entwickler-ecke....der=asc&start=14

Gruß Horst

Moin!

mandras hat folgendes geschrieben :

Wenn das Progr. beendet wird gibt Windows den belegten Speicher frei.

Das ist korrekt, sofern es um Speicher geht, den der Delphi-Speichermanager angefordert hat.

Es ist allerdings trotzdem möglich, selbst Speicher über die Windows-API anzufordern, für die Freigabe dieses Speichers ist man dann immer noch selbst verantwortlich, der wird nicht automatisch freigegeben. Das ist z.B. im Umfeld der Funktionen SHGetFolderLocation() so, hier habe ich mal was dazu geschrieben.

So gesehen ist es also durchaus möglich ein Speicherleck zu schrauben, das den für Windows verfügbaren Speicher auch nach Ende des Delphi-Programmes verringert! IMHO gilt das auch für alle erdenklichen Sprachen oder Script(sprachen), wenn man direkt an die Windows-API ran geht.

Fazit: Dass es kein guter Stil ist, Speicherlecks fahrlässig in Kauf zu nehmen, "weil Windows ja hinter mir aufräumt", sollte unbestritten sein. Wenn es aber direkt um API-Speicher geht, ist das sogar tödlich!

cu
Narses

Narses hat folgendes geschrieben :

So gesehen ist es also durchaus möglich ein Speicherleck zu schrauben, das den für Windows verfügbaren Speicher auch nach Ende des Delphi-Programmes verringert! IMHO gilt das auch für alle erdenklichen Sprachen oder Script(sprachen), wenn man direkt an die Windows-API ran geht.

Das muß ja wohl so sein. Der/die/das Windows-API interessiert herzlich wenig, mit welcher Programmiersprache die Befehle erstellt wurden, die dessen/ihre Befehle letztlich aufrufen. Einzige Ausnahme: Die Programmiersprache selbst müßte eingebaute automatische Funktionen haben (die z.B. mit "eincompiliert" oder "eingelinkt" werden), die "Schlampereien" von selbst ausbügeln. Bezweifele ich aber eher, denn Leute, die das Format haben, mit der/die/das API sach- und fachgerecht umzugehen, dürften weit überwiegend auch die Kenntnis und die Routine aufbringen, damit korrekt zu verwenden.

Delphi-Laie hat folgendes geschrieben :

Einzige Ausnahme: Die Programmiersprache selbst müßte eingebaute automatische Funktionen haben (die z.B. mit "eincompiliert" oder "eingelinkt" werden), die "Schlampereien" von selbst ausbügeln.

Das ist nicht möglich. Rein logisch nicht.
Denn wenn das Programm z.B. abstürzt (im Taskmanager abgeschossen, ...), wird schlicht kein Code des Programms mehr ausgeführt. Dementsprechend ist auch nichts da, das aufräumen kann.

Die Resourcen, die über API-Befehle reserviert werden, kann man aber auch ohnehin nicht automatisiert überwachen, da nicht eindeutig definierbar ist wann aufgeräumt werden soll.

Richtig. Rein logisch bezog ich mich mit diesem Gedankenexperiment auch auf den Fall, daß ein Programm ordnungsgemäß beendet wird. Für den Fall gibt es schließlich auch im Programm einiges (mal mehr, mal weniger) an Code abzuarbeiten.

Das nennt sich dann Garbage Collector, den es z.B. in Java und C# gibt. In Delphi gibt es den zwar nicht, aber wenn man Interfaces benutzt, werden die Objekte dahinter auch automatisch freigegeben.

Das hilft aber alles nicht bei direkt durch die API reservierten Ressourcen.

Hm. Irgendwie erging es mir bei diesem Thread ähnlich wie Mathematiker.
Ich dachte eigentlich auch, dass der Punkt hinter .Free wäre, den reservierten Speicher freizugeben (Delphi hat ja keine GC wie Java).
Also hab ich immer versucht, die noch vorhandenen Objekte zu "befreien" (Free) bei Programmende.

Nun hatte ich einen speziellen Fall, dass bei einem größeren Programm (Delphi) folgende Situation auftrat:
mein Programm sollte enden, ich hatte alles "befreit", was mir bewusst war.
Dennoch hing der Prozess im Speicher, und ich kriegte dieses Ding einfach nicht beendet.
Schliesslich fiel mir nix besseres ein, als Halt (am Ende des OnClose Events) aufzurufen, wohl im Bewusstsein, dass man das eigentlich nicht machen sollte.
Das funktionierte auch, und - obwohl die Lösung "schlecht" war - gab es damit keine (mir zu Ohren gekommenen) Probleme.

Erwähnenswert ist noch, dass ich eine ganze Zeitlang später in einem Java-Programm ein ähnliches Problem hatte.
Ich vermute, dass es mit irgendeinem Stream zusammenhing, den ich nicht ausfindig machen konnte. Natürlich versuche ich,
alle Streams zu schliessen, aber da war mir irgendeiner "durch die Lappen gegangen" vermutlich.

Olli

Wenn der Prozess hängt, kannst du .dbg Debuginformationen erzeugen und im Process Explorer schauen in welchem Thread an welcher Stelle da etwas hängt.

Meistens sind das nicht sauber beendete Threads (z.B. auch mit Indy), durch die ein Deadlock entsteht.