[MLton] Crash during cheney-copy on Windows

[Nicolas Bertolotti]

> It's not clear to me exactly what debugging you are able to enable and
> still observe the problem.  I believe the most important check would be
> "invariantForGC" which is run at the beginning and end of each
> collection.  Are you able to run this function and still observe the
> problem?  (It is in the debug version of the runtime and is also
> enabled
> by -DASSERT=1.)

The assertions are enabled so invariantForGC() is called and does not reveal anything.

> 
> If you are suspicious of old data in the heap, you could try explicitly
> clearing the new heap at the beginning of a Cheney copy (i.e. in
> majorCheneyCopyGC).

I examined the array allocation routine and it definitely properly resets the contents of all the cells. 

It is also not a limit case (such as a '<' instead of a '<=' somewhere) either as the crash appears to occur around the cell 15000 of a 32768 cells array.

Still investigating ...

> 
> 
> --djs
> 
> Nicolas Bertolotti wrote:
> > Hello,
> >
> >
> >
> > I am currently facing a crash of my product during the cheney-copy
> > operation on Windows. This crash is very hard to reproduce as it is
> very
> > volatile (some slight changes in the SML code make it disappear ; it
> > depends on the memory amount etc…).
> >
> >
> >
> > I finally could activate some debug messages and assertions (it is
> not
> > full the debugging mode because enabling it causes the issue to
> disappear) :
> >
> > [GC: Starting gc #73; requesting 512 nursery bytes and 0 old-gen
> bytes,]
> >
> > [GC:    heap at 0x31880000 of size 710,967,296 bytes,]
> >
> > [GC:    with nursery of size 617,405,820 bytes (86.8% of heap),]
> >
> > [GC:    and old-gen of size 93,561,476 bytes (13.2% of heap),]
> >
> > …
> >
> > [GC: Starting major Cheney-copy;]
> >
> > [GC:    from heap at 0x31880000 of size 710,967,296 bytes,]
> >
> > [GC:    to heap at 0x08fc0000 of size 710,967,296 bytes.]
> >
> > …
> >
> > [GC: Finished major Cheney-copy; copied 97,279,788 bytes.]
> >
> > …
> >
> >  [GC: Starting gc #77; requesting 512 nursery bytes and 0 old-gen
> bytes,]
> >
> > [GC:    heap at 0x08fc0000 of size 710,967,296 bytes,]
> >
> > [GC:    with nursery of size 612,833,480 bytes (86.2% of heap),]
> >
> > [GC:    and old-gen of size 98,133,816 bytes (13.8% of heap),]
> >
> > …
> >
> > [GC: Starting major Cheney-copy;]
> >
> > [GC:    from heap at 0x08fc0000 of size 710,967,296 bytes,]
> >
> > [GC:    to heap at 0x31880000 of size 710,967,296 bytes.]
> >
> > …
> >
> > foreachObjptrInObject (0x318c2318)  header = 000004c7  tag = ARRAY
> > bytesNonObjptrs = 0  numObjptrs = 1
> >
> > forwardObjptr  opp = 0x318c2318  op = 0x00000000091b7714  p =
> 0x091b7714
> >
> > forwardObjptr --> *opp = 0x319f57dc
> >
> > …
> >
> > forwardObjptr  opp = 0x318d1354  op = 0x00000000091d78c4  p =
> 0x091d78c4
> >
> > forwardObjptr --> *opp = 0x31a173ac
> >
> > forwardObjptr  opp = 0x318d1358  op = 0x00000000318da094  p =
> 0x318da094
> >
> > Assertion failed at line 58 of file gc/object.c
> >
> > ===> corresponds to the “assert (1 == (header &
> GC_VALID_HEADER_MASK));”
> > at the beginning of the splitHeader() function
> >
> >
> >
> > Using those debug messages, we can see that all calls to
> forwardObjptr()
> > are performed on objects whose address is, as expected, in the “from”
> > heap whereas the last call that leads to a crash receives an invalid
> > pointer whose address is in the “to” heap.
> >
> >
> >
> > We also see that the 2 heaps have been allocated during a previous
> call
> > to the garbage collector and a previous “cheney-copy” has already
> been
> > performed between those.
> >
> >
> >
> > I suspect that maybe a previous GC operation left some old pointers
> in
> > one of the heaps and those have not been properly cleared during an
> > object allocation or so on.
> >
> >
> >
> > In any case, I simply don’t know what to do in order to identify the
> > root cause of the issue. Any hint ?
> >
> >
> >
> > Best regards
> >
> >
> >
> > cid:image001.gif at 01C7BFD3.87CF8F80 <http://www.mathworks.fr/>
> >
> >
> >
> >
> >
> > Accelerating the pace of  engineering and science
> <http://www.mathworks.fr/>
> >
> > *Nicolas Bertolotti*
> > Senior Development Engineer
> >
> >
> >
> > 2 Rue de Paris
> > 92196 Meudon Cedex
> >
> > France
> >
> > Nicolas.Bertolotti at mathworks.fr
> <mailto:Nicolas.Bertolotti at mathworks.fr>
> >
> >
> >
> > tel:
> > fax:
> > mobile:
> >
> >
> >
> > +33.1.41.14.88.55
> >
> > +33.1.55.64.06.64
> >
> > +33.6.86.41.87.15
> >
> >
> >
> >
> > ---------------------------------------------------------------------
> ---
> >
> > _______________________________________________
> > MLton mailing list
> > MLton at mlton.org
> > http://mlton.org/mailman/listinfo/mlton