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

[Matthew Fluet]

On Sun, 9 Nov 2008, Wesley W. Terpstra wrote:
>> Of course, there are probably a number of places in the runtime where sizes
>> could overflow.  I would be particularly worried about things like array
>> allocation and stack growth, which could generate a large request.
>
> You're worried about a single array which almost exceeds 4GB and is
> then aligned to 4GB? Since it's completely impossible to satisfy these
> requests, couldn't we just bail out immediately with an out-of-memory
> error?

No, I'm worried about a 3.5G heap (which had 3.05G live data at the last 
major garbage collection, but now has only 2.0G live data) and a 1G array 
allocation.  This allocation should succeed (there is enough memory after 
the garbage collection); however, at 
<>/runtime/gc/garbage-collection.c:26, the computation:
   s->lastMajorStatistics.bytesLive + bytesRequested
will overflow, quite possibly allowing a secondary heap of 0.05G to be 
allocated, then leading to a bogus copying collection (due to the 
assertion failure at <>/runtime/gc/cheney-copy.c:53)