Speicherleck

aus Wikipedia, der freien Enzyklopädie

Du hast neue Nachrichten (Unterschied zur vorletzten Version).

Ein Speicherleck (englisch memory leak, gelegentlich auch Speicherloch oder kurz memleak) ist ein Ergebnis fehlerhafter Software. Ein solches Leck entsteht, wenn ein laufender Prozess einen Speicherbereich belegt, diesen jedoch im Zuge der Ausführung nicht mehr freigibt, durch einen Programmfehler aber selbst nicht mehr nutzen kann.

[Bearbeiten] Problematik

In einem Computer steht nur in begrenztem Maße Arbeitsspeicher zur Verfügung. Hierbei handelt es sich um eine Ressource innerhalb des Systems, die das Betriebssystem den einzelnen Prozessen exklusiv zur Verfügung stellt. Das heißt, einmal zugeteilter Speicher kann einem Prozess nicht mehr durch das Betriebssystem entzogen oder von anderen Prozessen benutzt werden. Fordert ein Prozess kontinuierlich neuen Arbeitsspeicher an ohne andere Bereiche wieder freizugeben, so kommt es zu einem Ressourcenengpass der u. U. zum Abbruch des Prozesses oder gar zu einem Absturz des kompletten Systems führen kann.

Das Speichermanagment eines modernen Betriebssystems stellt mittels virtueller Speicherverwaltung einen Adressraum bereit, von dem ein Prozess einzelne Seiten zugeteilt bekommt. Sobald ein Prozess beendet ist, stehen die belegten Speicherbereiche wieder zur Verfügung und können von anderen Prozessen genutzt werden.

Ist das Betriebssystem nicht mehr in der Lage, Speicheranforderungen eines Prozesses zu erfüllen, schlägt die fragliche Reservierung fehl. Einige Betriebssysteme bieten die Möglichkeit, die Speicheransprüche eines einzelnen Prozesses bereits lange vor der Erschöpfung des freien Speichers nicht zu erfüllen, um so die Folgen fehlerhafter Programme im Vorfeld einzudämmen.

[Bearbeiten] Lösungsmöglichkeiten

Bei den möglichen Ansätzen zur Speicherverwaltung kann grundsätzlich zwischen zwei Alternativen unterschieden werden:

Automatische Speicherbereinigung
Explizite Speicherfreigabe

Es gibt folgende Ansätze zur Vermeidung von Speicherlecks:

Analyse des Graphen aus Speicherbereichen (Knoten) und Referenzen (Kanten)
Analyse des Quell-Codes ähnlich der formalen Verifikation
Analyse konkreter Laufzeit-Situationen im Rahmen eines Software-Tests

Im folgenden sollen diese Alternativen kurz betrachtet werden.

[Bearbeiten] Automatische Speicherbereinigung

Falls die verwendete Laufzeitumgebung des Prozesses eine automatische Speicherbereinigung bereitstellt, kann der Anwendungsentwickler innerhalb des Programms Speicher adhoc belegen und verwenden. Sobald die Laufzeitumgebung feststellt, dass ein belegter Speicherbereich nicht mehr erreichbar ist, wird dieser wieder freigegeben. Nicht mehr erreichbar heißt in diesem Zusammenhang, dass keine gültige Variablenreferenz für den belegten Speicherbereich mehr existiert. Ein fehlerhafter Algorithmus kann jedoch auch dann noch ein Speicherleck produzieren, wenn wenigstens ein Speicherbereich referenziert werden kann, der aufgrund dieses Fehlers niemals wieder benutzt werden kann. Dieses Problem ist verwandt mit dem Halteproblem und wie dieses nur semi-entscheidbar.

Beispiele für Programmiersprachen mit einer Speicherverwaltung sind Java, Perl und Haskell.

[Bearbeiten] Explizite Speicherfreigabe

Im Gegensatz zur automatischen Speicherbereinigung kann der Anwendungsentwickler in anderen Programmiersprachen (C, C++ oder Pascal) die Speicherverwaltung selbst implementieren. Das heißt, es können dynamisch Speicherbereiche angefordert, verwendet und anschließend wieder freigegeben werden. Die Speicherbelegung erfolgt explizit und ist nicht an die Existenz einer Variablenreferenz gekoppelt.

Für die Anwendungsentwicklung bedeutet dies einen erheblichen zusätzlichen Aufwand und bildet eine häufige Fehlerquelle. Ein typischer Fehler ist zum Beispiel, dass Referenzen auf dynamisch belegten Speicher unbeabsichtigt überschrieben werden und der ursprünglich referenzierte Bereich nicht mehr freigegeben werden kann. Ein weiterer häufiger Fehler tritt auf, wenn relative Adressen innerhalb des Speicherbereichs falsch berechnet werden und über den vorgesehenen Speicherbereich hinaus geschrieben wird.

