[MLton] share bug

[Stephen Weeks]

> That means that GC_share didn't break any invariants that we check.
> The invariant check after GC that failed.  So, either GC_share is
> breaking an invariant that we don't check, which is then causing the
> minor GC to misbehave, or GC_share is creating a legal, but unusual
> situation that we haven't yet seen in the minor GC, and the minor GC
> is broken.  My bet is on the former.

Indeed.  I see the problem.  The invariant doesn't check that the card
map is correct.  It is possible that GC_share creates a pointer from
the old generation into the nursery.  If this happens on an unmarked
card, the next minor GC will fail to update the pointer.  That would
create exactly the situation you saw a pointer from a low address (old
generation) into a high one (nursery) that was no longer in the
nursery after the minor GC.

I am working on a fix so that GC_share updates the card map.  No need
to rerun your test.