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

[Nicolas Bertolotti]

Humm, I had forgotten that the other difference between my 2 compilers was the GMP version.

MLton 20070826 was compiled using gmp 4.2.1 whereas the new sources were compiled using gmp 4.2.2.

I switched back to version 4.2.1 and the example now works fine.

Thanks for your help ... it was not MLton's fault

I'm quite surprised anyway ... the bug really occurs at compilation 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.

> -----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.