Rheinwerk Computing < openbook > Rheinwerk Computing - Professionelle Bücher. Auch für Einsteiger.
Professionelle Bücher. Auch für Einsteiger.

Inhaltsverzeichnis
Vorwort
1 Einleitung
TEIL I: Einstieg in Linux
2 Die Installation
3 Erste Schritte
4 Linux als Workstation für Einsteiger
TEIL II: Grundlagen
5 Kernel
6 Grundlagen aus Anwendersicht
TEIL III: Die Shell
7 Die Shell
8 Reguläre Ausdrücke
9 Konsolentools
10 Die Editoren
11 Shellskriptprogrammierung mit der bash
12 Die C-Shell
TEIL IV: System- & Netzwerkadministration
13 Benutzerverwaltung
14 Grundlegende Verwaltungsaufgaben
15 Netzwerkgrundlagen
16 Anwendersoftware für das Netzwerk
17 Netzwerkdienste
18 Mailserver unter Linux
19 LAMP & Co.
20 DNS-Server
21 Secure Shell
TEIL V: Die grafische Oberfläche
22 Die grafische Oberfläche
23 Window-Manager und Desktops
24 X11-Programme
25 Multimedia und Spiele
TEIL VI: Systeminterna
26 Prozesse und IPC
27 Bootstrap und Shutdown
28 Dateisysteme
29 Virtualisierung und Emulatoren
TEIL VII: Programmierung und Sicherheit
30 Softwareentwicklung
31 Crashkurs in C und Perl
32 Einführung in Computersicherheit
33 Netzwerksicherheit überwachen
TEIL VIII: Anhang
A Lösungen zu den einzelnen Aufgaben
B Kommandoreferenz
C X11-InputDevices
D MBR
E Buch-DVDs
F Glossar
G Literatur
Stichwort
Ihre Meinung?

Spacer
Linux von Johannes Plötner, Steffen Wendzel
Das umfassende Handbuch
Buch: Linux

Linux
Rheinwerk Computing
1282 S., 5., aktualisierte Auflage 2012, geb., mit 2 DVDs
49,90 Euro, ISBN 978-3-8362-1822-1
Pfeil 30 Softwareentwicklung
Pfeil 30.1 Interpreter und Compiler
Pfeil 30.1.1 C und C++
Pfeil 30.1.2 Perl
Pfeil 30.1.3 Java
Pfeil 30.1.4 Tcl
Pfeil 30.1.5 Was es sonst noch gibt
Pfeil 30.2 Shared Libraries
Pfeil 30.2.1 Vorteile der Shared Libraries
Pfeil 30.2.2 Statisches Linken
Pfeil 30.2.3 Dateien
Pfeil 30.3 Debugging
Pfeil 30.3.1 Vorbereitung
Pfeil 30.3.2 Konsolenarbeit
Pfeil 30.3.3 DDD
Pfeil 30.4 Profiling
Pfeil 30.4.1 Compiler-Option
Pfeil 30.4.2 gprof verwenden
Pfeil 30.4.3 Profiling-Daten lesen
Pfeil 30.5 Tracing
Pfeil 30.6 Hilfe beim Finden von Bugs
Pfeil 30.6.1 ProPolice
Pfeil 30.6.2 Flawfinder und RATS
Pfeil 30.6.3 Electric Fence
Pfeil 30.7 Integrierte Entwicklungsumgebungen
Pfeil 30.8 Make
Pfeil 30.8.1 Makefile
Pfeil 30.8.2 Makros
Pfeil 30.8.3 Shellvariablen in Makefiles
Pfeil 30.8.4 Einzelne Targets übersetzen
Pfeil 30.8.5 Spezielle Targets
Pfeil 30.8.6 Tipps im Umgang mit Make
Pfeil 30.9 Die GNU Autotools
Pfeil 30.10 lex/flex und yacc/bison
Pfeil 30.10.1 flex grundlegend anwenden
Pfeil 30.10.2 bison/yacc grundlegend anwenden
Pfeil 30.11 Unix-Software veröffentlichen
Pfeil 30.12 Manpages erstellen
Pfeil 30.12.1 groff nutzen
Pfeil 30.12.2 Manpages installieren
Pfeil 30.13 Versionsmanagement
Pfeil 30.13.1 CVS
Pfeil 30.13.2 Subversion
Pfeil 30.13.3 Git
Pfeil 30.14 Wichtige Bibliotheken
Pfeil 30.14.1 Entwicklung grafischer Oberflächen
Pfeil 30.14.2 Weitere Bibliotheken
Pfeil 30.15 Zusammenfassung
Pfeil 30.16 Aufgaben

