[MLton] share bug

[Stephen Weeks]

> From my looking at it, it seems that the first GC after the first
> call to share got the segfault.

Excellent that it happens at the first call.  That should ease debugging.

> Looking at lines of the form
>     ?output? = hashCons(?input?)
> there are 11,682,512 calls and the same number  of  ?input?  values,  ranging
> from  0x600b3398  to  0x9e0b2b00.   There  are  10,022,696  ?output?  values,
> covering the same range.  Every ?output? value was also a ?input?
> value. 

Good.  The hash consing is only supposed to return existing objects.

> The value in the assert
>     p = 0x665aeab4
> was not one of the ?input?s, but the second one
>     *p = 0x9ac95540
> was both a ?input? and a ?output? value.
> 
> Any way, any notions of what is going on?

The invariant check at the beginning of the minor GC succeeded.  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.

I'll also note that the minor GC must have been initiated by
GC_arrayAllocate, since that is the only place that calls doGC with a
nonzero request for oldGenBytesRequested.

Can you tweak the runtime to call GC_display at the beginning and end
of the GC_share and the doGC?  That will give a bit more information
about the heap layout.