Task #22198: Address various issues in protodune-sp reconstruction
Possible memory leaks in GausHitFinder
Valgrind showed the following warning:
==22281== 16 bytes in 4 blocks are definitely lost in loss record 2,151 of 63,444 ==22281== at 0x4C2A243: operator new(unsigned long) (vg_replace_malloc.c:334) ==22281== by 0xD6DE25E: TFormula::HandleParamRanges(TString&) (TFormula.cxx:1176) ==22281== by 0xD6E093C: TFormula::PreProcessFormula(TString&) (TFormula.cxx:1644) ==22281== by 0xD6D99C1: TFormula::TFormula(char const*, char const*, bool, bool) (TFormula.cxx:403) ==22281== by 0xD6A6354: TF1::TF1(char const*, char const*, double, double, TF1::EAddToList, bool) (TF1.cxx:566) ==22281== by 0x61FD2DEA: reco_tool::BaselinedGausFitCache::CreateFunction(unsigned long) const (PeakFitterGaussian_tool.cc:51) ==22281== by 0x2828FC1C: hit::GausFitCache::Get(unsigned long) (GausFitCache.cxx:49) ==22281== by 0x61FD051F: reco_tool::PeakFitterGaussian::findPeakParameters(std::vector<float, std::allocator<float> > const&, std::vector<reco_tool::ICandidateHitFinder::HitCandidate, std::allocator<reco_tool::ICandidateHitFinder::HitCandidate> > const&, std::vector<reco_tool::IPeakFitter::PeakFitParams, std::allocator<reco_tool::IPeakFitter::PeakFitParams> >&, double&, int&) const (PeakFitterGaussian_tool.cc:205) ==22281== by 0x3521CAC8: hit::GausHitFinder::produce(art::Event&) (GausHitFinder_module.cc:380) ==22281== by 0x66C0BE0: art::EDProducer::produceWithFrame(art::Event&, art::ProcessingFrame const&) (EDProducer.cc:91) ==22281== by 0x6797845: art::detail::Producer::doEvent(art::EventPrincipal&, art::ModuleContext const&, std::atomic<unsigned long>&, std::atomic<unsigned long>&, std::atomic<unsigned long>&) (Producer.cc:125) ==22281== by 0x275B7D37: art::WorkerT<art::EDProducer>::implDoProcess(art::EventPrincipal&, art::ModuleContext const&) (WorkerT.h:198) ==22281==
#1 Updated by Gianluca Petrillo almost 2 years ago
reco_tool::BaselinedGausFitCache is, you guess, a cache. It is derived from
reco_tool::GausFitCache which turns out to explicitly state that its
TF1 functions are never deleted.
I probably chose that to avoid the ROOT ownership trouble (what if ROOT decides afterwards to delete the function? what if it still remembers it?).
More to the point: that is a design choice. It may be changed, but I am afraid it would take a good amount of ROOT-guess-work at the risk of occasional crashes at the end of a job1.
Is the leak itself a problem? I think it shouldn't, in that the memory would be released at the end of the job anyway.
Or is the annoyance the fact that it appears in valgrind output? If so, how do you think the annoyance could be eased?
1 This is good material for nightmares.