Quelltext der Seite Speicherleck

'''Speicherleck''' ({{enS|''memory leak''}}, gelegentlich auch ''Speicherloch'' oder kurz ''memleak'') bezeichnet einen Fehler in der [[Speicherverwaltung]] eines [[Computerprogramm]]s, der dazu führt, dass es einen Teil des [[Arbeitsspeicher]]s zwar belegt, diesen jedoch weder freigibt noch nutzt.

== Problematik ==
Arbeitsspeicher ist ein nur in endlicher Menge verfügbares [[Betriebsmittel (Informatik)|Betriebsmittel]], das einem Programm auch nicht ohne weiteres wieder entzogen werden darf. Wenn ein Programm durch Speicherlecks zunehmend mehr Arbeitsspeicher belegt, kann es dazu kommen, dass die Leistungsfähigkeit des Computers sinkt, da Teile des Arbeitsspeichers [[Paging|ausgelagert]] werden müssen.<!-- Das kann auch zum sogenannten [[Thrashing]] führen, wobei ständig Seiten in den [[Auslagerungsdatei|Hintergrundspeicher]] aus- und wieder eingelagert werden. // ? Dann müsste der 'lecke' Speicher noch verwendet werden, was der Def. 'Speicherleck' widerspricht! --> Wenn die Menge an Speicher, die ein [[Prozess (Informatik)|Prozess]] belegen kann, beschränkt wurde, ist es dem Programm irgendwann nicht mehr möglich, weiter Speicher zu [[Allokation (Informatik)|allozieren]] und es kommt zu einem [[Programmfehler]]. Bei Betriebssystemen mit unzureichendem Speicherschutz (z. B. bei [[Eingebettetes System|Embedded-Systemen]]) kann im [[Worst Case|schlimmsten Fall]] die Überbelegung des Speichers dazu führen, dass auch Teile des [[Betriebssystem]]s nicht mehr korrekt ausgeführt werden können und das System [[Systemabsturz|abstürzt]].

== Lösungsmöglichkeiten ==
Um Speicherlecks aufzuspüren, existieren mehrere Möglichkeiten:
# Analyse der Referenzen auf [[Speicherbereich]]e (z.&nbsp;B. [[Smart Pointer]]); diese Analyse erkennt nur nicht mehr zugreifbare Speicherbereiche.
# Analyse des [[Quelltext]]s auf [[Korrektheit (Informatik)|formale Korrektheit]].
# Analyse konkreter Laufzeit-Situationen im Rahmen eines Software-Tests.

=== Einschränkung negativer Auswirkungen ===
Der Speicher, der höchstens von einem Prozess belegt werden darf, kann durch das Betriebssystem beschränkt werden. Das behebt den ursprünglichen Fehler nicht, aber begrenzt die Auswirkungen auf andere Prozesse.

