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