Failed to solve a memory leakage problem

Dear ROOTers,

I’m sorry for being asking you by the most “popular” and stupid question
concerning a memory leakage. But unfortunately I failed to overcome the
problem I’ve encountered.

I’m trying to construct a class (KopioMCLoader) that is a descendant of
two skeleton classes (KopioMCntuple1 and KopioMCntuple5) produced by the
TTree::MakeClass method. Please see the following link:

And I’m trying to load the above mentioned classes by two ways:

root [0] .L
root [1] .L // 1st method of loading
root [2] .L


root [0] .L KopioMCntuple1.cxx
root [1] .L KopioMCntuple5.cxx // 2nd method of loading
root [2] .L KopioMCLoader.cxx

and invoke the following commands:

root [3] KopioMCLoader ld;
root [4] ld.MakeSnumDnumIndex();

If I use the 1st method of loading the KopioMCLoader class, then everything
is OK and the 4th comand produces an output:

nSensDet = 105
i = 1
i = 2
… etc
i = 104
i = 105

This output is implemented inside the KopioMCLoader::MaxOfSnumDnum method
intentionly for the test. Well, if I try to load the KopioMCLoader class
by using the 2nd method of loading, then by invoking the 4th command
I obtain the following output with a crashed root session
nSensDet = 105
i = 1
i = 2

*** Break *** segmentation violation
Generating stack trace…
… etc
Function () busy flag cleared
Function MaxOfSnumDnum() busy flag cleared
Function MakeSnumDnumIndex() busy flag cleared
OK, I have been trying to debug this problem by applying the following

gdb root.exe
run -l
.L KopioMCntuple1.cxx
.L KopioMCntuple5.cxx
.L KopioMCLoader.cxx
KopioMCLoader ld;

Then I’ve got the following result
nSensDet = 105
i = 1
i = 2

Program received signal SIGSEGV, Segmentation fault.
0x4073ccab in G__LD_p1_uchar ()
from /e949dsk/bnlku20/scratch/artamonov/root/root_v4.00.04/root/lib/
At this point I’d like to ask you where to go. I’m not sure this is a ROOT
problem, but I’m confused that I can produce working shared libraries.
Could you advise me what to do?


I’m working on Red Hat Linux 7.3 2.96-113 and ROOT with version 4.00/04

your second option lets Cint interpret your files on the fly. This has some limitations; you might try to issue the “.O 0” command to Cint before loading your files; this disables Cint optimizations. If I rememebr correctly there were some problems with optimized Cint parsing and loops.

The preferred way of loading your sources is the Aclic mode:
root [0] .L KopioMCntuple1.cxx+
root [1] .L KopioMCntuple5.cxx+
root [2] .L KopioMCLoader.cxx+

which compiles the files if necessary (i.e. if the library doesn’t exist, or if a file changed).

Hi Axel,

Thank you for your help. Yes, the ways you suggested are working. So it looks like there is
a problem in CINT. Hopefully this will be recovered somehow.