[MLton] Segmentation fault in 32 bit mode on a 6 GB machine with ram-slop 0.85

[Wesley W. Terpstra]

On Mon, Nov 3, 2008 at 11:22 PM, Nicolas Bertolotti
<Nicolas.Bertolotti at mathworks.fr> wrote:
> I recently experienced crashes running 32 bit binaries on a 6 GB machine
> with ram-slop 0.85. The output with "gc-messages" is the following:

What platform is this?

> As s->sysvals.ram is set to 4 294 967 295 in that case, sizeofHeapDesired()
> may return that value and lead to an attempt to create a heap of size 0
> because align(desiredSize, s->sysvals.pageSize) will then return 0.
>
> As a matter of fact, after looking at the code, it seems that a number of
> other situations may lead to similar issues (for instance, when
> sizeofHeapDesired() returns a value that would lead to an overflow when we
> add the size of the card/cross map).

Yes, the choice of desired heap doesn't respect the actual address
layout restrictions that exist for a process. I personally think we
need to include some platform-specific information about how big the
addressable space is, and cap the physical memory to this limit.

Linux has a 3G cap, MinGW a 2G cap, and cygwin a 1.2G cap. Perhaps
there is some system call which can inform this choice in a portable
way?

I pointed out a related problem on Oct 14
<http://mlton.org/pipermail/mlton/2008-October/030413.html>:
> Another thing I've noticed is that MLton's estimate of the available
> RAM can trick it into making bad choices for the heap size. You can
> only possibly get 1.2G on cygwin, but MLton thinks it should be able
> to get an amount = physical ram. It sets the minSize and desiredSize
> both too high and is the remap then fails. However, if it had a less
> aggressive minSize, it could have allocated another 300MB. I'm not
> sure what to do about this. Perhaps cap the physical RAM based on the
> platform?

I had hoped to generate some discussion, but it seems no one was listening. :-)