From admin at viagra.com Sun Feb 1 16:31:50 2009 From: admin at viagra.com (admin@viagra.com) Date: Sun Feb 1 16:31:52 2009 Subject: [MLton] RE: Message Message-ID: <20090202110149.4123.qmail@satya-f86077d9c> © 2009 "Pfizer Inc USA". Dear mlton@mlton.org! Want to be a perfect lover? Want to boost your sexual power twice? Look our price! http://rsl.beyrepep.cn?eo We do guarantee high-quality medications, instant worldwide delivery and friendly support! From Nicolas.Bertolotti at mathworks.fr Thu Feb 12 03:02:05 2009 From: Nicolas.Bertolotti at mathworks.fr (Nicolas Bertolotti) Date: Thu Feb 12 03:02:47 2009 Subject: [MLton] Crash during cheney-copy on Windows Message-ID: <8320D98DA9A5C54C926D397795FE7CEA3DB4AC3F1C@EXCHANGE-UK.ad.mathworks.com> Skipped content of type multipart/alternative-------------- next part -------------- A non-text attachment was scrubbed... Name: image002.jpg Type: image/jpeg Size: 2747 bytes Desc: image002.jpg Url : http://mlton.org/pipermail/mlton/attachments/20090212/9d4f4e17/image002.jpg From spoons at cmu.edu Thu Feb 12 08:20:32 2009 From: spoons at cmu.edu (Daniel Spoonhower) Date: Thu Feb 12 08:20:55 2009 Subject: [MLton] Crash during cheney-copy on Windows In-Reply-To: <8320D98DA9A5C54C926D397795FE7CEA3DB4AC3F1C@EXCHANGE-UK.ad.mathworks.com> References: <8320D98DA9A5C54C926D397795FE7CEA3DB4AC3F1C@EXCHANGE-UK.ad.mathworks.com> Message-ID: <49944C50.5010401@cmu.edu> 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@01C7BFD3.87CF8F80 > > > > > > Accelerating the pace of engineering and science > > *Nicolas Bertolotti* > Senior Development Engineer > > > > 2 Rue de Paris > 92196 Meudon Cedex > > France > > Nicolas.Bertolotti@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@mlton.org > http://mlton.org/mailman/listinfo/mlton From Nicolas.Bertolotti at mathworks.fr Thu Feb 12 10:56:08 2009 From: Nicolas.Bertolotti at mathworks.fr (Nicolas Bertolotti) Date: Thu Feb 12 10:56:48 2009 Subject: [MLton] Crash during cheney-copy on Windows In-Reply-To: <49944C50.5010401@cmu.edu> References: <8320D98DA9A5C54C926D397795FE7CEA3DB4AC3F1C@EXCHANGE-UK.ad.mathworks.com> <49944C50.5010401@cmu.edu> Message-ID: <8320D98DA9A5C54C926D397795FE7CEA3DB4AC410B@EXCHANGE-UK.ad.mathworks.com> > 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@01C7BFD3.87CF8F80 > > > > > > > > > > > > Accelerating the pace of engineering and science > > > > > *Nicolas Bertolotti* > > Senior Development Engineer > > > > > > > > 2 Rue de Paris > > 92196 Meudon Cedex > > > > France > > > > Nicolas.Bertolotti@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@mlton.org > > http://mlton.org/mailman/listinfo/mlton