Das ist ein MemoryLeak:
|
Speicherblock 1, dessen Adresse durch die Neubelegung des Zeigers p verlorengegangen ist, kann weder verwendet noch wiederverwendet werden. Er wird erst beim Programmende wieder freigegeben.
Ein MemoryLeak ist vor allem dann ein Problem, wenn der fehlerhafte Code oft durchlaufen wird (der Effekt ist additiv), wenn der verlorene Speicherblock groß ist und wenn das Programm selbst für eine lange Laufzeit bestimmt ist: Serverprogramme, Betriebssystembestandteile oder ähnliches.
Free the mallocs!
Speicherlöcher sind ohne Werkzeug-Unterstützung äußerst schwer zu finden. Einfache Debugger reichen i. d. R. nicht aus, besser sind Werkzeuge, die speziell auf Speicherprobleme zugeschnitten sind. Mehr auf Seite SpeicherChecker.
|
In allen Dokumentationen ich keine genauen Angaben zu realloc gefunden. Klar - die Größe von p wird auf size geändert usw. und zurückgegeben wird die Adresse von p, die sich offenbar ändern können muss (schließlich kann es sein, dass der Speicher hinter p schon reserviert ist und p sich vergrößern soll). Was passiert nun mit dem alten Speicher auf den p zeigte? Ich hab beim rumprobieren herausgefunden, dass realloc ihn freigibt. Stimmt das? Ist das Standart?
|
Eigentlich dachte ich, dass ich, dass ich den von localtime reservierten Speicher wieder eigenhöndig freigeben müsste. Muss ich anscheinend nicht, denn der Compiler meckert, dass dieser JunkPointer? zu groß ist. Anscheinend liegt dieser Speicher in einem Bereich, um den ich mich nicht zu kümmern brauch?
Alternative Möglichkeit, um das Problem der Speicherlecks loszuwerden:
Verwende einen Garbage Collector. Hier gibt es zum Beispiel den von Hans Boehm:
http://www.hpl.hp.com/personal/Hans_Boehm/gc/
Hat jemand Erfahrungen damit?