[MLton] latest MLton segfault in gmp

[Matthew Fluet]

On Fri, 9 Oct 2009, Wesley W. Terpstra wrote:
> On Fri, Oct 9, 2009 at 4:21 AM, Matthew Fluet <mtf at cs.rit.edu> wrote:
>
>> On Thu, 8 Oct 2009, Henry Cejtin wrote:
>>
>>> The  make  couldn't finish because the resulting mlton-compile segfaults
>>> compiling mllex.mlb.  In fact, that mlton-compile always segfaults, even
>>> compiling  a  hello-world.sml.   The gdb traceback shows that it died in
>>> __gmpz_mul_2exp().
>>>
>>> The version of gmp that I have is 2:4.3.1+dfsg-3.
>>>
>>
> I have reproduced this problem. Then I copied my svn/HEAD compiler from
> sarge to squeeze and it segfaulted as well. Something in squeeze has
> changed. The MinGW32 port self-compiles using 4.3.1 and debian hasn't
> patched gmp in any relevant way.

My x86-darwin (sing MacPorts gmp) also has 4.3.1, without problems.

> Can you run through the regression suite with mlton-20070826?
>>
>
> Here are the highlights:
>
> testing flexrecord.2:
> Type error: actual and formal not of same type
> actual: ('a_4068 * nat) * (nat * nat)
> formal: (nat * nat) * (nat * nat)
> expression: ZZZ_f x_0
> unhandled exception: TypeError
> compilation of flexrecord.2 failed with -type-check true

Test introduced by r6216 (20071127) and subsequently fixed.

> testing weak.2
> DeepFlatten.replaceVar global_0
> compilation of weak.2 failed with -type-check true

Test introduced by r6189 (20071120) and subsequently fixed.

So, no additional gmp bugs.  But, gmp reallocation bugs aren't always so 
obvious, because we always give it to the end of the heap (even if we 
limit checked for a smaller amount), so there is no error unless we really 
are running into the end of the heap.  Could you try the regressions again 
with '-debug true'?  That should throw an assertion if there really isn't 
enough room in the heap.  You could also try to compile HEAD with 20070826 
and '-debug true', which might be more revealing, since the resulting 
mlton-compile always segfaults.

Of course, I'm surprised that you and Henry see the same behavior.  If it 
is a bad limit check (due to a miscalculation of needed bytes for an 
IntInf result), then it is usually so dependent upon the exact sequence of 
GCs, which in turn is very sensitive to available memory and the exact 
contents of the heap (which includes things like the string representation 
of the path to the current executable, likely to be of different sizes on 
different machines), that it is nearly impossible to recreate on another 
machine.