TSelector hangs after using TChain::Add with wildcards

I am running code in an event loop that inherits from TSelector. I use STL containers, templates and so on, so I compile my code using gcc. I’ve been doing this for a while with few problems, I’ve recently noticed a strange behaviour (apparently) dependent on whether I use wildcards in TChain::Add.

When I don’t use wildcards, for example:
everything works fine, and the code exits properly.

When I replace that line (by use of a command line argument) with
now the process hangs. This occurs even if I run over a very small number of events (say 10) that certainly all occur within one file (each file has ~5000). Also, the hang occurs between the start of the last event, but before TSelector::Terminate() is called.

Oddly, the code does eventually terminate, though this might take hours (it was a while till I realised it was hanging rather than just inefficient processing).

I am happy to give any further details that might be needed, at the moment I don’t even know where to begin, and pasting all of my code wouldn’t be too helpful :wink: Any clues are appreciated!

Mike Flowerdew

Update: My test job finally completed after ~5 minutes (for 10 events, this should take seconds: the “hours” above was for a much larger job, but still one that should have taken nowhere near as long).

Interestingly, the Notify() function seems to be called another time after all (10) events have been processed. I’ve never seen this behaviour before, so it’s called 3 times in all:

  1. after the Init() function is called
  2. for the first file in the chain (immediately after 1 as far as I can tell)
  3. AFTER all events <-- this is the new one I’ve never seen before.

After this, the test job appears to exit normally.


Did you check what you have in the chain with

after calling TChain::Add ?

You do not specify which version of ROOT you use. In case you use an old version, could you try with a recent version: 5.16 or 5.17?



I can see nothing different between the two cases (the number of entries is odd, but the same for both cases). With just one file:

[quote]/batchstore/flowerdew/Ntuples/Thirty_um/trig1_misal1_mc12_V1.005802.JF17_pythia_jet_filter.recon.Ntuple.v12000601/user.michaelflowerdew.trig1_misal1_mc12_V1.005802.JF17_pythia_jet_filter.recon.Ntuple.v12000601_A.NTUPLE._00001.root tree:Ntuple1 entries=1234567890
With multiple files:

[quote]/batchstore/flowerdew/Ntuples/Thirty_um/trig1_misal1_mc12_V1.005802.JF17_pythia_jet_filter.recon.Ntuple.v12000601/user.michaelflowerdew.trig1_misal1_mc12_V1.005802.JF17_pythia_jet_filter.recon.Ntuple.v12000601_A.NTUPLE._00001.root tree:Ntuple1 entries=1234567890
/batchstore/flowerdew/Ntuples/Thirty_um/trig1_misal1_mc12_V1.005802.JF17_pythia_jet_filter.recon.Ntuple.v12000601/user.michaelflowerdew.trig1_misal1_mc12_V1.005802.JF17_pythia_jet_filter.recon.Ntuple.v12000601_A.NTUPLE._00002.root tree:Ntuple1 entries=1234567890
/batchstore/flowerdew/Ntuples/Thirty_um/trig1_misal1_mc12_V1.005802.JF17_pythia_jet_filter.recon.Ntuple.v12000601/user.michaelflowerdew.trig1_misal1_mc12_V1.005802.JF17_pythia_jet_filter.recon.Ntuple.v12000601_A.NTUPLE._00003.root tree:Ntuple1 entries=1234567890
/batchstore/flowerdew/Ntuples/Thirty_um/trig1_misal1_mc12_V1.005802.JF17_pythia_jet_filter.recon.Ntuple.v12000601/user.michaelflowerdew.trig1_misal1_mc12_V1.005802.JF17_pythia_jet_filter.recon.Ntuple.v12000601_A.NTUPLE._00004.root tree:Ntuple1 entries=1234567890
and so on, down to file 270, exactly as it should.

I am using ROOT 5.12/00. I will look into using a more modern version.


The problem seems to go away in root 5.14. I didn’t realise 5.12 was so old already!