[MLton] compiled binary freezes on solaris during LargeReal.fromLargeInt()

[Matthew Fluet]

On Mon, 15 Sep 2008, Nicolas Bertolotti wrote:
> MLton 20070826 was compiled using gmp 4.2.1 whereas the new sources were 
> compiled using gmp 4.2.2.

I would think that gmp 4.2.1 and 4.2.2 would be binary compatible.

> I'm quite surprised anyway ... the bug really occurs at compilation 
> time.

MLton does use IntInf to represent integer and word constants and for 
constant folding, etc., so GMP will be used by the compiler at compile 
time.

> After I build the binary with a runtime compiled using gmp 4.2.1, 
> I can run the binary successfully with the gmp 4.2.2 shared library in 
> LD_LIBRARY_PATH.

Weird.

>> -----Original Message-----
>> From: Matthew Fluet [mailto:fluet at tti-c.org]
>> Sent: Monday, September 15, 2008 9:33 PM
>> To: Nicolas Bertolotti
>> Cc: mlton at mlton.org
>> Subject: Re: [MLton] compiled binary freezes on solaris during
>> LargeReal.fromLargeInt()
>>
>> On Mon, 15 Sep 2008, Nicolas Bertolotti wrote:
>>> When you compile and run the following program on Solaris, using a
>> compiler based on the latest SVN sources (r6853):
>>
>> I assume this is on a Sparc (as opposted to an x86 or amd64).
>>
>>> val _ = print("OK1\n");
>>> val x = Time.toNanoseconds(Time.now());
>>> val _ = print("OK2\n");
>>> val y = LargeReal.fromLargeInt(x);
>>> val _ = print("OK3\n");
>>>
>>> It freezes (using all CPU resources) after printing the string < OK2 >.
>>>
>>> The same piece of code runs fine when it is built using the latest
>> official release.
>>>
>>> Any idea?
>>
>> The codepath for LargeReal.fromLargeInt is mostly in the GnuMP and gdtoa
>> libraries (see 'val fromIntInf' in <src>/basis-library/real/real.sml).
>>
>> I would suggest compiling the program with "-debug true" and running the
>> executable under gdb; a Ctrl-C when the program spins should reveal
>> whether it is in GnuMP (if you see "IntInf_toString" in the backtrace) or
>> in gdtoa (if you see "Real64_strto" in the backtrace).
>>
>> I would also suggest building MLton 20070826 from source on this machine
>> and compiling the program.  That would reveal whether there is something
>> specific about this machine (version of gcc, etc.) that triggers the
>> behavior or there is some change to the compiler from 20070826 to HEAD
>> that triggers the behavior.
>
> _______________________________________________
> MLton mailing list
> MLton at mlton.org
> http://mlton.org/mailman/listinfo/mlton
>
>