From 767ccdba23486209e922ddc079762feeca133495 Mon Sep 17 00:00:00 2001
From: Jan Altenberg <jan@jan-laptop.(none)>
Date: Fri, 30 Apr 2010 10:47:42 +0200
Subject: App Debugging fixes.

---
 .../app-debugging/handout_app-debugging_de.tex              | 13 ++++++-------
 1 file changed, 6 insertions(+), 7 deletions(-)

(limited to 'application-devel/app-debugging/handout_app-debugging_de.tex')

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
-- 
cgit v1.2.3

