From ce5c7229abcc66a7cb03d031bafc96c4568aa9bd Mon Sep 17 00:00:00 2001
From: Manuel Traut <manut@linutronix.de>
Date: Wed, 14 Mar 2012 06:20:14 +0100
Subject: fix ae oe ue in tex files

Signed-off-by: Manuel Traut <manut@linutronix.de>
---
 .../app-debugging/handout_app-debugging_de.tex     | 86 +++++++++++-----------
 1 file changed, 43 insertions(+), 43 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 b082790..a51177a 100644
--- a/application-devel/app-debugging/handout_app-debugging_de.tex
+++ b/application-devel/app-debugging/handout_app-debugging_de.tex
@@ -3,7 +3,7 @@
 \subsection{Applikationen Debuggen}
 
 \subsubsection{STRACE}
-Eine sehr einfache und mächtige Möglichkeit, Systemaufrufe und Signale
+Eine sehr einfache und m\"achtige M\"oglichkeit, Systemaufrufe und Signale
 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]
@@ -41,9 +41,9 @@ davon sind:\\
 \subsubsection{GDB}
 \paragraph{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
-für GDB (z.B. DDD). Eine einfache Debuggingsession stellt sich wie folgt dar:
+der f\"ur alle g\"angigen Prozessorarchitekturen verf\"ugbar ist. GDB bietet ein
+sehr m\"achtiges Commandlineinterface. Es existieren diverse grafische Frontends
+f\"ur GDB (z.B. DDD). Eine einfache Debuggingsession stellt sich wie folgt dar:
 \begin{lstlisting}[language=c]
 	/* hello.c */
 	#include <stdio.h>
@@ -54,7 +54,7 @@ für GDB (z.B. DDD). Eine einfache Debuggingsession stellt sich wie folgt dar:
 		return 0;
 	}
 \end{lstlisting}
-Übersetzen des Programms mit Debuginformationen:
+\"Ubersetzen des Programms mit Debuginformationen:
 \begin{lstlisting}
 $ gcc -g -o hello hello.c
 \end{lstlisting}
@@ -67,7 +67,7 @@ Hello world
 
 Program exited normally.
 \end{lstlisting}
-Mit dem Kommando ''list'' kann der zugehörige Quellcode angezeigt werden.
+Mit dem Kommando ''list'' kann der zugeh\"orige Quellcode angezeigt werden.
 Breakpoints werden mit ''break'' gesetzt:
 \begin{lstlisting}
 (gdb) list
@@ -81,8 +81,8 @@ Breakpoints werden mit ''break'' gesetzt:
 (gdb) break 5
 Breakpoint 1 at 0x400528: file hello.c, line 5.
 \end{lstlisting}
-Mit ''next'' und ''step'' werden einzelne Codezeilen ausgeführt,
-während ''next'' einem step-OVER und ''step'' einem step-IN entspricht:
+Mit ''next'' und ''step'' werden einzelne Codezeilen ausgef\"uhrt,
+w\"ahrend ''next'' einem step-OVER und ''step'' einem step-IN entspricht:
 \begin{lstlisting}
 (gdb) run
 Starting program: /home/jan/work/examples/hello 
@@ -95,11 +95,11 @@ Hello world
 (gdb) continue 
 Continuing.
 \end{lstlisting}
-Folgende Tabelle zeigt eine Übersicht der wichtigsten GDB Kommandos:\\
+Folgende Tabelle zeigt eine \"Ubersicht der wichtigsten GDB Kommandos:\\
 \begin{center}
 \begin{tabular}{|l|c|p{8cm}|}
 \hline