Unter [[Linux]] existiert eine [[Betriebssystemkernel|Kernelfunktion]], der ''OOM-Killer'' (engl. {{lang|en|out of memory killer}}), die zum Einsatz kommt, wenn alle Versuche fehlschlugen, Speicher zu allozieren. Sie wählt unter den laufenden Prozessen u.&nbsp;a. denjenigen mit dem höchsten Speicherbedarf, der kürzesten [[Laufzeit (Informatik)|Laufzeit]] und der niedrigsten Priorität und beendet diesen zwangsweise. Nach Beendigung des Prozesses wird aller von ihm belegter Arbeitsspeicher wieder freigegeben.<ref>[http://linux-mm.org/OOM_Killer linux-mm.org]</ref>

=== Automatische Speicherbereinigung ===
Falls die verwendete Laufzeitumgebung eine [[automatische Speicherbereinigung]] (''Garbage collection'') bereitstellt, versucht diese zu ermitteln, auf welche Speicherbereiche ein Prozess nicht mehr zugreifen kann. Stellt die Laufzeitumgebung fest, dass ein belegter Speicherbereich für das Programm nicht mehr ''erreichbar'' ist, wird dieser wieder freigegeben. Nicht mehr erreichbar heißt in diesem Zusammenhang, dass keine gültige [[Referenz (Programmierung)|Referenz]] – ausgenommen ''weak references'' – auf den belegten Speicherbereich mehr existiert. Speicherlecks können dabei dennoch entstehen, wenn der Speicher für das Programm noch erreichbar ist, d.&nbsp;h. es eine Referenz auf den Speicher hält, ihn aber dennoch nicht mehr verwendet.

=== Explizite Speicherfreigabe ===
Im Gegensatz zur automatischen Speicherbereinigung muss der Anwendungsentwickler bei einer manuellen Speicherverwaltung explizit [[Dynamischer Speicher|dynamische Speicherbereiche]] wieder freigeben. Versäumt er dies bspw. am Ende einer Funktion, wird anschließend die Referenz auf den noch reservierten Speicher gelöscht und der Bereich kann nicht mehr freigegeben werden.

=== 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 (auf Linux-Systemen) ist ''memcheck'' von [[Valgrind]]. Es führt eine Liste der allozierten Speicherbereiche mit und an welcher Stelle im Programm die Allokation stattfand. Bei Programmende überprüft es, ob alle allozierten Bereiche auch wieder freigegeben wurden. In sehr einfachen oder sehr gravierenden Fällen kann es ausreichen, nur den Speicherverbrauch eines Prozesses im zeitlichen Verlauf zu beobachten.

=== RAII ===
Eine [[Programmiertechnik]], die Speicherlecks verhindern kann, ist [[Ressourcenbelegung ist Initialisierung|RAII]] (Ressourcenbelegung ist Initialisierung). Hierbei wird der Speicherbereich einer Variablen bei ihrer Initialisierung reserviert und beim Verlassen ihres Gültigkeitsbereichs automatisch wieder freigegeben. Das hat gegenüber der automatischen Speicherverwaltung den Vorteil, dass die „Lebensdauer“ eines Objekts in der Regel genau bekannt ist.

RAII schützt nicht in jedem Fall vor Speicherlecks zweiter Art.

=== Formale Verifikation ===
Durch einen [[Korrektheit (Informatik)|Korrektheitsbeweis]] können insbesondere auch Speicherlecks entdeckt werden. Dieses Verfahren ist jedoch sehr zeitaufwendig und benötigt Expertenwissen. Die auf Speicherlecks spezialisierte Frage kann auch computergestützt mittels [[Statische Code-Analyse|Statischer Code-Analyse]] untersucht werden.

== Beispiele ==

=== C ===
Das bekannteste Beispiel für fehlende automatische Speicherverwaltung ist die Sprache [[C (Programmiersprache)|C]]. Neuer Speicher wird hier durch Funktionen wie <span style="font-family:monospace;">malloc</span> angefordert. Dabei liefern diese einen [[Zeiger (Informatik)|Zeiger]] auf den Anfang des entsprechenden Speicherbereichs. Der Verweis ist notwendig, um die Zuweisung zu identifizieren und sie mittels geeignetem Code wieder freizugeben (der Funktion <span style="font-family:monospace;">free</span>) oder nachträglich zu modifizieren. Geht der Zeiger verloren, dann kann der Prozess nicht mehr auf diesen Speicher zugreifen und ihn damit auch nicht freigeben, bzw. während seiner Laufzeit erneut verwenden. Ein verwandtes Problem besteht, wenn der Zeiger verändert wird, sowie umgekehrt, wenn der Speicher fälschlicherweise [[Mehrfache Deallokation|mehrfach deallokiert]] wird.

Das folgende Beispiel zeigt die Entstehung solch eines Speicherlecks:
<syntaxhighlight lang="c">
#include <stdlib.h>

int main(void)
{
   int *a; /* Zeiger auf einen als Ganzzahl interpretierten Speicherbereich */

   /* Speicher für Zeiger reservieren. */
   a = malloc(sizeof(int));
   /* ... */
   a = malloc(sizeof(int));   /* Zeiger auf zuvor allokierten Speicher wird überschrieben. */

   free(a);  /* Nur der zweite Speicherblock wird freigegeben --> Speicherleck */

   return EXIT_SUCCESS;
}
</syntaxhighlight>

Ab dem zweiten <code>a = malloc()</code> ist es nicht mehr möglich, auf den Speicherbereich zuzugreifen, auf den ''a'' zuvor verwies. Der Bereich kann dann regulär nicht mehr vom Programm freigegeben werden.

=== Automatische Speicherbereinigung ===
Das folgende Beispiel in [[Java (Programmiersprache)|Java]] zeigt, dass alleine der Ansatz der [[Automatische Speicherbereinigung|automatischen Speicherbereinigung]] nicht reicht, um Speicherlecks aufzudecken:

<syntaxhighlight lang="java">
private static List<Integer> nummern = new ArrayList<>();
public void erzeugeSpeicherleck() {
  for (int i=1; i<10000; i++)
    nummern.add(i);
}
// kein weiterer lesender Zugriff auf die List nummern
</syntaxhighlight>

Man erkennt hier, dass der Speicherbedarf ständig anwächst, es handelt sich also um ein Speicherleck, da kein lesender Zugriff mehr auf die Listen-Einträge erfolgt. Dieser Fehler wäre recht leicht durch [[statische Analyse]] zu erkennen, wohingegen der Graph aus Referenzen und Speicherbereichen den Fehler nicht erkennen lässt.

== Weblinks ==
* [http://linux-mm.org/OOM_Killer Die Arbeitsweise des OOM-Killers des Linux-Kernels] (englisch)
* [http://valgrind.org/ Valgrind Homepage]
* [http://www.codeguru.com/Cpp/W-P/ce/article.php/c3513 Memory leak detection for WinCE(-Applications)]
* [http://www.hboehm.info/gc/ A garbage collector for C/C++]

== Einzelnachweise ==
<references />

[[Kategorie:Speicherverwaltung]]
[[Kategorie:Programmfehler]]