DeBugging

Some debugging tips from Jack Morrison:

Some Linux versions require configuration changes to allow gdb to attach. Try changing ptrace_scope to "0" in /etc/sysctl.d/10-ptrace.conf

To watch something during normal operation, attaching to vt_main or vt_term is best. Debugging a startup issue is trickier, as vt_main is started by the vtpos loader. What I do is bypass the vtpos startup in vt_main and run vt_main in a separate gdb window:

window 1: gdb vtpos b 455 (where loader/loader_main.cc calls system() to start vt_main) run

window 2: gdb vt_main b (wherever)

window 1: jump 456 (skip over system())

window 2: (within a few seconds of previous step): run /tmp/vtmain

Launching vt_main from GDB in a second terminal and skipping the system call in vtpos is the way to approach debugging ViewTouch while watching it run. If you're not doing it this way, or some other way that works (and which you'd like to share with us) then you're doing it the hard way.

Thanks, Jack. Over the years Jack, who had nothing to do with actually creating ViewTouch, has been able to go into the code and fix bugs which not even the engineers who created ViewTouch were able to find. I ascribe his success to his raw talent, his vast knowledge of and experience with C++ but also to his mastery of debugging. Thanks, Jack. You're a real pro and you have my utmost respect!

Update: March 23, 2020 How to Debug with GDB: Frank Graziano offers this correction / update.

Open two terminals, Window 1 and Window 2. Window 1: gdb vtpos b 153 - this is where loader calls vt_main run

Window 2: gdb vt_main b xxx - any line number

Window 1: jump 154 - skip over calling vt_main

Within a few seconds switch to Window 2 and issue GDB command: run /tmp/vt_main

GDB will run vt_main, stopping at the specified breakpoint.