[MLton] Memory problems with latest CVS?

[Stephen Weeks]

> Then, I did:
>   mlton @MLton ram-slop 0.7 gc-summary  -- \
>         -default-ann 'sequenceUnit true' \
>         -target self -verbose 2 -output mlton-compile \
>         -debug true \
>         mlton-stubs.*.c mlton-stubs.*.S
> which links with the debug runtime.  I verified that the resulting
> compiler there would segfault in the manner I described last night.  I get
> no assertion failures from the runtime system.

BTW, you could also use -keep o and the .o files to speed up when you
want to just relink or change the runtime.

> (gdb) bt
> #0  0xb7565579 in __lll_mutex_lock_wait () from /lib/tls/libc.so.6
...
> #8  0x088c9821 in binary (lhs=0x2d5ba35c "\t    ",
>     rhs=0x14 <Address 0x14 out of bounds>, bytes=235703092,
>     binop=0x88cd03c <Posix_IO_write+28>) at basis/IntInf.c:193
...
> #31 0x088cd03c in Posix_IO_write (fd=16,
>     b=0x88dc030
> "U\211WVS\203<\213E\f\213}\020\213p\004\213_\004\2111\205\211U\017\210\003\002",
> i=-1375503360, s=153313034) at Posix/IO/write.c:6
> #32 0x088c98d9 in IntInf_mul (
>     lhs=0x88dc030
> "U\211WVS\203<\213E\f\213}\020\213p\004\213_\004\2111\205\211U\017\210\003\002",
> rhs=0xae037c00 "", bytes=153313034)
>     at basis/IntInf.c:215
...
> #36 0x088dc030 in __gmpz_ior ()

> 2) The last call mlton was responsible for was the call to IntInf_mul in
>    runtime/basis/IntInf.c, which was tail-call elimated by gcc to the call
>    to binary in runtime/basis/IntInf.c.  You'll note that the rhs doesn't
>    seem to be a valid pointer.

I guess __lll_mutex_lock_wait would explain the hang.

I don't understand why {lhs, rhs, bytes} aren't the same in the call
to binary from #8 and the call to IntInf_mul from #32, since
IntInf_mul just passes them along unchanged.

I agree with henry that bytes is huge (in both of them).

I don't understand why the gmpz_ior is there.

I'd say to recompile the runtime with DEBUG_INT_INF = TRUE in
IntInf.c, relink, and rerun.  You might also add some more printf's in
IntInf.c in binary and IntInf_mul.  You might also turn on DEBUG_ARRAY
in gc.c, since the IntInf implementation allocates the arrays before
passing them to the Gmp.  That might be too much noise though.