Problem 737

The .txt file from Valgrind is not reacheable, so I cannot verify if what
reported is indeed a leak or not.
In any case, in the user's application it is used:
  /tracking/storeTrajectory 1
in the macro used for the run.
This will of course internally store all trajectories in a container using the
G4Allocator.
Note that the allocator will NOT release the memory at the end of each event,
but will reuse it during the run. So, if a 'big' event will increase the pool,
the overall size of consumed memory will increase. For this purpose, the
G4Allocator provides a method ResetStorage() which can be called in the user's
application at the end of a certain number of events to free-up the allocated
memory and return it to the free store.
To verify if indeed memory is leaked, you should compare the output of
Valgrind (overall memory leaked) with two runs with different number of events
(so then you can exclude the memory leaked for initialisation)
I imagine that if the trajectories are not stored (flag set to 0) the memory
increase will not be that relevant.
Please, let us know if that fixes your problem and if so also please update the
related posting on Hypernews, thanks.

The massif files are accesible now.

Also for the storeTrajectory it was initial set to zero. I noticed the increased
memory consumption using the zero value. I made one run with storeTrajectory 1
to see how worse the things would be and right after I zipped the project to
make it available to you. I should have changed storeTrajectory back to 0. Sorry
about that.

One extra piece of information is that I was noticing the memory consumption
with top from the start of a run. It started with 30MB and for every big event
it would make a jump of the order of 100MB. The memory consumption would remain
that even after these events where processed.

One other thing to take note is that since I'm using corsika as the event
generator, for every Geant4 event there may be up to 3000-4000 Geant4 primary
particles.

I'll try the ResetStorage() method of G4Allocator and tell you if it helps.


Vlasios Vasileiou

In the beginning of every event, I call the ResetStorage() method (from inside
my SD class) to free the memory occupied by my sensitive detectors.

G4Allocator<milPMTHit> milPMTHitAllocator;

milPMTHitAllocator.ResetStorage()

I could verify that if I don't reset the allocated storage for the SD
hits, it is always increasing as the G4Allocator doesn't release it.

However, while the SD storage now starts empty for each event, the overall
consumed memory by the program is still high and increasing.

Maybe there are some other data,apart hits, stored in the allocator?
What else? Tracks? I use storeTrajectory 0.

Thanks,
Vlasios Vasileiou

Also tracks are stored using an allocator, if an event produces a massive
number of tracks the memory will of course increase, but would expect that
it will reach a stable plateau at some point...
Can you specify the system (Linux distribution) and compiler you are using ?

It does reach a plateu of about 350-400 MB, but isn't this too much? There are
many tracks in the sim since it simulates cerenkov photons produced in a pond
from air showers.

I'm using Redhat Enterprise Linux 3 and gcc 3.2.3 with G4OPTIMISE enabled.