diff options
Diffstat (limited to 'application-devel/app-debugging')
| -rw-r--r-- | application-devel/app-debugging/handout_app-debugging_de.tex | 18 |
1 files changed, 9 insertions, 9 deletions
diff --git a/application-devel/app-debugging/handout_app-debugging_de.tex b/application-devel/app-debugging/handout_app-debugging_de.tex index a7e1fac..acbd340 100644 --- a/application-devel/app-debugging/handout_app-debugging_de.tex +++ b/application-devel/app-debugging/handout_app-debugging_de.tex @@ -7,7 +7,7 @@ \begin{document} -\section*{STRACE} +\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: @@ -43,8 +43,8 @@ davon sind:\\ \hline \end{tabular} \end{center} -\section*{GDB} -\subsection*{Interaktives Debugging mit GDB} +\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 @@ -129,7 +129,7 @@ quit & q & GDB beenden \\ \end{tabular} \end{center} -\subsection*{Analyse von core-Files} +\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, @@ -207,7 +207,7 @@ Program terminated with signal 11, Segmentation fault. #0 0x0000000000400538 in main () at segfault.c:6 \end{lstlisting} -\section*{Memory debugging} +\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: @@ -216,7 +216,7 @@ Die häufigsten Probleme, die es hier zu untersuchen gilt, sind: \item Memory leaks \item ''Use after free()'' \end{itemize} -\subsection*{GLIBC: MTrace} +\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: @@ -265,7 +265,7 @@ Address Size Caller 0x15364a0 0x1 at /home/jan/work/examples/mem_leak.c:13 [...] \end{lstlisting} -\subsection*{GLIBC: Hooks für malloc()} +\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, @@ -294,7 +294,7 @@ void *function (size_t size, size_t alignment, const void *caller) 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} +\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 @@ -412,7 +412,7 @@ DUMA\_ALLOW\_MALLOC\_0 & malloc() mit der Größe 0 als Fehler ausgeben\\ \end{center} Es gibt noch viele andere Environment Variablen. Deren Bedeutung ist der Manpage von libduma zu entnehmen: ''man duma'' -\subsection*{Valgrind} +\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 |