Anzeige:
Ergebnis 1 bis 8 von 8

Thema: Debuggen mit KDevelop und GDB

  1. #1
    Registrierter Benutzer
    Registriert seit
    19.01.2006
    Ort
    Kaiserslautern
    Beiträge
    12

    Debuggen mit KDevelop und GDB

    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 ?? ()

  2. #2
    Registrierter Benutzer
    Registriert seit
    23.08.2005
    Ort
    Heilbronn
    Beiträge
    13
    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:
    Code:
    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.
    Code:
    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

  3. #3
    Registrierter Benutzer
    Registriert seit
    23.08.2005
    Ort
    Heilbronn
    Beiträge
    13

  4. #4
    Registrierter Benutzer
    Registriert seit
    19.01.2006
    Ort
    Kaiserslautern
    Beiträge
    12
    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:

    Code:
    (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

  5. #5
    Registrierter Benutzer Avatar von SeeksTheMoon
    Registriert seit
    22.02.2002
    Beiträge
    762
    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.
    I haven't lost my mind - It's somewhere on a backup-disc

  6. #6
    Registrierter Benutzer
    Registriert seit
    19.01.2006
    Ort
    Kaiserslautern
    Beiträge
    12

    Thumbs up Ich kann debuggen!!!

    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.

  7. #7
    Registrierter Benutzer
    Registriert seit
    19.01.2006
    Ort
    Kaiserslautern
    Beiträge
    12

    Ich habs...

    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

  8. #8
    dyle
    Gast
    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

Lesezeichen

Berechtigungen

  • Neue Themen erstellen: Nein
  • Themen beantworten: Nein
  • Anhänge hochladen: Nein
  • Beiträge bearbeiten: Nein
  •