Hi, Pete, Aaron,
I recalled in the middle of my class some issues with respect to those
histograms. If we really want to clean them up, we can make the arrays
arrays of histograms instead of pointer to histograms, however, if any one
ever wants to draw those histograms, we better keep them in the scope and
pay the price of potential memory leak.
Here s the reason: Root updates the canvases when the script returns, that
is at the closing curly bracket, to successfully update a drawing of a
histogram, the histogram itself must be in scope. Imagine that we delete
all the histograms in the destructor of DetRecon or ScRecon and then we
run such a script:
{
TBLDetRecon det;
... ... // histograms in det are filled;
hist->Draw(); // assuming hist is one of the histograms in det;
} // here, all pads are updated
the pad/canvass that draws hist will be blank because hist is deleted when
~TBLDetRecon() is called. In same light, one will not be able to get
Mean/variance of hist after this point.
I feel that having a lot of TH?F or TTree in a library might not be a good
idea in general because we would have to decide to delete them or not. One
solution is to write them into a root file and open the file later.
I have started rewriting DetRecon anyway. I hope when finished, DetRecon
will take care of few things: selecting out valid tof/cc/nc hits,
calibrate them using Pete's calibration, associate a set of outer detector
hits with a certain track reconstructed, place a few cuts to determine the
particle ID of the tracks probable even give an ID to the event as a
whole. I am very lured to get rid of all the histograms and let user
fill histograms in their macros. This is the
easiest thing for me to do but this may be nasty to people who are using
those histograms. Anyhow, it may take me a little while to finish and
check the codes in. Let me know your opinion.
Chi
On Wed, 18 Sep 2002, Aaron Joseph Maschinot wrote:
>
> I'm not exactly sure which memory leaks you are talking about. However,
> the ones having to do with the TBLScRecon and TBLDetRecon have their
> source in that multiple histograms are given the same name inside of
> TBLDetRecon::InitData. If that problem still exists when I get to Bates,
> I'll check in the appropriate changes to CVS.
>
> Aaron
>
>
>
>
> On Tue, 17 Sep 2002, zhangchi wrote:
>
> >
> > Hi everyone,
> >
> > Last Thursday, after my computer started to swap, I decided that I wanted
> > to do something about the resource leak in BlastLib2. There were a lot of
> > memory blocks allocated by new yet not released by delete.
> >
> > Here are a few things I did:
> >
> > 1. I wrote destructors for a few classes to delete the heap objects.
> >
> > 2. Especially I wrote a destructor for TEventDisplay in nsed.cc. used
> > auto_ptr in some places to return memory after exiting.
> >
> > 3. I added private copy constructor and assignment operator = to some of
> > the classes. This will forbid a few things:
> > copy: T t1; T t2(t1);
> > assign: T t1; T t2=t1;
> > pass by value: f(T t); must use: f(T& t) of f (T* t)
> >
> > the 3rd one may affect some codes you wrote. For instance constructors of
> > TBLDetRecon and TBLScRecon are slightly modified.
> >
> > So far, except for a few TFiles and histograms in TBLFitTrack and
> > TBLDetRecon, all objects located on heap by new are removed using delete.
> >
> > Since the changes involve memory manipulation, if the code crashed by any
> > chance, please let me know, and I am more than willing to debug with you.
> >
> > By the way, please please do not write statements like this anymore:
> >
> > fCheckAnal[5] = new TGCheckButton(fG2, new TGHotString("Stubs"), -1);
> >
> > the TGHotString is doomed to be a memory leak, it does not give anyone any
> > chance. At least, we should leave a handle such that delete could be used
> > safely later.
> >
> > Unfortunately, I could not make it to the meeting tomorrow.
> >
> > Chi
> >
> >
> >
> >
>
This archive was generated by hypermail 2.1.2 : Mon Feb 24 2014 - 14:07:28 EST