Hi Mathieu,
>From what you describe, you must have a huge leak.
You never delete the objects created at each event.
AutoDelete (default) calls the destructor of the class for each branch.
But if the corresponding object is a collection, the objects in the collection
are not deleted by default. You have two possibilities:
-implement an Event destructor with statements like
myCollection->Delete(); delete myCollection; myCollection=0;
for each collection, collection of collections.
- call myCollection->SetOwner(). In this case, if all your collections
own the objects, a simple call to "delete myCollection" will also
delete the objects in the collection and you do not have
to implement a class destructor.
You only need to call SetOwner once in the program writing the Tree.
Rene Brun
Mathieu Ribordy wrote:
>
> Hi Rene and roottalk,
>
> I remember your reply to an email from Thomas Bretz about memory leak,
> nov. 9, 2001, when reading arrays. I'm currently working with the
> v3.02/07 and am facing very bad memory leak when reading a tree (when
> processing/writing it, I do not encounter any increase in memory
> ressources which are used). I have a default constructor in all involved
> classes, which do not allocate any memory.
>
> I suspect that I am at the origin of the problem. But, as I can't find
> any mistake, I was also thinking that ROOT could possibly be at the
> origin of it, and that the AutoDelete is not able to deal with a
> structure like: a class object (event) having containers of class
> objects (tracks), having themself containers of further class objects
> (hits relating track objects), having themselves a member pointing to a
> class object (a hit)
>
> I explain a bit different the last sentence:
>
> - to simplify a class event has a container of tracks and a container of
> hits
> - the next step is to associate some hits to a track (a subset of the
> hits), and other additional informations coming from the association of
> this subset of hits to a specific track. Then, to a track object belongs
> a container of objects which are relating hits to tracks. Those objects
> are then made out of member, whose one of them is a pointer to a hit
>
> This structure seems to cause problem, I can hardly draw 10'000 event,
> when I draw 1000 events, the memory which is used is about 160 MB,
> issuing some plots (5) looking like the following statement (it should
> also help to understand the structure):
> event_tree->Draw("event->GetTrack(0)->GetNumberOfHits()")
> where GetTrack returns a ptr to a track
>
> The file size, for 1000 events, not compressed is 32 MB. Then each plot
> seems to increase the used memory by about the file size ???
>
> The problem disappear in case I don't stream the container of hits
> relating track objects (or at least, I have no problem to deal with
> 10'000 events plots)
>
> Then the question is to know if such a scheme can be handled by ROOT or
> not. If yes, I have to look further to identify the problem more clearly
>
> Thanks for any help,
>
> Mathieu
This archive was generated by hypermail 2b29 : Sat Jan 04 2003 - 23:50:52 MET