Creative ideas on how to debug heap corruption

[George Colpitts]

+Moritz

On Mon, Aug 31, 2020 at 11:17 AM George Colpitts <george.colpitts at gmail.com>
wrote:

> I assume you're familiar with the following from
> https://www.aosabook.org/en/ghc.html 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 gmail.com>
> wrote:
>
>> 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 ouroborus.net>
>> wrote:
>>
>>>
>>>
>>> > On 31 Aug 2020, at 5:54 pm, Moritz Angermann <
>>> moritz.angermann at gmail.com> 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.
>>>
>>> http://hackage.haskell.org/package/vacuum-2.2.0.0/docs/GHC-Vacuum.html
>>> https://hackage.haskell.org/package/packman
>>>
>>> Ben.
>>>
>>>
>>>
>>> _______________________________________________
>>> ghc-devs mailing list
>>> ghc-devs at haskell.org
>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>>>
>> _______________________________________________
>> ghc-devs mailing list
>> ghc-devs at haskell.org
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20200831/0eadd5c9/attachment.html>