Re: [gtk-list] Re: how can I trust glib when it has so manymemleaks?

[Joshua Richardson <jric bu edu>]

On Thu, 18 Mar 1999, Ionutz Borcoman wrote:

> Havoc Pennington wrote:
> > 
> > It keeps a pool of memory for different data types, such as linked list
> > nodes. If you free a linked list node it goes back into the pool. This
> > avoids calling malloc() and free() all the time; malloc() and free() are
> > relatively slow functions to use.
> > 
> > I'm sure the glib guys are taking patches. :-)
> 
> Give me one reason to believe you that that memory is not leaking. How
> are the guys from glib checking they don't have leaks ? I agree that I'm
> not an expert, so please teach me how to do the stuff in the right way ?
> 
> Otherwise, all of these are just nice words and nothing more :-(
> 

Note the functions g_mem_profile(), g_mem_check().  The funny thing is
that I have to admit to never having used these myself, because according
to the documentation, it appears that you have to make a special
configuration of the glib library.  I might propose having two libraries,
glib and glib_debug.  glib_debug could contain only the revised portions
of the code, presumably the g_new(), g_free() functions.  Then, when you
wanted to do memory profiling/checking, you could just link glib_debug
before glib, just the way libefence is used to override the C library
malloc/free functions.

>From reading Havoc's comments, I'm coming to the unsettling realization
that maybe glib is somehow able to hold onto memory after program
termination?  How can it, and is that really the case?  If so, I guess my
application compile-time solution would be tougher to implement.

Best,  --josh

----------------------------------------------------------------
                       Joshua Richardson
Dept. Cognitive and Neural Systems / Center for Adaptive Systems
                       Boston University
----------------------------------------------------------------

> TIA (at least for the nice words :-)
> 
> Ionutz
> 
> -- 
> To unsubscribe: mail -s unsubscribe gtk-list-request@redhat.com < /dev/null
> 
>