\documentclass{lxarticle} \usepackage{german} \usepackage[utf8]{inputenc} \usepackage{lxheaders} \usepackage{lxextras} \lstset{keywordstyle=\color{blue}} \begin{document} \section*{STRACE} Eine sehr einfache und mächtige Möglichkeit, Systemaufrufe und Signale zu tracen, ist das Tool ''strace''. Die Anwendung ist denkbar einfach. Dem Aufruf des zu tracenden Programms wird einfach strace vorangestellt: \begin{lstlisting}[language=bash] $ strace /bin/ls execve("/bin/ls", ["/bin/ls"], [/* 50 vars */]) = 0 brk(0) = 0x2246000 access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or directory) mmap(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f32457fe000 access("/etc/ld.so.preload", R_OK) = -1 ENOENT (No such file or directory) open("/etc/ld.so.cache", O_RDONLY) = 3 fstat(3, {st_mode=S_IFREG|0644, st_size=110532, ...}) = 0 mmap(NULL, 110532, PROT_READ, MAP_PRIVATE, 3, 0) = 0x7f32457e3000 close(3) = 0 \end{lstlisting} Strace besitzt eine Vielzahl von Commandline\-para\-metern. Die wichtigsten davon sind:\\ \begin{center} \begin{tabular}{|c|p{5cm}|} \hline \textbf{Parameter} & \textbf{Zweck} \\ \hline -f & follow forks \\ \hline -v & Verbose mode \\ \hline -T & Zeit ausgeben, die in jedem Syscall verbracht wird \\ \hline -p PID & Auf PID attachen \\ \hline \end{tabular} \end{center} \section*{GDB} \subsection*{Interaktives Debugging mit GDB} Der GNU Debugger: GDB stellt einen vollwertigen interaktiven Debugger dar, der für alle gängigen Prozessorarchitekturen verfügbar ist. GDB bietet ein sehr mächtiges Commandlineinterface. Es existieren diverse grafische Frontends für GDB (z.B. DDD). Eine einfache Debuggingsession stellt sich wie folgt dar: \begin{lstlisting}[language=c] /* hello.c */ #include int main (void) { printf("Hello world\n"); return 0; } \end{lstlisting} Übersetzen des Programms mit Debuginformationen: \begin{lstlisting} $ gcc -g -o hello hello.c \end{lstlisting} Starten der Debugsession: \begin{lstlisting} $ gdb ./hello (gdb) run Starting program: /home/jan/work/examples/hello Hello world Program exited normally. \end{lstlisting} Mit dem Kommando ''list'' kann der zugehörige Quellcode angezeigt werden. Breakpoints werden mit ''break'' gesetzt: \begin{lstlisting} (gdb) list 1 #include 2 3 int main (void) 4 { 5 printf("Hello world\n"); 6 return 0; 7 } (gdb) break 5 Breakpoint 1 at 0x400528: file hello.c, line 5. \end{lstlisting} Mit ''next'' und ''step'' werden einzelne Codezeilen ausgeführt, während ''next'' einem step-OVER und ''step'' einem step-IN entspricht: \begin{lstlisting} (gdb) run Starting program: /home/jan/work/examples/hello Breakpoint 1, main () at hello.c:5 5 printf("Hello world\n"); (gdb) next Hello world 6 return 0; (gdb) continue Continuing. \end{lstlisting} Folgende Tabelle zeigt eine Übersicht der wichtigsten GDB Kommandos:\\ \begin{center} \begin{tabular}{|l|c|p{8cm}|} \hline \textbf{Kommando} & \textbf{Abkürzung} & \textbf{Zweck} \\ \hline run & r & Programm starten \\ \hline continue & c & Programm fortsetzen \\ \hline break X & b & Breakpoint in Zeile X setzen \\ \hline step & s & step IN \\ \hline next & n & step OVER \\ \hline print var & -- & Inhalt von Variable var anzeigen \\ \hline display var & -- & Inhalt von Variable var jedes mal anzeigen, wenn das Programm stoppt \\ \hline backtrace & bt & Backtrace anzeigen \\ \hline frame X & f & Im aktuellen Stack zu Frame Nr. X wechseln \\ \hline quit & q & GDB beenden \\ \hline \end{tabular} \end{center} \subsection*{Analyse von core-Files} Neben der Möglichkeit des interaktiven Debuggings findet GDB auch häufig eine weitere Anwendung: Die ''Post-Mortem-Analyse'' von Problemen. Wird eine Applikation beispielsweise durch seinen Segmentation Fault beendet, wird ein sogenanntes core-File erzeugt, welches u.A. den aktuellen Stack der Applikation beinhaltet. Das Erzeugen von core-Files ist per Default deaktiviert und kann mit dem Kommanto ''ulimit'' aktiviert werden: \begin{lstlisting} ulimit -c unlimited \end{lstlisting} Die maximale Größe des zu erzeugenden core-Files wird ulimit als Parameter übergeben. Gibt es keine Größenbeschränkung kann einfach ''unlimited'' als Parameter übergeben werden. Der Name des zu erzeugenden Files kann unter /proc/sys/kernel/core\_pattern festgelegt werden. Folgende Formatoptionen können hier verwendet werden: \begin{center} \begin{tabular}{|c|l|} \hline \textbf{Format} & \textbf{Bedeutung} \\ \hline \%p & PID \\ \hline \%u & User ID \\ \hline \%g & Group ID \\ \hline \%h & Hostname \\ \hline \%e & Executable filename \\ \hline \%s & Signal number: Signal, welches dem Prozess gesendet wurde \\ \hline \%t & UNIX Time \\ \hline \end{tabular} \end{center} Folgendes Beispiel verdeutlicht die Analyse eines core-Files: \begin{lstlisting}[language=c] /* segfault.c */ #include int main (void) { char *arthur_dent = NULL; printf("%c\n", *arthur_dent); return 0; } \end{lstlisting} Programm übersetzen: \begin{lstlisting} $ gcc -g -o segfault segfault.c \end{lstlisting} Ggf. core\_pattern setzen \begin{lstlisting} $ echo core-%p > /proc/sys/kernel/core_pattern \end{lstlisting} Coredumps aktivieren: \begin{lstlisting} $ ulimit -c unlimited \end{lstlisting} Programm starten: \begin{lstlisting} $ ./segfault Segmentation fault (core dumped) \end{lstlisting} core-File analysieren: \begin{lstlisting} gdb ./segfault core-2567 [...] Loaded symbols for /lib64/ld-linux-x86-64.so.2 Core was generated by `./segfault'. Program terminated with signal 11, Segmentation fault. #0 0x0000000000400538 in main () at segfault.c:6 6 printf("%c\n", *arthur_dent); (gdb) bt #0 0x0000000000400538 in main () at segfault.c:6 \end{lstlisting} \section*{Memory debugging} Eine sehr häufige Problemstellung bei der Fehlersuche in Applikationen ist das Aufspüren von Problemen in der dynamischen Speicherverwaltung. Die häufigsten Probleme, die es hier zu untersuchen gilt, sind: \begin{itemize} \item Schreiben / Lesen über die Grenze von Speicherbereichen \item Memory leaks \item ''Use after free()'' \end{itemize} \subsection*{GLIBC: MTrace} Die GNU C Library, GLIBC, liefert bereits ein integriertes Werkzeug zum Debuggen von Speicherproblemen:MTrace. Die Anwendung von MTrace ist denkbar einfach. Im ersten Schritt ist der Code um folgende Zeilen zu ergänzen: \begin{lstlisting} [...] #include [...] mtrace(); \end{lstlisting} MTrace wertet die Umbebungsvariable MALLOC\_TRACE aus. Diese Variable gibt an, in welches Logfile MTrace seinen Output schreiben soll. Folgendes Beispiel verdeutlicht die Anwendung von MTrace: \begin{lstlisting}[language=C] /* mem_leak.c */ #include #include #include int main(void) { int i = 0; char *blurb = NULL; mtrace(); for(i = 0; i < 50; i++) blurb = malloc(sizeof(char)); free(blurb); } \end{lstlisting} Übersetzen und Ausführen der Applikation: \begin{lstlisting}[language=bash] $ gcc -g -o mem_leak mem_leak.c $ MALLOC_TRACE=mytrace.log ./mem_leak \end{lstlisting} Auswerten des Logfiles mit dem mtrace Tool: \begin{lstlisting}[language=bash] $ mtrace ./mem_leak mytrace.log Memory not freed: ----------------- Address Size Caller 0x1536460 0x1 at /home/jan/work/examples/mem_leak.c:13 0x1536480 0x1 at /home/jan/work/examples/mem_leak.c:13 0x15364a0 0x1 at /home/jan/work/examples/mem_leak.c:13 [...] \end{lstlisting} \subsection*{GLIBC: Hooks für malloc()} Neben mtrace() sieht die GLIBC noch Hooks vor, um Callbacks einzuhängen, die bei jedem Aufruf von malloc(), realloc(), free() oder memalign() aufgerufen werden. Hiermit steht eine sehr einfache Möglichkeit zur Verfügung, dynamische Speicherverwaltung individuell zu überwachen.\\ Folgende Variablen sind für diesen Zweck vorgesehen:\\ \_\_malloc\_hook: \begin{lstlisting}[language=C] /* function prototype */ void *function (size_t size, const void *caller) \end{lstlisting} \_\_realloc\_hook: \begin{lstlisting}[language=C] /* function prototype */ void *function (void *ptr, size_t size, const void *caller) \end{lstlisting} \_\_free\_hook: \begin{lstlisting}[language=C] /* function prototype */ void *function (void *ptr, const void *caller) \end{lstlisting} \_\_memalign\_hook: \begin{lstlisting}[language=C] /* function prototype */ void *function (size_t size, size_t alignment, const void *caller) \end{lstlisting} ACHTUNG: Bei der Verwendung von malloc() Hooks ist Vorsicht geboten! Jeglicher Aufruf, der seinerseits wiederrum einen malloc() Aufruf initiiert, führt innerhalb eines malloc() Hooks unvermeidlich zu einer Rekursion. \subsection*{libDUMA} Ein weiteres bekanntes Werkzeug zum Speicherdebugging ist eine Bibliothek mit dem Namen DUMA. Hierbei handelt sich um einen Fork der bekannten Electric Fence Libraries von Bruce Perence. DUMA ermöglicht es durch einfaches Linken gegen die Bibliothek, Speicherprobleme wie Leaks oder das Schreiben über Array Grenzen hinaus zu detektieren. Hierzu bringt DUMA eigene Implementierungen von malloc() und free(). Zum Detektieren von Überschriebenen Array Grenzen reicht das dynamische Linken oder das einfache ''Pre-loading'' gegen / von libDUMA. Erkennt DUMA einen Fehler wird ein Segmentation Fault erzeugt. Die Fehlersituation kann dann mittels core-File oder interaktivem Debuggen analysiert werden. Zum Aufspüren von Memory Leaks muß statisch gegen libDUMA gelinkt und weiterhin duma.h inkludiert werden. Bezogen auf unser Beispiel bedeutet dies: \begin{lstlisting} /* mem_leak.c */ #include #include #include int main(void) { int i = 0; char *blurb = NULL; for(i = 0; i < 50; i++) blurb = malloc(sizeof(char)); free(blurb); } \end{lstlisting} Übersetzen der Applikation (Achtung: Linkreihenfolge beachten!!!): \begin{lstlisting}[language=bash,basicstyle=\ttfamily\fontsize{9}{9}\selectfont] $ gcc -g -o mem_leak mem_leak.c /usr/lib/libduma.a \ -lpthread \end{lstlisting} Ausführen der Applikation: \begin{lstlisting} $ ./mem_leak DUMA 2.5.15 (static library) Copyright (C) 2006 Michael Eddington Copyright (C) 2002-2008 Hayati Ayguen , Procitec GmbH Copyright (C) 1987-1999 Bruce Perens DUMA: ptr=0x7f7280bdbfff size=1 type='malloc()' alloced from mem_leak.c(11) not freed DUMA: ptr=0x7f7280bddfff size=1 type='malloc()' alloced from mem_leak.c(11) not freed [...] \end{lstlisting} Das Detektieren von überschriebenem Speicher erfordert, wie bereits beschrieben, kein statisches Linken gegen libDUMA: \begin{lstlisting}[language=C] /* array_access.c */ #include #include #include int main(void) { int *my_array = (int*) malloc(10 * sizeof(int)); int i = 0; memset(my_array, 0, 10); for(i = 0; i < 11; i++) printf("%d ", my_array[i]); printf("\n"); return 0; } \end{lstlisting} Ohne libDUMA: \begin{lstlisting} $ gcc -g -o array_access array_access.c ./array_access 0 0 0 0 0 0 0 0 0 0 135121 \end{lstlisting} Mit libDUMA: \begin{lstlisting}[language=bash,basicstyle=\ttfamily\fontsize{9}{9}\selectfont] $ gcc -lduma -g -o array_access array_access.c $ ulimit -c unlimited $ ./array_access Segmentation fault (core dumped) $ gdb array_access core Loaded symbols for /lib64/ld-linux-x86-64.so.2 Core was generated by `./array_access'. Program terminated with signal 11, Segmentation fault. #0 0x00000000004006b7 in main () at array_access.c:10 10 printf("%d\n", my_array[i]); (gdb) print i $1 = 10 \end{lstlisting} Mit libDUMA und LD\_PRELOAD: \begin{lstlisting}[language=bash,basicstyle=\ttfamily\fontsize{9}{9}\selectfont] $ gcc -g -o array_access array_access.c $ LD_PRELOAD=/usr/lib/libduma.so ./array_access Segmentation fault (core dumped) [...] \end{lstlisting} Das Verhalten von libDUMA kann durch folgende Umgebungsvariablen beeinflußt werden: \begin{center} \begin{tabular}{|l|p{8cm}|} \hline \textbf{Variable} & \textbf{Bedeutung} \\ \hline DUMA\_ALIGNMENT & Alignment des allozierten Speichers \\ \hline DUMA\_PROTECT\_BELOW & DUMA platziert normalerweise ''Marker'' hinter dem allozierten Speicherbereich. Das Setzen dieser Variable veranlaßt DUMA die Marker VOR den allozierten Bereich zu setzen\\ \hline DUMA\_REPORT\_ALL\_LEAKS & Alle Memory leaks anzeigen (auch wenn Sourcefile und Zeilennummer nicht verfügbar sind)\\ \hline DUMA\_ALLOW\_MALLOC\_0 & malloc() mit der Größe 0 als Fehler ausgeben\\ \hline \end{tabular} \end{center} Es gibt noch viele andere Environment Variablen. Deren Bedeutung ist der Manpage von libduma zu entnehmen: ''man duma'' \subsection*{Valgrind} Valgrind ist das wohl mächtigste Werkzeug, das zur Analyse von Speicherproblemen zur Verfügung steht. Es handelt sich um mehrere Werkzeuge, die unter anderem auch Profiling Funkionaliät bieten. Valgrind erreicht eine sehr hohe Trefferquote. Leider gibt es derzeit nur beschränkten Support für ARM CPUs (derzeit gibt es noch harte Abhängigkeiten nach ARMv7). Die Analyse des Memory Leak Beispiels mit valgrind gestaltet sich wie folgt: \begin{lstlisting}[language=C] /* mem_leak.c */ /* Keine Anpassung der Sourcen notwendig!!! */ #include #include int main(void) { int i = 0; char *blurb = NULL; for(i = 0; i < 50; i++) blurb = malloc(sizeof(char)); free(blurb); } \end{lstlisting} Übersetzen der Applikation: \begin{lstlisting}[language=bash] $ gcc -g -o mem_leak mem_leak.c \end{lstlisting} Analyse mit valgrind: \begin{lstlisting}[basicstyle=\ttfamily\fontsize{9}{9}\selectfont] $ valgrind --leak-check=full ./mem_leak =5764= Memcheck, a memory error detector =5764= Copyright (C) 2002-2009, and GNU GPL'd, by Julian Seward et al. =5764= Using Valgrind-3.6.0.SVN-Debian and LibVEX; rerun with -h for copyright info =5764= Command: ./mem_leak =5764= =5764= HEAP SUMMARY: =5764= in use at exit: 49 bytes in 49 blocks =5764= total heap usage: 50 allocs, 1 frees, =5764= 50 bytes allocated =5764= 49 bytes in 49 blocks are definitely lost in =5764= loss record 1 of 1 =5764= at 0x4C274A8: malloc (vg_replace_malloc.c:236) =5764= by 0x40058D: main (mem_leak.c:10) =5764= =5764= LEAK SUMMARY: =5764= definitely lost: 49 bytes in 49 blocks [...] \end{lstlisting} \end{document}