Anmelden

Archiv verlassen und diese Seite im Standarddesign anzeigen : Debuggen mit KDevelop und GDB



Sascha Bahl
26-02-2006, 17:48
Hallo!

Zunächst einmal: Ja, ich habe mir die anderen Threads, die debuggen mit KDevelop als Thema haben durchgelesen. Leider haben diese mir nicht weitergeholfen.
Das eigentliche Problem:

Leider habe ich bis jetzt mehr unter Windows mit dem Visual Studio als unter Linux programmiert. Meine Erfahrungen und Herangehensweise beim debuggen beispielsweise versuche ich natürlich abzuleiten. Was mir nicht ganz klar ist: Ich setze einen Breakpoint in einer bestimmten Zeile, dann betätige ich den Knopf "Führt die Anwendung im Debugger aus!". Programm startet, hält aber nicht am Breakpoint an, sondern überspringt diesen. Wenn ich den Breakpoint an einer Stelle platziere, die erst später ausgeführt wird, kann ich die Anwendung anhalten und auch Einzelschritte ausführen um von einer Zeile zur nächsten zu springen. Der Haken: Ich sehe nicht in welcher Zeile ich mich gerade befinde. Ausserdem zeigt mir die Überwachung der Variable nur 0 an oder ein Fragezeichen. Die Meldung: "Keine Quelle: #0 ..." überzeugt mich davon, dass hier was noch nicht stimmt. Nur was? In den configure-Optionen habe ich schon den Parameter "--enable-debug=full" angegeben. Kompiliert wird mit g++ und der Option -g3.

Was habe ich noch übersehen, was mache ich falsch? Ich habe weder in den Manpages, noch über Suchmaschinen oder diesem Forum Antworten auf meine Fragen gefunden. Natürlich ist mir auch klar, dass debuggen nur eine Form des Fehler findens ist. strace oder Ausgaben während der Codeausführung sind mir nicht fremd. Aber Debuggen aus KDevelop halte ich für bequemer und effizienter, wenn ich nicht völlig falsch liege, dass es ungefähr so komfortabel ist wie im Visual Studio. Entschuldigt aber den Vergleich zu Micro$oft-Produkten. Ich hasse sie. Um so wichtiger debuggen unter Linux zu verstehen.

Vielen Dank schonmal

Sascha Bahl

P.S.
KDE 3.4, KDevelop 3.2, ansonsten SuSE 9.3

Auszug der Ausgabe von GDB:

/bin/sh -c /home/sascha/ssserver/debug/libtool gdb /home/sascha/ssserver/debug/src/ssserver -fullname -nx -quiet
(gdb) set edit off
(gdb) set confirm off
*** Warning: inferring the mode of operation is deprecated.
*** Future versions of Libtool will require -mode=MODE be specified.
Using host libthread_db library "/lib/tls/libthread_db.so.1".
(gdb)
(gdb)
(gdb) set print static-members off
(gdb) tty /dev/pts/4
(gdb) set width 0
(gdb) set height 0
(gdb) set stop-on 1
(gdb) handle SIG32 pass nostop noprint
(gdb) handle SIG41 pass nostop noprint
(gdb) handle SIG43 pass nostop noprint
(gdb) set print asm-demangle on
(gdb) set output-radix 10
(gdb) cd /home/sascha/ssserver/debug/src
(gdb) break cserversocket.cpp:70
Breakpoint 1 at 0x804903f: file /home/sascha/ssserver/src/cserversocket.cpp, line 70.
(gdb) break cserversocket.cpp:82
Breakpoint 2 at 0x80490ca: file /home/sascha/ssserver/src/cserversocket.cpp, line 82.
(gdb) run
Stopped due to shared library event
(gdb) continue
Stopped due to shared library event
(gdb) continue
Stopped due to shared library event
(gdb) continue

