Memory leak running LArG4
Tingjun Yang reported evidence of a memory leak in
LArG4 module, that did not show in
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.
#1 Updated by Gianluca Petrillo about 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
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.