[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: lynx-dev more on leaks
From: |
dickey |
Subject: |
Re: lynx-dev more on leaks |
Date: |
Sun, 15 Nov 1998 15:27:17 -0500 (EST) |
>
> 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
- Re: lynx-dev more on leaks,
dickey <=