Bug #22265

Task #22198: Address various issues in protodune-sp reconstruction

Possible memory leaks in GausHitFinder

Added by Tingjun Yang about 2 years ago. Updated almost 2 years ago.

Start date:
Due date:
% Done:


Estimated time:


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 (
==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 (
==22281==    by 0x3521CAC8: hit::GausHitFinder::produce(art::Event&) (
==22281==    by 0x66C0BE0: art::EDProducer::produceWithFrame(art::Event&, art::ProcessingFrame const&) (
==22281==    by 0x6797845: art::detail::Producer::doEvent(art::EventPrincipal&, art::ModuleContext const&, std::atomic<unsigned long>&, std::atomic<unsigned long>&, std::atomic<unsigned long>&) (
==22281==    by 0x275B7D37: art::WorkerT<art::EDProducer>::implDoProcess(art::EventPrincipal&, art::ModuleContext const&) (WorkerT.h:198)


#1 Updated by Gianluca Petrillo about 2 years ago

The object 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.

#2 Updated by Tingjun Yang about 2 years ago

Hi Gianluca,

Thanks for the detailed information. As long as it is not a real memory leak, I don't think we need to change anything. I can live with the valgrind warning.


#3 Updated by Tingjun Yang about 2 years ago

  • % Done changed from 0 to 100
  • Status changed from New to Resolved

#4 Updated by Tingjun Yang almost 2 years ago

  • Status changed from Resolved to Closed

Also available in: Atom PDF