Re: lynx-dev more on leaks

[dickey]

> 
> 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? 

the difference is this: it can be unfreed memory if the application
allocates a buffer that it doesn't want to free (such as the one I
used for setbuf).  There's a number of those - I call them permanent
leaks - for runtime efficiency.  You _could_ free all memory explictly
on exit, but that's not a good idea in some cases.  I put together
a binary tree (actually AVL) last year for vile, and allocating is
fast - but deallocating is slow.  When I run the no-leaks testing through
that, deallocating a 1000-node tree takes several seconds.
  
If you lose the pointer - that's a leak that should be fixed, of course.

> 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. 

and auditing the memory (freeing the known permanent leaks) can be slow.
The gettext code uses some sort of hash table; it may/may not (probably
doesn't) have code to instrument it in this way.

>    Klaus 


-- 
Thomas E. Dickey
address@hidden
http://www.clark.net/pub/dickey