Übungen zu Systemprogrammierung 1 (SP1)

Ähnliche Dokumente
Überblick. Verlässliche Echtzeitsysteme. Anmeldung an Gerrit I. Gerrit. Übungen zur Vorlesung. Isabella Stilkerich, Florian Franzmann, Martin Hoffmann

Übungen zu Systemprogrammierung 1

Übungen zu Systemprogrammierung 1 (SP1)

Übungen zu Softwaresysteme I Jürgen Kleinöder Universität Erlangen-Nürnberg Informatik 4, 2004 E-Uebung3.fm

Übungen zu Systemprogrammierung 1

Übungen zu Systemprogrammierung 1 (SP1)

Tools zur Programmierung mit C Software Entwicklung 1

Lehrstuhl für Datenverarbeitung. Technische Universität München. Grundkurs C++ Debugging

Ein-Ausgabefunktionen in C (letzter Abschnitt Vorlesungsstoff ab C.110)

U3 3. Übung U3-1 Fehlerbehandlung U3 3. Übung U3-1 Fehlerbehandlung malloc(3) open(2) qsort(3) erkennt Fehler angebrachte Behandlung

Übungen zu Systemprogrammierung 1 (SP1)

Übungen zu Systemprogrammierung 1 (SP1)

Teil I Debuggen mit gdb

Übungen zu Systemprogrammierung 1

Lehrstuhl für Datenverarbeitung. Technische Universität München. Grundkurs C++ Dokumentation mit Doxygen

Computergestütztes wissenschaftliches Rechnen SoSe 2004

Advanced Programming in C

Betriebssysteme. Tafelübung 4. Speicherverwaltung. Olaf Spinczyk.

Kurzeinführung in C99

Betriebssysteme. Tafelübung 4. Speicherverwaltung. Olaf Spinczyk.

Betriebssysteme. Agenda. Tafelübung 4. Speicherverwaltung. Olaf Spinczyk.

Debugging mit GDB Albrecht Oster Proseminar C - Grundlagen und Konzepte

K Ergänzungen zur Einführung in C

Valgrind. Speicherleaks und Bugs finden. Frederik Heber. Seminarreihe Technische Numerik. Institut für Numerische Simulation, Universität Bonn

Übungen zu Systemprogrammierung 2 (SP2)

Effizientes Memory Debugging in C/C++

C für Fortgeschri/ene 2 Dynamische Speicherverwaltung Programmprüfung und Debugging. Benedikt Huber

Exploit-Entwicklung mit Python

Variablen. Deklaration: «Datentyp» «Variablenname» Datentyp bestimmt Größe in Bytes: sizeof Beispiel: long int v; Größe: 4 Bytes

Einführung in die Programmiersprache C

Einführung in die Programmiersprache C

Übungen zu Softwaresysteme I Jürgen Kleinöder Universität Erlangen-Nürnberg Informatik 4, 2004 K-Uebung9.fm

Informatik. Pointer (Dynamisch) Vorlesung. 17. Dezember 2018 SoSe 2018 FB Ing - SB Umwelttechnik und Dienstleistung - Informatik Thomas Hoch 1

Bedienungshinweise für XEmacs, make und GNU Debugger

Debugging mit ddd (Data Display Debugger)

U4-1 Aufgabe 3: einfache malloc-implementierung

C/C++-Programmierung


ESP Tutorium. Studienassistent: Ewald Moitzi. Gruppe 1

Probeklausur Name: (c)

Fehlererkennung. C - Kurs September This work is licensed under a Creative Commons AttributionNonComercialShareAlike 3.0 License.

Präprozessor und make. einfache Makros Makros nehmen eine Textersetzung vor. Erst nach der Ersetzung muss gültiger C-Code vorliegen.

Speicherverwaltung in C

Lehrstuhl Informatik 4

C/C++ Debugging mit CDT unter Eclipse

Programmieren in Haskell Debugging

Systemprogrammierung

Aufgabe 3. Aufgabe 4.

Einführung Sprachfeatures Hinweise, Tipps und Styleguide Informationen. Einführung in C. Patrick Schulz

F Zeiger, Felder und Strukturen in C

Lehrstuhl Informatik 4

Kontrollfragen Mikrocontroller Programmiersprache C H1203 Felix Rohrer

Übungspaket 29 Dynamische Speicherverwaltung: malloc() und free()

Programmiersprachen Einführung in C

Einführung in die Programmiersprache C

Mint Medical GmbH. Einführung in. Valgrind. (dynamische Speicheranalyse) Lucas Beyer. Seite

