CMS encountered a case where, when a branch is added to a Tree in the middle of processing, the IMT code for TTree::Flush triggers a segfault. See https://its.cern.ch/jira/browse/CMSCOMPPR-3348
From Chris Jones:
The problem appears to be the TTree has an inconsistent list of branches. I'm running the job in the debugger with a debug version of ROOT. The relevant place for the crash is here:
The branch being worked on is at entry `j` which is 909. However, if we get the size of `fSortedBranches` we get
(gdb) print fSortedBranches.size()
$9 = 893
So clearly we are getting a value outside the range of the number of branches in the sorted list.
I believe the problem is here:
the fSortedBranch list is only guaranteed to be the same size as the internal list of branchs in the TTree
the first time this routine is called. Since Andrea said they add more branches later, which can happen after a `TTree::FlushBaskets` is called, then `fSortedBranches` is no longer the correct size and we read off the end of the container.
Seems that the fSortedBranch cache ought to be invalidated each time a branch is added or removed. Looking quickly at the code, I expect it is possible to trigger the segfaults on reads too.