Program received signal SIGINT, Interrupt.
0xffffe410 in ?? ()
(gdb) backtrace
#0 0xffffe410 in ?? ()
#1 0xbfffef98 in ?? ()
#2 0x0804b008 in ?? ()
#3 0xbfffeee0 in ?? ()
#4 0x401d8681 in accept () from /lib/tls/libc.so.6
#5 0x08049220 in CServerSocket (this=0x804b008) at /home/sascha/ssserver/src/cserversocket.cpp:68
#6 0x08048cf7 in main (argc=1, argv=0xbffff064) at /home/sascha/ssserver/src/ssserver.cpp:49
(gdb) print buffer
$1 = 0
(gdb) frame 0
#0 0xffffe410 in ?? ()
(gdb) step
Cannot find bounds of current function
(gdb) backtrace
#0 0xffffe410 in ?? ()

Hampelmann
10-03-2006, 18:12
Hallo Sascha!

Ich liste für Dich mal ein paar relevante GDB Kommandos auf, diese solltest Du entweder in ein gdb config script einbauen oder auf der GDB Kommandozeile eingeben, aber das wäre umständlich, da Du das ja immer jedes Mal aufs neue machen müßtest:

directory <Quellverzeichnis>
Wenn Dein Projekt über mehrere Verzeichnisse geht, solltest Du sie nacheinander in obiger Syntax eingeben. Ich glaub standardmäßig wird nur im aktuellen Pfad gesucht.

set breakpoint pending on
Damit noch nicht setzbare Breakpoints auch nach dem Laden von Bibliotheken erneut versucht werden zu setzen muß man entweder in der GUI den Schalter unter den Project Settings aktivieren oder diesen Befehl angeben.

Ich benutze auch KDevelop und habe mir immer angewöhnt in ein Verzeichnis innerhalb meines Projekts eine ausführbare Datei names gdb abzulegen, hierin die Kommandozeilenoptionen für den GDB festzulegen und auf ein gdb config datei zu verweisen, die dann alle Kommandos enthält. Die KDevelop GUI für den GDB sieht zwar relativ gut aus, ist aber ein Sch**ß! Wobei die GDB Integration noch deutlich besser ist wie bei Anjuta.

Ciao,

Timo

Hampelmann
10-03-2006, 19:44
Hallo Sascha!
Beispielskripte kannst Du unter
http://www.software-engineering.org/~karamba/gdb_config
http://www.software-engineering.org/~karamba/gdb
finden.

Ciao,

Timo

Sascha Bahl
11-03-2006, 23:17
Hallo Hampelmann!

Vielen Dank für die Hinweise und Scripte. Ich habe Deine Tipps mal umgesetzt, was leider nicht zum Erfolg führte. Allerdings ist mir aufgrund dessen so einiges klarer geworden. Die Verzeichnisse sind wohl alle korrekt, wie mir die Ausgabe von GDB verrät:



(gdb) cd /home/sascha/ssserver/debug/src
(gdb) set args --mode=execute
(gdb) break cserverobserver.cpp:43
Breakpoint 1 at 0x80497e2: file /home/sascha/ssserver/src/cserverobserver.cpp, line 43.
(gdb) run

Wenn ich das richtig interpretiere, hat er den Breakpoint erkannt und wohl auch angehalten, dann aber gleich wieder weitergemacht. In der Praxis sah das so aus: Ich habe einen Breakpoint gesetzt, Programm im Debugger ausgeführt und das Programm ist gleich durchgelaufen ohne am Breakpoint halt zu machen. Ist nur die Frage, warum?

Wenn Du mir dabei auch weiterhelfen kannst, wäre das echt spitze.

Gruß

Sascha Bahl

SeeksTheMoon
15-03-2006, 10:52
ich verwende statt kdevelop lieber kdbg zum Debuggen. Ich habe auch nicht gepeilt wie das Debuggen in kdevelop klappen soll (ich hatte kein autoconf+make-Projekt, was kdevelop wohl gestört hat und ich habe auch einen Installationspfad verwendet, mit dem kdevelop wohl nicht einverstanden war - da gibt es erheblichen Nachbesserungsbedarf).

