(RunCodeWithSysFluxUniverses = True) vs EffPurityHists
daughter package used to notice the bug: CCQENu1DME
location of ntuples used: /pnfs/minerva/persistent/users/drut1186/HopefullyFinalMateusTuples/
location of histograms that contain the bug: /pnfs/minerva/persistent/users/mateusc/CCQENu_v21r1p1_Pub_May2019_NEWMuonEnergySys_YESSysFluxUniverses_CV/
version of CCQENuUtils.cxx: 1.60
version of EffPurityHists.cxx: 1.7
version of FluxReweighter: 1.32
New version of FluxReweighter seem to have problem with EffPurityHists. A segmentation fault happens after what seems to be the first event to access GetSysUniFluxWeight. The error is quite similar to the one seem in MuonEventSelection before GetSysUniFluxWeight had a protection against anti-nu events added. The Segfault is added in the attached files.
#2 Updated by Daniel Ruterbories over 1 year ago
Mateus and I looked at this this morning (5/30/2019).
First I tested this code against 2DLE with the correlations turned on against the first file in 1B. It passed.
Mateus make clean and tried again. Failed
I check out his package in my CCQENu area and run against hist code, 1B first file. Passes.
I check out clean area, grabbing HEAD of Ana/CCQENu, Ana/CCQENu1DME, Ana/PlotUtils. Build and run 1B first file. Passes.
Mateus is rightfully worried this is an odd event causing the issue. He runs the first file for 1B and I run all of 1L. Mine passes his fails.
Conclusions so far is his working area has an issue in the build. The committed code works. He will continue to investigate.
#3 Updated by Daniel Ruterbories over 1 year ago
- Status changed from New to Resolved
OKAY. Root memory management is confusing.
Turned off the FluxConstraint in FluxReweighter (commented it out) and code crashes no matter the CCQENu configuration.
The FIX is when I pull the histogram out of the MUon_Energy.root file that you SetDirectory(0).
I hypothesize that the FluxConstraint has a TH1::AddDirectory(false) in it someplace which kills this memory management craziness. All the other macros Mateus ran seem to have the TH1::AddDirectory(false) in the main() function which also killed the craziness.
Anyways, the stupid SetDirectory fixes the issue for people crazy enough to not have AddDirectory(false) in their code. THIS BUG IS SQUASHED. I shall go home now.