diff options
Diffstat (limited to 'application-devel/app-debugging/handout_app-debugging_de.tex')
| -rw-r--r-- | application-devel/app-debugging/handout_app-debugging_de.tex | 86 |
1 files changed, 43 insertions, 43 deletions
diff --git a/application-devel/app-debugging/handout_app-debugging_de.tex b/application-devel/app-debugging/handout_app-debugging_de.tex index b082790..a51177a 100644 --- a/application-devel/app-debugging/handout_app-debugging_de.tex +++ b/application-devel/app-debugging/handout_app-debugging_de.tex @@ -3,7 +3,7 @@ \subsection{Applikationen Debuggen} \subsubsection{STRACE} -Eine sehr einfache und mächtige Möglichkeit, Systemaufrufe und Signale +Eine sehr einfache und m\"achtige M\"oglichkeit, 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] @@ -41,9 +41,9 @@ davon sind:\\ \subsubsection{GDB} \paragraph{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: +der f\"ur alle g\"angigen Prozessorarchitekturen verf\"ugbar ist. GDB bietet ein +sehr m\"achtiges Commandlineinterface. Es existieren diverse grafische Frontends +f\"ur GDB (z.B. DDD). Eine einfache Debuggingsession stellt sich wie folgt dar: \begin{lstlisting}[language=c] /* hello.c */ #include <stdio.h> @@ -54,7 +54,7 @@ für GDB (z.B. DDD). Eine einfache Debuggingsession stellt sich wie folgt dar: return 0; } \end{lstlisting} -Übersetzen des Programms mit Debuginformationen: +\"Ubersetzen des Programms mit Debuginformationen: \begin{lstlisting} $ gcc -g -o hello hello.c \end{lstlisting} @@ -67,7 +67,7 @@ Hello world Program exited normally. \end{lstlisting} -Mit dem Kommando ''list'' kann der zugehörige Quellcode angezeigt werden. +Mit dem Kommando ''list'' kann der zugeh\"orige Quellcode angezeigt werden. Breakpoints werden mit ''break'' gesetzt: \begin{lstlisting} (gdb) list @@ -81,8 +81,8 @@ Breakpoints werden mit ''break'' gesetzt: (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: +Mit ''next'' und ''step'' werden einzelne Codezeilen ausgef\"uhrt, +w\"ahrend ''next'' einem step-OVER und ''step'' einem step-IN entspricht: \begin{lstlisting} (gdb) run Starting program: /home/jan/work/examples/hello @@ -95,11 +95,11 @@ Hello world (gdb) continue Continuing. \end{lstlisting} -Folgende Tabelle zeigt eine Übersicht der wichtigsten GDB Kommandos:\\ +Folgende Tabelle zeigt eine \"Ubersicht der wichtigsten GDB Kommandos:\\ \begin{center} \begin{tabular}{|l|c|p{8cm}|} \hline -\textbf{Kommando} & \textbf{Abkürzung} & \textbf{Zweck} \\ +\textbf{Kommando} & \textbf{Abk\"urzung} & \textbf{Zweck} \\ \hline run & r & Programm starten \\ \hline @@ -125,7 +125,7 @@ quit & q & GDB beenden \\ \end{center} \paragraph{Analyse von core-Files} -Neben der Möglichkeit des interaktiven Debuggings findet GDB auch häufig +Neben der M\"oglichkeit des interaktiven Debuggings findet GDB auch h\"aufig 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 @@ -134,11 +134,11 @@ 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 +Die maximale Gr\"oße des zu erzeugenden core-Files wird ulimit als Parameter +\"ubergeben. Gibt es keine Gr\"oßenbeschr\"ankung kann einfach ''unlimited'' als +Parameter \"ubergeben werden. Der Name des zu erzeugenden Files kann unter /proc/sys/kernel/core\_pattern festgelegt werden. Folgende Formatoptionen -können hier verwendet werden: +k\"onnen hier verwendet werden: \begin{center} \begin{tabular}{|c|l|} \hline @@ -172,7 +172,7 @@ Folgendes Beispiel verdeutlicht die Analyse eines core-Files: return 0; } \end{lstlisting} -Programm übersetzen: +Programm \"ubersetzen: \begin{lstlisting} $ gcc -g -o segfault segfault.c \end{lstlisting} @@ -203,18 +203,18 @@ Program terminated with signal 11, Segmentation fault. \end{lstlisting} \subsubsection{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: +Eine sehr h\"aufige Problemstellung bei der Fehlersuche in Applikationen +ist das Aufsp\"uren von Problemen in der dynamischen Speicherverwaltung. +Die h\"aufigsten Probleme, die es hier zu untersuchen gilt, sind: \begin{itemize} -\item Schreiben / Lesen über die Grenze von Speicherbereichen +\item Schreiben / Lesen \"uber die Grenze von Speicherbereichen \item Memory leaks \item ''Use after free()'' \end{itemize} \paragraph{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: +Im ersten Schritt ist der Code um folgende Zeilen zu erg\"anzen: \begin{lstlisting} [...] #include <mcheck.h> @@ -243,7 +243,7 @@ int main(void) free(blurb); } \end{lstlisting} -Übersetzen und Ausführen der Applikation: +\"Ubersetzen und Ausf\"uhren der Applikation: \begin{lstlisting}[language=bash] $ gcc -g -o mem_leak mem_leak.c $ MALLOC_TRACE=mytrace.log ./mem_leak @@ -260,12 +260,12 @@ Address Size Caller 0x15364a0 0x1 at /home/jan/work/examples/mem_leak.c:13 [...] \end{lstlisting} -\paragraph{GLIBC: Hooks für malloc()} -Neben mtrace() sieht die GLIBC noch Hooks vor, um Callbacks einzuhängen, +\paragraph{GLIBC: Hooks f\"ur malloc()} +Neben mtrace() sieht die GLIBC noch Hooks vor, um Callbacks einzuh\"angen, 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:\\ +aufgerufen werden. Hiermit steht eine sehr einfache M\"oglichkeit zur Verf\"ugung, +dynamische Speicherverwaltung individuell zu \"uberwachen.\\ +Folgende Variablen sind f\"ur diesen Zweck vorgesehen:\\ \_\_malloc\_hook: \begin{lstlisting}[language=C] /* function prototype */ @@ -287,19 +287,19 @@ void *function (void *ptr, const void *caller) 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 +Aufruf, der seinerseits wiederrum einen malloc() Aufruf initiiert, f\"uhrt innerhalb eines malloc() Hooks unvermeidlich zu einer Rekursion. \paragraph{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 +Electric Fence Libraries von Bruce Perence. DUMA erm\"oglicht es durch einfaches +Linken gegen die Bibliothek, Speicherprobleme wie Leaks oder das Schreiben \"uber Array Grenzen hinaus zu detektieren. Hierzu bringt DUMA eigene Implementierungen -von malloc() und free(). Zum Detektieren von Überschriebenen Array Grenzen +von malloc() und free(). Zum Detektieren von \"Uberschriebenen 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 +Aufsp\"uren 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 */ @@ -318,12 +318,12 @@ int main(void) free(blurb); } \end{lstlisting} -Übersetzen der Applikation (Achtung: Linkreihenfolge beachten!!!): +\"Ubersetzen 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: +Ausf\"uhren der Applikation: \begin{lstlisting} $ ./mem_leak DUMA 2.5.15 (static library) @@ -339,7 +339,7 @@ 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, +Das Detektieren von \"uberschriebenem Speicher erfordert, wie bereits beschrieben, kein statisches Linken gegen libDUMA: \begin{lstlisting}[language=C] /* array_access.c */ @@ -399,20 +399,20 @@ DUMA\_PROTECT\_BELOW & DUMA platziert normalerweise ''Marker'' hinter dem allozi 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)\\ +nicht verf\"ugbar sind)\\ \hline -DUMA\_ALLOW\_MALLOC\_0 & malloc() mit der Größe 0 als Fehler ausgeben\\ +DUMA\_ALLOW\_MALLOC\_0 & malloc() mit der Gr\"oß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'' \paragraph{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 +Valgrind ist das wohl m\"achtigste Werkzeug, das zur Analyse von Speicherproblemen +zur Verf\"ugung steht. Es handelt sich um mehrere Werkzeuge, die unter anderem auch +Profiling Funkionali\"at bieten. Valgrind erreicht eine sehr hohe Trefferquote. Leider +gibt es derzeit nur beschr\"ankten Support f\"ur ARM CPUs (derzeit gibt es noch +harte Abh\"angigkeiten nach ARMv7). Die Analyse des Memory Leak Beispiels mit valgrind gestaltet sich wie folgt: \begin{lstlisting}[language=C] /* mem_leak.c */ @@ -431,7 +431,7 @@ int main(void) free(blurb); } \end{lstlisting} -Übersetzen der Applikation: +\"Ubersetzen der Applikation: \begin{lstlisting}[language=bash] $ gcc -g -o mem_leak mem_leak.c \end{lstlisting} |