Am Sam, 2002-07-20 um 11.32 schrieb Martin Oehler:
Hi!
Am Sam, 2002-07-20 um 09.41 schrieb Ralf Corsepius:
Am Fre, 2002-07-19 um 11.00 schrieb Martin Oehler:
Aus eigener Erfahrung würde das Speicherleck-Szenario für YOU nach fünfmaligem Starten dafür sorgen, dass von meinen Speicher nix mehr da ist, meine Festplatte aus dem swappen gar nicht mehr rauskommt und das System sich dann wohl aufhängt. :)
Nein, die hier diskutierte Variante von Memory-Leaks wirkt sich nur bei Programmen aus, die _dauerhaft_ laufen, wie z.B. Daemons, da Programme jeglichen Speicher beim Beenden wieder freigeben.
Ich bin eigentlich davon ausgegangen, dass man YOU (und yast2) wieder beendet. Es könnte sein, dass wir aneinander vorbeireden.
Ich sprach lediglich davon, dass die Art der Memory-Leaks, die hier diskutiert wird, keine persistenten Memory-Leaks produzieren darf, da "normal" (d.h. statisch, automatisch und dynamisch) allokierter Speicher immer beim Beenden eines Programms freigegeben wird, egal wie defekt die Applikation sein mag. D.h. nicht, dass YOU nicht fehlerhaft sein mag und persistente Memory-Leaks produziert, es heisst lediglich, dass ich deinen Schluss für nicht stimmig halte. Persistente Memory-Leaks könnten z.B. durch * Treiber-Bugs ... * Zombies (Prozesse, die sich nicht sauber beenden) oder geforkte Prozesse die beim Tod nicht sauber beendet werden ... * Bugs im Kernel-Memory-Management + SYSV-Shared-Mem. u.s.w. entstehen. Doch selbst wenn nach Beendigung eines Prozesses Speicher nicht sofort wieder freigegeben wird, muss dass noch lange nicht heissen, dass "der Speicher persistent leckt" - Es kann sein, dass sich im Hintergrund irgendetwas verändert hat, irgendetwas dynamisch nachgeladen worden sein, aber noch nicht wieder freizugeben worden sein (z.B. könnte ein Kernel-Module nachgeladen worden sein und noch "herumhängen", es könnten Daemons gestartet worden sein, die vorher nicht liefen (z.B. irgendwelche Sounddaemons), es könnten Caches gefüllte worden sein, die vorher nicht gefüllt waren (z.B. squid), usw. usf.).
Ich zeige mal ein Beispiel auf für ein memory leak, wie ich eines meinte: (vielleicht wird dann klarer, was ich oben geschrieben habe)
vorher: -------
free total used free shared buffers cached Mem: 1545840 92884 1452956 0 5720 43328 -/+ buffers/cache: 43836 1502004 Swap: 1694848 41776 1653072
Programm läuft: ---------------
free total used free shared buffers cached Mem: 1545840 1515944 29896 0 10064 62424 -/+ buffers/cache: 1443456 102384 Swap: 1694848 812344 882504
hinterher: (3,4,...,10 Min) ----------
free total used free shared buffers cached Mem: 1545840 215084 1330756 0 35320 97292 -/+ buffers/cache: 82472 1463368 Swap: 1694848 0 1694848 Damit das eine Aussagekraft hat, müsstest Du auch beobachten, welcher Prozess vor und nachher, wieviel Speicher benutzt hat.
Den Speicher kriege ich zur Laufzeit nicht mehr. Und das wird nach jedem Ausführen weniger. Ob das Programm zur Laufzeit soviel Speicher brauchen sollte, steht auf einem anderen Blatt... Egal, obiges paarmal gemacht, und schon steht mein Rechner. Welcher Kernel?
Genau so sehen auch die Symptome des Swap/Memory-Management-Problems mit Kerneln ca. < 2.4.10 aus. Ralf