I had given up this issue, but today I saw there was a new version 4.01/04.
In the release notes it is written:
[quote] Extended support for I/O of STL collections
Very complex cases of STL collections, or collections of collections, etc has been implemented in collaboration with Markus Frank from LHCB. STL collections are also supported in TTree split mode.[/quote]
I said: “wow, they made it!” and I rushed to try it.
So I was very sad to realize the appearently nothing has changed on this subject in the new ROOT.
With nested std::vector<> the program still crashes at TTree::Branch().
With nested TClonesArray the program runs but no splitting is available.
Absolutely nothing new.
(see my post “Can TClonesArray be nested?” for details on my classes design).
Collection within collections can not be split (it would extremely complex to implement and support). However there should not be any crashes.
What the releases notes are referering to is the fact we added support for splitting (one level) all STL collections in the same lines as was previously done for vector and TClonesArray (so for vector there is essentially no changes). We also added the possibility of reading back those containers without the original libraries.
Well, I must be doing something wrong as I still see crashes in such cases:
root [0] .x sample_writer_new.C
Info in <TUnixSystem::ACLiC>: creating shared library /home/ddangelo/./sample_bx
_classes_new_C.so
Fatal in <TBranchElement::>: fType==3 || fType==4 violated at line 887 of `tree/
src/TBranchElement.cxx'
aborting
Generating stack trace...
0x40e1c7ec in TBranchElement::BuildTitle(char const*) + 0xe2 from /cern/root/li
b/libTree.so
0x40e1c83a in TBranchElement::BuildTitle(char const*) + 0x130 from /cern/root/l
ib/libTree.so
0x40e19829 in TBranchElement::TBranchElement[in-charge](char const*, TStreamerI
nfo*, int, char*, int, int, int) + 0xe67 from /cern/root/lib/libTree.so
0x40e20be1 in TBranchElement::Unroll(char const*, TClass*, TClass*, int, int, i
nt) + 0x767 from /cern/root/lib/libTree.so
0x40e198bf in TBranchElement::TBranchElement[in-charge](char const*, TStreamerI
nfo*, int, char*, int, int, int) + 0xefd from /cern/root/lib/libTree.so
0x40e3cec4 in TTree::Bronch(char const*, char const*, void*, int, int) + 0x7b6
from /cern/root/lib/libTree.so
0x40e3b9db in TTree::Branch(char const*, char const*, void*, int, int) + 0x41 f
rom /cern/root/lib/libTree.so
0x40e576b4 in <unknown> from /cern/root/lib/libTree.so
0x407048e7 in G__call_cppfunc + 0x266 from /cern/root/lib/libCint.so
0x406f3fde in G__interpret_func + 0x706 from /cern/root/lib/libCint.so
0x406dbbc0 in G__getfunction + 0x134f from /cern/root/lib/libCint.so
0x40760c63 in G__getstructmem + 0x82a from /cern/root/lib/libCint.so
0x4075ad49 in G__getvariable + 0x4db from /cern/root/lib/libCint.so
0x406d3146 in G__getitem + 0x5c1 from /cern/root/lib/libCint.so
0x406d1d5e in G__getexpr + 0x783e from /cern/root/lib/libCint.so
0x40719a5e in G__exec_function + 0x1d5 from /cern/root/lib/libCint.so
0x407206ab in G__exec_statement + 0x23eb from /cern/root/lib/libCint.so
0x406baf3b in G__exec_tempfile_core + 0x2ce from /cern/root/lib/libCint.so
0x406bb145 in G__exec_tempfile + 0x22 from /cern/root/lib/libCint.so
0x407284cf in G__process_cmd + 0x4188 from /cern/root/lib/libCint.so
0x401a9419 in TCint::ProcessLine(char const*, TInterpreter::EErrorCode*) + 0xa9
from /cern/root/lib/libCore.so
0x401a9526 in TCint::ProcessLineSynch(char const*, TInterpreter::EErrorCode*) +
0x46 from /cern/root/lib/libCore.so
0x4010963d in TApplication::ProcessFile(char const*, int*) + 0x849 from /cern/r
oot/lib/libCore.so
0x40108d79 in TApplication::ProcessLine(char const*, bool, int*) + 0x5fd from /
cern/root/lib/libCore.so
0x4109c069 in TRint::HandleTermInput() + 0x1dd from /cern/root/lib/libRint.so
0x4109aeda in TTermInputHandler::Notify() + 0x24 from /cern/root/lib/libRint.so
0x4109c9e2 in TTermInputHandler::ReadNotify() + 0x12 from /cern/root/lib/libRin
t.so
0x40232397 in TUnixSystem::CheckDescriptors() + 0x143 from /cern/root/lib/libCo
re.so
0x40231287 in TUnixSystem::DispatchOneEvent(bool) + 0x161 from /cern/root/lib/l
ibCore.so
0x4016c5a8 in TSystem::InnerLoop() + 0x18 from /cern/root/lib/libCore.so
0x4016c54d in TSystem::Run() + 0x6f from /cern/root/lib/libCore.so
0x40109860 in TApplication::Run(bool) + 0x32 from /cern/root/lib/libCore.so
0x4109bb65 in TRint::Run(bool) + 0x327 from /cern/root/lib/libRint.so
0x0804886d in main + 0x71 from /cern/root/bin/root.exe
0x4120c7f7 in __libc_start_main + 0xc7 from /lib/i686/libc.so.6
0x0804876d in _Unwind_Resume + 0x31 from /cern/root/bin/root.exe
I attach a script version which reproduces the problem.
Thanks for the clear example. There was a missing protection that let ROOT try to split nested stl containers in your case. This will be fix shortly in the CVS repository.
You can also avoid any problem by preventing explicitly the splitting: