Unknown issue with Tree /reading

cej25 · April 21, 2026, 2:55pm

I have some (borrowed) code that generates a ROOT tree with some gamma data. It’s long and complicated to look through and I don’t have contact with the original authors. But, it does execute and complete fully without any error termination messages, making me think that the root file generation does complete.

I then try to use this tree (call it tree1) in some follow-up codes for merging with other data, applying corrections etc. In each of these subsequent codes, the program becomes stuck (RAM usage increases until program crashes) at the line:

TTreeReader tree_reader(tree1);

Long64_t Entt=tree_reader.GetEntries(true);

tree_reader.SetEntry(Entt-1); // ← hangs here

I checked another tree (call it tree2) produced a long time ago (with a version of the code that doesn’t exist so I can’t compare, but it should be effectively the same). tree2 should have identical Gamma data to tree1 which is the only relevant part for this analysis. It appears to me like it does, scanning some hundreds of entries. But running the subsequent programs on tree2, they work perfectly.

It feels to me that somehow tree1 was not generated “properly”, perhaps is was corrupted in some way. My question is, if I provide these trees, could anyone tell if tree1 is indeed corrupted somehow- or has anyone seen an issue where SetEntry() just hangs forever?

If it is any other issue (such as the codes generating each tree were fundamentally different and it’s impossible for you to tell without more information) then I don’t expect an answer, that’s fine. I’m just wondering if anyone has any tricks to spot whether tree1 is corrupted in a subtle way or something, that I’m missing, since it looks identical to tree2 in the relevant way.

Link to tree files: root_trees_apr26 – Google Drive

Thanks,

Calum

Wile_E_Coyote · April 21, 2026, 3:41pm

Try:
root -q -l tree1.root -e 'gFile->ls(); BRIKENTree->Print(); BRIKENTree->Scan("*");
root -q -l tree2.root -e 'gFile->ls(); BRIKENTree->Print(); BRIKENTree->Scan("*");

cej25 · April 21, 2026, 3:48pm

I have scanned both trees fairly thoroughly to ensure that the Gamma data is identical, but they just look identical.

dastudillo · April 21, 2026, 3:54pm

tree1.root:

root [] BRIKENTree->GetEntries()
(long long) 332421
root [] BRIKENTree->Scan("Gamma.T","","",3,332418)
************************
*    Row   *   Gamma.T *
************************
*   332418 * 2.194e+11 *
*   332419 * 2.194e+11 *
*   332420 * 2.194e+11 *
************************
(long long) 3

tree2.root:

root [] BRIKENTree->GetEntries()
(long long) 1239865
root [] BRIKENTree->Scan("Gamma.T","","",3,332418)
************************
*    Row   *   Gamma.T *
************************
*   332418 *         0 *
*   332419 *         0 *
*   332420 * 1.691e+11 *
************************
(long long) 3

cej25 · April 21, 2026, 3:56pm

this is unsurprising since there is some (quite a lot) ancillary data in tree2, so the entries won’t match up. but corresponding timestamps for the gamma entries should show identical energies etc.

dastudillo · April 21, 2026, 4:06pm

Well, “should” does not necessarily mean “does”, so first you should make sure this is the case. As for the crash with SetEntry, I did not get a crash (root 6.36.10 on linux), but maybe it depends on your code. I did a very simple example:

void tree_reader(Int_t x=1) {
  TFile *myFile = TFile::Open(Form("tree%d.root",x));
  TTreeReader tree_reader("BRIKENTree", myFile);
  Long64_t Entt = tree_reader.GetEntries(true);
  TTreeReaderValue<ULong_t> myT(tree_reader, "Gamma.T");
  tree_reader.SetEntry(Entt-1);
  cout << *myT << endl;
}

and get:

root [0] .x tree_reader.C(1)
Warning in <TClass::Init>: no dictionary for class BrikenTreeData is available
219494323965
root [1]

...

root [0] .x tree_reader.C(2)
Warning in <TClass::Init>: no dictionary for class BrikenTreeData is available
0
root [1]

Wile_E_Coyote · April 21, 2026, 4:12pm

@cej25 The output of “BRIKENTree->Print();” shows that these trees have different structures. So, if your analysis code depends on it, it will misbehave (for one of them, “Ancillary.*” branches are missing).

@dastudillo Try comparing trees using the condition "Gamma.type==2".

cej25 · April 21, 2026, 4:27pm

Hi @dastudillo thanks,

I will be more careful with my wording, I really meant that you should find they are identical.

Anyway in fact I also tried something similar, testing SetEntry with a very basic macro, and the troublesome file gives no problem. So I guess I am somehow more lost but also less convinced there is an issue with tree1.

cej25 · April 21, 2026, 4:29pm

Hi @Wile_E_Coyote yes tree1 should be missing the Ancillary branch, this is no problem. The analysis does not depend on it.

It is as I imagine that this problem probably requires a bit more information than I am able to even provide right now.

dastudillo · April 21, 2026, 4:29pm

@Wile_E_Coyote Gamma.T seems to be the same with that, but Gamma.newts is just slightly different (tree1 on top, tree2 bottom):

Anyway, probably the crash is more important.

Wile_E_Coyote · April 21, 2026, 4:48pm

@cej25 The “tree_reader.SetEntry(Entt-1);” will return different things, and your analysis may depend on the particular “Gamma.*” values (e.g., when there are zeros returned):

root -q -b -l tree1.root -e 'BRIKENTree->Scan("*", "", "", 1, BRIKENTree->GetEntries() - 1)'
root -q -b -l tree2.root -e 'BRIKENTree->Scan("*", "", "", 1, BRIKENTree->GetEntries() - 1)'

cej25 · April 21, 2026, 4:49pm

This could be true but in these programs the SetEntry line doesn’t (seem to) execute fully. Although as I mentioned to dastudillo, with a simple macro that loads the tree and tries this command, it seems to work. So it may well be some issue with the way these follow up programs are set up. I will look into this a bit more.