App debugging fixes

1 files changed, 11 insertions, 11 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 */