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.hru...@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 <b...@ouroborus.net> wrote: > >> >> >> > On 31 Aug 2020, at 5:54 pm, Moritz Angermann < >> moritz.angerm...@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@haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs >> > _______________________________________________ > ghc-devs mailing list > ghc-devs@haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs >
_______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
