Seg fault with root 5.22a

Hello everyone,

Several months ago, I was doing a physical analysis using the 4.4.2b version of root. Now, my working environment has been updated, and I must use a new version of root, the 5.22a one. But a part of my code doesn’t work with this new version. I am not sure whether my code is in cause but it seems clear to me that I adapted my code correctly in order to work with the new environment. So, I usually produce rootfiles in 2 steps : the first one uses the original rootfiles delivered by my collaboration, and create “class-like” rootfiles (I defined my own C++ objects in a first time). The second one use these rootfiles to create more “traditionnal” rootfiles with trees and leaves, that represent physical variables. All these steps worked perfectly with the old setups.

This is the seg fault message I obtain at the second step, using the new setups of the collaboration and the new version of root :

*** Break *** segmentation violation
Using host libthread_db library “/lib/tls/libthread_db.so.1”.
Attaching to program: /proc/5790/exe, process 5790
[Thread debugging using libthread_db enabled]
[New Thread -1208858304 (LWP 5790)]
0x005db7a2 in _dl_sysinfo_int80 () from /lib/ld-linux.so.2
#1 0x022054b3 in __waitpid_nocancel () from /lib/tls/libc.so.6
#2 0x021ae779 in do_system () from /lib/tls/libc.so.6
#3 0x0177798d in system () from /lib/tls/libpthread.so.0
#4 0x009facfd in TUnixSystem::Exec ()
from /d0usr/products/root/Linux-2-4/v5_22_00a-GCC_3_4_3-dzero-rh7/lib/libCore.so
#5 0x00a01571 in TUnixSystem::StackTrace ()
from /d0usr/products/root/Linux-2-4/v5_22_00a-GCC_3_4_3-dzero-rh7/lib/libCore.so
#6 0x009fd869 in TUnixSystem::DispatchSignals ()
from /d0usr/products/root/Linux-2-4/v5_22_00a-GCC_3_4_3-dzero-rh7/lib/libCore.so
#7 0x009fd913 in SigHandler ()
from /d0usr/products/root/Linux-2-4/v5_22_00a-GCC_3_4_3-dzero-rh7/lib/libCore.so
#8 0x009fca1e in sighandler ()
from /d0usr/products/root/Linux-2-4/v5_22_00a-GCC_3_4_3-dzero-rh7/lib/libCore.so
#9
#10 0x0018a4c9 in TBufferFile::ReadFloat ()
from /d0usr/products/root/Linux-2-4/v5_22_00a-GCC_3_4_3-dzero-rh7/lib/libRIO.so
#11 0x001b6d32 in TGenCollectionStreamer::ReadMap ()
from /d0usr/products/root/Linux-2-4/v5_22_00a-GCC_3_4_3-dzero-rh7/lib/libRIO.so
#12 0x001b818a in TGenCollectionStreamer::Streamer ()
from /d0usr/products/root/Linux-2-4/v5_22_00a-GCC_3_4_3-dzero-rh7/lib/libRIO.so
#13 0x0018af3d in TCollectionStreamer::Streamer ()
from /d0usr/products/root/Linux-2-4/v5_22_00a-GCC_3_4_3-dzero-rh7/lib/libRIO.so
#14 0x0018bab7 in TCollectionClassStreamer::operator() ()
from /d0usr/products/root/Linux-2-4/v5_22_00a-GCC_3_4_3-dzero-rh7/lib/libRIO.so
#15 0x009b4229 in TClass::Streamer ()
from /d0usr/products/root/Linux-2-4/v5_22_00a-GCC_3_4_3-dzero-rh7/lib/libCore.so
#16 0x00187a12 in TBufferFile::StreamObject ()
from /d0usr/products/root/Linux-2-4/v5_22_00a-GCC_3_4_3-dzero-rh7/lib/libRIO.so
#17 0x001b6c77 in TGenCollectionStreamer::ReadMap ()
from /d0usr/products/root/Linux-2-4/v5_22_00a-GCC_3_4_3-dzero-rh7/lib/libRIO.so
#18 0x001b818a in TGenCollectionStreamer::Streamer ()
from /d0usr/products/root/Linux-2-4/v5_22_00a-GCC_3_4_3-dzero-rh7/lib/libRIO.so
#19 0x0018af3d in TCollectionStreamer::Streamer ()
from /d0usr/products/root/Linux-2-4/v5_22_00a-GCC_3_4_3-dzero-rh7/lib/libRIO.so
#20 0x0018bab7 in TCollectionClassStreamer::operator() ()
from /d0usr/products/root/Linux-2-4/v5_22_00a-GCC_3_4_3-dzero-rh7/lib/libRIO.so
#21 0x009b4229 in TClass::Streamer ()
from /d0usr/products/root/Linux-2-4/v5_22_00a-GCC_3_4_3-dzero-rh7/lib/libCore.so
#22 0x00184e0d in TBufferFile::ReadFastArray ()
from /d0usr/products/root/Linux-2-4/v5_22_00a-GCC_3_4_3-dzero-rh7/lib/libRIO.so
#23 0x0024921e in TStreamerInfo::ReadBuffer<char**> ()
from /d0usr/products/root/Linux-2-4/v5_22_00a-GCC_3_4_3-dzero-rh7/lib/libRIO.so
#24 0x001ce8d0 in TStreamerInfo::ReadBufferClones ()
from /d0usr/products/root/Linux-2-4/v5_22_00a-GCC_3_4_3-dzero-rh7/lib/libRIO.so
#25 0x070a50fa in TBranchElement::ReadLeaves ()
from /d0usr/products/root/Linux-2-4/v5_22_00a-GCC_3_4_3-dzero-rh7/lib/libTree.so
#26 0x070995b6 in TBranch::GetEntry ()
from /d0usr/products/root/Linux-2-4/v5_22_00a-GCC_3_4_3-dzero-rh7/lib/libTree.so
#27 0x070a12df in TBranchElement::GetEntry ()
from /d0usr/products/root/Linux-2-4/v5_22_00a-GCC_3_4_3-dzero-rh7/lib/libTree.so
#28 0x070a126b in TBranchElement::GetEntry ()
from /d0usr/products/root/Linux-2-4/v5_22_00a-GCC_3_4_3-dzero-rh7/lib/libTree.so
#29 0x070e904c in TTree::GetEntry ()
from /d0usr/products/root/Linux-2-4/v5_22_00a-GCC_3_4_3-dzero-rh7/lib/libTree.so
#30 0x08099508 in main (argc=3, argv=0xbff5b374) at …/src/ana.cxx:223