Übungen zu Systemnahe Programmierung in C (SPiC) Inhalt. Sebastian Maier, Heiko Janker (Lehrstuhl Informatik 4) Übung 5. Wintersemester 2015/2016

Einführung in die Programmierung zusammengesetzte Datentypen, dynamischer Speicher

EZS Handwerkszeug. Übung zur Vorlesung EZS. Florian Franzmann Martin Hoffmann Tobias Klaus Peter Wägemann

Programmiertechnik. Teil 4. C++ Funktionen: Prototypen Overloading Parameter. C++ Funktionen: Eigenschaften

2Binden 3. und Bibliotheken

Datenkapselung: public / private

Übung zu Grundlagen der Betriebssysteme. 3. Übung

Praktikum zu Einführung in die Informatik für LogWiIngs und WiMas Wintersemester 2017/18. Vorbereitende Aufgaben

Dynamische Speicherverwaltung

Zeiger vom Typ void* benötigen weniger Speicher als andere Zeiger, da bei anderen Zeigertypen zusätzlich die Größe gespeichert werden muss.

Annahmen. Verlässliche Echtzeitsysteme. Frage 5. Frage 4. Zu was wird -1L > 1U auf x86-64 ausgewertet? Auf x86?

Verlässliche Echtzeitsysteme

4. Speicherverwaltung

Mapra: C++ Teil 2. Felix Gruber, Sven Groß. 2. Mai 2017 IGPM. Felix Gruber, Sven Groß (IGPM) Mapra: C++ Teil 2 2. Mai / 11

Software Entwicklung 1

Inhalt Übungen zu Systemnahe Programmierung in C (SPiC) Inhalt. Terminal - historisches (etwas vereinfacht) Seriell. Computer. Netzwerk DFÜ.

4. Speicherverwaltung

Programmverstehen + Fehlersuche

Homogene Multi-Core-Prozessor-Architekturen

Zeiger. C-Kurs 2012, 2. Vorlesung. Tino Kutschbach 10.

Crashkurs C++ - Teil 1

225. gdb der Gnu Debugger

Datenstrukturen, Alignment Stack Prozeduraufruf, Parameterübergabe und -rückgabe (Calling Conventions) Leaf procedures

Übungen zur Vorlesung Systemsicherheit

DAP2 Praktikum Blatt 1

Pointer und Array Bugs in C / C++: Werkzeuge jenseits des Debuggers. Klaus Kusche, Juni 2013

1 Fehler in Bibliotheksfunktionen. 1 Überblick. 2 Ziele der Aufgabe. Besprechung der 1. Aufgabe

Praktikum zu Einführung in die Informatik für LogWiIngs und WiMas Wintersemester 2016/17. Vorbereitende Aufgaben

Dynamische Speicherverwaltung

Dynamischer Speicher

Offenbar hängt das Ergebnis nur von der Summe der beiden Argumente ab...

Übungen zu Grundlagen der systemnahen Programmierung in C (GSPiC) im Sommersemester 2018

U3-1 Organisatorisches

Praktikum angewandte Systemsoftwaretechnik (PASST)

Übungen zu Systemnahe Programmierung in C (SPiC) Inhalt. Moritz Strübe, Rainer Müller (Lehrstuhl Informatik 4) Sommersemester 2014

1 pulsierender Speicher

7. Organisation von Informationen

Typ : void* aktuelle Parameter Pointer von beliebigem Typ

Dynamisches Speichermanagement

Einführung. Übungen zur Vorlesung Virtuelle Maschinen. Stefan Potyra. SoSe 2009

Beispiel 2a Die eigenen ersten Schritte mit dem Gnu-Debugger GDB für Remote-Debugging

Totalview. Henrichs NEC Australia. Dieter an Mey

Transkript:

Übungen zu Systemprogrammierung 1 (SP1) B1 Debugging Jens Schedel, Christoph Erhardt, Jürgen Kleinöder Lehrstuhl für Informatik 4 Verteilte Systeme und Betriebssysteme 03-B1_handout Friedrich-Alexander-Universität Erlangen-Nürnberg SS 2015 04. bis 08. Mai 2015 https://www4.cs.fau.de/lehre/ss15/v_sp1

Agenda 3.1 Linux-Install-Party der FSI 3.2 Haupteingang nach Walhall 3.3 gdb 3.4 Gelerntes anwenden 03-B1_handout c js, ce, jk SP1 (B1 SS 2015) 3 Debugging 3 2

Agenda 3.1 Linux-Install-Party der FSI 3.2 Haupteingang nach Walhall 3.3 gdb 3.4 Gelerntes anwenden install-party: 2015-04-28 c js, ce, jk SP1 (B1 SS 2015) 3 Debugging 3.1 Linux-Install-Party der FSI 3 3

