From 2d43f24f10f39a7397220a05c5c189d24dc3b894 Mon Sep 17 00:00:00 2001 From: Jan Altenberg Date: Thu, 29 Apr 2010 15:04:17 +0200 Subject: App debugging fixes --- .../app-debugging/handout_app-debugging_de.tex | 22 +++++++++++----------- .../app-debugging/pres_app-debugging_de.tex | 2 +- 2 files changed, 12 insertions(+), 12 deletions(-) diff --git a/application-devel/app-debugging/handout_app-debugging_de.tex b/application-devel/app-debugging/handout_app-debugging_de.tex index 537f62d..821421d 100644 --- a/application-devel/app-debugging/handout_app-debugging_de.tex +++ b/application-devel/app-debugging/handout_app-debugging_de.tex @@ -218,7 +218,7 @@ Die häufigsten Probleme, die es hier zu untersuchen gilt, sind: \item ''Use after free()'' \end{itemize} \subsection*{GLIBC: MTrace} -Die GNU C Library, GLIBC, liefert bereits ein Integriertes Werkzeug zum +Die GNU C Library, GLIBC, liefert bereits ein integriertes Werkzeug zum Debuggen von Speicherproblemen. Die Anwendung von MTrace ist denkbar einfach. Im ersten Schritt ist der Code um folgende Zeilen zu ergänzen: \begin{lstlisting} @@ -268,8 +268,8 @@ Address Size Caller \end{lstlisting} \subsection*{GLIBC: Hooks für malloc()} Neben mtrace() sieht die GLIBC noch Hooks for, um Callbacks einzuhängen, -die bei jedem Aufrunf von malloc(), realloc(), free() oder memalign() -aufgerufen werden. Hiermit steht eine sehr einfach Möglichkeit zur Verfügung, +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:\\ \_\_malloc\_hook: @@ -298,9 +298,9 @@ 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 +von malloc() und free(). Zum Detektieren von Überschriebenen Array Grenzen reicht das dynamische Linken oder das einfache ''pre-loading'' gegen / von libDUMA. -Erkennt DUMA eine Fehler wird ein Segmentation Fault erzeugt. Die Fehlersituation +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: @@ -342,7 +342,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 überschriebenem Speicher erfordert, wie bereits beschrieben, kein statisches Linken gegen libDUMA: \begin{lstlisting}[language=C] /* array_access.c */ @@ -390,7 +390,7 @@ $ LD_PRELOAD=/usr/lib/libduma.so ./array_access Segmentation fault (core dumped) [...] \end{lstlisting} -Das Verhalten von libDUMA durch folgende Umgebungsvariablen beeinflußt werden: +Das Verhalten von libDUMA kann durch folgende Umgebungsvariablen beeinflußt werden: \begin{center} \begin{tabular}{|l|p{8cm}|} \hline @@ -398,11 +398,11 @@ Das Verhalten von libDUMA durch folgende Umgebungsvariablen beeinflußt werden: \hline DUMA\_ALIGNMENT & Alignment des allozierten Speichers \\ \hline -DUMA\_PROTECT\_BELOW & DUMA platziert normalerweise ''Marker'' hinter dem Allozierten Speicherbereich. +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 ist)\\ +nicht verfügbar sind)\\ \hline DUMA\_ALLOW\_MALLOC\_0 & malloc() mit der Größe 0 als Fehler ausgeben\\ \hline @@ -411,11 +411,11 @@ DUMA\_ALLOW\_MALLOC\_0 & malloc() mit der Größe 0 als Fehler ausgeben\\ 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 +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 Beispiel mit valgrind gestaltet +harte Abhängigkeiten nach ARMv7). Die Analyse des Memory Leak Beispiels mit valgrind gestaltet sich wie folgt: \begin{lstlisting}[language=C] /* mem_leak.c */ diff --git a/application-devel/app-debugging/pres_app-debugging_de.tex b/application-devel/app-debugging/pres_app-debugging_de.tex index 85c8aa7..433c0d1 100644 --- a/application-devel/app-debugging/pres_app-debugging_de.tex +++ b/application-devel/app-debugging/pres_app-debugging_de.tex @@ -203,7 +203,7 @@ ulimit & core dumpt aktivieren und größe festlegen \\ \hline cat /proc/sys/kernel/core\_pattern & Aktuelles Namenspattern für core files anzeigen \\ \hline -echo core-\%p \textgreater /proc/sys/kernel/core\_pattern & Aktuelles Namenspattern für core files anzeigen \\ +echo core-\%p \textgreater /proc/sys/kernel/core\_pattern & Namenspattern für core files setzen \\ \hline gdb ./exe corefile & Coredump mit GDB anzeigen \\ \hline -- cgit v1.2.3