Shared object with same file- and classname

Hi All,
I noticed a strange behaviour with ROOT 3.10/03, CINT 5.15.115 on Linux (kernel 2.4.26/gcc 2.95.3 glibc-2.2.2) (and also an ROOT4 Version on the same system) which I think is a bug of CINT.

In short if a dynamic library has the same name as a class the library contains CINT crashes if you load twice with .L

The attachment contains a source file wich conains a very small class named sotest. The makefile creates two shared libraries wich are, apart from the name, exactly identical. The one is named the other is named

If you start root and type .L twice eveything is fine.
If you start root and type .L twice, I get:

root [0] .L
root [1] .L
reloading /data/samson/flc/current/./ 0

*** Break *** segmentation violation
Generating stack trace…
0x40165bf6 in IgnoreInclude__5TROOTPCcT1 + 0xba from /products/ROOT/3.10_03/gcc-2.95.3/root/lib/
0x401a1d0b in IgnoreInclude + 0x2b from /products/ROOT/3.10_03/gcc-2.95.3/root/lib/
0x4068098a in G__loadfile + 0x10ba from /products/ROOT/3.10_03/gcc-2.95.3/root/lib/
0x406aa93b in G__reloadfile + 0x34b from /products/ROOT/3.10_03/gcc-2.95.3/root/lib/
0x406aeafd in G__process_cmd + 0x2975 from /products/ROOT/3.10_03/gcc-2.95.3/root/lib/
0x401a27d1 in ProcessLine__5TCintPCcPQ212TInterpreter10EErrorCode + 0xa1 from /products/ROOT/3.10_03/gcc-2.95.3/root/lib/

I don’t know if this is system dependent or even a bug in CINT, maybe you can reproduce this issue
Cheers, Joe.
sotest.tar.gz (788 Bytes)


Strangely enough, I can not reproduce your problem.
Please download ROOT v4.00/06a and check whether this is still failing.
If it is still failing, make sure to rebuild ROOT in debug mode and send me the stack trace of what happens when it crashes.


As you could not reproduce the error I tried to reproduce the error on an other system (in fact DESY-Linux 5 instead of DESY-Linux 4) with gcc-3.3.3 and the bug did not appear in any root version.
Unfortunately the latest gcc-2.95.3 version of ROOT I have installed is 4.00_04, where the error still occurs, but when using any ROOT version which is compiled with gcc-2.95.3 on DESY-Linux 5, the bug reappears (so the bug might be compiler depedent).

The first think i noticed on the “gcc-3.3.3 ROOT version” was a different output when reloading the shared library:
on gcc-3.3.3 root:

root [0] .L
root [1] .L
reloading /scratch/samson/sotest/./ 0
root [2]

whereas at an gcc-2.95 version the output is:

root [0] .L
root [1] .L
reloading /data/samson/flc/040628/sotest/./ 0
Warning in TClassTable::Add: class sotest already in TClassTable
root [2]

maybe the already helps you.

Here is the full stack trace of the gcc-2.95.3 version of ROOT 4.00_04 (I hope it is new enough)

*** Break *** segmentation violation
Generating stack trace…
0x4018f064 in GetClass__C5TROOTPCcb + 0x410 from /products/ROOT/4.00_04/gcc-2.95.3/root/lib/
0x40190d06 in IgnoreInclude__5TROOTPCcT1 + 0xba from /products/ROOT/4.00_04/gcc-2.95.3/root/lib/
0x401cf6fb in IgnoreInclude + 0x2b from /products/ROOT/4.00_04/gcc-2.95.3/root/lib/
0x4076213a in G__loadfile + 0x10ca from /products/ROOT/4.00_04/gcc-2.95.3/root/lib/
0x4078d1ab in G__reloadfile + 0x347 from /products/ROOT/4.00_04/gcc-2.95.3/root/lib/
0x4079131b in G__process_cmd + 0x28c3 from /products/ROOT/4.00_04/gcc-2.95.3/root/lib/
0x401d0230 in ProcessLine__5TCintPCcPQ212TInterpreter10EErrorCode + 0xb0 from /products/ROOT/4.00_04/gcc-2.95.3/root/lib/
0x4014d21e in ProcessLine__12TApplicationPCcbPi + 0x4ae from /products/ROOT/4.00_04/gcc-2.95.3/root/lib/
0x410c18d3 in HandleTermInput__5TRint + 0x1eb from /products/ROOT/4.00_04/gcc-2.95.3/root/lib/
0x410c0909 in Notify__17TTermInputHandler + 0x29 from /products/ROOT/4.00_04/gcc-2.95.3/root/lib/
0x410dcdf8 in ReadNotify__17TTermInputHandler at /data/gcc-2.95.3/hierhinein/gcc/…/…/gcc-2.95.3/gcc/cp/ from /products/ROOT/4.00_04/gcc-2.95.3/root/lib/
0x4023899a in CheckDescriptors__11TUnixSystem + 0xda from /products/ROOT/4.00_04/gcc-2.95.3/root/lib/
0x402381ec in DispatchOneEvent__11TUnixSystemb + 0xb0 from /products/ROOT/4.00_04/gcc-2.95.3/root/lib/
0x401a06a2 in InnerLoop__7TSystem + 0x2e from /products/ROOT/4.00_04/gcc-2.95.3/root/lib/
0x401a061f in Run__7TSystem + 0x6f from /products/ROOT/4.00_04/gcc-2.95.3/root/lib/
0x4014ddca in Run__12TApplicationb + 0x32 from /products/ROOT/4.00_04/gcc-2.95.3/root/lib/
0x410c1297 in Run__5TRintb + 0x2f7 from /products/ROOT/4.00_04/gcc-2.95.3/root/lib/
0x080487dc in main + 0x88 from /products/ROOT/4.00_04/gcc-2.95.3/root/bin/root.exe
0x41144c5f in __libc_start_main at /usr/src/packages/BUILD/glibc-2.2.2/csu/…/sysdeps/generic/libc-start.c:129 from /lib/
0x08048681 in _start + 0x21 from /products/ROOT/4.00_04/gcc-2.95.3/root/bin/root.exe
Root > Function () busy flag cleared
Function () busy flag cleared

If this is not enough information for you, please tell me, and I will try to give you the missing information.

Cheers, Joe.


The most likely cause at this point, since you do not notice the problem with gcc 3.3 and that gcc 2.95 issues

[quote]Warning in TClassTable::Add: class sotest already in TClassTable
is a compiler bugs similar to “when unloading the libraries the compiler does not properly call all the destructors of the global objects”. These desctructors are in charge of inducing the cleaning of ROOT structure regarding the library being unloaded. Without this cleanup, ROOT still thinks that (part of) the library is loaded and try to use it (with catastrophic error).

Sorrowfully, I do not know any other work-around except, use a newer compiler or do not reload libraries :frowning: