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
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 muenster.de/~naumana/rootgdb.html. Let me know whether you find it useful and I’ll transfer it to the ROOT web pages.
at catch throw I get (among other things) this when I
bt
#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.
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
If not I will just have to go ahead and learn all the details of memory allocation and deloccation…
There are many ways . 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 valgrind.org) 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