Re: Memory leaks / Help with memprof & ps output

[Enrico Weigelt <weigelt metux de>]

On Tue, Apr 09, 2002 at 01:06:13AM -0400, Valdis Kletnieks vt edu wrote:

<snip>
> Having to walk the *entire* heap can be rather painful if you
> have a large heap - I've seen programs where 400M of heap is *average*,
> and that "any bit patterns" can be a hassle too. ;)
thats right.
but: are normal gtk/glib applications using so much memory ?
i didnt see anyone yet.

so its not the normal case. such applications should use another 
memory allocator. (i dont think the libc allocator is capable of 
working with such heap sizes efficently when its crashing on an double
free() on the other side)

> Also, look athttp://www.hpl.hp.com/personal/Hans_Boehm/gc/gcinterface.html
> and ponder:
> 
> 1) The existence of GC_malloc_atomic()
> 
> 2) The comments on GC_free() 
> 
> Yes, it's very nice, but I don't think it's a 100% portable drop-in, nor is it
> the be-all and end-all of memory allocators. 
is there anything which solves evry problem in the world ?
i want to make the common things simple and clean. there will always be
cases where you cannot work with this. but in most of these cases people 
wont use glib btw.

> It's interesting to note that many of the 'users' listed are using it as a 
> leak detector only, or are Java/Scheme/ whatever runtime systems where they 
> can be careful about using malloc_atomic and similar issues while keeping 
> the user program in a sandbox.
yes, it seems to be an psychologic question. many people dont trust in GCs.
they're looking for every possible disatwantage before really trying it out.
(i did exactly this some years ago, before i was forced me to work with oberon. 
at the end i really liked it, even the language itself cant stand against java)

<snip>
> Unfortunately, this is C, not Java - it's *very* hard to call a glib
> routine that returns a pointer to some just-allocated memory object,
> and then resist the temptation to store that pointer in a variable,
> pass it to another function, assign the variable to another variable,
> and so on, and unlike a JVM, a C assignment is usually done
> without having to invoke the runtime environment.
i dont see the problem ?

the GC walks through all memory which potentially contains references
and marks referenced atoms as 'used'. if there's no reference to 
an atom, it is simply unreachable and so can be thrown away.

<snip>
> The problem here is that '*c = b;' just created another reference that
> your reference counting heap allocator doesn't know about.  

aehm... i thought we're talking about an conservative collector ...
refcounting doesn work here. right. this would require special support
from user (coder) side.

> The HB collector *will* manage to find that reference - at the expense 
> of walking through the entire stack/heap, and probably erroneously
> flagging a number of blocks as 'referenced'.
this perhaps may occour, but minimal.
perhaps there's a way to use some debugging symbols for getting typeinfo.

> And of course, there's always circularly linked lists. ;)
these are problematic for refcounting, not for an conservative GC.

~-n
--
 Enrico Weigelt    ==   meTUX IT services 
 software development, IT service, internet security solutions
 www:     http://www.metux.de/        phone:     +49 36207 519931
 email:   contact metux de            cellphone: +49 174 7066481