[mercury-users] Debugging 'memory leaks' (fwd)

[Peter Wang]

On 2008-03-31, Ondrej Bojar <bojar at ufal.ms.mff.cuni.cz> wrote:
> Peter Wang wrote:
>>> but the heapsize never sinks, as show in the truncated log below.
>>
>> That's the normal behaviour without munmap, so unless the heap seems to
>> keep growing without bound, I wouldn't worry about it.
>
> I've investigated the issue with rotd-2008-03-27 and --boehm-gc-munmap, and 
> nothing is unmapped even in this case.

Just to confirm, you did run ./configure --enable-gc-munmap?

> I have two guesses what needs a fix:
>
> 1. ./boehm_gc/os_dep.c: GC_unix_get_mem
>    When allocating memory, GC_unix_get_mem first try to do it using sbrk. I 
> have never allocated memory this way so I'm just guessing that one cannot 
> simply make holes in a process data segment by dealocating bits of it. My 
> guess is that GC_unix_mmap_get_mem should be preferred with 
> --boehm-gc-munmap

Yes. If USE_MMAP is defined (done by ./configure --enable-gc-munmap)
then GC_unix_get_mem calls GC_unix_mmap_get_mem.

> 2. ./boehm_gc/allchblk.c: GC_freehblk
>     There is a FIXME remark at the end of the function that indicates a 
> problem with timestamps => no block would become old enough to munmap.
>
> Before I delve deeper to figure out which of 1. and/or 2. indeed hold in my 
> case and try to tweak them without knowing much about the GC, I'd like to 
> hear your opinion. Can you rule out something right away?

Don't know about this one.

Peter

--------------------------------------------------------------------------
mercury-users mailing list
Post messages to:       mercury-users at csse.unimelb.edu.au
Administrative Queries: owner-mercury-users at csse.unimelb.edu.au
Subscriptions:          mercury-users-request at csse.unimelb.edu.au
--------------------------------------------------------------------------