[MLton] Memory problems with latest CVS?

[Stephen Weeks]

> Right, disabling refFlatten shouldn't affect the sequence I posted, since
> the compiler exhibiting the problem was built with mlton-20040819 and the
> seg fault occurs long before the refFlatten pass.
> 
> On the other hand, building with a mlton-XXX that doesn't perform
> refFlatten will result in a compiler that exhibits a very different heap
> structure, which may mask the problem.

What I did last night was to rebuild 20040819 with itself and its
runtime having totalRam hardwired to 4,160,765,952, the value you used
to generate the segfault.  I then tried bootstrapping CVS HEAD.
Unfortunately this isn't exactly the same situation you were in (code
being compiled is slightly different, path is different, etc.) and the
compile went fine.

Given how sensitive this bug is, I'm not sure it's worth spending more
effort trying to recreate your environment on my machine.  Perhaps we
could proceed with debugging on your machine.  In mail last week, you
mentioned that you could reliably get the segfault during a gc, while
in the mail from last night, the segfault was after a gc.  It might be
easier if you can get back to the situation where the segfault is
during the GC, since we may be able to more easily understand the code

In any case, have you tried bootstrapping with -debug true, so the
second round of compilation (the one that is failing) is using a
runtime with asserts on?

Also, assuming you can get to where the segfault is in the gc, could
you run the second round compile under gdb so we can find out the line
in gc.c that is faulting?