Fatal in <TGenVectorProxy> using TTreeFormula


I am trying to loop over a TTree containing a vector branch and a vector. I defined some TTreeFormula-s and everything works fine for one file. However, as soon as the loop loads the second file, I end up getting the following error:

Fatal in : At> Logic error - no proxy object set.

I am calling UpdateFormulaLeaves when the tree switches. I’ll try to prepare a minimal example, but I was hoping someone can tell me what I’ve missed. The sort of code I have is like this:

TTreeFormula* boolSelection = new TTreeFormula("f","boolBranch",chain);
   TTreeFormula* doubleVar = new TTreeFormula("f","doubleBranch",chain);

   int cTreeNum = -1;
   long nEntries = chain->GetEntries();

   for(long i=0;i<nEntries;i++) {
      if(cTreeNum != chain->GetTreeNumber()) { 
         cout << "update" << endl;

      for(int j=0;j<boolSelection->GetNdata();j++) {
         if(boolSelection->GetNdim()==0) continue;
         if(boolSelection->EvalInstance(j)!=1) continue;
         doubleVar->EvalInstance(j); //I do something with this value. If I comment this out, I don't have problems

Can anyone see what I’ve missed here?

For those who have access to cern afs, I’ve put two of my files in a public area, just replace the first two lines in the above code with:

 TChain* chain = new TChain("roiTree");
   TTreeFormula* boolSelection = new TTreeFormula("f","efexROI_isStandardETMax",chain);
   TTreeFormula* doubleVar = new TTreeFormula("f","efexROI_TauClus",chain);

And the error is reproducible for me.


One of the oddity of TTreeFormula is that you must always (if GetNdata > 0) call EvalInstance(0) even if you do not use this value. For optimization reason this is used as the ‘trigger’ to set the environment properly for each entry/event. So Use:

bool first = true; for(int j=0;j<boolSelection->GetNdata();j++) { if(boolSelection->GetNdim()==0) continue; if(boolSelection->EvalInstance(j)!=1) continue; if (first && j!=0) { first = false; doubleVar->EvalInstance(0); } // solves the problem. doubleVar->EvalInstance(j); }


Thanks for confirming this. I did indeed figure this out myself after several hours, with plenty of cursing when I found the comment in the root code that explained this unusual thing had to be done.

Thanks again.