Re: Regard to the memory leak in BlastLib2

From: zhangchi (zhangchi@general.lns.mit.edu)
Date: Thu Sep 19 2002 - 11:24:31 EDT


Hi tong,

I heard you mentioned the leak in X-windows once, but I never related it
to out codes. But now I understand. If X leaks memory, I guess any effort
to fix nsed is just a waste of time. :(

I guess I overeacted. I had nsed running on auto for quite a while and
then see my swap is increasingly used. It made me feel a bit
uncomfortable.

Good that I am done playing with it and will spend my time on something
more useful.

Chi

On Wed, 18 Sep 2002 tong@MIT.EDU wrote:

> Hi,
>
> x-window leaks! This is well known in GNU community.
> So don't expect to get nsed memory leak free.
> We use nsed for just event display and it is O.K. to have
> the program to leak a few hundred bytes per event (displayed).
>
> -T
>
> Quoting zhangchi <zhangchi@general.lns.mit.edu>:
>
> >
> > Hi Tong,
> >
> > You are very right. I bumped into so many seg faults trying to implement
> > destructors for the classes. It took me a few days to trace them down.
> > At least it does not crash on my machine now.
> >
> > I did not find a lot of holes in TBLWc1*, so for a lot of Wc1* classes, it
> > is safe to leave it to the compiler to generate a default one. In fact I
> > did not find objects created and destructed per event cause any leak. This
> > is very assuring. Objects like TBLRecon is less of a problem, since it is
> > created at the beginning and even if it did not have a proper destructor,
> > the operating system will take the memory back after the program exits any
> > way. But if we instantiate two TBLRecon, the former one will not hand the
> > resource over to the second one.
> >
> > Yet as 3-D windows, saving ps/eps in nsed definitely cause leaks. I fixed
> > them( I hope).
> >
> > Anyway, I patch the leaks I found so far. And if some day, we needed to do
> > similar thing, I am willing to volunteer.
> >
> > Chi
> >
> >
> > On Wed, 18 Sep 2002 tong@MIT.EDU wrote:
> >
> > > Hi all,
> > >
> > > It is not surprising that we have many memory leaks.
> > > We have never optimized the code or debug for memory
> > > leaks.
> > >
> > > Because some classes have pointer to pervious classes, especially
> > > in TBLWc1*, deleting just that class might cause memory leak, too.
> > > For some reason, if you need to delete TBLWc1* class, you have to
> > > follow all the way down to hit container class and delete'm all.
> > > What I am saying is that if you just put "delete" for every "new," you
> > > will get run time segmentation error.
> > >
> > > -T
> > >
> > > Quoting Adam DeGrush <degrush@MIT.EDU>:
> > >
> > > > Hello All,
> > > >
> > > > There is a way that ROOT facilitates keeping track of objects created on
> > the
> > > > heap using "new" . One can create a TList container and then add every
> > > > object
> > > > to the container as its created. So for example:
> > > >
> > > >
> > > > //Create a TList
> > > > TList *fTrashCan = new TList;
> > > >
> > > > //An ordinary class
> > > > myClass *A = new myClass;
> > > > anotherClass *B = new anotherClass;
> > > > //Add them to the container
> > > > fTrashCan->Add(A);
> > > > fTrashCan->Add(B);
> > > >
> > > > //When you are done with the object, ROOT will free the memory taken by A
> > and
> > > > B
> > > > in one fatal swoop
> > > > fTrashCan->Delete();
> > > >
> > > > //Then free up memory by fTrashCan
> > > > delete fTrashCan;
> > > >
> > > >
> > > > This may help someone
> > > >
> > > > Cheers,
> > > > Adam
> > > >
> > > >
> > >
> > >
> > >
> >
> >
>
>
>



This archive was generated by hypermail 2.1.2 : Mon Feb 24 2014 - 14:07:28 EST