c-dilks
commented
1 year ago Another, maybe related problem: the MCParticles branch becomes inaccessible after reading one event, when attempting to read the second. For example:
for(unsigned e=0; e<reader.getEntries(); e++) {
// access collections, and print their sizes
fmt::print("Event {}:",e);
auto &simParts = store.get<edm4hep::MCParticleCollection>("MCParticles"); fmt::print(" simParts.size={}",simParts.size());
auto &recParts = store.get<edm4eic::ReconstructedParticleCollection>("ReconstructedChargedParticles"); fmt::print(" recParts.size={}",recParts.size());
fmt::print("\n");
// next event
store.clear();
reader.endOfEvent();
}Expected result:
testing on single-particle simulations, reconstructed from Juggler
Event 0: simParts.size=4 recParts.size=1
Event 1: simParts.size=3 recParts.size=1
Event 2: simParts.size=3 recParts.size=1
Event 3: simParts.size=3 recParts.size=1
Event 4: simParts.size=6 recParts.size=1
Event 5: simParts.size=2 recParts.size=1
...Actual result:
Tested on DIS production 22.11.0, an updated file from Dmitry, and on a file I produced locally from eicrecon
Event 0: simParts.size=4 recParts.size=1
*** Break *** segmentation violation
Event 1:
===========================================================
There was a crash.
This is the entire stack trace of all threads:
===========================================================
#0 0x00007fcaa44c5c46 in wait4 () from /lib/x86_64-linux-gnu/libc.so.6
#1 0x00007fcaa443a2fb in ?? () from /lib/x86_64-linux-gnu/libc.so.6
#2 0x00007fcaa4b3035d in TUnixSystem::StackTrace() () from /opt/software/linux-debian-x86_64/gcc-12.2.0/root-6.26.06-to6dg6u6muoorlvtlnt6sfkin2lvmxhl/bin/../lib/libCore.so.6.26
#3 0x00007fcaa4b2fcf4 in TUnixSystem::DispatchSignals(ESignals) () from /opt/software/linux-debian-x86_64/gcc-12.2.0/root-6.26.06-to6dg6u6muoorlvtlnt6sfkin2lvmxhl/bin/../lib/libCore.so.6.26
#4 <signal handler called>
#5 0x00007fca937abe28 in edm4hep::MutableMCParticle::MutableMCParticle(edm4hep::MCParticleObj*) () from /opt/software/linux-debian-x86_64/gcc-12.2.0/edm4hep-0.6-i2hmstpmbqgbd737obs6jk3al3ruyu6t/lib/libedm4hep.so
#6 0x00007fca937ad23f in edm4hep::MCParticleCollection::operator[](unsigned int) () from /opt/software/linux-debian-x86_64/gcc-12.2.0/edm4hep-0.6-i2hmstpmbqgbd737obs6jk3al3ruyu6t/lib/libedm4hep.so
#7 0x00007fca937af795 in edm4hep::MCParticleCollectionData::setReferences(podio::ICollectionProvider const*, bool) () from /opt/software/linux-debian-x86_64/gcc-12.2.0/edm4hep-0.6-i2hmstpmbqgbd737obs6jk3al3ruyu6t/lib/libedm4hep.so
#8 0x00007fca93a23e13 in podio::EventStore::doGet(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, podio::CollectionBase*&, bool) const () from /opt/software/linux-debian-x86_64/gcc-12.2.0/podio-0.15-ejugz5lwj3trxsarqd4i6ljws3jcmpic/lib/libpodio.so
#9 0x00007fca93132c7f in ?? ()
#10 0x00005556e76ec920 in ?? ()
#11 0x0000000000000000 in ?? ()
===========================================================
The lines below might hint at the cause of the crash.
You may get help by asking at the ROOT forum https://root.cern/forum
Only if you are really convinced it is a bug in ROOT then please submit a
report at https://root.cern/bugs Please post the ENTIRE stack trace
from above as an attachment in addition to anything else
that might help us fixing this issue.
===========================================================
#5 0x00007fca937abe28 in edm4hep::MutableMCParticle::MutableMCParticle(edm4hep::MCParticleObj*) () from /opt/software/linux-debian-x86_64/gcc-12.2.0/edm4hep-0.6-i2hmstpmbqgbd737obs6jk3al3ruyu6t/lib/libedm4hep.so
#6 0x00007fca937ad23f in edm4hep::MCParticleCollection::operator[](unsigned int) () from /opt/software/linux-debian-x86_64/gcc-12.2.0/edm4hep-0.6-i2hmstpmbqgbd737obs6jk3al3ruyu6t/lib/libedm4hep.so
#7 0x00007fca937af795 in edm4hep::MCParticleCollectionData::setReferences(podio::ICollectionProvider const*, bool) () from /opt/software/linux-debian-x86_64/gcc-12.2.0/edm4hep-0.6-i2hmstpmbqgbd737obs6jk3al3ruyu6t/lib/libedm4hep.so
#8 0x00007fca93a23e13 in podio::EventStore::doGet(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, podio::CollectionBase*&, bool) const () from /opt/software/linux-debian-x86_64/gcc-12.2.0/podio-0.15-ejugz5lwj3trxsarqd4i6ljws3jcmpic/lib/libpodio.so
#9 0x00007fca93132c7f in ?? ()
#10 0x00005556e76ec920 in ?? ()
#11 0x0000000000000000 in ?? ()
===========================================================
DraTeots
Environment: (where does this bug occur, have you tried other environments)
mainfor latest released):mainHEADfor the most recent on git):Steps to reproduce: (give a step by step account of how to trigger the bug)
Some branches (
Collections) are inaccessible when reading the output data usingpodio::EventStore(the commonEventStore, notEICrecon'spodioplugin version).Here is a ROOT macro
test_read.Cto demonstrate the issue; it can be run on any recenteicreconoutput file that has the specified branches:Given
eicreconoutput filerec.tree.edm4eic.root, run the three tests:Expected Result: (what do you expect when you execute the steps above)
Test
0is okay, since it only accessMCParticlesandReconstructedChargedParticlesTest
1should be similar, something like this:Test
2should print the typesActual Result: (what do you get when you execute the steps above)
Test
0is okay, since it only accessMCParticlesandReconstructedChargedParticlesTest
1crashes, since it accessesReconstructedChargedParticlesAssociations, one of the problematic branchesTest
2runs correctly until we try to accessReconstructedChargedParticlesAssociations. You can generalize theforloop here, usingauto collNames = collIDTable->names();instead; in this case you will find many more branches that crash upon access.