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

[Matthew Fluet]

On Mon, 3 Nov 2008, Nicolas Bertolotti 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:
> [GC: Found 6,245,584,896 bytes of RAM; using 4,294,967,295 bytes (68.8% of RAM).]

You can see that the runtime initialization does not attempt to use more 
RAM than the virtual address space, even if this means using a smaller 
ram-slop than specified.

However, as the note in <>/runtime/gc/init.c states, we should ensure that 
s->sysval.ram is aligned by the page size; this wasn't being done when 
SIZE_MAX was used as the maximum ram.  Though, that comment is really 
describing the test at <>/runtime/gc/garbage-collection.c:29, which 
chooses to use the mark-compact garbage collector if the current heap is 
larger than RAM.

> ...
> [GC: Starting gc #739; requesting 512 nursery bytes and 0 old-gen bytes,]
> [GC:    heap at 0x0e194000 of size 3,854,442,496 bytes,]
> [GC:    with nursery of size 215,045,648 bytes (5.6% of heap),]
> [GC:    and old-gen of size 3,639,396,848 bytes (94.4% of heap),]
> [GC:    and nursery using 215,045,140 bytes (5.6% of heap, 100.0% of nursery).]
> [GC: Creating heap of size 0 bytes (+ 0 bytes card/cross map) cannot be satisfied,]
> [GC:    backing off by 27,533,312 bytes with minimum size of 3,854,442,496 bytes.]
> [GC: Created heap at 0xf77ea000 of size 4,267,433,984 bytes (+ 33,341,440 bytes card/cross map).]
> [GC: Starting major Cheney-copy;]
> [GC:    from heap at 0x0e194000 of size 3,854,442,496 bytes,]
> [GC:    to heap at 0xf77ea000 of size 4,267,433,984 bytes.]
> [GC: Shrinking stack of size 2,088,960 bytes to size 98,560 bytes, using 3,080 bytes.]
> Received signal 11
>
> 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.

That seems to be the case.

> I am looking for the best way to fix this issue and your help would be 
> greatly appreciated.
>
> 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).
>
> Any hint ?

I think that the best solution is for sizeofHeapDesired to return a size 
that will not overflow when aligned and will not overflow when combined 
with the card/cross map size.  This can be handled using the architecture 
virtual address space limit -- irrespective of any OS specific limits. 
Indeed, I think the whole question of sizing policies that take into 
account RAM, OS specific factors (like contiguous address space), etc. 
should be entirely separate from avoiding overflow of size computations.

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.

-Matthew