Variable-length array in TTree if length variable is set to zero?

[Michael_Kelsey]

How does ROOT handle the situation with a variable length array where the dimension has been set to zero? I have a TTree with an old-style variable length array:

Int_t nChan;
Double_t EChan[12];
eventsum->Branch("nChan", &nChan, "nChan/I");
eventsum->Branch("EChan", EChan, "EChan[nChan]/D");

On some events, there may not be any of this channel data, in which case nChan=0. How does ROOT handle that situation on writing? I’m getting a segfault “near” where this data gets filled and written out within each event:

#6  0x00002b0a46432bf0 in TBufferFile::WriteFastArray(double const*, int) () from /sw/eb/sw/ROOT/6.14.06-foss-2018b-Python-3.6.6/lib/libRIO.so
#7  0x00002b0a471efb4c in TBranch::FillLeavesImpl(TBuffer&) () from /sw/eb/sw/ROOT/6.14.06-foss-2018b-Python-3.6.6/lib/libTree.so
#8  0x00002b0a471f56b3 in TBranch::FillImpl(ROOT::Internal::TBranchIMTHelper*) [clone .localalias.114] () from /sw/eb/sw/ROOT/6.14.06-foss-2018b-Python-3.6.6/lib/libTree.so
#9  0x00002b0a472611f8 in TTree::Fill() () from /sw/eb/sw/ROOT/6.14.06-foss-2018b-Python-3.6.6/lib/libTree.so
#10 0x000000000051029f in CDMSSimRoot::SaveEventData (this=0x23119d0) at CDMSSimRoot.cc:561

Unfortunately this is in a multithreaded application (with all the ROOT stuff protected behind efficiency killing mutexes), and happens after an hour or more into the job. I’m trying to infer the cause, and this seemed like one of the possibilities.

I would prefer not to have to convert these data structures to vectors, as we have a large amount of past simulation data already written, and changing the TTree structure will mess up downstream analysis code.

ROOT Version: 6.14
Platform: MacOS, LInux
Compiler: GCC, LLVM

[vpadulan]

Hi @Michael_Kelsey,
I think @pcanal can give you details about that.
Cheers,
Vincenzo

[pcanal]

This is quite weird. The ‘zero’ element case is handled nicely and essentially does not write anything. The only thing I can think of is that nChan could be (inadvertently) set to a very large value (much more than 12) …

Another issue could be that the thread are (unintentionally) stepping on each other toes either by setting the same value of nChan and/or messing up the “address” associated with the branch.

Do you have a pointer to the source code (in particular the part where nChain is assigned and the part that calls SetBranchAddress)?

[Michael_Kelsey]

Thank you, @pcanal! I left this open to get an answer to my zero question. It is great to know that it is not only handled, but handled elegantly.

Yes, I found the problem in my own code. The data array is in my class immediately after the nChan variable. It turns out that I was not properly checking for an “invalid index” case, and in some cases was filling EChan[-1], stomping on nChan.

I caught this in the debugger at a point where nChan = 3926458. Sigh…