Ich bin mir nicht mehr sicher aber ich meine gelesen(gehört?) zu haben, dass moderne Betriebssysteme (Windows XP, 2003,...) Speicherlöscher mittlerweile "entdecken".
Also meine App verursacht beim Beenden ein Speicherloch. Normalerweise ist dieser Speicherbereich erst wieder nach dem Rechnerneustart verfügbar. Bei den moderneren wird der aber wieder während der laufenden Sitzung zur Verfügung gestellt. Ist diese Information korrekt?

P.S.: Wie sieht das unter Linux aus?

Wenn Du dem OS den Speicher nicht zurückgibst, wird es nicht entscheiden, dass Du ihn nicht mehr brauchst. Es wird sich höchstens weigern, Dir weiteren Speicher zuzuteilen.

Sowas kann nur funktionieren wenn die "Benutzer" des allokierten Speichers überwacht werden (etwa durch Referenzzählung), und das nennt man dann Garbage Collection, die Standard C++ bekanntlich nicht mitbringt.

EDIT:
Hups, habe ich da was falsch verstanden?
Ist mit "Neustart" ein Rechnerneustart oder ein Programmneustart gemeint?

EDIT2:
Falls zweiteres, ein beendetes Programm abzuräumen bereitet modernen BS keine Probleme (nichtmal Windows :D) - aber ich schliesse mich Storm an, dass Du das Problem nicht umschiffen sondern aufspüren solltest.

Grundsätzlich kannst du dich auf sowas nciht verlassen, räum deinen Kram also selber auf! Gehört einfach zur guten Sitte.
Es mag sein das einige Betriebsysteme sehen das sich ein Programm beendet hat und den Speicher freigeben, aber verlassen sollte amn sich darauf nicht!

Um Himmels Willen. Ich sorge stets dafür meine Speicher aufzuräumen. Das OS als etvl. GC ausnutzen ist nicht sonderlich elegant.

Es war nur eine generelle Frage, da Speicherlöcher immer mal auftreten können. Ich arbeite derzeit an Webapplikationen. Deshalb interssiert mich ob das Server-OS sich im Fall des Falles darum kümmert. Nicht das der Speicher nach 1000 Aufrufen in die Knie geht.

EDIT:
Hups, habe ich da was falsch verstanden?
Ist mit "Neustart" ein Rechnerneustart oder ein Programmneustart gemeint?

EDIT2:
Falls zweiteres, ein beendetes Programm abzuräumen bereitet modernen BS keine Probleme (nichtmal Windows :D) - aber ich schliesse mich Storm an, dass Du das Problem nicht umschiffen sondern aufspüren solltest.

Habe es mal geändert. Ich meinte Rechnerneustart. Aber das OS räumt also schon nach dem Programmneustart/-ende und auch nach einem Programmabsturz auf, richtig?

Storm.Xapek.de schrieb:

Gerade bei servern sit es wichtig penibel darauf zu achten das kein speicher "verloren" geht. Die Programme sollen schließelich zum Teil monate laufen, und oft ist ein reboot inakzeptabel. Wenn du darauf achtest hast du kein Problem, fals dennoch etwas schiefgeht kannst du immernoch hoffen das ein wunder geschieht.

Das ist auch mein Ziel. Aber ich wollte einfach mal für den Fall der Fälle fragen.

Also, grundsätzlich: immer den speicher selber aufräumen. Wenn du eine Serveranwendung programmierst, dann wäre trotzdem .NET gute wahl - denn niemand ist perfekt, irgendwas geht dir irgendwann verloren, und .NET sorgt dafür, das es keine instabilität deswegen gibt

Was du gehört hast gilt für Programmierer mit Java und (was ja moderner trend von WinXP ist) - fürs MS .NET Framework. Der überprüft, ob du speicher "verloren" hast und macht den frei. ABER: das passiert nur, wenn dem system das frei speicher ausgeht, außerdem ist es eine recht lange sache, bringt performance-verlust.

Das heißt, es wird auch nichts nach dem Programmende aufgeräumt obwohl die interne Prozessverwaltung des OS ja sieht, dass der Speicherbereich des gerade geschlossenen Prozesses nicht leer ist.

Maverick89 schrieb:

Also, grundsätzlich: immer den speicher selber aufräumen. Wenn du eine Serveranwendung programmierst, dann wäre trotzdem .NET gute wahl - denn niemand ist perfekt, irgendwas geht dir irgendwann verloren, und .NET sorgt dafür, das es keine instabilität deswegen gibt

