Crash related to looping descriptor not matching particle decay tree

A segmentation fault (found by @hoslee) occurs in a case where we are looking for particular decay descriptors having two of the same final state composite particles. In some cases simply changing the order of the composite particles prevents the crash, at least for a modest sample of 10k events. However this may simply mean that we hadn't run into the problem and perhaps it could occur if we run over larger samples.

The Sprucing line that the code runs over is SpruceBandQ_DoubleCharm_D0ToHH. This sprucing line currently constructs candidates of the form: psi(3770) -> D0 D0, where D0 can decay to all possible two-body charged final states involving {K,\pi}, and psi(3770) is a placeholder to combine the D0 with no mass cut. (real decay is D^0\bar{D}^0 but we cannot really identify which D is which flavour since we reconstruct all D decay possibilities... our thought was that D0 D0 was an acceptable approach though D~0 D0 could have also been used)

In this case, the particular crash may be related to a mismatch between the particle decay tree stored (presumably by the Sprucing identification) and the decay descriptor we are running over the sprucing line (looking for a specific decay). Here's some lines from the output that occur before the crash.

DoubleCharm.DecayFinder               DEBUG Particle decay tree: psi(3770) -> (D0 -> pi- pi+) (D0 -> K- K+)
DoubleCharm.DecayFinder               DEBUG Looping through the possibilities: psi(3770) -> (D0 -> K- pi+) (D0 -> pi+ ^pi-)
DoubleCharm.DecayFinder               DEBUG Particle tree matches descriptor: psi(3770) -> (D0 -> K- pi+) (D0 -> pi+ ^pi-)

The related options, yaml, and a log file are attached.

• dv_options.py
• options.yaml
• FunTuple.log

We run execute the code via the command line lb-run DaVinci/v64r9 lbexec dv_options:main options.yaml | & tee FunTuple.log

For some reason the crash log seems to indicate multi-threading; though n_threads is set to 1 in the .yaml file, so perhaps the multithreading is in some overarching process.

P.S. We are, alternatively, exploring the possibility of using only a psi(3770) -> D0 D0 decay descriptor, and then using the F.CHILD functors and assigned CHILD particle IDs to distinguish the different D0 decay modes; however it is not clear to us that this working yet, as in a small test the aggregate number of D0 daughters assigned as kaons and pions were not the same for both D0 candidates (we expect they should be --- unless there is some preferential ordering of the D0_1 and D0_2 candidates). We are not sure how the sprucing+DaVinci chooses to store selected candidates and assign kaon/pion hypothesis (and also if, for example, the same track would be stored as both kaon and a pion if possibly both hypotheses would pass selection criteria [e.g. D0 mass window cut]).