Hi, Ralf! Am Sam, 2002-07-20 um 12.26 schrieb Ralf Corsepius:
Am Sam, 2002-07-20 um 11.32 schrieb Martin Oehler:
Es könnte sein, dass wir aneinander vorbeireden.
Hehe, wenn ich nochmal drüberlese, mindestens ein bißchen :)
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.
Damit hast Du ja auch recht. Jedenfalls sollte es so sein. Ich wollte jedoch nur ausdrücklich davor warnen, sich darauf zu verlassen (im Hinterkopf hatte ich die Beispielapplikation). Die frisst natürlich keinen Speicher mehr nach dem Beenden, unterscheidet sich damit auch grundsätzlich von einem defekten demon.
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.
Um YOU ging es mir gar nicht so sehr...s.o., y2bignfat hat seinen Namen wahrscheinlich nicht zufällig ;)
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.
ja
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.).
Jo, das meinte ich, s.o. [Beispiel rausgenommen]
Damit das eine Aussagekraft hat, müsstest Du auch beobachten, welcher Prozess vor und nachher, wieviel Speicher benutzt hat.
Das passt schon um die Qualität (oder sollte ich sagen den Horror) des Problems zu bewerten, hier machts die Erfahrung mit dem Verhalten der SW, an der man seit Jahren arbeitet.
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?
2.4.16 original SuSE
Genau so sehen auch die Symptome des Swap/Memory-Management-Problems mit Kerneln ca. < 2.4.10 aus.
Ich will dem Kernel jetzt mal nicht die Schuld geben, meine Probleme habe ich auf verschiedenen (2.4.18 usw.) Kerneln. Das ist alles nicht so einfach, da das eine größtenteils mathematische Anwendung ist mit teilweise ziemlich wilden Datenstrukturen. Alles auch noch HW-beschleunigt (nvidia-Treiber), teilweise parallel (PVM) und die graphic engine ist auch neu. Da kriegt man leicht bugs, die das System nicht mehr fängt. Gerade die nvidia-Treiber sind auch nicht gerade (je nach Version) unproblematisch. Soviel zur Praxis. :) Ich denke, wir sind uns einig. Oder? CU Martin