Rheinwerk Computing - Zum Seitenanfang

30.3 DebuggingZur nächsten Überschrift

Ein sehr wichtiges Werkzeug in der Softwareentwicklung ist der Debugger. Jede gute Entwicklungsumgebung enthält entweder selbst einen Debugger (das ist beispielsweise bei Microsofts Visual-Studio/.NET der Fall) oder greift auf einen externen Debugger zurück (etwa KDevelop unter Linux).

Ein Debugger hat die Aufgabe, das Fehlverhalten von Programmen für den Entwickler auffindbar zu machen. Dabei kann man Programmanweisung für Programmanweisung einzeln ablaufen lassen, während man parallel beispielsweise den Inhalt diverser Variablen im Blick behält.

Wir werden uns in diesem Buch mit dem mächtigsten freien Unix-Debugger auseinandersetzen: dem GNU-Debugger GDB. Er ist eigentlich auf jedem Linux- und BSD-System vorhanden und aufgrund seiner Verfügbarkeit auf diversen Plattformen sowie seines großen Funktionsumfangs äußerst beliebt.

Leider schrecken viele Entwickler trotzdem vor diesem Debugger zurück, da seine Anwendung (ohne Zuhilfenahme von Zusatztools) auf die Konsole beschränkt ist und alle Befehle von Hand eingegeben werden müssen. Doch auch dafür gibt es Lösungen, etwa die grafischen Fontends Xxgdb oder DDD.

Im Folgenden geben wir zunächst eine Einführung in das Debuggen mit dem GDB auf der Konsolenebene und kommen anschließend auf den DDD zu sprechen, der Ihnen bereits mehr Komfort bietet und einfacher zu bedienen ist.


Rheinwerk Computing - Zum Seitenanfang

30.3.1 VorbereitungZur nächsten ÜberschriftZur vorigen Überschrift

In diesem Kapitel werden wir ein Beispielprogramm, das mit einem Fehler versehen ist, als Debugging-Grundlage verwenden. Das Listing dieses Programms sehen Sie hier:

Listing 30.15 sample.c

#include <stdio.h>
#include <string.h>

int main(int argc, char *argv[])
{
char a[]="abcdefghijklmnopqrstuvwxyz";

strcpy(a+26, a);

return 0;
}

Unser Programm nennt sich sample. Normalerweise würde man es durch einen Aufruf von

gcc -o sample sample.c

übersetzen, doch reicht dies nicht aus, um komfortabel mit dem GNU-Debugger zu arbeiten. Dazu muss man gcc die Compiler-Option -g übergeben. Der Aufruf gestaltet sich also folgendermaßen:

gcc -g -o sample sample.c

Führt man sample aus, erhält man, wie zu erwarten, eine Zugriffsverletzung im Speicher. In diesem Fall erstellen Unix-Systeme einen sogenannten Coredump. Dies ist eine Datei, deren Name sich aus dem Programmnamen und der Endung .core zusammensetzt und ein Speicherabbild des bis dahin ausgeführten Programmes enthält. Diese Datei wird beim Debuggen verwendet, um die Absturzstelle im Programm aufzuspüren.

Listing 30.16 sample

$ ./sample
Segmentation fault (core dumped)
$ ls
sample sample.c sample.core

Rheinwerk Computing - Zum Seitenanfang

30.3.2 KonsolenarbeitZur nächsten ÜberschriftZur vorigen Überschrift

Nun werden wir uns zunächst auf der blanken Konsole bewegen und einige Grundlagen des gdb erlernen. Dazu rufen wir gdb mit der Binärdatei und der Core-Datei als Argumente auf. Nachdem die Startmeldungen erschienen sind, teilt uns GDB auch gleich die Fehlerquelle mit, bei der die Speicherzugriffsverletzung stattfand: nämlich während eines Aufrufs der C-Libary-Funktion strcpy().

Listing 30.17 gdb starten

