Memory Leak
 
StartSeite | Neues | TestSeite | ForumSeite | Teilnehmer | Kategorien | Index | Hilfe | Einstellungen | Ändern

Veränderung (letzte Änderung) (Korrektur, Autor, Normalansicht)

Hinzugefügt: 28a29,30
: Die Linux-Manpage dokumentiert es exakt. Ist p null, verhält sich realloc wie malloc. Ist size null, verhält es sich wie free. Andernfalls wird versucht, die Allokation bei p in ihrer Größe anzupassen, geht das nicht, wird neu allokiert, verschoben und free(p) aufgerufen.


Hinzugefügt: 36a39
: So ist es. Steht auch in der Manpage.

Hinzugefügt: 47a51,52
: Der löst auch nicht alle Probleme. Benutze ihn, wenn du komplexe Allokationsmuster hast. Wenn du ihn benutzen willst, um nicht mehr über Speichermanagement nachdenken zu müssen, wird er dir nicht helfen.


Verändert: 49c54
KategorieProgrammierung KategorieCee
KategorieProgrammierung KategorieC KategorieCee

Ein "SpeicherLeck". Vorzugsweise zu beobachten an kommerziellen, gekauften Softwareprodukten. Bekanntes Problem u.a. beim Programmieren in der SpracheCee.

Das ist ein MemoryLeak:

char *p;
p=malloc(1); /* Speicherblock 1 */
p=malloc(1); /* Speicherblock 2 */

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.


void *realloc (void *p, size_t size);

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?

Nein es ist kein Standart, sondern Standard. ;-)

Die Linux-Manpage dokumentiert es exakt. Ist p null, verhält sich realloc wie malloc. Ist size null, verhält es sich wie free. Andernfalls wird versucht, die Allokation bei p in ihrer Größe anzupassen, geht das nicht, wird neu allokiert, verschoben und free(p) aufgerufen.


struct tm *localtime (const time_t *tp);

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?

So ist es. Steht auch in der Manpage.


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?

Der löst auch nicht alle Probleme. Benutze ihn, wenn du komplexe Allokationsmuster hast. Wenn du ihn benutzen willst, um nicht mehr über Speichermanagement nachdenken zu müssen, wird er dir nicht helfen.


KategorieProgrammierung KategorieC KategorieCee
StartSeite | Neues | TestSeite | ForumSeite | Teilnehmer | Kategorien | Index | Hilfe | Einstellungen | Ändern
Text dieser Seite ändern (zuletzt geändert: 29. November 2007 8:39 (diff))
Suchbegriff: gesucht wird
im Titel
im Text