Dear colleagues,
I’d like to report on an unexpected issue that I observed using the LXBATCH system at CERN to execute a job in which a root macro, based on RDF , is executed on a ROOT File.
The macro contains the following line at the beginning:
ROOT::EnableImplicitMT();
Since I submit a single-core, single-host job, correctly I observe in the log the following:
Warning in <RTaskArenaWrapper>: CPU Bandwith Control Active. Proceeding with 1 threads accordingly
This is absolutely expected due to my job settings.
However, after this an error is reported:
Error in <TTreeReaderValue::Get()>: Value reader for branch isSignalBox not properly initialized, did you call TTreeReader::Set(Next)Entry() or TTreeReader::Next()?
RDataFrame::Run: event loop was interrupted
Error in <TRint::HandleTermInput()>: std::out_of_range caught: RDataFrame: Filter could not retrieve value for column 'isSignalBox' for entry 0. You can use the DefaultValueFor operation to provide a default value, or FilterAvailable/FilterMissing to discard/keep entries with missing values instead.
Indeed, the branch isSignalBox is properly stored in the TFile, and I can read if I open root terminal (even inside the host where the job is running, via condor_ssh_to_job).
If, inside the same terminal, I load the macro and I execute it, I get the same error.
I observed that, if I remove the MT instruction, the macro runs fine, suggesting some kind of conflict.
I suspect this is a bug - the expected behavior was to force (correctly!) the macro to run with a single thread, but without any data-access issue.
ROOT Version: 6.36.02
Platform: Rocky Linux 9
Compiler: gcc15