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