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

Feedback Re: Memory leak from G4VParameterisation::ComputeTransform() 

Forum: Geometry
Re: Feedback Memory leak from G4VParameterisation::ComputeTransform() (Michael H. Kelsey)
Date: 14 Apr, 2018
From: Gabriele Cosmo <Gabriele Cosmo>

Hi Mike,

thanks to share your experience on this. Nevertheless, this is a rather known
aspect anyone especially making use of parameterisations, have to take into
account. We may express this more explicitly in the guides, even if I should
make you notice what is already explicitly mentioned in the introduction of
the chapter for physical volumes... quoting: "The user has to take care of the
deletion of any additional transformation or rotation matrices allocated
dynamically in his/her own application".

Cheers, Gabriele

On Fri, 13 Apr 2018 19:19:09 GMT, Michael H. Kelsey wrote:
> 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 (
> and
> ).
> 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

 Add Message Add Message
to: "Re: 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 ]