An und für sich stimme ich dem zu. Auch gerade bei Webapplikationen ist das .NET Framework eine wahre Goldgrube. Unter anderem laufen .NET Apps leider nicht ohne weiteres auf Linuxsystemen. Und Mono kann ich leider nicht auf dem Linuxserver installieren.

Das heißt, es wird auch nichts nach dem Programmende aufgeräumt obwohl die interne Prozessverwaltung des OS ja sieht, dass der Speicherbereich des gerade geschlossenen Prozesses nicht leer ist.

also ich meinte das run-time.

nach beenden des prozesses ist was anderes. Ich glaub dass es bei NT+ aufgeräumt wird, genau kann ichs dir nicht sagen, aber man kann es ja leicht ausprobieren.

Das heißt, es wird auch nichts nach dem Programmende aufgeräumt obwohl die interne Prozessverwaltung des OS ja sieht, dass der Speicherbereich des gerade geschlossenen Prozesses nicht leer ist.

Lass Dir nix einreden. Maverick89 redet von Garbage Collection, nicht von Memory Management

Wenn die blöde SharpDevelop-Beta mal wieder den Rechner runterzieht, weil er meint 850 MB virtuellen Speicher belegen zu müssen, kille ich den Prozess und der Speicher ist wieder frei. (Falls jetzt das Argument kommt SharpDevelop ist .NET - a) wird es beim Installieren native compiliert und b) überlässt ein Prozess-Kill dem Framework wenig Gelegenheit aufzuräumen)

EDIT: Ok, hat sich gerade (s.o.) geklärt

Maverick89 schrieb:

Also, grundsätzlich: immer den speicher selber aufräumen. Wenn du eine Serveranwendung programmierst, dann wäre trotzdem .NET gute wahl - denn niemand ist perfekt, irgendwas geht dir irgendwann verloren, und .NET sorgt dafür, das es keine instabilität deswegen gibt

An und für sich stimme ich dem zu.

Ich auch (nur dass das nicht den Anschein erweckt )

Wenn du in unix nen prozess killst, wird auch aller Speicher den er beim Speichermanager allokiert hat (Pid), wieder freigegeben

Windows genau so ... zumindest behaupted das MS ^^
Kann man aber leicht selber pruefen mit den entsprechenden Tools, ... Speicher allokieren, programm beenden lassen / oder per Taskmanager killen, und voiala, weg isser ^^

Probleme sind eher, wennd er prozess sich ned 100% killen laaesst, und verwaist irgendwo noch als leiche dahinduempelt.

Das entbindet natuerlich nicht davon seinen speicher selber wieder freizugeben ... gruende dafuer gibt es tausende ...

Ciao ..

Probleme sind eher, wennd er prozess sich ned 100% killen laaesst, und verwaist irgendwo noch als leiche dahinduempelt.

Und ein weiteres Problem dürfte sein, daß ein Programm mitunter mehr reserviert als nackten Speicher - und File-Handles oder Datenbank-Verbindungen wird dein Betriebssystem ziemlich sicher NICHT freigeben, wenn du das Programm killst (oder ohne die nötigen Aufräumarbeiten beendest).

Filehandles räumt das Betriebssystem schon auf (zumindest Linux und alle unixoide, die ich so kenne)

Es gibt hier auch Leute, die es tatsächlich gewagt haben, ein MS-System zu verwenden

Und außerdem waren die Beispiele oben frei aus der Luft gegriffen - wenn das System die verwendeten Ressourcen tatsächlich selber freigeben kann, hast du Glück. Aber es ist besser, du kümmerst dich selber darum, dann bist du auf der sicheren Seite.

Wie das mit anderen Dingen ist, wenn du das Programm einfach killst, ist unterschiedlich:

1. Socketverbindungen werden normal 'geclosed'. (Bei TCP noch ein client terminated Packet gesendet)
2. Aus Punkt 1 folgert dann auch, dass alle Datenbank Verbindungen beendet wurden.
3. Bei OpenGL/DirectX ist mir kein Fehlverhalten bekannt, der Grafikkartenspeicher wird ebenfalls freigegeben, sowie die Fragment/Vertex Shader.
4. Sehr fehleranfällig sind nach meiner Erfahrung alle Dinge die mit TV Karten zu tun haben, wenn man da nicht richtig deinited dann war es das meistens.
5. Ansonsten ist das Verhalten auch stark von der Platform abhängig.

Grundsätzlich ist nur noch zu sagen, wie auch schon ein Vorgänger sagte: Niemals mit dem Ziel programmieren, dass das OS "das schon macht". Immer schön Destruktoren benutzen, zu jedem new/malloc gehört auch ein delete/free.