[MLton] Crash with 4GB ram
Stephen Weeks
MLton@mlton.org
Wed, 17 Dec 2003 10:25:43 -0800
> We have a crash of an mlton-20030716 generated executable when run on a
> Sun with 4Gb RAM.
Thanks for the bug report Alain.
> One of our engineers suspects it is due to an overflow in the following
> code.
...
> If totalRAM is equal to 4Gb, the above multiplication result will indeed
> wrap around to zero.
> I suspect the same problem can occur with totalSwap, and in various
> places in the code where totalRam+totalSwap is computed without
> promotion to 64bits.
I agree completely. On December 10, I checked in a fix for this bug
that changed the implementation of totalRam on Cygwin, Linux, and
Solaris:
static W32 totalRam (GC_state s) {
W32 maxMem;
W64 tmp;
maxMem = 0x100000000llu - s->pageSize;
tmp = sysconf (_SC_PHYS_PAGES) * (W64)s->pageSize;
return (tmp >= maxMem) ? maxMem: (W32)tmp;
}
This keeps totalRam as 32 bits, but avoids the overflow I believe. In
the same checkin I also eliminated totalSwap, and all of the sums of
totalRam and totalSwap. Let me know if you are aware of other
potential overflows.
> Would it be worthwhile to change the type of totalRam and totalSwap to
> unsigned long long, as well as to promote various computations in gc.c
> to 64 bits ?
Yes. My plan is to do this whenever we first port to a platform to
support 64 bit pointers.