Crash during cheney-copy on Windows
|
View:
New views
6 Messages
—
Rating Filter:
Alert me
|
 |
Crash during cheney-copy on Windows
by Nicolas Bertolotti-2
::
Rate this Message:
Some parts of this message have been removed.
Learn more about Nabble's security policy.
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
_______________________________________________ MLton mailing list MLton@... http://mlton.org/mailman/listinfo/mlton |
|||||||||||||
|
|
Re: Crash during cheney-copy on Windows
by Daniel Spoonhower-3
::
Rate this Message:
|
|||||||||||||
|
|
RE: Crash during cheney-copy on Windows
by Nicolas Bertolotti-2
::
Rate this Message:
|
|||||||||||||
|
|
RE: Crash during cheney-copy on Windows
by Nicolas Bertolotti-2
::
Rate this Message:
Some parts of this message have been removed.
Learn more about Nabble's security policy.
I am facing a sporadic
signal 11 (segmentation fault) on Linux which could be caused by the same bug. After enabling assertions,
I could identify that there was a sporadic assertion failure in
updateCrossMap() : void updateCrossMap
(GC_state s) {
GC_cardMapIndex cardIndex; pointer
cardStart, cardEnd; … cardEnd =
cardStart + CARD_SIZE; loopObjects: assert
(objectStart < oldGenEnd); <= this assertion may sporadically
fail assert
((objectStart == s->heap.start or cardStart < objectStart)
and objectStart <= cardEnd); … The assertion fails
during the execution of a minor cheney copy that occurs after 2 calls to
GC_pack() and the heap size did not change during the execution of the 2nd
GC_pack(). I finally identified that
the SVN revision r6776 introduced a change that was motivated by the fact we
need to clear the cross map after every major GC. But, if we look at the code,
we can see that the cross map is only cleared when the ‘mayResize’
flag is set (and, as a matter of fact, this flag is not set by GC_pack()) : void majorGC
(GC_state s, size_t bytesRequested, bool mayResize) { … if (mayResize)
{
resizeHeap (s, s->lastMajorStatistics.bytesLive + bytesRequested);
setCardMapAndCrossMap (s); } … } As the revision r6776
also introduces the removal of some calls to clearCrossMap() which were
performed systematically at the end of a major cheney-copy or major
mark-compact, it seems to me that the call to setCardMapAndCrossMap(s) should
actually always be performed (or maybe adding a else { clearCrossMap(s); }
would be enough). I moved the call to
setCardMapAndCrossMap(s) after the if and it seems to solve the issue (anyway, as
it was sporadic, I am not so sure) What do you think ? Nicolas From: mlton-bounces@...
[mailto:mlton-bounces@...] On Behalf Of Nicolas Bertolotti 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
_______________________________________________ MLton mailing list MLton@... http://mlton.org/mailman/listinfo/mlton |
|||||||||||||
|
|
RE: Crash during cheney-copy on Windows
by Nicolas Bertolotti-2
::
Rate this Message:
|
|||||||||||||
|
|
Re: RE: Crash during cheney-copy on Windows
by Matthew Fluet-5
::
Rate this Message:
|
| Free embeddable forum powered by Nabble | Forum Help |
