[MLton] bug in MLton.share?

[Stephen Weeks]

> I have a program which uses MLton.share and which on a certain input
> segfaults.
...
> It didn't die in share, but quite a bit later, using the object on
> which share had been run.

The code for MLton.share uses two things: the mark code from the
mark-compact GC to walk the object and a hash table to do hash consing
of the subobjects in the object's graph.  If the failure is after the
share, that means that either the hash consing shared a subobject that
it shouldn't have or that there is a bug in the mark phase.

Perhaps you can run a GC immediately after calling MLton.share by
counting the number of shares in the run and tweaking your code to
count the number of calls to share, and then calling GC just after the
bad share.  Doing this with asserts on as Matthew suggested could show
something.

Another thing to do would be to run a mark-compact GC in place of the
offending call to share (again by counting).  That would test the mark
code without the hash-consing code.  And with asserts on, would check
the heap after the mark compact runs.