Mit kdbg hat alles geklappt.
ddd ist auch ein gutes Debugging-Interface (hat noch ein paar Features die kdbg nicht hat), allerdings kam es nicht mit Umlauten in meinen Quelltextkommentaren klar und hat dann keinen Code mehr angezeigt.

Sascha Bahl
22-03-2006, 21:19
Hallo!

Es ist mir nicht ganz erklärbar. Aber nachdem ich den Tipp von SeeksTheMoon befolgt habe und KDbg installiert habe und dank der Hilfe von Johannes Sixt, der das Programm entwickelt hat, es auch zum Laufen bekommen habe, probierte ich heute trotzdem nocheinmal mit KDevelop zu debuggen. Ging tadelos. Es ist komisch.

Ich danke euch jedenfalls allen für die Hilfe.

Sascha Bahl
27-03-2006, 21:49
Hätte mir auch jemand sagen können, dass man mit dem GDB keine Breakpoints anfahren kann die in Konstruktoren oder Destruktoren sind. Grund dafür ist wohl ein Bug. Ich habe mein Programm reorganisiert und jetzt klappt auch das Debuggen.

Aber trotzdem vielen Dank für eure Hilfe :-)

Sascha Bahl

dyle
12-04-2006, 13:41
Bin eigentlich auf der Suche nach was anderem aber habe bis jetzt mal das gelesen und möchte auch was sagen (Senf dazugeben):

Also: der gcc ab (ich glaube) Version 3.3 kompiliert aus einem constructor *mehrere* ins binary. Zur Laufzeit wird dann der geeignete genommen. Warum und wieso das so ist muss man googeln. Habe irgendwo auf der gcc-site darüber gelesen (sorry, dass ich die URL nicht liefern kann, ist aber einige Zeit her ...). Hat aber was mit Optimierung zu tun und ist *kein* Bug sondern ISO/C++ konform.

Falls nun ein Breakpoint in einem constructor ist, dann bekommt der gdb ein Signal aus einem Code-Bereich, welches er nicht in Zusammenhang mit dem Source bringen kann. Also hält der gdb kurz an, sucht verzweifelt nach einem passenden Source-Teil, weil ja irgendwo breakpoint gesetzt, kann Signal nicht matchen und gibt auf ... [mal so in etwa die Sachlage].

Weiters: wenn man mit Optimierung kompiliert (-Oxx) dann versteht's der gcc einige Variablen einfach mal weg-zu-optimieren und den Code kräftig zu rearrangieren. Falls man mit den GNU Tools arbeitet, dann empfehle ich die CFLAGS und CXXFLAGS manuel auf "-g" zu setzen und keine Optimierung zu aktivieren. Der gdb kommt ansonsten mit optimierten Code auch noch ganz gut zurecht. Zugegeben: es mutet manchmal dann etwas seltsam an, wenn der "next step" ganze 10 Zeilen weiter ist ... außerdem wird's ein bisschen haarig, wenn der Breakpoint in einem weg-optimierten Teil liegt ...

Ob jetzt KDevelop, gdb pur, kgdb, ddd oder was sonst noch verwendet wird ist IMHO eigenltich recht gleich. Bei KDevelop ist's halt ein grafisch ansprechenderes Frontend zum gdb.

Im Zusammenhang mit den GNU Autotools ist allerdings auch libtool nicht zu vergessen, welches einige Mühe machen kann. Denn: um GNU Autotools zu debuggen ruft man *nicht* "gdb myapp -param" auf sondern eigentlich "libtool gdb myapp -param" (wenn myapp das executable ist). Grund: das erzeugte "myapp" ist u.U. nur eine Script welches in ".libs/" auf das reale "myapp" zeigt. Das macht libtool deswegen um Library-Konflikte zu umgehen (man baut an einer Library, welche aber in einer Version bereits am Rechner fest installiert ist).

Hoffe, ein wenig Senf von da oben, schmeckt ...

lG