I didn't see it on the roottalk.
---------- Forwarded message ----------
Date: Wed, 28 Nov 2001 17:43:02 -0500
From: Timothy E. Miller <tim@bnl.gov>
To: Stephane Tourneur <tourneur@fnal.gov>
Subject: Re: [ROOT] memory leak and differences between root 2.26 and 3.01
On Wed, 2001-11-28 at 16:37, Stephane Tourneur wrote:
> I still get the same numbers as output of gObjectTable->Print() and my
> application still freezes due to the memory leak.
> Any other suggestions?
Here's a more complete answer...along with some educated guesses. There
was a second memory leak I overlooked in your macro. hphi->DrawCopy()
also returns a newly created object as well. So, the new macro would
look something like:
void draw () {
TFile *file = new TFile("Histo2D.root");
TString auxhistname = "Trk vs El (d0) ALL CUTS";
TH2F* plot = (TH2F*)file->Get(auxhistname);
TH1F* hphi = new TH1F("","",4,0,4);
TH1D* hd = plot->ProjectionX("",50,50);
hphi->SetBinContent(1,hd->GetMean());
delete hd;
TH1* hphi_copy = hphi->DrawCopy();
delete hphi;
delete hphi_copy;
delete plot;
file->Close(); // I add the Close() for my own sake.
delete file;
}
The change in the gObjectTable->Print() is summarized by the table:
Before .L draw.C+ : 666 633 3388 35880 31708
After .L draw.C+ : 698 665 3388 37504 33332
After draw() using
your macro: 3305 3272 8392 147980 143808
After draw() using
my changes: 3227 3194 6564 140240 136068
So it's clear there is some leaking in your macro... as for the rest
of the change in size...
Here's an excerpt of the gObjectTable->Print() after the draw() using
my changes:
TStreamerInfo 22 22 84 1848 1848
TStreamerBase 22 22 100 2200 2200
TStreamerBasicType 52 52 96 4992 4992
TStreamerObjectPointer 2 2 92 184 184
TStreamerString 7 7 92 644 644
TStreamerObject 3 3 92 276 276
TStreamerObjectAny 3 3 92 276 276
TStreamerBasicPointer 1 1 116 116 116
TAxis 6 6 128 768 768
TH1F 1 1 580 580 580
TGMenuTitle 7 7 108 756 756
THistPainter 1 1 180 180 180
TFrame 1 1 76 76 76
TCanvas 1 1 640 640 640
TGCanvas 1 1 88 88 88
TGCompositeFrame 1 1 80 80 80
TRootCanvas 1 1 176 176 176
TGMenuBar 1 1 92 92 92
TRealData 1319 1319 36 47484 47484
TDataMember 188 188 36 6768 6768
TMethod 425 425 36 15300 15300
TBaseClass 37 37 32 1184 1184
TMethodCall 16 16 60 960 960
TF1 13 13 240 3120 3120
TGHScrollBar 1 1 164 164 164
TContextMenu 1 1 52 52 52
TGPopupMenu 7 7 124 868 868
TBits 13 13 24 312 312
TGPicture 5 5 76 380 380
TGScrollBarElement 6 6 80 480 480
TH1D 1 1 580 580 580
TGStatusBar 1 1 96 96 96
TGVerticalLayout 3 3 20 60 60
TGViewPort 1 1 92 92 92
TGHorizontalLayout 1 1 20 20 20
TRootContextMenu 1 1 140 140 140
TGVScrollBar 1 1 164 164 164
All of these are new in the output as compared to the output prior to
the draw() call. The counts on some previously existing classes also
change...but I've left those out for brevity.
Some of this I believe is ROOT loading a copy of the class the first
time it is referenced. I've seen some examples of this in various
tidbits of code in the online reference manual (at least, I think that's
what it was doing). As for why there are still 1319 copies of TRealData
still on the heap...I'm not sure. Maybe it's the number of objects that
fit in a buffer for streaming data???
Hopefully, with this additional output, some more knowledgeable people
can comment. Oh, for the record, this was generated with 3.02.01.
Cheers,
-Tim
This archive was generated by hypermail 2b29 : Tue Jan 01 2002 - 17:51:10 MET