Peter,
Are you sure that you do not build a memory-resident Tree?
When you create teh tree, proceed like
TFile *f = new TFile("myfile.root","recreate");
TTree *T = new TTree("T",..);
and not the inverse.
If the symptom still p;ersists, send the result of
T->Print();
after a reasonable number of entries.
You do not indicate which version of ROOT. I assume 4.00/08.
Rene Brun
On Wed, 11 Aug
2004, Peter Skensved wrote:
> Hi,
>
> I'm running an application which builds a large tree. It shows
> signs of memory leaks so I started running it with memory checking
> turned on . The first ( and largest ) item in the leak.info file is
> as follows :
>
>
> Leaked allocations: 151 Leaked size: 608077
> operator new[](unsigned) (newdelete/src/NewDelete.cxx:333).
> 333 return ::operator new(size);
> TBasket::WriteBuffer() (tree/src/TBasket.cxx:487).
> 487 fBuffer = new char[buflen];
> TBranch::Fill() (tree/src/TBranch.cxx:487).
> 487 Int_t nout = basket->WriteBuffer(); // Write buffer
> TBranchElement::Fill() (tree/src/TBranchElement.cxx:923).
> 923 if (!TestBit(kDoNotProcess)) nbytes += TBranch::Fill();
> TBranchElement::Fill() (tree/src/TBranchElement.cxx:920).
> 920 if (!branch->TestBit(kDoNotProcess)) nbytes += branch->Fill();
> TTree::Fill() (tree/src/TTree.cxx:2249).
> 2249 nbytes += branch->Fill();
> main (FillTree.cxx:1523).
> 1523 sno->Fill();
>
>
>
> Am I correct in interpreting this as 151 instances of a leak of .6 Mb ?
>
> I looked at the code in TBasket::WriteBuffer() . I don't understand a lot of it
> but two things struck me : fBuffer is never deleted and fBuffer appears to be
> re-assigned inside the loop.
>
>
>
> I'm using version 4.00.08
>
>
> peter
>
>
>
> ----
>
> Peter Skensved Email : peter@SNO.Phy.QueensU.CA
> Dept. of Physics,
> Queen's University,
> Kingston, Ontario,
> Canada
>
>
>
This archive was generated by hypermail 2b29 : Sun Jan 02 2005 - 05:50:09 MET