$ gdb sample sample.core
GNU gdb 6.1
Copyright 2004 Free Software Foundation, Inc.
(...)
This GDB was configured as "i386-unknown-openbsd3.6"
Core was generated by `sample'.
Program terminated with signal 11, Segmentation fault.
Reading symbols from /usr/lib/libc.so.34.2...done.
Loaded symbols for /usr/lib/libc.so.34.2
Reading symbols from /usr/libexec/ld.so...done.
Loaded symbols for /usr/libexec/ld.so
#0 0x047ad4fb in strcpy () from /usr/lib/libc.so.34.2
(gdb)

run und kill

Würden wir das Programm einfach durchlaufen lassen (gestartet wird mit dem Befehl run), würde sich uns die gleiche Information zeigen. Ein Programm in der Ausführung lässt sich durch den Befehl kill abbrechen.

Listing 30.18 sample durchlaufen lassen

(gdb) run
Starting program: /home/cdp_xe/test/sample

Program received signal SIGSEGV, Segmentation fault.
0x000bc523 in strcpy () from /usr/lib/libc.so.34.2

list

Möchte man sich nun den Sourcecode des Programms ansehen, ruft man einfach den Befehl list auf. Dabei wird wahrscheinlich nicht gleich der gesamte Quelltext angezeigt. Durch mehrmaliges Betätigen der Enter-Taste werden weitere Zeilen inklusive deren Zeilennummern angezeigt. Wenn alle Zeilen durchlaufen wurden, erhalten Sie eine entsprechende Meldung.

Breakpoints

Möchte man nun einen Breakpoint setzen, ist es von großem Vorteil, die Zeilennummern zu kennen, die man, wie Sie ja nun wissen, via list herausbekommt. Dabei verwendet man den Befehl break, der als Parameter die Nummer der Zeile übergeben bekommt, in der ein Breakpoint gesetzt werden soll.

[»]Da fast jedes Softwareprojekt aus mehreren Quelldateien besteht, reicht es natürlich nicht aus, wenn man irgendeine Zeilennummer für einen Breakpoint angeben kann. Um zusätzlich die Quelldatei anzugeben, wird der Dateiname einfach zusätzlich bei break übergeben: break x.c:7.

Listing 30.19 break

(gdb) list
1 #include <stdio.h>
2 #include <string.h>
3
4 int main(int argc, char *argv[])
5 {
6 char a[]="abcdefghijklmnopqrstuvwxyz";
7
8 strcpy(a+26, a);
9
10 return 0;
11 }
(gdb)
Line number 12 out of range; sample.c has 11 lines.
(gdb) break 7
Breakpoint 1 at 0x1c0005fd: file sample.c, line 7.

Unser sample-Programm wird bei der Ausführung also nun in Zeile 7 angehalten. Da wir wissen, dass an der Speicherstelle a+26 nicht genug Platz für den Buffer-Inhalt von a sein wird, können wir – nachdem wir das Programm durch run bis zu dieser Position haben laufen lassen – den Wert von a so verändern, dass a nur noch das String-Terminierungszeichen \0 enthäl.

Würde nun also \0 an a+26 (dort steht sowieso ein \0) kopiert, so riefe dies keine Speicherzugriffsverletzung hervor, und das Programm würde normal beendet.

set

Der Wert einer Variablen wird mit dem Befehl set verändert:

Listing 30.20 Den Wert einer Variablen anpassen

(gdb) run
Starting program: /home/cdp_xe/test/sample

Breakpoint 1, main (argc=1, argv=0xcfbf33e0) at
sample.c:8
8 strcpy(a+26, a);
(gdb) set variable a = "\0"

step und cont

Nun möchte man natürlich auch testen, ob die weitere Ausführung des Programms funktioniert. Hierzu kann man entweder alle weiteren Anweisungen bis zum Programmende bzw. bis zum nächsten Breakpoint automatisch ablaufen lassen (was mit dem Befehl cont erreicht wird) oder auch schrittweise vorgehen, wobei jeweils nur eine Anweisung ausgeführt wird. Dazu verwendet man den Befehl step.

Listing 30.21 Der Befehl step

(gdb) step
10 return 0;
(gdb) step
11 }
(gdb) step
0x1c0004c1 in ___start ()
(gdb) step
Single stepping until exit from function ___start,
which has no line number information.

Program exited normally.

Variablen abfragen

Möchte man hingegen beim Ablauf des Programms den Wert einer Variablen abfragen, ist auch dies kein Problem. Der Name der Variablen wird dazu einfach an den Befehl print übergeben.

Listing 30.22 print a

(gdb) print a
$1 = "abcdefghijklmnopqrstuvwxyz"
(gdb) print argc
$3 = 1
(gdb) print argv
$4 = (char **) 0xcfbfb410
(gdb) print argv[0]
$5 = 0xcfbfb614 "/home/cdp_xe/test/sample"

help

Der GNU-Debugger unterstützt noch zahlreiche weitere Funktionen, auf die wir allerdings nicht im Einzelnen eingehen können. Daher verweisen wir auf die interne Hilfe-Funktion des Debuggers, die man, wie könnte es anders sein, mit dem Befehl help aufruft.

Weitere Informationen zum gdb in ausführlicherer Form erhalten Sie über die Info-Seite des Debuggers: info gdb.


Rheinwerk Computing - Zum Seitenanfang

30.3.3 DDDZur vorigen Überschrift

Für den Fall, dass man nicht alle GDB-Befehle direkt eingeben möchte, kann man ein Frontend zu Hilfe nehmen. Dabei gibt es verschiedene Frontends, beispielsweise ncurses-basierte für die Konsole und diverse X11-Varianten, etwa den veralteten Xxgdb. Wir werden uns mit einem sehr leistungsstarken GDB-basierten X11-Debugger, dem Data Display Debugger (DDD) beschäftigen.

Der DDD ist ein vergleichsweise einfach zu verwendender Debugger mit einigen sehr interessanten Features. Entwickelt wurde DDD an der technischen Universität Braunschweig, und er unterstützt neben C und C++ auch Fortran, Ada und einige weitere Sprachen.

Sie müssen DDD übrigens nicht zwangsläufig in Verbindung mit GDB verwenden. Es können über die entsprechenden Optionen auch andere Debugger, etwa jdb, Ladebug, perldebug, WDB, XDB oder PyDB verwendet werden. Außerdem kann der DDD auch remote debuggen.

Start

Gestartet wird DDD per Aufruf des Kommandos ddd und Angabe der Programm- datei des zu debuggenden Programms.

Bedienung

Die Bedienung des DDD ist recht intuitiv – lesen Sie auch die Tipps, die beim Start des Tools angezeigt werden.

Erwähnenswert ist vor allen Dingen die Möglichkeit, die Strukturen des Programms grafisch hervorzuheben. Dazu klickt man eine Variable während der Laufzeit mit der rechten Maustaste an (am besten setzt man sich hierzu irgendwo Breakpoints) und klickt auf Display bzw. Display für Pointer.

Abbildung

Abbildung 30.2 ddd zeigt Strukturen an.

Analog dazu kann man natürlich auch ganz einfach den GDB-Befehl graph display verwenden. Um beispielsweise den Inhalt der Variablen char *Q zu überwachen, müsste der folgende Befehl eingegeben werden:

Listing 30.23 *Q anzeigen lassen

(gdb) graph display *Q

Einzelne Werte der Strukturen lassen sich so einfach und unaufwändig überwachen und entweder direkt mit dem gdb-Befehl oder per Mausklick anpassen. Auch wenn Sie also mit den GDB-Befehlen auf Kriegsfuß stehen, ist dies also kein Problem.



Ihre Meinung

Wie hat Ihnen das Openbook gefallen? Wir freuen uns immer über Ihre Rückmeldung. Schreiben Sie uns gerne Ihr Feedback als E-Mail an kommunikation@rheinwerk-verlag.de.

<< zurück
 Ihre Meinung?
Wie hat Ihnen das Openbook gefallen?
Ihre Meinung

 Buchempfehlungen
Zum Rheinwerk-Shop: Linux Handbuch






 Linux Handbuch


Zum Rheinwerk-Shop: Linux Server






 Linux Server


Zum Rheinwerk-Shop: Raspberry Pi






 Raspberry Pi


Zum Rheinwerk-Shop: Ubuntu 14.04 LTS






 Ubuntu 14.04 LTS


Zum Rheinwerk-Shop: Roboter bauen mit Arduino






 Roboter bauen
 mit Arduino


 Lieferung
Versandkostenfrei bestellen in Deutschland, Österreich und der Schweiz
InfoInfo




Copyright © Rheinwerk Verlag GmbH 2012
Für Ihren privaten Gebrauch dürfen Sie die Online-Version natürlich ausdrucken. Ansonsten unterliegt das Openbook denselben Bestimmungen, wie die gebundene Ausgabe: Das Werk einschließlich aller seiner Teile ist urheberrechtlich geschützt.
Alle Rechte vorbehalten einschließlich der Vervielfältigung, Übersetzung, Mikroverfilmung sowie Einspeicherung und Verarbeitung in elektronischen Systemen.


Nutzungsbestimmungen | Datenschutz | Impressum

Rheinwerk Verlag GmbH, Rheinwerkallee 4, 53227 Bonn, Tel.: 0228.42150.0, Fax 0228.42150.77, service@rheinwerk-verlag.de

Cookie-Einstellungen ändern