Creative ideas on how to debug heap corruption

George Colpitts george.colpitts at
Mon Aug 31 14:17:22 UTC 2020

I assume you're familiar with the following from and that this facility is still there.
Just in case you are not:

So, the debug RTS has an optional mode that we call *sanity checking*.
Sanity checking enables all kinds of expensive assertions, and can make the
program run many times more slowly. In particular, sanity checking runs a
full scan of the heap to check for dangling pointers (amongst other
things), before *and* after every GC. The first job when investigating a
runtime crash is to run the program with sanity checking turned on;
sometimes this will catch the invariant violation well before the program
actually crashes.

On Mon, Aug 31, 2020 at 11:08 AM Csaba Hruska <csaba.hruska at>

> Dump the whole heap into file during GC traversal or taking the whole
> allocated area. hmm, maybe this is the same as core dump.
> On Mon, Aug 31, 2020 at 11:00 AM Ben Lippmeier <benl at> wrote:
>> > On 31 Aug 2020, at 5:54 pm, Moritz Angermann <
>> moritz.angermann at> wrote:
>> >
>> > If anyone has some create ideas, I'd love to hear them.  I've been
>> wondering
>> > if just logging allocations (offset, range, type) would help figuring
>> out what we
>> > expected to be there; and then maybe try to break on the allocation,
>> (and
>> > subsequent writes).
>> >
>> > I'm sure some have been down this road before.
>> Force a GC before every allocation, and make the GC check the validity of
>> the objects before it moves anything. I think this used to be possible by
>> compiling the runtime system in debug mode.
>> The usual pain of heap corruption is that once the heap is corrupted it
>> may be several GC cycles before you get the actual crash, and in the
>> meantime the objects have all been moved around. The GC walks over all the
>> objects by nature, so get it to validate the heap every time it does, then
>> force it to run as often as you possibly can.
>> A user space approach is to use a library like vacuum or packman that
>> also walks over the heap objects directly.
>> Ben.
>> _______________________________________________
>> ghc-devs mailing list
>> ghc-devs at
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the ghc-devs mailing list