diff options
Diffstat (limited to 'application-devel')
| -rw-r--r-- | application-devel/app-debugging/handout_app-debugging_de.tex | 13 |
1 files changed, 6 insertions, 7 deletions
diff --git a/application-devel/app-debugging/handout_app-debugging_de.tex b/application-devel/app-debugging/handout_app-debugging_de.tex index 821421d..c73cdd0 100644 --- a/application-devel/app-debugging/handout_app-debugging_de.tex +++ b/application-devel/app-debugging/handout_app-debugging_de.tex @@ -9,10 +9,9 @@ \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 +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 $ strace /bin/ls execve("/bin/ls", ["/bin/ls"], [/* 50 vars */]) = 0 brk(0) = 0x2246000 @@ -47,7 +46,7 @@ davon sind:\\ \section*{GDB} \subsection*{Interaktives Debugging mit GDB} Der GNU Debugger: GDB stellt einen vollwertigen interaktiven Debugger dar, -der für alle gängigen Prozessortarchitekturen verfügbar ist. GDB bietet ein +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] @@ -133,7 +132,7 @@ quit & q & GDB beenden \\ \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 +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: @@ -219,7 +218,7 @@ Die häufigsten Probleme, die es hier zu untersuchen gilt, sind: \end{itemize} \subsection*{GLIBC: MTrace} Die GNU C Library, GLIBC, liefert bereits ein integriertes Werkzeug zum -Debuggen von Speicherproblemen. Die Anwendung von MTrace ist denkbar einfach. +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} [...] @@ -271,7 +270,7 @@ Neben mtrace() sieht die GLIBC noch Hooks for, 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 stehen hierzu zur Verfügung:\\ +Folgende Variablen sind für diesen Zweck vorgesehen:\\ \_\_malloc\_hook: \begin{lstlisting}[language=C] /* function prototype */ @@ -299,7 +298,7 @@ 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. +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 |