CodeDebugging

gdb

gdb is the gnu standard text-only debugger. We set up a compatible version when you set up an Offline version.

Here are a few simple commands to get started, there is an online manual.

If your command is

 mu2e -s genReco.art -c Print/fcl/print.fcl

Evoke gdb with:

 gdb --args mu2e -s genReco.art -c Print/fcl/print.fcl

Start execution:

(gdb) run

You can also restart execution by typing "run" again. If you run once, the libraries won't all be loaded, but when you re-run they will be. Show the call stack:

(gdb) where

Select second frame in stack:

(gdb) frame 2

Typically, the exe will have been built on another machine, so gdb can't find the source code. You can tell it about source directories like:

(gdb) dir  /cvmfs/mu2e.opensciencegrid.org/Offline/v7_0_4/SLF6/prof/Offline/Print/src

These commands can be put in a .gdbinit file. Step one line, stepping over function calls:

(gdb) n

Step one line, stepping into function calls:

(gdb) s

Set break by function (tab completion available if libraries are loaded)

(gdb) break 'mu2e::CaloHitPrinter::Print(art::Event const& event, std::ostream& os)'

Set break by line number

(gdb) break 'CaloHitPrinter.cc:102'

Continue after a break:

(gdb) cont

Run to the end of a stack call:

(gdb) finish

Print local variable "x":

(gdb) p x

Print stl vector "myVector"

(gdb) print *(myVector._M_impl._M_start)@myVector.size()

list code line n

(gdb) list n

Catch art throws

(gdb) catch throw

It is possible to to do very much more such as setting break on a memory location write, attach to a running process, examine threads, call functions, set values, break after certain conditions, etc.

valgrind

valgrind is a memory debugger which largely works by inserting itself into all heap access and flagging memory as requiring a callback before use. It can detect:

• use of unintialized variables
• using a pointer to access memory not allocated to that pointer
• double deletion
• memory leaks

It is installed on all interactive machines, or you can UPS setup a particular version.

Here is a typical command

valgrind --leak-check=yes --error-limit=no -v  \
        --demangle=yes --show-reachable=yes  --num-callers=20 

The additional memory checking causes the exe to run much slower.

You may find that packages like root libraries may have so many (probably not consequential) errors detected that it drowns out the useful messages. You can create a file of error types, or source code to suppress, please see the documentation.