Message: Memory leak from G4VParameterisation::ComputeTransform() Not Logged In (login)
 Next-in-Thread Next-in-Thread
 Next-in-Forum Next-in-Forum

Feedback Memory leak from G4VParameterisation::ComputeTransform() 

Forum: Geometry
Date: 13 Apr, 2018
From: Michael H. Kelsey <Michael H. Kelsey>

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:
 1 1
 All All
Outline Depth:
 1 1
 2 2
 All All
Add message: (add)

1 Feedback: Re: Memory leak from G4VParameterisation::ComputeTransform()   (Gabriele Cosmo - 14 Apr, 2018)
 Add Message Add Message
to: "Memory leak from G4VParameterisation::ComputeTransform()"

 Subscribe Subscribe

This site runs SLAC HyperNews version 1.11-slac-98, derived from the original HyperNews


[ Geant 4 Home | Geant 4 HyperNews | Search | Request New Forum | Feedback ]