The program crashes at the execution of :

myfilter->fChain->GetEntry(i);

I attached the rootfile produced at the first step and used as an input file at the second step. The problem happens when I add the “b-tagging” variables to my tree (probability weights) and if when try to read the tree after that.
At the first step, I noticed I get a warning that appeared when I add the “b-tagging” code to my configuration files and when I execute these files. It is :

Warning in TClass::TClass: no dictionary for class ReadEvent::object_generator is available

Thank you very much for your help,

Jerome
myname.root (101 KB)

What I endly tried to do yesterday was to replace my current packages concerning the “b-tagging” part by the old ones (these used with the old release and the old version of root). The compilation was ok, and I got the same warning than before with these old packages, but in my new environment. So I think that it is the way that the code interacts with root that has changed (using the b-tag), but I can’t figure out what to do for this issue yet.
Would someone have an idea for this ?

Cheers,

Jerome

Philippe will investigate more in details what happens with your file when he wakes up.
I started a quick investigation and see that GetEntry crashes at the first entry when trying to read a map with strings with a huge number of elements (more than 17 millions) in the map. It looks like you had something non initialized in the job writing the map and this worked by chance when reading the entry with old ROOT versions.
This should be detected by ROOT to avoid a crash and Philippe will look into it.

Rene

Hello Rene,

Thank you very much for this clue.
Cheers,

Jerome

Hi Jerome,

The file seem (a priori) oddly written as the inner map (of string and float) seems to be written in ‘memberwise’ fashion where as we expect it to be written objectwise. Can you send me a way to reproduce the writting/creation of the file you sent (myname.root).

Thanks,
Philippe