Project

General

Profile

Bug #14800

Memory leak running LArG4

Added by Gianluca Petrillo almost 4 years ago. Updated over 3 years ago.

Status:
Closed
Priority:
High
Category:
Simulation
Target version:
-
Start date:
12/09/2016
Due date:
% Done:

100%

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

Description

Tingjun Yang reported evidence of a memory leak in LArG4 module, that did not show in v06_16_00.
It shows when running standard_g4_dune10kt_1x2x6.fcl on a GENIE generated file.

The memory of a test job with 100 events shows a peak memory of 2.7 GB (compared to 2.4 GB in the previous version), with the all the last 5 events in the standard MemoryTracker report on screen showing an increase between 20 and 50 MB.

History

#1 Updated by Gianluca Petrillo almost 4 years ago

  • Status changed from New to Assigned
  • Assignee set to Gianluca Petrillo
  • % Done changed from 0 to 100

After two hours of investigation while Tingjun kept trying to persuade me that this was actually a memory leak from the last commit in larsim, the problem was identified in commit larsim:0ecca073c5352dd902490d8731dd371c26047c34, where sim::OpDetPhotonTable uses a singleton to accumulate results, but it does not clean in between events. That is, a memory leak from the last commit in larsim.
In fact, the related data product can be seen steadily increasing in size event after event in the output file.

The specific solution was to have a method returning the result which also clears it: therefore that method, sim::OpDetPhotonTable::YieldOpDetBacktrackerRecords(), will return the result only once, and then the object needs to be filled again.
This is in my opinion a superior solution to the mechanism already in place for the other data in the object, that is to rely on the user to call sim::OpDetPhotonTable::ClearTable() when done. An alternative solution would have in fact been to add the deletion of the leaking results in that method.

Solution has been pushed as larsim:55f3da19f624e6d61e3a9466170b0c81fcd636e3.

This is also another brick in the wall with the "use singleton responsibly" graffiti on it.

#2 Updated by Gianluca Petrillo almost 4 years ago

  • Status changed from Assigned to Resolved

#3 Updated by Gianluca Petrillo over 3 years ago

  • Status changed from Resolved to Closed


Also available in: Atom PDF