3. Memory Leak - und danach?

Memory Leak - und danach?

  • M

    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.

    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

    0
  • H

    Maverick89 schrieb:

    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.

    0
  • M

    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.

    0
  • L

    HaJo. schrieb:

    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 😉 )

    0
  • R

    Alle moderneren BS "ünterstuetzen" das, mehr oder weniger gut ...

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

    0
  • C

    RHBaum schrieb:

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

    0
  • L

    Filehandles räumt das Betriebssystem schon auf (zumindest Linux und alle unixoide, die ich so kenne), bei Datenbankressourcen hängt ja meist noch ein Server dahinter, der seinerseits Resourcen für den Client belegt hält (zumindest bis zu irgendeinem Timeout) wenn dieser gekillt wird.

    0
  • B

    Unter Unix werden z.B. SysV-Shared-Memory-Segmente nicht automatisch freigegeben, temporäre Dateien werden natürlich auch nicht automatisch gelöscht. Der Rest, insbesondere normal allozierter Speicher, natürlich schon! Ein Speicherleck, was über das Programmende hinweg besteht, ist schon ein ziemlich harter Brocken und sollte unbedingt gefixt werden.

    0
  • C

    LordJaxom schrieb:

    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.

    0
  • F

    Wenn du ein Programm (egal ob selbst geschriebenes oder nicht) beendest, dann sind dessen (Speicher-)Resourcen auf JEDEM Betriebssystem (das im Protected Mode läuft, also alle Windows ab 95/NT, alle Unixe [weis nicht genau, aber es gibt bestimmt auch welche die im Real Mode laufen...], etc...) wieder freigegeben.

    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.

    0
  • A

    Was sagt ihr dazu: http://www.fachschaft.informatik.tu-darmstadt.de/forum/viewtopic.php?t=4057?
    Aehnlichen Effekt hatte ich unter Linux. Als ich mit der Arbeit fertig war und Quake spielen wollte, ruckelte es mit 5fps vor sich hin.

    0
Anmelden zum Antworten