Debugging (with GDB)

setup ARB build

  • edit config.makefile
    • set DEBUG=1
    • set STABS=1
  • (rebuild if anything changed)

ARB functions useful for debugging

  • GB_dump(GBDATA*)
    prints a dump of the database element. Crashes easily - see below on how to continue.
  • GB_dump_db_path(GBDATA*)
    prints the hierarchical path from DB root to given element

gdb usage e.g.:

p GB_dump(variable)

Continuing after assertions

When an assertion (arb_assert) fails, arb will stop when running inside gdb, just as if you have set a breakpoint.

  • you may use continue to continue execution
  • if impractical (e.g. because inside a loop), use
    handle SIGTRAP nostop
    finish # repeat until you are outside the loop(s)
    handle SIGTRAP stop

See history for continuing SIGSEGV assertions.

Execute previous line again

  • (assuming we are currently on line 305)
    show previous line using
    info line 304
    shows sth like
    Line 304 of "arb_progress.cxx" starts at address 0x7ffff7631517 <initial_progress::update_gauge(double)+259> and ends at 0x7ffff763153d <initial_progress::update_gauge(double)+297>.
  • modify PC according to output
    set $pc=0x7ffff7631517
  • PC should have move to line 304 now.

Note: this will not undo any side-effects.
See also: reverse-next and reverse-step

Handle Xwindow-grabs

Problem: If debugger stops inside a xwindow-callback (eg. in a callback called from XtDispatchEvent), it is impossible to enter keyboard commands into the debugger :/

Solution: run debugger and arb on different displays (eg. two PCs or inside and outside a virtual machine):

  1. start VM and remote login to VM from HOST via ssh -Y ...
  2. start debugger (inside VM, but with display on HOST)
  3. in gdb call set environment DISPLAY :0 before you start arb
    ⇒ arb will popup inside VM display

Workaround (with side-effects):

  • iconify arb (when breakpoint has been hit)
Last modified 3 years ago Last modified on Nov 19, 2021, 6:15:45 PM