Problem 765

Summary:	Cannot free space in G4Allocator
Product:	Geant4	Reporter:	rikard.sandstrom
Component:	global/management	Assignee:	Gabriele Cosmo <Gabriele.Cosmo>
Status:	RESOLVED WORKSFORME
Severity:	normal
Priority:	P2
Version:	6.2
Hardware:	PC
OS:	Linux

Description rikard.sandstrom 2005-07-06 09:30:41 CEST

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.

Comment 1 Gabriele Cosmo 2005-07-11 11:20:59 CEST

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.

Comment 2 Gabriele Cosmo 2005-12-09 02:55:59 CET

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.