Disclaimer: Dieser Thread wurde aus dem alten Forum importiert. Daher werden eventuell nicht alle Formatierungen richtig angezeigt. Der ursprüngliche Thread beginnt im zweiten Post dieses Threads.
Aufgabe 4: Memory leak in Beispielimplementierung
Hi,
die Beispielimplementierung hat ein memory leak: Sollten noch Hintergrund-Prozesse laufen, wenn clash beendet wird, dann wird die Liste nicht geleert und der Speicher der Listenelemente nie freigegeben.
Ich schätze mal fast dass das Absicht ist. Sobald die clash beendet wird, wird der Speicher ja freigegeben.
Das glaube ich kaum, denn schon bei der wsort gab es Abzüge, wenn man den Speicher direkt vor dem Beenden des Programmes nicht freigegeben hat.
Wenn sich in SP nichts geändert hat, dann gilt da, dass beim normalen Beenden des Programms alles aufgeräumt werden muss, bei einem Fehler irgendwo zwischendrin aber ein exit() erlaubt ist.
Bei der Sache geht es ja darum, gute Programmierpraxis zu vermitteln und da ist ein solches Verhalten bei länger laufenden Programmen das Gewünschte.
Beispielszenario: Ich kann mich nicht erinnern, wo ich eine Datei abgelegt habe will jetzt den gesamten Rechner danach durchsuchen. Dazu kann ich grep -R “Dateiinhalt” / verwenden. Das dauert ne Weile, aber was soll’s.
Wenn jetzt grep nie free() oder close() verwenden würde, dann wäre der Computer dann irgendwann hauptsächlich damit beschäftigt, Daten die niemand mehr braucht auf die Festplatte zu swappen bis grep dann komplett abstürzt weil es zu viele Dateideskriptoren verwendet und keine neuen Dateien mehr öffnen darf. Das ist also doof und grep soll bitte schön im normalen Betrieb alles freigeben was es nicht mehr braucht.
Wenn grep aber irgendwann zwischendurch sagt “oh da ist jetzt ein Fehler wegen dem ich nicht weitermachen kann”, dann schadet da ein exit() auch nicht, das Betriebssystem kümmert sich schon darum, alle Dateien zu schließen und den Speicher freizugeben.
1 Like
Das gilt natürlich weiterhin in SP, im Erfolgsfall muss aller Speicher freigegeben und alle Dateien geschlossen werden.
Bei dieser Aufgabe reicht aber die Schnittstelle für die plist nicht, um das zu implementieren. Ist also kein Problem wenn da in diesem Spezialfall Speicher verloren geht.
Man kann doch die Liste durchgehen und für jedes Element removeElement aufrufen !?
Man müsste also erstmal alle Element sammeln und dann jeweils [m]removeElement()[/m] aufrufen - schön ist das nicht.
Mit anderen Worten: in diesem Fall könnte man sich das Modul plist auch ganz sparen.
Ich hätte jetzt eher erwartet, dass das Modul plist eine Funktion wie plistFree() bereit stellt, die am Ende alles aufräumt.
Ja, die Funktion fehlt.
Ich würde das jetzt auch nicht unbedingt als Memoryleak sehen (aber frag mich nicht, wie es bei der Korrektur aussieht, aber da die Referenzimplementierung das ja auch tut…). Ein Leak wäre es für mich nur, wenn die Liste zur Laufzeit irgendwie Zeiger “verlieren” würde und so Speicherbereiche nie wieder freigeben kann. Aber hier sind ja lediglich noch ein paar Daten zu noch laufenden Prozessen vorhanden, die ja trotzdem freigegeben werden würden, wenn die Prozesse denn beendet werden würden.
An dieser Stelle müsste dann auf jeden Fall noch der Aufrufer dafür sorgen, dass während des Ausführens von [m]plistFree()[/m] kein [m]SIGCHLD[/m] durchkommen kann, dessen Behandlungsfunktion auf die Prozessliste zugreift.
gabs denn bei der clash (sp1 aufgabe4?) schon Signalhandler? 
Äh, richtig, ich hab die Aufgabe mit der [m]rush[/m] (SP2) verwechselt. Stand nicht fett genug obendrüber, dass es hier um SP1 geht. 