Mailinglist Archive: opensuse-programming-de (118 mails)

[Eilert Brinkmann <eilert@xxxxxxxxxxxxxxxxxxxxxxxx>]

Peter Wiersig wrote:
> Bernhard Walle wrote:
> > 
> > Warum? Könntest Du / ein anderer das etwas näher (für Anfänger wie
> > mich) erläutern? Was heißt "Speicherleck"?

Es geht reservierter Speicher "verloren": Man benutzt ihn nicht mehr,
gibt ihn aber auch nicht wieder frei. Um das in das Beispiel
einzubauen, sagen wir mal, main() legt den String in dynamisch
reservierten Speicher und übergibt dann den Pointer darauf an tester():

  [...]
  char *field = strdup("teststring");
  tester(&field);
  [...]

Nun überschreibt die Funktion tester() den Pointer mit einem anderen
Wert, nämlich den Pointer auf einen neuen String:

  void tester(char **t)
  {
    *t = strdup("langer string");
  }

Dann ist der ursprüngliche Wert des Pointers field weg, denn field
zeigt jetzt ja auf den von tester() mit strdup() neu angelegten
Speicherbereich. Damit ist der von main() mit strdup() angelegte
Speicherbereich nicht mehr ansprechbar, aber -- er wurde ja nicht
freigegeben -- weiterhin reserviert. Wenn sich solche Sachen häufen
und das Programm länger läuft, dann wird der Speicherbedarf des
Prozesses mit der Zeit ganz schön groß...

Abhilfe könnte man z.B. schaffen, indem tester() den alten
Speicherbereich erst freigibt:

  void tester(char **t)
  {
    free(*t);
    *t = strdup("langer string");
  }

Das ist dann im Endeffekt so ähnlich wie Deine Variante mit realloc(),
nur daß der neue Speicherbereich ruhig eine andere Anfangsadresse als
der alte haben kann. Bei einer solchen Lösung darf *t aber keinesfalls
ein Zeiger auf eine String-Konstante sein, denn die kann man natürlich
nicht freigeben.

> http://www.dwheeler.com/secure-programs/Secure-Programs-HOWTO/buffer-overflow.html

Nein, Pufferüberläufe sind etwas anderes als Speicherlecks. Bei einem
Pufferüberlauf geht kein reservierter Speicher verloren, sondern es
wird über die Grenzen eines zu kleinen Speicherbereichs hinaus
geschrieben -- die möglichen Folgen sind im allgemeinen nicht gerade
harmloser...

Eilert
-- 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
       Eilert Brinkmann -- Universitaet Bremen -- FB 3, Informatik
            eilert@xxxxxxxxxxxxxxxxxxxxxxxx - eilert@xxxxxxx
              http://www.informatik.uni-bremen.de/~eilert/