We have an application (MEMPHYS) that have replicas in its geometry. If we do on the run manager : G4RunManager* runManager = new G4RunManager; runManager->SetGeometryToBeOptimized(false); .... <usual declarations to setup geometry (with replicas), etc...> runManager->Initialize(); ... delete runManager; We have a memory problem at exit that clearly comes from the usage of the "SetGeometryToBeOptimized" and the presence of replicas in the MEMPHYS geometry. On a Mac with the geant4-08-00 and a g++-4.0, the Mac signal a problem with a : MEMPHYS_session.exe(322) malloc: *** Deallocation of a pointer not malloced: 0xbfff6258; This could be a double free(), or free() called with the middle of an allocated block; Try setting environment variable MallocHelp to see tools to help debug To dig the point, we did a port on a Linux (with a geant4-07-01 only and a g++-3.2.3) and valgrind clearly confirms with : ==21376== ==21376== Invalid free() / delete / delete[] ==21376== at 0x401B3E0: operator delete(void*) (vg_replace_malloc.c:246) ==21376== by 0x56AA63B: G4PVReplica::~G4PVReplica() (in /geant4/geant4-08-00/slc3_gcc323/ lib/Linux-g++/libG4volumes.so) ==21376== by 0x58C699C: G4PhysicalVolumeStore::Clean(bool) (in /geant4/geant4-08-00/ slc3_gcc323/lib/Linux-g++/libG4geometrymng.so) ==21376== by 0x58C67B8: G4PhysicalVolumeStore::~G4PhysicalVolumeStore() (in /geant4/ geant4-08-00/slc3_gcc323/lib/Linux-g++/libG4geometrymng.so) ==21376== by 0x58C6D72: __tcf_0 (in /geant4/geant4-08-00/slc3_gcc323/lib/Linux-g++/ libG4geometrymng.so) ==21376== by 0x67E66C2: exit (in /lib/tls/libc-2.3.2.so) ==21376== by 0x67D17EB: __libc_start_main (in /lib/tls/libc-2.3.2.so) ==21376== Address 0xBEFF0940 is not stack'd, malloc'd or (recently) free'd ==21376== ==21376== ERROR SUMMARY: 997 errors from 4 contexts (suppressed: 2640 from 4) ==21376== malloc/free: in use at exit: 55,765,322 bytes in 551,170 blocks. ==21376== malloc/free: 7,186,830 allocs, 6,635,661 frees, 1,662,052,439 bytes allocated. ==21376== For counts of detected errors, rerun with: -v ==21376== searching for pointers to 551,170 not-freed blocks. ==21376== checked 44,901,260 bytes. ==21376== ==21376== LEAK SUMMARY: ==21376== definitely lost: 14,542,876 bytes in 301,128 blocks. ==21376== possibly lost: 8,794,956 bytes in 4,111 blocks. ==21376== still reachable: 32,427,490 bytes in 245,931 blocks. ==21376== suppressed: 0 bytes in 0 blocks. ==21376== Use --leak-check=full to see details of leaked memory. On the Mac the program exit anyway properly but on a Linux it crashes. Knowing that it is a geant4 release moment and before jumping in more debugging, we prefer to do a bug report now ; it is perhaps something already known and fixed or something easily fixable. Cheers
Do you have a test application where we can analyse and reproduce the problem ? Optimisation does not apply to replicas in Geant4, as such setting on or off optimisation from the run-manager should not have any effect for replicas. From the dump reported the problem seems related to the deallocation of a replicated volume, not clear why and cannot reproduce it.
Can you please verify that in your simulation you are doing the following: - using replicated volumes with replication along phi axis; - explicitely deleting at the end of the application rotation matrices assigned to any of your physical volumes. If so, try to assign to zero the pointer of the rotation matrix deleted. This should solve the problem. On replicas, rotation matrices are internally created and then destroyed automatically in the destructor, since in this case ownership is responsibility of G4PVReplica. We plan to implement in a near future a registration/deregistration mechanism for attributes associated to volumes to avoid situations of ambiguity for the ownership of pointers. Please, let us know.
Then we have definitely : - phi replicas - one rotation matrix - but the rotation matrix is not deleted for the moment in the program. Anyway, I have tried by having the lonely rotation matrix as member of out DetctorConstruction class and then explicitly delete it in the destructor of this class and setting the (then member) pointer to null, but it does not seem to fix the problem. At least I still have the memory leak message on my Mac.
