Re: [MLton] Bug report (Ur/Web, ARM)

On Wed, Oct 21, 2015 at 2:24 AM, Jason Pepas <[email protected]> wrote:
> I'm trying to build Ur/Web on a small ARM processor, and I'm running into an
> error which asked me to send a bug report to this email address.
>
> Here's the output:
>
> mlton  -mlb-path-var 'SRC /tmp/tmp.NB4Wn4SfA7/urweb-20151018/src'
> -mlb-path-var 'BUILD /tmp/tmp.NB4Wn4SfA7/urweb-20151018/src' -output
> bin/urweb src/compiler.mlb
> unhandled exception: SysErr
> MLton bug: unhandled exception in Basis Library
> Please send a bug report to [email protected].
> Makefile:836: recipe for target 'bin/urweb' failed
>
> Ur/Web is known to require several hundred megabytes of RAM during this
> mlton step.
>
> The ARM machine I'm using (a pogoplug) only has 128MB of RAM, but has 1GB of
> swap, so I don't think that's the problem.
>
> Perhaps mlton doesn't support ARM?

It seems that the mlton compiler proper (which is itself a mlton
compiled program) is raising an uncaught exception during the
evaluation of the Basis Library.  Just a reminder: as a whole program
compiler, each mlton compiled executable essentially evaluates the
entirety of the SML Basis Library followed by the evaluation of the
user program.  For the most part, the SML Basis Library evaluates
purely -- it simply defines many structures, signatures, functions,
values, types, etc.  However, there are a few points where evaluation
of the SML Basis Library has side effects: setting up
stdin/stdout/stderr, etc.  The SysErr exception generally corresponds
to a C function that would normally set errno on an error condition.
My guess is that your ARM system is unable to support a C library
function that we think is generally safe to call in the Basis Library
(safe in the sense that although it could technically fail, it seems
unlikely to fail).  We've encountered this a few times in the past;
generally, one needs to track down the failing C function call and the
corresponding place where it is used in the Basis Library
implementation and insert an explicit "handle SysErr _ => ..." that
yields a reasonable default.

To confirm, try simply running "mlton" (no options, no file to
compile) on your device.  Normally, this would echo back a version
string, but I expect it to again report the unhandled exception in the
Basis Library.

If you are able to run strace on your device, then "strace mlton"
might reveal the failing system call.

Unfortunately, we would need to fix the unhandled exception in the
Basis Library implementation and then you would need an updated build
of MLton for ARM.

------------------------------------------------------------------------------