Project

General

Profile

Bug #22265

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

Possible memory leaks in GausHitFinder

Added by Tingjun Yang 4 months ago. Updated 2 months ago.

Status:
Closed
Priority:
Normal
Assignee:
-
Start date:
04/02/2019
Due date:
% Done:

100%

Estimated time:
Duration:

Description

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== 

History

#1 Updated by Gianluca Petrillo 4 months 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 4 months 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.

Thanks,
Tingjun

#3 Updated by Tingjun Yang 4 months ago

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

#4 Updated by Tingjun Yang 2 months ago

  • Status changed from Resolved to Closed


Also available in: Atom PDF