Veranstaltungshinweis Linux-Install-Party der FSI am Mittwoch, den 06.05.2015, um 14:00 im 02.152-113 (Blaues Hochhaus, 2. Stock) weitere Informationen unter https://fsi.informatik.uni-erlangen.de/linuxinstall install-party: 2015-04-28 c js, ce, jk SP1 (B1 SS 2015) 3 Debugging 3.1 Linux-Install-Party der FSI 3 4

Agenda 3.1 Linux-Install-Party der FSI 3.2 Haupteingang nach Walhall 3.3 gdb 3.4 Gelerntes anwenden valgrind: 2015-04-20 c js, ce, jk SP1 (B1 SS 2015) 3 Debugging 3.2 Haupteingang nach Walhall 3 5

valgrind Baukasten von Debugging- und Profiling-Werkzeugen Für uns relevant: memcheck Erkennt Speicherzugriff-Probleme: Nutzung von nicht-initialisiertem Speicher Zugriff auf freigegeben Speicher Zugriff über das Ende von allozierten Speicherbereichen valgrind: 2015-04-20 c js, ce, jk SP1 (B1 SS 2015) 3 Debugging 3.2 Haupteingang nach Walhall 3 6

valgrind Zugriffe auf nicht allozierten Speicher finden =711= Invalid read of size 4 =711= at 0x804841B: main (test.c:19) =711= Address 0x0 is not stack d, malloc d or (recently) free d =711= =711= Process terminating with default action of signal 11 (SIGSEGV) =711= Access not within mapped region at address 0x0 In Zeile 19 wird lesend auf die Adresse 0x0 zugegriffen Der Prozess wird auf Grund einer Speicherzugriffsverletzung (SIGSEGV) beendet valgrind: 2015-04-20 =787= Invalid write of size 1 =787= =787= at 0x48DC9EC: memcpy (mc_replace_strmem.c:497) by 0x80485A2: test_malloc (test.c:57) =787= by 0x80484A8: main (test.c:22) =787= Address 0x6d1f02d is 0 bytes after a block of size 5 alloc d In Zeile 57 wird memcpy aufgerufen, welches ein Byte an eine ungültige Adresse schreibt c js, ce, jk SP1 (B1 SS 2015) 3 Debugging 3.2 Haupteingang nach Walhall 3 7

valgrind Auffinden von nicht freigegebenem Speicher =787= HEAP SUMMARY: =787= in use at exit: 5 bytes in 1 blocks =787= total heap usage: 1 allocs, 0 frees, 5 bytes allocated Bei Programmende ist noch ein Speicherbereich (Block) belegt Während der Programmausführung wurde einmal malloc() und keinmal free() aufgerufen Mit Hilfe der Option --leak-check=full --show-reachable=yes wird angezeigt, wo der Speicher angelegt wurde, der nicht freigegeben wurde. valgrind: 2015-04-20 =799= 5 bytes in 1 blocks are definitely lost in loss record 1 =799= =799= at 0x48DAF50: malloc (vg_replace_malloc.c:236) by 0x8048576: test_malloc (test.c:52) =799= by 0x80484A8: main (test.c:22) In Zeile 52 wurde der Speicher angefordert Im Quellcode Stellen identifizieren, an denen free()-aufrufe fehlen c js, ce, jk SP1 (B1 SS 2015) 3 Debugging 3.2 Haupteingang nach Walhall 3 8

valgrind Auffinden uninitialisierten Speichers =799= Use of uninitialised value of size 4 =799= at 0x4964316: _itoa_word (_itoa.c:195) =799= by 0x4967C59: vfprintf (vfprintf.c:1616) =799= by 0x496F3DF: printf (printf.c:35) =799= by 0x8048562: test_int (test.c:48) =799= by 0x8048484: main (test.c:15) In Zeile 48 wird auf uninitialisierten Speicher zugegriffen Mit Hilfe der Option --track-origins=yes wird angezeigt, wo der uninitialisierte Speicher angelegt wurde valgrind: 2015-04-20 =683= Use of uninitialised value of size 4 =683= at 0x4964316: _itoa_word (_itoa.c:195) =683= by 0x4967C59: vfprintf (vfprintf.c:1616) =683= by 0x496F3DF: printf (printf.c:35) =683= by 0x8048562: test_int (test.c:48) =683= by 0x8048484: main (test.c:15) =683= Uninitialised value was created by a stack allocation =683= at 0x804846A: main (test.c:10) c js, ce, jk SP1 (B1 SS 2015) 3 Debugging 3.2 Haupteingang nach Walhall 3 9

