Using debugger in ROOT


I have bumped into the problem of an
Error: Symbol G__exception is not defined in current scope …
Error: type G__exception not defined FILE: …

I would like to use a debugger to find the cause of the problem. My analysis looper runs over a certain number of datasets, but after some datasets I get the error message above.

Now, on a previous thread with similar problems the advice was to do

.L Looper.C+g
gdb root.exe

I then get:

I would be very thankful for some guidance!



This means that $ROOTSYS/lib is not on your LD_LIBRARY_PATH. To check what it is when gdb start dogdb> shell echo $LD_LIBRARY_PATH



thanks for your reply. I managed to set the path right so the debugger is up and running.

However, I am having trouble understanding how to use it properly. How to get the information that I need. Can you suggest some good tutorials?

I guess I need to find out where in my program an exception is thrown and catched. I should use breakpoints, but how to find out where in my program the problems happens?



a few centuries ago I wrote an intro for debugging ROOT at Let me know whether you find it useful and I’ll transfer it to the ROOT web pages.

Cheers, Axel.

Thanks, I will have a try. This was exactly what I was looking for. A more “human-like” explanation of what to do!

Get back once I have had a go…


I have been trying a bit now,

I have asked gdb to
catch throw
catch catch

at catch throw I get (among other things) this when I

#19 0x05de4239 in G__fileHYeBxv_2130_0_181 (result7=0xbfeb34c0,
funcname=0xffffffff <Address 0xffffffff out of bounds>, libp=0xbfeaf5a0,
hash=-121) at /mn/tid/epf-s1/maikenp/TestArea/./fileHYeBxv.cxx:4274
#20 0x00a47c02 in Cint::G__ExceptionWrapper ()

Now how to get hold of the funcname? How to know what to do next?

Would be very grateful for some hints what to do now!



hmm, now that I read your post you can probably debug the problem without GDB: execute the magic command “.T 1” at the ROOT prompt before running your code, and you’ll see it flying by as CINT interprets it. It should now show you which line causes the exception. You can also execute “.exception 0” to tell CINT not to catch exceptions.

Cheers, Axel.

If I do
.exception 0
I got:

terminate called after throwing an instance of 'std::bad_alloc’
what(): St9bad_alloc

Does this mean that there is no memory left to allocate? I know my program has started using lots of memory, can that be the problem?

My bad c++ programming is starting to give me problems maybe…


Yes, this is message is very often synonymous with out-of-memory. So you will need to track down memory leak, etc…


Thank you very much for your guidance.

I will have to go carefully through my code and find any memory leaks…

->I suppose there is no “easy” or standard way of doing this with gdb? Some magical command that finds the leaks? If there is I would very much like to know it :wink:

If not I will just have to go ahead and learn all the details of memory allocation and deloccation…

Thanks again,

Hi Maiken,

There are many ways :slight_smile:. If you run with gdb it should show you which memory allocation was the one that provoke the crash. Also you can use valgrind (see to detect memory leaks. Also you can use the ROOT memory tools:

To be able to track the allocation of TObjects, you should modify your .rootrc file - used by ROOT to setup the ROOT environment. Specifically, you want to make sure that two items are set to 1 (one):
Root.MemStat and Root.ObjectStat

Activate memory statistics (size and cnt is used to trap allocation of

blocks of a certain size after cnt times)

Root.MemStat: 1
Root.MemStat.size: -1
Root.MemStat.cnt: -1
Root.ObjectStat: 1

Then while in your ROOT interactive session, type:
gObjectTable->Print( )
This will display the contents of the memory table.


Thank you very much for all the tips.

I will go ahead and try out some of your options!