|Message: Memory leak from G4VParameterisation::ComputeTransform()||Not Logged In (login)|
Click on the Forum title, e.g. on the "Forums by Category" page, to read a sequence of postings to the Forum and its threads all in one page. If you are only interested in one thread or the thread following a specific posting, click the thread or the posting, which takes you to a smaller page, which contains only the part you are interested in and may be easier to navigate.
Messages are "chained" if there are only replies at the first level, i.e. 1/1.html, 1/1/1.html etc. In case of "chained" messages the message number is replaced by the icon and there is no indentation.
Inline: Display the subject line only or also the text of the posting(s); for the choice "All" the "Outline" choices are switched off.
|1||0||1||no text / full text of posting|
|2||1||All||text for level 1 only / text for All postings|
Outline: Choose the depth of the posting thread, successive toggle controls provide increasing detail.
|1||2||1||2 levels / 1 level (original posting)|
|2||3||2||3 levels / 2 levels|
|3||3||All||3 levels / all levels (all postings)|
I recently "improved" my detector geometry model by adding the detailed arrangment of sensor pad lithography on my gemanium crystal surfaces. I used (obviously) G4PVParameterised, in order to place the roughly 11,000 individual pads on my 100 mm disk. Things worked very nicely in my geometry tests: I got the correct layout in visualization (and it was interesting to watch the pads get placed one by one), and throwing small numbers of test tracks showed that the pads were getting hit or not hit as expected.
Unfortunately, my first larger-scale run failed horribly, with a massive memory leak that overran both physical and swap allocation (it got up to 20 GB after just ten events, and crashed soon thereafter). I was able to collect some partial valgrind data which implicated my CDMSElectrodeMask::ComputeTransform() function, and a search of HN showed that two other people have run into exactly the same issue (http://hypernews.slac.stanford.edu/HyperNews/geant4/get/geometry/598.html and http://hypernews.slac.stanford.edu/HyperNews/geant4/get/geometry/1280.html).
Essentially, G4VParameterised is required to pass into G4VPhysicalVolume::SetRotation() a persistent pointer to G4RotationMatrix. G4VPhysicalVolume does not take ownership of the pointer, and therefore doesn't delete it when the geometry store is cleaned up. G4VParameterised also has no way to know when the pointer is no longer in use, and cannot delete it itself. This is an obvious, and potentially very large, memory leak. I don't think we can use smart pointers in this situation either, because nowhere in the code is there an indication that the allocated object is no longer in use!
Both John Allison and Gabriele Cosmo suggested similar workarounds: pre-create the pointers needed once, indexed by copy number, and pass those over and over, deleting the set in the destructor.
I think it could be helpful to include some discussion to this effect, and in particular warning about the memory leakage from using the G4VPhysicalVolume interface at face value, in the Developers' Guide.
-- Michael Kelsey
|Inline Depth:||Outline Depth:||Add message:|