TTreeReaderValue kSetupNotSetup

ROOT
#1

I’m trying to read in from a TChain using a TreeReader. I have:

	TChain* inputdata = new TChain("tankflux");
	inputdata->Add("fluxesandtables/input_flux.*.root");
	inputdata->LoadTree(0);
	
	TTreeReader* inputfilereader = new TTreeReader(inputdata);
	Int_t numinputevents = inputfilereader->GetEntries(true);		
	// returns 3485, correctly
	
	TTreeReaderValue<Int_t> rdrrun((*inputfilereader), "run");
	
	TTreeReader::EEntryStatus entrystats = inputfilereader->SetEntry(0);	
	// returns kEntryValid
	Bool_t nextsuccess = inputfilereader->Next();					
	// returns true
	
	ESetupStatus runsetupst = rdrrun.GetSetupStatus();				
	// returns kSetupNotSetup

All this appears to be ok, except that the TreeReaderValue is not setup. Looking at examples, I can’t see what steps I need to take to set it up. As expected, if i try to read from it I get:

Error in <Get()>: Value reader not properly initialized, did you remember to call TTreeReader.Set(Next)Entry()?

But, as above, I have indeed called both.

#2

Is there a branch called “run” which stores integers in the trees? Can you share a file to reproduce the behaviour?

#3

Hi dpiparo
There is a branch called run. I’ve included a minimal working example. This one doesn’t print the error message, but segfaults at the same line.
annie_tank_flux.100.root (90 KB)
mainprogram2.cc (2.97 KB)

#4

Hi,

thanks for the reproducer.
Once changing the line

inputdata->Add("fluxesandtables/annie_tank_flux.*.root");

into

inputdata->Add("annie_tank_flux.*.root");

your example works for me. Can you try that too?

Danilo

#5

Hi Danilo.
That’s pretty curious. I assume you’ve placed the root file alongside the source file - in my case the annie_tank_flux file is in a subdirectory, hence the relative path. Without moving the file, changing that line produces 0 events in the input file. entrystat: 0 success -7 -7 Error in <CreateProxy()>: The tree does not have a branch called run. You could check with TTree::Print() for available branches. END OF INPUT FILE!!!!!!

But even if I copy the input file into the same directory, I receive the same errors as before - the tree is opened and entries read, but TreeReaderValue statuses are still -7 and I still get a segfault.

#6

odd.
What version of ROOT are you using?

Danilo

#7

6.04/14

#8

Hi,

I can reproduce that with 6.04.
I can certainly work in order to provide to you a workaround. On the other hand the 6.06 series (first release in december 2015) does not show this behaviour: is it an option for you to upgrade the ROOT version?

Cheers,
Danilo

#9

Hi Danilo,
Updating to root 6.06 should be possible. I’ll give it a try later and post back. Thanks again for looking into this. :slight_smile:

#10

Sorry for the delay and for having to revive this issue, but I’ve updated to 6.06 and the issue remains. As previously, number of entries is read correctly, SetEntry returns valid entry, next returns success, but TTreeReaderValues return status kSetupNotSetup. Same code as before, but now in ROOT 6.06.04.

Any further suggestions? :confused:

#11

Hello,

what release exactly?

Danilo

#12

Hi Danilo,
Um, 6.06/04? Is there more to say than that?

#13

Hi,

thanks for specifying that in the first place: I initially missed that line.
I tried the reproducer on the cern cluster, lxplus, using the central root installation on afs* and cannot reproduce the issue.
On what platform are you running?

Danilo

This can be set up as follows:

. /afs/cern.ch/sw/lcg/external/gcc/4.9/x86_64-slc6-gcc49-opt/setup.sh
. /afs/cern.ch/sw/lcg/app/releases/ROOT/6.06.04/x86_64-slc6-gcc49-opt/root/bin/thisroot.sh
#14

Hi Danilo.
I’m not a CERN user so I don’t have access to the CERN AFS to try your commands.
My system runs Linux Mint Debian:

$uname -a Linux minihal 3.2.0-4-amd64 #1 SMP Debian 3.2.57-3 x86_64 GNU/Linux

I’ll try to get this setup on the fermilab system as another reference, but eventually would need to get it working locally as well.

#15

Hi,

nevermind the afs setup: I thought it was worth mentioning a potential common ground.
I am not sure what to look for, so I’ll ask some basic questions:
o Are you sure you were really running ROOT 6.06 and not 6.04 because of some nasty misconfiguration effect?
o What compiler are you using?
o What is the cmake command you used to configure ROOT?

Cheers,
Danilo

#16

I’ve run $ root-config --version 6.06/04 $ cmake -DGeant4_DIR=/my/path/to/GEANT4/geant4-10.02/install/lib/Geant4-10.2.0 -DROOT_DIR=/my/path/to/ROOT/root-6.06.04/build ../sourcefiles $ make clean $ make and I can also see build warnings related to ROOT6.06 (shadow declarations of CLHEP variables like ‘s’) so I’m pretty confident it’s building using 6.06.
Compiler is g+±4.9.
The cmake instruction for building root was cmake -DCMAKE_INSTALL_PREFIX=/my/path/to/ROOT/root-6.06.04/install -Dcxx11=ON -Dgdml=ON -Droofit=ON -xml=ON -x11=ON -DCMAKE_BUILD_TYPE=RelWithDebInfo -Dmt=ON -Dkrb5=ON /my/path/to/ROOT/root-6.06.04/sourcefiles

Thanks again for the continued support

#17

Hi,

puzzling. could you add

std::cout << gROOT->GetVersion() << std::endl;

in your macro to triple-check this?

#18

Hi Danilo,
The compiled application returns 6.06/04