segfault with heap profiling.

[Simon Marlow]

> I've been getting a segfault whenever I try to run my program with
> +RTS -hc (having compiled with profiling enabled).  Any idea 
> what might
> cause this, or how I might track it down?  I am using ghc 
> 6.0.1, and see
> this problem on both linux (debian testing) and macos X.  On 
> macos X the
> crash log looks like it's crashing in heapCensusChain.
> 
> My program uses ForeignPtrs quite a bit, so my only (rather 
> weak) theory is
> that perhaps the profiler is trying to look at the contents of my
> ForeignPtrs?

Unlikely.  Any chance you could package up a test case that we can
repeat here?

> In a sort of related question, is there any way I can make 
> the heap size
> decrease? In my test case, the memory usage peaks pretty 
> early, and then it
> keeps running for another few hours.  It would be nice if it 
> could shrink
> the heap again to release swap.

GHC doesn't currently release any memory back to the OS.  It would be
possible to do the easy thing, which is to just release a megablock (1Mb
chunk) when it becomes unused, but you'd probably want some logic to
prevent thrashing (repeatedly freeing and re-acquiring the same chunk).


A better idea would be to use madvise() to reclaim the swap associated
with dead memory, without actually freeing it back to the OS.

> And actually, even though according to
> +RTS -Sstderr my live memory usage drops, the heap size (as 
> seen by top)
> keeps going up (a megabyte every second or so) until the process gets
> killed because it's eaten up all the swap and memory.  :(  I 
> suspect the
> problem may be in the allocation I'm doing via ForeignPtrs, 
> but I'm not
> sure how to track anything down without profiling working.

Almost certainly this is caused by malloc() allocation.  As far as I'm
aware, GHC keeps good track of memory that it has allocated itself.

Cheers,
	Simon