190 likes | 354 Views
Debugging Under Linux. Sebastien Ponce Friday, 8 March 2002. Overview. When to use a debugger ? Available debuggers Very short introduction to gvd (GNU Visual Debugger) Some hints on debugging Gaudi Jobs Demo. When to Use a Debugger ?. If you compiled in debug mode :
E N D
Debugging Under Linux • Sebastien Ponce • Friday, 8 March 2002
Overview • When to use a debugger ? • Available debuggers • Very short introduction to gvd (GNU Visual Debugger) • Some hints on debugging Gaudi Jobs • Demo
When to Use a Debugger ? • If you compiled in debug mode : • When you want to trace an application execution (breakpoints, step in, ...) • When you want to know where the execution crashes (segmentation fault is handled) • If you compiled in optimize mode : • You can still know which functions were called and which one failed
What to Do With a Core ? • You can still debug a program after a segmentation fault if you have a core file • You can learn about • Where it failed • What were the values of variables at this time • What was the call stack at this time
Available Debuggers • GDB • Default linux debugger • Powerfull & stable • Installed on lxplus • BUT for experts only • DDD • Based on gdb • Installed on lxplus • Allow Visual debugging • BUT not stable • GVD • Based on gdb • Installed in LHCb • Allow visual debug • Stable • Can be found for free at http://libre.act-europe.fr/gvd/ • Very easy to install locally PREFERED CHOICE
Launching gvd • Launching gvd : source setup.csh gvd <executable> • Inside gvd : [set breaking points] run <options> • In case of core dump : source setup.csh gvd <executable> • Inside gvd : FileOpen Core Dump <core>
gvd Basics Menu bar Tool bar Data display Call stack Source files Source code Current Line Gdb window
Some Hints for Gaudi Jobs • Gaudi is using shared libraries • The source files of these do no appear in gvd before the libraries are loaded • The trick is : gvd <executable> break main run <options> next here we loaded the ApplicationMgr break ApplicationMgr::configure cont finish now every dll is loaded
Demo (1) • Launch : tar xvf demo.tar cd demo make ./hello Segmentation Fault gvd hello
Demo (2) • gdb windows : (gdb) run Starting Program: /home/sponce/demo/hello Program received signal SIGSEGV, Segmentation fault 0x400e1630 in strcmp() from /lib/libc.so.6 (gdb) • In menu Data Call Stack • In Tool Bar Up
strcmp called from Hello::print argument line was 0x0 Click "Up" once more to see where the line argument was set to 0x0 Demo (3)
when print argument is missing, the default is a 0 pointer and fails. The default has to be changed to empty string Demo (4) Hello::print called from Hello::displayMessage with no argument
Demo (5) • Edition of Hello.h : static void print (char* line = 0); becomes : static void print (char* line = ""); • In a shell : make ./hello Segmentation Fault gvd hello • In gvd run There is another bug !
Demo (6) • In gvd : display Call Stack “Up" • The bug is still in strcmp, line is still 0x0 • In gvd : “Up" DataDisplay Any Expression ”this” Then click on the fields of this to see the internal values
We'll try to place a breakpoint where the initialization of m_message is done, i.e. In the constructor of Hello. Demo (7) thism_message is 0x0
Demo (8) • In gvd : Click on the blue point in front of line 4 of Hello.cpp to set a break point there Click run Say you want to start from beginning • gvd stops when the program reaches line 4 obviously the constructor was called with message = 0x0 Click "Up" to see where we came from
We were suppose to go through line 20, not 22 since we gave no argument This should have been 1 == argc !!! Fix and run. All Right ! Demo (9)
Demo (10) This is an example of what you get in case of non debug mode You still have the call stack but not the values of the arguments
Demo (11) This show you what you get from a core : gvd hello File->Open Core It’s equivalent to run the program inside the debugger