-\textbf{Kommando} & \textbf{Abkürzung} & \textbf{Zweck} \\
+\textbf{Kommando} & \textbf{Abk\"urzung} & \textbf{Zweck} \\
 \hline
 run & r & Programm starten \\
 \hline
@@ -125,7 +125,7 @@ quit & q & GDB beenden \\
 \end{center}
 
 \paragraph{Analyse von core-Files}
-Neben der Möglichkeit des interaktiven Debuggings findet GDB auch häufig
+Neben der M\"oglichkeit des interaktiven Debuggings findet GDB auch h\"aufig
 eine weitere Anwendung: Die ''Post-Mortem-Analyse'' von Problemen. Wird
 eine Applikation beispielsweise durch seinen Segmentation Fault beendet,
 wird ein sogenanntes core-File erzeugt, welches u.A. den aktuellen Stack der
@@ -134,11 +134,11 @@ und kann mit dem Kommanto ''ulimit'' aktiviert werden:
 \begin{lstlisting}
 ulimit -c unlimited
 \end{lstlisting}
-Die maximale Größe des zu erzeugenden core-Files wird ulimit als Parameter
-übergeben. Gibt es keine Größenbeschränkung kann einfach ''unlimited'' als
-Parameter übergeben werden. Der Name des zu erzeugenden Files kann unter
+Die maximale Gr\"oße des zu erzeugenden core-Files wird ulimit als Parameter
+\"ubergeben. Gibt es keine Gr\"oßenbeschr\"ankung kann einfach ''unlimited'' als
+Parameter \"ubergeben werden. Der Name des zu erzeugenden Files kann unter
 /proc/sys/kernel/core\_pattern festgelegt werden. Folgende Formatoptionen
-können hier verwendet werden:
+k\"onnen hier verwendet werden:
 \begin{center}
 \begin{tabular}{|c|l|}
 \hline
@@ -172,7 +172,7 @@ Folgendes Beispiel verdeutlicht die Analyse eines core-Files:
 		return 0;
         }
 \end{lstlisting}
-Programm übersetzen:
+Programm \"ubersetzen:
 \begin{lstlisting}
 $ gcc -g -o segfault segfault.c
 \end{lstlisting}
