| Summary: | Memory Leakage on G4ParticleHPContAngularPar::cacheInit() | ||
|---|---|---|---|
| Product: | Geant4 | Reporter: | Roy <admin> |
| Component: | run | Assignee: | Pedro.Arce |
| Status: | RESOLVED DUPLICATE | ||
| Severity: | normal | CC: | Koichi.Murakami |
| Priority: | P4 | ||
| Version: | 10.4 | ||
| Hardware: | All | ||
| OS: | All | ||
|
Description
Roy
2018-08-17 21:13:17 CEST
So yes I can confirm is a bug somewhere in the actual logic, the comment in the destructor here is quite clear https://github.com/Geant4/geant4/blob/6aa23be5171b125c3363b5a4cfa00a57e524598b/source/global/management/include/G4CacheDetails.hh#L252 // Ownership is for client // delete (*cache)[id]; So during the destruction phase the vector is cleaned, but NOT the object inside... which are responsability of the owner of the cache. Now I will check if is ok to delete during the destructor this cache, or if this value has been passed around. I am now 99% sure that yes is possible to clean element in the cache in the destructor of G4ParticleHPContAngularPar, the content is not passed anywhere after the end of life of the obj. I will now mod my local copy, and let run a quite long simulation. Basically the problem arises from https://github.com/Geant4/geant4/blob/6aa23be5171b125c3363b5a4cfa00a57e524598b/source/global/management/include/G4CacheDetails.hh#L227 In case that the value to be placed in the Cache is a ptr, a temporary object is created, stored and than LOST because later will be overwritten... If instead the object is not a ptr, the temp one is created, and than later properly destroyed when is overwritten. I also checked adding https://en.cppreference.com/w/cpp/types/is_pointer static_assert (std::is_pointer<V>::value, "do not use with PTR"); To see where else a ptr is used and is in several place. Proposed fix is to template<class V> void G4Cache<V>::Put( const V& val ) const { if constexpr(std::is_pointer<V>::value) { delete GetCache(); } GetCache() = val; } But sadly is cached a ptr of G4VelocityTable which is a singleton, so ... no public destructor... So I think we just have to change the leaking class to not store a ptr... Hi, Roy Thank you for reporting a bug with detailed investigation. And sorry for my late response. I have a question on your report. In the G4ParticleHPContAngularPar class, toBeCached struct is defined for G4Cache template. http://www-geant4.kek.jp/lxr/source/processes/hadronic/models/particle_hp/include/G4ParticleHPContAngularPar.hh#L49 class It contains three G4double and two pointers to G4ReactionProduct. http://www-geant4.kek.jp/lxr/source/processes/hadronic/util/include/G4ReactionProduct.hh You said " But sadly is cached a ptr of G4VelocityTable which is a singleton, so ... no public destructor... " G4VelocityTable is defined as a static member of G4Track. But, G4ReactionProduct has the pointer to G4ParticleDefinition not to G4Track. Could you explain how G4VelocityTable is related to this problem ? And I'd explain memory allocation of a singleton object. It is allocated automatically at the beginning of running the program, and is deleted at the end of running the program. Its constructor and destructor are invoked automatically and are not called by other classes. So, no public constructor and destructor are provided. Thank you and Cheers, Hisaya Hy Hisaya. The problem with the singleton is that the proposed fix with the "static if" can not be applied, because ... it can not call the destructor for this object! So ... is not leaking the Singleton, but is blocking the cache to ... work with just a single small fix... I forward this problem to Makoto, who is responsible for G4Cache Problem is already fixed in the development version and will be included in next releases. *** This problem has been marked as a duplicate of problem 2026 *** |