lynx-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: lynx-dev more on leaks


From: Klaus Weide
Subject: Re: lynx-dev more on leaks
Date: Sun, 15 Nov 1998 11:33:21 -0600 (CST)

On Sun, 15 Nov 1998 address@hidden wrote:

> > > Actual leaks report    (actual leaks:      2629  total size:   28990 
> > > bytes) 
> > > 
> > >  Total  Num of  Leaked      Allocation call stack 
> > >  Size   Blocks  Block 
> > >                 Address 
> > > ======  ====== ==========  ======================================= 
> > >  23880    1194      -      dcgettext__ < dgettext__ 
> > >   2392    1196      -      dcgettext__ < dgettext__ 
> > >   2233     203      -      HTSACopy < UCGetLYhndl_byMIME 
> > >    348      29      -      calloc < store_cookie 
> > >    137       7      -      HTSACat < MakeNewMapValue 
> >  
> > Is that there are leaks in these 5 places, resulting in 2,629 actual leaks. 

The ones in UCGetLYhndl_byMIME and MakeNewMapValue (3rd & 5th line) seem
to be the same ones I found with --enable-find-leaks.  Those functions get
called a lot.

> I guess so (I do something similar for vile and ncurses, but haven't paid a
> lot of attention to the convention in Lynx's no-leaks code, and haven't
> done _any_ leak testing on the gettext code yet).  The bulk of the
> allocations are in the gettext code (and it's not clear at the moment if
> Lynx is reporting unfreed memory, or memory to which the pointers have been
> discarded).

I don't understand the difference.  If you lose the pointer, you cannot
free it, right?

Lynx reports memory that has been allocated with one of the wrappers for
malloc/calloc/etc but not freed (with the wrapper around free) at program
exit. Including LYleaks.h automatically defines the wrappers as macros.
It shows each place in the source (with lien number) where an offending
allocation occurred, and the last memory content.  You don't get a nice
summary as with Larry's stuff, but you get more detail.  It can slow down
running lynx a lot.

   Klaus

reply via email to

[Prev in Thread] Current Thread [Next in Thread]