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