<div dir="ltr">Thanks everyone. I have indeed been trying to get somewhere with sanity checking. That used to help quite a bit for the deadstripping stuff that happened on iOS a long time ago, but that was also much more deterministic.<div>Maybe I'll try to see if running it through qemu will give me some more determinism. That at least gives somewhat predictable allocations. It could still end up being some annoying memory ordering issues, the llvm backend</div><div>just managed to happen to not run into by luck, or optimisation passes. </div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Aug 31, 2020 at 10:29 PM Csaba Hruska <<a href="mailto:csaba.hruska@gmail.com">csaba.hruska@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>Fuzzing:<br><ol><li>generate simple random stg programs</li><li>compile and run with RTS sanity checking enabled<br></li><li>compare the program result between different backends</li></ol></div>The fuzzer should cover all codegen cases and all code in RTS. Maybe this could be checked by the existing tools. <br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Aug 31, 2020 at 4:19 PM George Colpitts <<a href="mailto:george.colpitts@gmail.com" target="_blank">george.colpitts@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="ltr"><div class="gmail_default" style="font-family:"times new roman",serif;font-size:large">+Moritz<br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Aug 31, 2020 at 11:17 AM George Colpitts <<a href="mailto:george.colpitts@gmail.com" target="_blank">george.colpitts@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div style="font-family:"times new roman",serif;font-size:large">I assume you're familiar with the following from <a href="https://www.aosabook.org/en/ghc.html" target="_blank">https://www.aosabook.org/en/ghc.html</a> and that this facility is still there. Just in case you are not: </div><div style="font-family:"times new roman",serif;font-size:large"><br></div><blockquote style="margin:0px 0px 0px 40px;border:medium none;padding:0px"><div style="font-family:"times new roman",serif;font-size:large"><span style="color:rgb(51,51,51);font-family:"Helvetica Neue",Helvetica,Arial,sans-serif;font-size:13px">So, the debug RTS has an optional mode that we call </span><em style="color:rgb(51,51,51);font-family:"Helvetica Neue",Helvetica,Arial,sans-serif;font-size:13px">sanity checking</em><span style="color:rgb(51,51,51);font-family:"Helvetica Neue",Helvetica,Arial,sans-serif;font-size:13px">. 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 </span><em style="color:rgb(51,51,51);font-family:"Helvetica Neue",Helvetica,Arial,sans-serif;font-size:13px">and</em><span style="color:rgb(51,51,51);font-family:"Helvetica Neue",Helvetica,Arial,sans-serif;font-size:13px"> 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.</span></div></blockquote></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Aug 31, 2020 at 11:08 AM Csaba Hruska <<a href="mailto:csaba.hruska@gmail.com" target="_blank">csaba.hruska@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">Dump the whole heap into file during GC traversal or taking the whole allocated area. hmm, maybe this is the same as core dump. <br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Aug 31, 2020 at 11:00 AM Ben Lippmeier <<a href="mailto:benl@ouroborus.net" target="_blank">benl@ouroborus.net</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><br>
<br>
> On 31 Aug 2020, at 5:54 pm, Moritz Angermann <<a href="mailto:moritz.angermann@gmail.com" target="_blank">moritz.angermann@gmail.com</a>> wrote:<br>
> <br>
> If anyone has some create ideas, I'd love to hear them. I've been wondering<br>
> if just logging allocations (offset, range, type) would help figuring out what we<br>
> expected to be there; and then maybe try to break on the allocation, (and<br>
> subsequent writes).<br>
> <br>
> I'm sure some have been down this road before. <br>
<br>
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.<br>
<br>
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.<br>
<br>
A user space approach is to use a library like vacuum or packman that also walks over the heap objects directly.<br>
<br>
<a href="http://hackage.haskell.org/package/vacuum-2.2.0.0/docs/GHC-Vacuum.html" rel="noreferrer" target="_blank">http://hackage.haskell.org/package/vacuum-2.2.0.0/docs/GHC-Vacuum.html</a><br>
<a href="https://hackage.haskell.org/package/packman" rel="noreferrer" target="_blank">https://hackage.haskell.org/package/packman</a><br>
<br>
Ben.<br>
<br>
<br>
<br>
_______________________________________________<br>
ghc-devs mailing list<br>
<a href="mailto:ghc-devs@haskell.org" target="_blank">ghc-devs@haskell.org</a><br>
<a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs" rel="noreferrer" target="_blank">http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs</a><br>
</blockquote></div>
_______________________________________________<br>
ghc-devs mailing list<br>
<a href="mailto:ghc-devs@haskell.org" target="_blank">ghc-devs@haskell.org</a><br>
<a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs" rel="noreferrer" target="_blank">http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs</a><br>
</blockquote></div>
</blockquote></div></div>
</blockquote></div>
</blockquote></div>