From f6f0ee15f6ab3bee6150edb7b842c6624bfd8cae Mon Sep 17 00:00:00 2001
From: Manuel Traut <manut@linutronix.de>
Date: Wed, 26 Jan 2011 01:49:35 +0100
Subject: Aufräumen und neu strukturieren Teil 1
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

- alle images wurden ins Wurzelverzeichnis verschoben

- TEXINPUTS wird projektspezifisch gesetzt

- es besteht die Möglichkeit einzelne pdfs zu generieren (wie bisher)
   desweiteren ist es möglich eigene Zusammenstellungen anzulegen

- Einsstellungen welche das Design der Dokumente definieren werden nun
   in config*.tex & tail*.tex im Wurzelverzeichnis definiert

- templates an neue Umgebung angepasst

- in jedem Kapitelverzeichnis liegt nun eine Datei section welche das Kapitel
   beschreibt (mind. überschrift). Diese kann ggf. inkludiert werden.

- TODO: es sind noch nicht alle Dokumente auf die neue Struktur umgestellt
   (siehe Makefile)

Signed-off-by: Manuel Traut <manut@linutronix.de>
---
 .../app-debugging/handout_app-debugging_de.tex     | 29 +++++++++-------------
 1 file changed, 12 insertions(+), 17 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 acbd340..b082790 100644
--- a/application-devel/app-debugging/handout_app-debugging_de.tex
+++ b/application-devel/app-debugging/handout_app-debugging_de.tex
@@ -1,13 +1,8 @@
-\documentclass{lxarticle}
-\usepackage{german}
-\usepackage[utf8]{inputenc}
-\usepackage{lxheaders}
-\usepackage{lxextras}
-\lstset{keywordstyle=\color{blue}}
+\input{confighandout}
 
-\begin{document}
+\subsection{Applikationen Debuggen}
 
-\section{STRACE}
+\subsubsection{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
 des zu tracenden Programms wird einfach strace vorangestellt:
@@ -43,8 +38,8 @@ davon sind:\\
 \hline
 \end{tabular}
 \end{center}
-\section{GDB}
-\subsection{Interaktives Debugging mit GDB}
+\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
@@ -129,7 +124,7 @@ quit & q & GDB beenden \\
 \end{tabular}
 \end{center}
 
-\subsection{Analyse von core-Files}
+\paragraph{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,
@@ -207,7 +202,7 @@ Program terminated with signal 11, Segmentation fault.
 #0  0x0000000000400538 in main () at segfault.c:6
 \end{lstlisting}
 
-\section{Memory debugging}
+\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:
@@ -216,7 +211,7 @@ Die häufigsten Probleme, die es hier zu untersuchen gilt, sind:
 \item Memory leaks
 \item ''Use after free()''
 \end{itemize}
-\subsection{GLIBC: MTrace}
+\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:
@@ -265,7 +260,7 @@ Address   Size   Caller
 0x15364a0 0x1 at /home/jan/work/examples/mem_leak.c:13
 [...]
 \end{lstlisting}
-\subsection{GLIBC: Hooks für malloc()}
+\paragraph{GLIBC: Hooks für malloc()}
 Neben mtrace() sieht die GLIBC noch Hooks vor, 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,
@@ -294,7 +289,7 @@ void *function (size_t size, size_t alignment, const void *caller)
 ACHTUNG: Bei der Verwendung von malloc() Hooks ist Vorsicht geboten! Jeglicher
 Aufruf, der seinerseits wiederrum einen malloc() Aufruf initiiert, führt
 innerhalb eines malloc() Hooks unvermeidlich zu einer Rekursion.
-\subsection{libDUMA}
+\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
@@ -412,7 +407,7 @@ DUMA\_ALLOW\_MALLOC\_0 & malloc() mit der Größe 0 als Fehler ausgeben\\
 \end{center}
 Es gibt noch viele andere Environment Variablen. Deren Bedeutung ist der
 Manpage von libduma zu entnehmen: ''man duma''
-\subsection{Valgrind}
+\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
@@ -464,4 +459,4 @@ $ valgrind --leak-check=full ./mem_leak
 [...]
 \end{lstlisting}
 
-\end{document}
+\input{tailhandout}
-- 
cgit v1.2.3

