+Moritz On Mon, Aug 31, 2020 at 11:17 AM George Colpitts <george.colpi...@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.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
