diff options
Diffstat (limited to 'application-devel')
| -rw-r--r-- | application-devel/app-debugging/handout_app-debugging_de.tex | 86 | ||||
| -rw-r--r-- | application-devel/devel-environment/handout_devel-environment_de.tex | 2 |
2 files changed, 44 insertions, 44 deletions
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} diff --git a/application-devel/devel-environment/handout_devel-environment_de.tex b/application-devel/devel-environment/handout_devel-environment_de.tex index 1ac1b6f..d36527c 100644 --- a/application-devel/devel-environment/handout_devel-environment_de.tex +++ b/application-devel/devel-environment/handout_devel-environment_de.tex @@ -38,7 +38,7 @@ H\"aufig eingesetzte textbasierte Editoren unter Linux sind: \item yed \end{itemize} -Hilfreich beim Arbeiten auf der Textkonsole ist auch das Programm \cmd{screen}. +Hilfreich beim Arbeiten auf der Textkonsole ist auch das Programm screen. Screen bietet eine Tab Funktionalit\"at f\"ur die Konsole. Z.b. kann in einem screen der Editor gestartet werden, in einem weitern make und im N\"achsten z.B. man. Dies w\"urde folgenderma\ss en durchgef\"uhrt: |