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

[Sean Christopher Rhea <srhea ece utexas edu>]

The best thing to do (IMHO) is to add a flag (a compile one, for speed
purposes) that gets glib to use malloc/free instead.  This will slow it
down, but will allow you to use ANY type of memory checker to check your
code (usually by changing which malloc/free the code is linked against).
Btw, the leg work on this one shouldn't take too long.

Sean C. Rhea

                  --- Please respond to srhea@acm.org ---

On Wed, 17 Mar 1999, Joe Pfeiffer wrote:

> 
>    On Thu, 18 Mar 1999, Ionutz Borcoman wrote:
>    > 
>    > This is INSANE ! It's like giving a kid a posisoned candy :-(
>    > How can I differentiate what ccmalloc sais for glib comparred with what
>    > it says for my program ?
> 
>    Well, the glib memory caching speeds dynamic data structures up by a large
>    factor. If that interferes with ccmalloc, well, such is life. 
> 
> Ionutz has a really good point here -- finding memory leaks is hard
> enough without having libraries that hide them.  Hmmm...  I haven't
> looked at glib's implementation, but if it has a memory
> allocation/deallocation package built into it (which I'd sort of
> expect), it ought to be reasonably straightforward to do something
> like either compile this with its current implementation or as a
> wrapper around malloc/free...
> -- 
> Joseph J. Pfeiffer, Jr., Ph.D.       Phone -- (505) 646-1605
> Department of Computer Science       FAX   -- (505) 646-1002
> New Mexico State University          http://www.cs.nmsu.edu/~pfeiffer
> 
> -- 
> To unsubscribe: mail -s unsubscribe gtk-list-request@redhat.com < /dev/null
> 
>