Project

General

Profile

Bug #5569

Memory leaks in LArG4

Added by Wesley Ketchum over 6 years ago. Updated over 6 years ago.

Status:
Closed
Priority:
Urgent
Category:
Simulation
Target version:
Start date:
03/02/2014
Due date:
% Done:

0%

Estimated time:
Occurs In:
Experiment:
MicroBooNE
Co-Assignees:
Duration:

Description

We are seeing very big memory leaks running the LArG4 module. This isn't new to this version necessarily, but they have become crippling, in that we have difficulties running some jobs for 10 events on grid. An example can be found here: /uboone/data/uboonepro/g4/v1_00_03/prodgenie_bnb_nue_cosmic_3window_uboone/15250424_45. The fcl file in that directory is what we typically run. An input file to run over would be /uboone/data/uboonepro/gen/v1_00_03/prodgenie_bnb_nue_cosmic_3window_uboone/15241372_45/prodgenie_bnb_nue_cosmic_3window_uboone_15241372_45_gen.root.

This is a little nebulous, but we could use help in profiling this to find where the memory leak is coming from. It seems far worse in events with lots of activity/charge deposition (the worst-offenders are the 3-frame simulations with cosmic rays). As this is affecting our current production challenge, I'm setting the priority to urgent (please reset if that's not appropriate): I'd like to help out, so if there are certain things I can do let me know. I'm not familiar with this code though, so I've included a number of people as watchers here who are probably more familiar.

History

#1 Updated by Wesley Ketchum over 6 years ago

OK! Perhaps resolved. Further testing necessary, but see
---https://cdcvs.fnal.gov/redmine/projects/larsim/repository/revisions/9c8896085d914fcaab56bce91366ce2ab60d2010
---https://cdcvs.fnal.gov/redmine/projects/larsim/repository/revisions/3fe5166a90c3df7d6b1266dd64b8766d785567a6

Adding Ben Jones as a watcher, so he can comment and make sure that it looks like that's OK.

#2 Updated by Gianluca Petrillo over 6 years ago

I had noticed that and in fact I was going to upload a fix similar to yours.
I confirm that the problem is the places you changed, although I haven't tried your fix.

#3 Updated by Gianluca Petrillo over 6 years ago

Incidentally, having in OpDetPhotonTable.cxx:


  void OpDetPhotonTable::AddPhoton(int opchannel, sim::OnePhoton&& photon)
  {
    if(!fDetectedPhotons[opchannel]) 
      {
        fDetectedPhotons[opchannel] = new sim::SimPhotons;
        fDetectedPhotons[opchannel]->SetChannel(opchannel);
      }
    fDetectedPhotons[opchannel]->push_back(photon);
    //    mf::LogInfo("OpDetPhotonTable") << "Registering detection of a photon in opchannel " <<opchannel<<std::endl;

  }

and in OpFastScintillation.cc (and similarly in OpDetSensitiveDetector.cxx)

            sim::OnePhoton PhotToAdd;
            PhotToAdd.InitialPosition  = PhotonPosition;
            PhotToAdd.Energy           = Energy;
            PhotToAdd.Time             = Time;
            PhotToAdd.SetInSD          = false;

            fst->AddPhoton(itdetphot->first, std::move(PhotToAdd));

would avoid a call to new completely (and no risk of leak, of course).

#4 Updated by Wesley Ketchum over 6 years ago

  • Status changed from New to Resolved
  • Assignee set to Wesley Ketchum

marking as resolved.

#5 Updated by Lynn Garren over 6 years ago

  • Status changed from Resolved to Closed

Also available in: Atom PDF