rozummially trucks-记得无循环

In diesem Abschnitt, die Übung, wollen wir euch erklären,

wie ihr Speicher zuûtveler in euremואiamen Programmen entdecken und beheben könnt.

Das Programm, das wir dazu benutzen ist Wallgrind.

Bei Wallgrind handelt es sich um eine Sammlung von Werkzeugen

die einem dabei helfen Programme zu debucken und ein Profil darüber zu erstellen.

Das bedeutet, die Laufzeit des Programms zu analisieren

Für uns ist dabei nur ein kleiner Teil von Walcrant relevant, nämlich Memcheck.

Mit diesem Teil können wir Speicherzugriffe überprüfen und schauen, ob diese auf nicht

initialisierten Speicher zugreifen oder ob wir auf Speicherzugreifen, der bereits wieder

freigegeben wurde.

Ebenfalls können wir überprüfen, ob wir über den zugewiesenen Speicher in irgendeiner

Art und Weise hinausgreifen.

Damit wir Walcrant sinnvoll nutzen können, müssen wir beim Kompilieren die Option bin

strich klein g mit übergeben, damit wir Debug-Symbole in unserem Programm haben.

Dabei muss betont werden, dass eine Laufzeitprüfung wie sie Wallgrind anstellt,

nur die Anwesenheit von Fehlern zeigen kann, nicht aber deren Abwesenheit.

Das bedeutet, dass abhängig von den Eingaben gegebenenfalls noch Fehler auftreten können,

die ihr bei eurer Überprüfung mit Wallgrind nicht gefunden habt.

Da die Ausgabe von Wallgrind, wenn man seine Fehler damit finden möchte, ein bisschen

schwierig zu lesen ist, geben wir auch diesmal wieder eine Einführung.

Dafür haben wir hier ein kleines Beispiel vorbereitet, mit einem Programm, das seg-foldet

sobald ich es ausführe.

Wenn ich wissen möchte, an welcher Stelle das Programm seg-foldet, ist es zu empfehlen,

dass ich das Programm einmal mit Wallgrind ausführe.

Um es mit Wallgrind auszuführen, tippe ich einfach Wallgrind und dann die Namen des

Programmes.

Wenn ich dies nun ausführe, bekomme ich eine Ausgabe, die aussieht wie folgt.

Was ich hier herauslesen kann ist, dass der Prozess terminiert ist, weil ein Segmentation

Folter zugestellt bekommen hat.

So viel wusste ich auch schon vorher.

Was spannender ist, ist, was noch weiter oben steht.

Hier steht nämlich der Grund, weshalb und an welcher Stelle das Programm gesequoltet

ist.

Hier heißt es Invalid Read of Size 8.

Das bedeutet, ich habe an einer Stelle 8 Bytes gelesen und diese Stelle war nicht gültig.

Gefolgt von einem Stack Trace, der mir aufzeigt, an welcher Stelle dies geschehen ist.

Plus in der letzten Zelle, die noch hervorgehoben ist, steht, dass dies an der Adresse 0 geschehen

ist und dass die Adresse 0 weder auf dem Stack ist, nicht allokiert wurde via malloc und

auch keine Adresse ist, die wieder durch Free freigegeben wurde.

Besonders hilfreich ist an dieser Stelle nun der Stack Trace.

Hieraus kann ich lesen, dass das Programm in Zeile 14 in der Datei SackFault.c diesen

ungebildigen Speicherzugriff hatte.

Also springe ich nun in Zeile 14 der Datei und was ich an dieser Stelle habe, ist der

Vergleich eines Members einer globalen Variable mit null.

Da die Fehlermeldung bedeutet invalid read of size 8, muss ich davon ausgehen, dass von

einer Adresse gelesen wurde.

Das bedeutet, irgendein Wert wurde von Adresse 0 geladen.

Und das einzige, was auf dieses Muster zugetrifft, ist an dieser Stelle die Dereferenzierung von

Pointer next, weil es sich bei ptr um ein Zeiger handelt, auf ein Stück Speicher, und