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

[Nicolas Bertolotti]

There was actually another bug in heap.c. Here is an additional patch to fix it:
--- mlton/runtime/gc/heap.c   2008-04-11 19:12:58.000000000 +0200
+++ mltonp1/runtime/gc/heap.c 2008-04-22 16:24:50.000000000 +0200
@@ -337,6 +337,7 @@
       }
       GC_diskBack_read (data, curHeapp->start, size);
       GC_diskBack_close (data);
+      curHeapp->oldGenSize = size;
     } else {
       GC_diskBack_close (data);
       if (s->controls.messages)

Unfortunately, now, I get the following error:
            deepFlatten starting
Out of memory.  Unable to allocate 1,686,393,408 bytes.

... which, I guess, is a different problem.

Nicolas

> -----Original Message-----
> From: Nicolas Bertolotti
> Sent: Tuesday, April 22, 2008 4:13 PM
> To: Nicolas Bertolotti; Matthew Fluet
> Cc: mlton at mlton.org
> Subject: RE: [MLton] Crash fread(...) failed (only read 0) (Cannot
> allocate memory) during deepFlatten with MLton 20070826
>
> It seems that the segmentation fault actually corresponds to a different
> bug.
>
> Here is the end of the log I get using the "gc-messages" flag:
> ...
> [GC: Reading heap at 0x563cb000 of size 1,746,532,092 bytes from disk.]
> [GC: Translating heap at 0x55719000 of size 0 bytes from 0x563cb000.]
> [GC: Finished gc #160; time 28,789 ms,]
> [GC:    heap at 0x55719000 of size 1,760,493,568 bytes,]
> [GC:    with nursery of size 880,246,784 bytes (50.0% of heap),]
> [GC:    and old-gen of size 0 bytes (0.0% of heap).]
> /bin/sh: line 33: 25040 Segmentation fault
> ...
>
> Still investigating ...
>
> Nicolas
>
> > -----Original Message-----
> > From: mlton-bounces at mlton.org [mailto:mlton-bounces at mlton.org] On Behalf
> > Of Nicolas Bertolotti
> > Sent: Tuesday, April 22, 2008 1:40 AM
> > To: Matthew Fluet
> > Cc: mlton at mlton.org
> > Subject: RE: [MLton] Crash fread(...) failed (only read 0) (Cannot
> > allocate memory) during deepFlatten with MLton 20070826
> >
> > Thanks for the answer.
> >
> > I applied the patch and tried to rebuild.
> >
> > Unfortunately, here is what I get now:
> >             deepFlatten starting
> > /bin/sh: line 33: 26073 Segmentation fault      ./lock-exec.x86-linux
> > /tmp/MLton-build.lock /mathworks/GNB/hub/pst/build-tools-R2008b-
> > testing/bin/mlton -cc-opt -D_UNIX -align 4 -verbose 2 -const
> > 'TextIO.bufSize 65536' -const 'MLton.detectOverflow false' -runtime no-
> > load-world -native-split 100000 -cc-opt -s -native-optimize 3 -cc-opt -
> O2
> > -cc-opt -funroll-loops -cc-opt -ffast-math -cc-opt -fomit-frame-pointer
> -
> > cc-opt -fno-exceptions -cc-opt -fexpensive-optimizations -cc-opt -freg-
> > struct-return -cc-opt -unroll-all-loops -target i686-pc-linux -link-opt
> -
> > L. -link-opt -lz -output iabc-dfa.cx86-linux sources.mlb MLton_ffi.c
> > $EXTRA_C_FILES
> >
> > I am still investigating but you may know what's going on.
> >
> > Nicolas
> >
> > > -----Original Message-----
> > > From: Matthew Fluet [mailto:fluet at tti-c.org]
> > > Sent: Monday, April 21, 2008 2:00 AM
> > > To: Matthew Fluet
> > > Cc: Nicolas Bertolotti; mlton at mlton.org
> > > Subject: Re: [MLton] Crash fread(...) failed (only read 0) (Cannot
> > > allocate memory) during deepFlatten with MLton 20070826
> > >
> > > On Sun, 20 Apr 2008, Matthew Fluet wrote:
> > > > 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.
> > >
> > > Actually, this isn't right.  The runtime will attempt to page to disk
> > only
> > > if creating a heap of the minimum size cannot be satisfied with the
> > > existing heap resident.
> > >
> > > It is curious that your program compiles without paging the heap to
> disk
> > > on the 4G machine, but not on the 2G machine, since the virtual memory
> > > address space should be the same on the two machines.  That is, the
> > amount
> > > of physical memory shouldn't affect whether the virtual memory system
> is
> > > able to satisfy the request.
> > >
> > > Of course, starting off with different physical memory sizes means
> that
> > > different heap sizes will be realized by the compile on the two
> > machines,
> > > so the point at which the paging occurs on the 2G machine may not
> > > correspond to any GC on the 4G machine.
> >
> >
> > _______________________________________________
> > MLton mailing list
> > MLton at mlton.org
> > http://mlton.org/mailman/listinfo/mlton