Hi Doug, and also Aaron,
I actually counted the number of "new" and "delete", there were much much
more "new" than "delete". :) which means a lot of objects created on heap
with "new" were not "delete"d.
The histograms in TBLDetRecon and TBLScRecon are not deleted anyway, so
they are leaks, I do not know if root will automatically clean them up
when we ask it to create new histograms with the same name. However, when
I tried to delete the one root file and two histograms in TBLFitTrack, I
got seg fault. Please let me know how to fix it.
I realized half way into the mess, that if one only invoke one instance of
TBLRecon and then quit the program like we always do using
"root -l recon.C"
then the operating system will take back the chunk of memory any way. I am
not sure but probably no leaks what so ever.
But the day I bump into problem, I was invoking recon.C (in fact a
variation I made) in root repeatedly for 100 events or so, after several
times of .x recon.C, I noticed an ever increasing momery usage.
I also used an nsed, and saved a lot of ps/eps figures, the way nsed is
coded makes each press of ps/eps button a memory leak. Same apply the 3-D
window. I wrapped the pointer to the TPostScript objects with an
auto_ptr, so when the the block of code finished the object will be
deleted when the auto_ptr goes out of scope.
With two recon.C, two nsed, two xemacs running together, my machine in
started swapping constantly after a few hours such abusing and the running
became pretty slow. It has 700M memory, swapping is not a ussual thing
unless you push it hard enough.
I confess, I only had a general suspect of memory leak, but was never able
to spot all of them with 100% confidence, except for the ones mentioned
above, so I had to take the pain to match every new with a delete. :(
I tried to use memprof on a compiled version of recon.C I made , it says
initial allocation exceeds the maximum capability or something. I
downloaded a memory debug tool called Valgrind wish to pin point the leak,
but it quickly produces more than 300 error messages and the last words I
got out of it were:
"more than 300 errors found, I will not report errors any more, Go fix you
program!"
That was a pretty funny error message.
Cheers
Chi
On Tue, 17 Sep 2002, Douglas Hasell wrote:
> I may be naive about such things but I believe one should be very careful
> about using the "new" operator in C++. It should only be used to
> dynamically create a new instance of an object in memory and then it has to
> be explicitly removed using the "delete" command otherwise memory leaks
> ocurr. It is not required to use "new" when creating a new instance of
> something.
>
> For example
>
> DKHobj MyDKHobj;
>
> and
>
> DKHobj *MyDKHobjptr = new DKHobj;
>
> both produce an instance of the object DKHobj (whatever that is) but the
> first form is automatically deleted when it goes out of scope but the
> second form must be explicitly deleted by the command
>
> delete MyDKHobjptr;
>
> If the delete command is not present or the pointer is lost because you go
> outside the scope of MyDKHobjptr then the memory space is never released.
>
> So be sure you need to use dynamic memory allocation and then be sure that
> you delete it when you are done and that the program can't bypass the
> delete statement even with interrupts, breaks, error returns, etc.
>
> --On Tuesday, September 17, 2002 4:10 PM -0400 zhangchi
> <zhangchi@general.lns.mit.edu> 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
> >
> >
> >
>
>
>
> Cheers,
> Douglas
>
> 26-415 M.I.T. Tel: +1 617 258 7199
> 77 Massachusetts Avenue Fax: +1 617 258 5440
> Cambridge, MA 02139 E-mail: hasell@mit.edu
>
This archive was generated by hypermail 2.1.2 : Mon Feb 24 2014 - 14:07:28 EST