[MLton] Crash during cheney-copy on Windows

[Daniel Spoonhower]

Hi, Nicolas.  Here are a couple of ideas.

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.)

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).


--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