Symptom: Memory leak caused by a sensitive detector. The G4Hit is created with new and never deleted during the run. The solution (works) is to manually delete all element in the G4THitsCollection at EndOfEvent(G4HCofThisEvent* HCE). The real problem: The G4Hits were allocated using G4Allocator, overloading the new and delete operators, exactly as in the novice examples. Doing this does _not_ free the memory on a delete thrown from the sensitive detector. Nor does the memory get freed by using ResetStorage(). The only option to make sure the memory is freed after the event is to not use the G4Allocator and hence not overload the new and delete operators. It is believed this causes a slower performance at run time.
Thanks for reporting this symptom. We could reproduce indeed this behavior which seems not related to the way G4Allocator is implemented though, but to a change in behavior of the compiler from gcc-2.95.2 onwards. To be clear, G4Allocator::ResetStorage() frees the memory allocated in the allocator pool in the correct way, which means that if called at regular intervals during a run, the memory allocated is assured not to grow out of control over a certain plateau. In any case, it is assured that no memory is leaked. With gcc-2.95.2, the memory is noticeably returned to the free store and to the system. With gcc-3.2.3 and higher, this seems to be no longer the case and the total allocated memory remains constant and never decreasing. The problem report is kept open for the time being, pending investigation and possible bug-report to gcc.
The behavior is to be identified in a memory optimisation made by the compiler to eventually avoid memory fragmentation and more performant usage of the allocated memory. No real leaks are observed as faulty behavior of the Geant4 allocator class.