@@ -203,18 +203,18 @@ Program terminated with signal 11, Segmentation fault.
 \end{lstlisting}
 
 \subsubsection{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:
+Eine sehr h\"aufige Problemstellung bei der Fehlersuche in Applikationen
+ist das Aufsp\"uren von Problemen in der dynamischen Speicherverwaltung.
+Die h\"aufigsten Probleme, die es hier zu untersuchen gilt, sind:
 \begin{itemize}
-\item Schreiben / Lesen über die Grenze von Speicherbereichen
+\item Schreiben / Lesen \"uber die Grenze von Speicherbereichen
 \item Memory leaks
 \item ''Use after free()''
 \end{itemize}
 \paragraph{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:
+Im ersten Schritt ist der Code um folgende Zeilen zu erg\"anzen:
 \begin{lstlisting}
 [...]
 #include <mcheck.h>
@@ -243,7 +243,7 @@ int main(void)
         free(blurb);
 }
 \end{lstlisting}
-Übersetzen und Ausführen der Applikation:
+\"Ubersetzen und Ausf\"uhren der Applikation:
 \begin{lstlisting}[language=bash]
 $ gcc -g -o mem_leak mem_leak.c
 $ MALLOC_TRACE=mytrace.log ./mem_leak
@@ -260,12 +260,12 @@ Address   Size   Caller
 0x15364a0 0x1 at /home/jan/work/examples/mem_leak.c:13
 [...]
 \end{lstlisting}
-\paragraph{GLIBC: Hooks für malloc()}
-Neben mtrace() sieht die GLIBC noch Hooks vor, um Callbacks einzuhängen,
+\paragraph{GLIBC: Hooks f\"ur malloc()}
+Neben mtrace() sieht die GLIBC noch Hooks vor, um Callbacks einzuh\"angen,
 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 sind für diesen Zweck vorgesehen:\\
+aufgerufen werden. Hiermit steht eine sehr einfache M\"oglichkeit zur Verf\"ugung,
+dynamische Speicherverwaltung individuell zu \"uberwachen.\\
+Folgende Variablen sind f\"ur diesen Zweck vorgesehen:\\
 \_\_malloc\_hook:
 \begin{lstlisting}[language=C]
 /* function prototype */
@@ -287,19 +287,19 @@ void *function (void *ptr, const void *caller)
 void *function (size_t size, size_t alignment, const void *caller)
 \end{lstlisting}
 ACHTUNG: Bei der Verwendung von malloc() Hooks ist Vorsicht geboten! Jeglicher
-Aufruf, der seinerseits wiederrum einen malloc() Aufruf initiiert, führt
+Aufruf, der seinerseits wiederrum einen malloc() Aufruf initiiert, f\"uhrt
 innerhalb eines malloc() Hooks unvermeidlich zu einer Rekursion.
 \paragraph{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
-Linken gegen die Bibliothek, Speicherprobleme wie Leaks oder das Schreiben über
+Electric Fence Libraries von Bruce Perence. DUMA erm\"oglicht es durch einfaches
+Linken gegen die Bibliothek, Speicherprobleme wie Leaks oder das Schreiben \"uber
 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 \"Uberschriebenen Array Grenzen
 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
+Aufsp\"uren von Memory Leaks muß statisch gegen libDUMA gelinkt und weiterhin
 duma.h inkludiert werden. Bezogen auf unser Beispiel bedeutet dies:
 \begin{lstlisting}
 /* mem_leak.c */
@@ -318,12 +318,12 @@ int main(void)
         free(blurb);
 }
 \end{lstlisting}
-Übersetzen der Applikation (Achtung: Linkreihenfolge beachten!!!):
+\"Ubersetzen der Applikation (Achtung: Linkreihenfolge beachten!!!):
 \begin{lstlisting}[language=bash,basicstyle=\ttfamily\fontsize{9}{9}\selectfont]
 $ gcc -g -o mem_leak mem_leak.c /usr/lib/libduma.a \
    -lpthread
 \end{lstlisting}
-Ausführen der Applikation:
+Ausf\"uhren der Applikation:
 \begin{lstlisting}
 $ ./mem_leak
 DUMA 2.5.15 (static library)
@@ -339,7 +339,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 \"uberschriebenem Speicher erfordert, wie bereits beschrieben,
 kein statisches Linken gegen libDUMA:
 \begin{lstlisting}[language=C]
 /* array_access.c */
@@ -399,20 +399,20 @@ DUMA\_PROTECT\_BELOW & DUMA platziert normalerweise ''Marker'' hinter dem allozi
 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 sind)\\
+nicht verf\"ugbar sind)\\
 \hline
-DUMA\_ALLOW\_MALLOC\_0 & malloc() mit der Größe 0 als Fehler ausgeben\\
+DUMA\_ALLOW\_MALLOC\_0 & malloc() mit der Gr\"oße 0 als Fehler ausgeben\\
 \hline
 \end{tabular}
 \end{center}
 Es gibt noch viele andere Environment Variablen. Deren Bedeutung ist der
 Manpage von libduma zu entnehmen: ''man duma''
 \paragraph{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
-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 Beispiels mit valgrind gestaltet
+Valgrind ist das wohl m\"achtigste Werkzeug, das zur Analyse von Speicherproblemen
+zur Verf\"ugung steht. Es handelt sich um mehrere Werkzeuge, die unter anderem auch
+Profiling Funkionali\"at bieten. Valgrind erreicht eine sehr hohe Trefferquote. Leider
+gibt es derzeit nur beschr\"ankten Support f\"ur ARM CPUs (derzeit gibt es noch
+harte Abh\"angigkeiten nach ARMv7). Die Analyse des Memory Leak Beispiels mit valgrind gestaltet
 sich wie folgt:
 \begin{lstlisting}[language=C]
 /* mem_leak.c */
@@ -431,7 +431,7 @@ int main(void)
         free(blurb);
 }
 \end{lstlisting}
-Übersetzen der Applikation:
+\"Ubersetzen der Applikation:
 \begin{lstlisting}[language=bash]
 $ gcc -g -o mem_leak mem_leak.c
 \end{lstlisting}
-- 
cgit v1.2.3

