[MLton] Memory problems with latest CVS?
Stephen Weeks
MLton@mlton.org
Thu, 9 Sep 2004 12:37:28 -0700
> 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.