segfault bug

[Stephen Weeks]

> I don't expect it to fit, I expect it to run out of space.

Ahh.

> I'm makeing the latest MLton on the machine with 1 gig of RAM and I will try it
> out, but given the delicacy of the bug, even if it goes away can we be confident
> that it has been fixed? 

If it succeeds with -limit-check-per-block true and fails with
-limit-check-per-block false, then I am willing to assume it is the
limit check bug.  It's not a guarantee, but it is pretty good
evidence, especially given the other data you just mentioned.

> Any notion of what the bug actually is? 

The bug is that limit check insertion can fail to put a limit check in
where one is needed at a loop header.  Hence, if the loop follows
around a certain path, the heap frontier can overrun the limit.

If you really wanted to find out, you could use "-native false" and
put some more frontier asserts inside the Object, ArrayNoPointers, and
ArrayPointers macros in ccodegen.h.  These might show where the
frontier overruns the limit.

> Again, note that the failure is on entry to the GC.

That is consistent with a heap overrun prior to the entry.  Although
that should get caught with the "frontier < limit" check in the
GC invariant.