Well, I am fighting against a utility which is linked against an old ROOT version … 5.28/00 trunk@37585.
I have a disk resident TChain which I try to analyze (using a dedicated compiled utility, the utility that produced these files is also based on the same version of ROOT libraries).
However, usually, I get a segmentation violation like this:
...
#9 <signal handler called>
#10 ... in TString::Streamer(TBuffer&) ()
from /.../libCore.so.5.28
#11 ... in int TStreamerInfoActions::VectorPtrLooper<&(TStreamerInfoActions::ReadTString(TBuffer&, void*, TStreamerInfoActions::TConfiguration const*))>(TBuffer&, void*, void const*, TStreamerInfoActions::TConfiguration const*) ()
from /.../libRIO.so.5.28
#12 ... in TBufferFile::ReadSequenceVecPtr(TStreamerInfoActions::TActionSequence const&, void*, void*) ()
from /.../libRIO.so.5.28
#13 ... in TBranchElement::ReadLeavesClonesMember(TBuffer&) ()
from /.../libTree.so.5.28
#14 ... in TBranch::GetEntry(long long, int) ()
from /.../libTree.so.5.28
#15 ... in TBranchElement::GetEntry(long long, int) ()
from /.../libTree.so.5.28
#16 ... in TBranchElement::GetEntry(long long, int) ()
from /.../libTree.so.5.28
#17 ... in TTree::GetEntry(long long, int) ()
from /.../libTree.so.5.28
#18 ... in TChain::GetEntry(long long, int) ()
from /.../libTree.so.5.28
#19 ... at ... MyChain->GetEntry(SomeNumber); ...
...
Sometimes, however, there is no error and the utility runs fine (nothing is changed, the same utility, the same TChain data files, …, just another trial).
What’s worse, if I try that utility under a debugger, it usually runs fine … without segmentation violation.
There is NO way to upgrade ROOT in the whole analysis framework.
There is NO way to try the same TChain with a new “standalone” ROOT (the TChain mostly contains analysis framework-specific objects, so it needs a lot of additional analysis framework-specific libraries).
I wonder … does the above problem with “TString::Streamer” ring a bell with anybody?
Has a problem like this been identified and repaired in ROOT between the old version 5.28/00 trunk@37585 and the current one (also “v5-28-00-patches”, if possible)?
==11463== Conditional jump or move depends on uninitialised value(s)
==11463== at ...: TClonesArray::ExpandCreateFast(int) (in /.../libCore.so.5.28)
==11463== by ...: TBranchElement::ReadLeavesClones(TBuffer&) (in /.../libTree.so.5.28)
==11463== by ...: TBranch::GetEntry(long long, int) (in /.../libTree.so.5.28)
==11463== by ...: TBranchElement::GetEntry(long long, int) (in /.../libTree.so.5.28)
==11463== by ...: TTree::GetEntry(long long, int) (in /.../libTree.so.5.28)
==11463== by ...: TChain::GetEntry(long long, int) (in /.../libTree.so.5.28)
==11463== by ...: ... MyChain->GetEntry(SomeNumber); ...
That’s the same source code line which produces segmentation violation.
Unfortunately, under valgrind it runs without segmentation violation (just like in case I use debugger).
Note, I said I was NOT able to try the whole analysis framework with a recent ROOT release.
I did a small test …
I have here a “standalone” ROOT 5.28/00f branches/v5-28-00-patches@40439 (not the newest one, but still only one month old), so I set PATH and LD_LIBRARY_PATH to the new ROOT and then I run my utility (it remains compiled with the “old” ROOT). I still get segmentation violation with the “new” ROOT in the same way as with the “old” ROOT.
With valgrind you should be able to use the --db-attach=yes option to attach a debugger and find out which branch is leading to the ‘Conditional jump or move depends on uninitialised value’. Once you have this name, you can double check that the value being passed to SetBranchAddress for that branch is of the correct type and properly initialized. Also you can try to the valgrind option --track-origins=yes which may (or may not) show more information on the origin of the problem.
Thanks. The additional flag helped (i.e. “–track-origins=yes”).
In a particular TChain (called “MyChain” in my previous mails here), there is a TBranch with a TClonesArray. In principle, this array should contain a (one) valid object for every TChain entry. I have found, however, that occasionally, for some entries in the TChain, that array has no objects. Now, after I read an entry and before I process that particular TClonesArray further, I always check that MyArray->GetEntries() != 0 and the problem seems to be gone.
Don’t ask me why it was dying in “MyChain->GetEntry(…)” reporting an error related to “TString::Streamer” (that particular TChain doesn’t seem to contain any TString explicitly).