[MLton] Crash fread(...) failed (only read 0) (Cannot allocate memory) during deepFlatten with MLton 20070826

[Matthew Fluet]

On Sun, 20 Apr 2008, Matthew Fluet wrote:
> On Fri, 18 Apr 2008, Nicolas Bertolotti wrote:
>>  eof
>>  fread (0x574e5000, 1, 2000101560, _) failed (only read 0).
>>   (Cannot allocate memory)
>>
>>  Looking at the code, I could not figure how this could happen.
>
> It occurs when the runtime system decides to page the heap to disk in order 
> to free up virtual memory to reallocate the heap at a larger size.
> It will do this if the desired heap size is approaching the physical memory 
> limit, even if there is plenty of swap space available on the machine.
>
> There is a bug in <src>/runtime/platform/diskBack.unix.c, introduced on the 
> x86_64-branch by SVN revision 4642 on 20060711.  That revision switched to 
> ANSI C stdio functions, but dropped the lseek in diskBack_read.  This means 
> that, when reading back the heap, it begins to read from the temporary file 
> with the file position at the end of the written heap; that explains why 
> fread failed with EOF.

I believe that the bug is now fixed by SVN r6596:
   http://mlton.org/cgi-bin/viewsvn.cgi?rev=6596&view=rev
You should be able to apply the diffs of that revision to the 20070826 
sources, rebuild the compiler, and eliminate the compile abort.

If, on the other hand, you rebuild the compiler from SVN trunk HEAD, then 
you should add "@MLton may-page-heap true" to the flags passed to mlton. 
Because of the security and 'least-surprise' concerns of dumping 2+ 
gigabytes of heap to the disk during the execution of a program, the 
runtime defaults to not paging the heap to disk, and instead will report 
out-of-memory and terminate.