Die explizite Speicherfreigabe bietet dem Anwendungsentwickler jedoch mehr Möglichkeiten, die Verwendung der Ressource Hauptspeicher innerhalb der Anwendung selbst zu steuern. Dies ist insbesondere bei systemnahen Anwendungen, Echtzeitanwendungen oder mobilen Anwendungen von Bedeutung, da hier die nicht-funktionalen Anforderungen gegenüber dem Speicherbedarf bzw. dem Antwortzeitverhalten normaler Anwendungen abweichen.

[Bearbeiten] Systematische Tests

Durch systematisches Testen mit Hilfe entsprechender Werkzeuge, die mit einer gewissen Sicherheit feststellen können, welche Speicherbereiche einem Speicherleck zuzuordnen sind, kann man den Problemen der formalen Verifikation entgehen.

Ein bekanntes solches Werkzeug ist Valgrind. Es untersucht die Speicherbenutzung eines Prozesses zur Laufzeit. In wenigen offensichtlichen Fällen kann es ausreichen, nur den Speicherverbrauch eines Prozesses zu untersuchen.

[Bearbeiten] formale Verifikation

Durch einen Korrektheitsbeweis können insbesondere auch Speicherlecks entdeckt werden. Dieses Verfahren ist jedoch sehr Zeit-aufwendig und benötigt hochqualifiziertes Personal. Die auf Speicherlecks spezialisierte Frage kann auch Computer gestützt untersucht werden.

[Bearbeiten] Beispiele

Das bekannteste Beispiel für fehlende automatische Speicherverwaltung ist die Sprache C. Neuer Speicher wird in C-Programmen durch die Funktion malloc angefordert. Dabei liefert malloc einen Zeiger auf den Anfang des entsprechenden Speicherbereichs. Dieser Verweis ist notwendig, um den Speicher mittels geeignetem Code wieder freizugeben (mittels der Funktion free). Geht der Zeiger verloren oder wird verändert, kann der Prozess nicht mehr auf diesen Speicher zugreifen und ihn damit auch nicht freigeben.

[Bearbeiten] C

Das folgende Beispiel zeigt die Entstehung eines Speicherlecks anhand eines in C implementierten Programmes:

int main(void)
{
   int       *a, *b; /* Zeiger auf einen als Ganzzahl interpretierten Speicherbereich */
   
   /* Speicher für Zeiger reservieren. Falls Allokation fehlschlägt, Prozess beenden. */
   if( (a=(int *)malloc(sizeof(int))) == NULL)
       exit(EXIT_FAILURE);
   if( (b=(int *)malloc(sizeof(int))) == NULL)
       exit(EXIT_FAILURE);

   *a = 5;           /* Schreibt den Wert „5“ in den von a referenzierten Speicherbereich     */
   *b = 3;           /* Schreibt den Wert „3“ in den von b referenzierten Speicherbereich     */
    a = b;           /* Weist dem Zeiger a das Ziel des Zeigers b  zu. */

   /* a und b verweisen nun auf den gleichen Speicherbereich. Der zuvor von a referenzierte
    * Speicher ist damit verwaist und kann nicht mehr freigegeben werden. An dieser Stelle
    * entsteht ein Speicherleck. 
    */

   free(b);           /* Gibt den von b referenzierten Speicher frei */
   free(a);           /* Führt zu einem Fehler, da der Bereich, auf den a
                       * verweist, bereits freigegeben wurde (in der vorherigen Zeile) 
                       */
   return EXIT_SUCCESS;
}

Ab dem Schritt a = b ist es nahezu unmöglich, auf den Speicherbereich zuzugreifen, auf den a zuvor verwies. Der Bereich kann meist auch nicht mehr vom Programm freigegeben werden.

[Bearbeiten] C++

Das folgende Beispiel zeigt die Entstehung eines Speicherlecks anhand eines in C++ implementierten Programmes:

int main()
{
   int * pi = new int[5]; // Speicher für 5 Objekte vom Typ int angefordert
   delete pi;             // Speicher wird versehentlich nur für das erste Objekt freigegeben 
   return 0;
}

//Korrekt: delete[] pi;

[Bearbeiten] Automatische Speicherbereinigung

Das folgende Beispiel zeigt das Versagen des Ansatzes der automatischen Speicherbereinigung im Pseudocode:

PROCEDURE main
 LIST a
 LOOP
  a.INSERT(1)
  IF DATE() == START_TIME()+10000 THEN BREAK
 END
END

Man sieht hier deutlich, dass der Speicherbedarf ständig anwächst. Unter der Annahme, dass der zunehmende Speicherbedarf selbst nicht Zweck des Programms ist, handelt es sich also um ein Speicherleck, da gar kein lesender Zugriff auf die Listen-Einträge erfolgt. Dieser Fehler wäre recht leicht durch statische Analyse zu erkennen, während aber der Graph aus Referenzen und Speicherbereichen den Fehler nicht erkennen lässt.