4. Gtk3 richtig debuggen

Gtk3 richtig debuggen

  • C

    Hallo,

    meine in C geschriebene Applikation stürzt sporadisch ab, ohne dass ich eine aussagekräftige Fehlermeldung erhalte.
    Wenn ich, wie ich im Internet recherchiert habe, beim Compilieren das Flag --enable-debug mit angebe, erhalte ich bereits beim Compilieren eine Fehlermeldung.

    Wie kann ich das Problem am besten angehen?

    Viele Grüße

    0
  • M

    Debugger anhängen, Exceptions aktivieren und schauen, was beim Crash passiert.

    0
  • C

    Wie mir gerade auffällt, vergaß ich zu erwähnen, dass ich zum Debuggen gdb benutze.

    0
  • M

    Und was genau ist das Problem? Kannst du mit gdb umgehen? Ist an deinem Problem irgendwas GTK3 spezifisches? Das glaube ich jetzt eigentlich nicht, wahrscheinlich hast du irgendeinen mehr oder weniger banalen Fehler gemacht und im Debugger sollte man auch ziemlich schnell draufkommen können.

    0
  • ?

    einfach mit gdb laufen lassen, wenn es "abstürzt" fängt gdb das Signal (z.B. Speicherzugriffsfehler) und du erhältst einen Callstack.
    Das reicht normalerweise um den Fehler zu finden!

    0
  • C

    Also ich erhalte folgende Meldung:

    (schach:3346): Gdk-ERROR **: The program 'schach' received an X Window System error.
    This probably reflects a bug in the program.
    The error was 'BadLength (poly request too large or internal Xlib length erro'.
    (Details: serial 386759 error_code 16 request_code 139 minor_code 0)
    (Note to programmers: normally, X errors are reported asynchronously;
    that is, you will receive the error a while after causing it.
    To debug your program, run it with the GDK_SYNCHRONIZE environment
    variable to change this behavior. You can then get a meaningful
    backtrace from your debugger if you break on the gdk_x_error() function.)

    Program received signal SIGTRAP, Trace/breakpoint trap.
    0x00007ffff48ac3d9 in g_logv () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
    (gdb)

    Daraus kann ich nichts Konkretes ablesen.

    0
  • M

    Und jetzt gibts du bt ein und schaust dir den Callstack an. Dann siehst du, wo du in deinem Code herkommst und was du falsch machst.

    0
  • ?

    Mechanics schrieb:

    Und jetzt gibts du bt ein und schaust dir den Callstack an. Dann siehst du, wo du in deinem Code herkommst und was du falsch machst.

    gdb ist sicher ein mächtiges Debugtool. Und richtig - man findet damit die meisten Bugs.
    Aber wer natürlich aus der Welt der Breakpoints, "Step in" oder "Step out" usw. Debugwelt kommt, hat eine sehr steile Lernkurve zu bewältigen.

    Den einzigen vernünftigen Debugger mit GUI für GTK+, den ich kenne, ist im IDE Anjuta enthalten.
    Nachteil bei Anjuta - man muss sich an das vorgegebene Schema halten und hat im IDE auch Glade integriert usw... Also viel Ballast dabei.

    Btw: Den "ddd", der ja auf gdb basiert, habe ich mit GTK+ nie zum laufen gebracht.

    0
  • C

    Leider bietet mir "bt" auch keine bessere Aussagekraft:

    This probably reflects a bug in the program.
    The error was 'BadLength (poly request too large or internal Xlib length erro'.
    (Details: serial 1472765 error_code 16 request_code 57 minor_code 0)
    (Note to programmers: normally, X errors are reported asynchronously;
    that is, you will receive the error a while after causing it.
    To debug your program, run it with the GDK_SYNCHRONIZE environment
    variable to change this behavior. You can then get a meaningful
    backtrace from your debugger if you break on the gdk_x_error() function.)

    Program received signal SIGTRAP, Trace/breakpoint trap.
    0x00007ffff48ac3d9 in g_logv () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
    (gdb) bt
    #0 0x00007ffff48ac3d9 in g_logv () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
    #1 0x00007ffff48ac522 in g_log () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
    Cannot access memory at address 0x7fffffff9f58

    Dann werde ich wohl mal Anjuta testen.

    0
  • M

    Hast du auch die ganzen Debugsymbole für das Zeug? Ich hab gdb bisher vor allem mit Assembler benutzt, aber ich bin mir ziemlich sicher, dass er Adressen auflösen würde, wenn er Debug Symbole finden würde.

    0
  • C

    Also ich hab beim Compilieren -g als Flag mit angegeben.

    0
  • M

    Aber hast du auch Debug Symbole für glib usw.?

    0
  • C

    Nein, scheinbar dann nicht. Ich dachte, dass das so reicht. Ich werd mich mal schlau machen :).

    0
  • ?

    Ich gehöre eigentlich auch zu den Hardcore Freaks von GTK+ ....
    Aber sowas möchte ich jedem eigentlich ersparen, jedenfalls in der heutigen Zeit: 😉
    https://developer.gnome.org/gtk3/3.0/gtk-running.html

    Wenn ich mit GTK+ entwickle, ist mein bester Freund zum Debuggen eigentlich

    g_print

    https://developer.gnome.org/glib/2.37/glib-Warnings-and-Assertions.html
    🙂
    Und wenn man sich mit Anjuta anfreunden kann - eben dieses....

    Ach ja - ein gutes, neues Jahr an Alle!

    0
  • C

    So, ich habe jetzt gtk mit --debug-enable=yes konfiguriert.
    Nun habe ich mit valgrind und folgenden Parametern:

    valgrind ./a.out --gdk-debug misc --gtk-debug misc

    mein Programm gestartet.
    Das Programm hängt irgendwann und lässt sich nur durch ein SIGKILL beenden. Jedoch erhalte ich keinerlei Debug-Ausgaben.
    Mit gdb das gleiche.

    Was kann ich tun?

    Ach ja - ein gutes, neues Jahr an Alle!

    Vielen Dank und selbiges gilt für dich und andere Forumsteilnehmer :).

    0
  • C

    der Fehler war, dass ich nicht im Main-Thread auf Gtk-Widgets zugegriffen habe. Habe dies nun geändert und erhalte keine Fehler mehr :).

    0
  • M

    Ok, das darf man in keinem der Toolkits tun, die ich kenne. Aber hilft dir das auch generell weiter, wenn du später andere Probleme hast? Ohne seine Software sinnvoll debuggen zu können, kann man IMHO nicht arbeiten.

    0
  • C

    Ja, doch; ich habe ja nun gtk mit --debug-enable=yes konfiguriert und erhalte auch Ausgaben wenn ich mit gdb debugge. Damit sollte ich (hoffentlich) zurecht kommen.

    0
Anmelden zum Antworten