valgrind Spezialfall: Zugriff auf uninitialisierten Speicher bei Bedingungsprüfungen =683= Conditional jump or move depends on uninitialised value(s) =683= at 0x48DC0E7: GI_strlen (mc_replace_strmem.c:284) =683= by 0x496886E: vfprintf (vfprintf.c:1617) =683= by 0x496F3DF: printf (printf.c:35) =683= by 0x8048562: test_int (test.c:48) =683= by 0x8048484: main (test.c:15) valgrind: 2015-04-20 c js, ce, jk SP1 (B1 SS 2015) 3 Debugging 3.2 Haupteingang nach Walhall 3 10

Agenda 3.1 Linux-Install-Party der FSI 3.2 Haupteingang nach Walhall 3.3 gdb 3.4 Gelerntes anwenden gdb: 2015-04-20 c js, ce, jk SP1 (B1 SS 2015) 3 Debugging 3.3 gdb 3 11

Debugger: gdb Ein Debugger dient zum Suchen und Finden von Fehlern in Programmen Im Debugger kann man u.a. das Programm schrittweise abarbeiten Variablen- und Speicherinhalte ansehen und modifizieren core dumps (Speicherabbilder beim Programmabsturz) analysieren Erlauben von core dumps (in der laufenden Shell): z. B. limit coredumpsize 1024k oder limit coredumpsize unlimited Programm sollte Debug-Symbole enthalten mit GCC-Flag -g übersetzen Aufruf des Debuggers mit gdb <Programmname> gdb: 2015-04-20 c js, ce, jk SP1 (B1 SS 2015) 3 Debugging 3.3 gdb 3 12

Beispiel void initarray(long *array, unsigned int size) { int i; for ( i=0; i<=size; i++ ) { array[i] = 0; } } int main(int argc, char *argv[]) { long *array; long buf[7]; array = buf; initarray(buf,sizeof(buf)/sizeof(long)); while ( array!= buf+sizeof(buf)/sizeof(long) ) { printf("%ld\n", *array); array++; } gdb: 2015-04-20 } exit(exit_success); c js, ce, jk SP1 (B1 SS 2015) 3 Debugging 3.3 gdb 3 13

Befehlsübersicht Programmausführung beeinflussen Breakpoints setzen: b [<Dateiname>:]<Funktionsname> b <Dateiname>:<Zeilennummer> Starten des Programms mit run (+ evtl. Befehlszeilenparameter) Fortsetzen der Ausführung bis zum nächsten Stop mit c (continue) schrittweise Abarbeitung auf Ebene der Quellsprache mit s (step: läuft in Funktionen hinein) n (next: behandelt Funktionsaufrufe als einzelne Anweisung) Breakpoints anzeigen: info breakpoints Breakpoint löschen: delete breakpoint# gdb: 2015-04-20 c js, ce, jk SP1 (B1 SS 2015) 3 Debugging 3.3 gdb 3 14

Befehlsübersicht Variableninhalte anzeigen/modifizieren Anzeigen von Variablen mit: p expr expr ist ein C-Ausdruck, im einfachsten Fall der Name einer Variable Automatische Anzeige von Variablen bei jedem Programmstopp (Breakpoint, Step,...): display expr Setzen von Variablenwerten mit set <variablenname>=<wert> Ausgabe des Funktionsaufruf-Stacks (backtrace): bt Quellcode an aktueller Position anzeigen: list gdb: 2015-04-20 Watchpoints: Stoppt Ausführung bei Zugriff auf eine bestimmte Variable watch expr: Stoppt, wenn sich der Wert des C-Ausdrucks expr ändert rwatch expr: Stoppt, wenn expr gelesen wird awatch expr: Stopp bei jedem Zugriff (kombiniert watch und rwatch) Anzeigen und Löschen analog zu den Breakpoints c js, ce, jk SP1 (B1 SS 2015) 3 Debugging 3.3 gdb 3 15

Agenda 3.1 Linux-Install-Party der FSI 3.2 Haupteingang nach Walhall 3.3 gdb 3.4 Gelerntes anwenden 03-B1_handout c js, ce, jk SP1 (B1 SS 2015) 3 Debugging 3.4 Gelerntes anwenden 3 16

Aktive Mitarbeit erforderlich! Aufgabenstellung Einfach verkettete Liste mit fifo-semantik int insertval(int val): Fügt den Wert val in die verkettete Liste ein. val darf nicht negativ sein. int removeval(): Entfernt den ältesten Wert aus der Liste und gibt diesen zurück. Ist die Liste leer, wird -1 zurückgeliefert. 03-B1_handout c js, ce, jk SP1 (B1 SS 2015) 3 Debugging 3.4 Gelerntes anwenden 3 17