Closed
Bug 684619
Opened 13 years ago
Closed 13 years ago
Assertion failure: addr % Cell::CellSize == 0, at jsgc.h:665
Categories
(Core :: JavaScript Engine, defect)
Tracking
()
RESOLVED
FIXED
mozilla11
Tracking | Status | |
---|---|---|
firefox9 | - | --- |
People
(Reporter: decoder, Unassigned)
References
Details
(Keywords: assertion, testcase)
Attachments
(2 files)
2.22 KB,
application/x-compressed-tar
|
Details | |
4.05 KB,
patch
|
bhackett1024
:
review+
|
Details | Diff | Splinter Review |
The attached test asserts on mozilla-central revision a351ae35f2c4 (with shell build fix from mozilla-inbound rev fff3dc9478ce). See README for options and running instructions. This test only works on 32 bit debug builds. Stepping through the assert will crash: Program received signal SIGSEGV, Segmentation fault. 0x0805a65b in js::gc::ArenaHeader::allocated (this=0xdadad000) at ../../jsgc.h:391 391 JS_ASSERT(allocKind <= FINALIZE_LIMIT);
Comment 1•13 years ago
|
||
A GC gets triggered in the middle of the FindReferences shell-only debugging function, when a call to JS_SetElement allocates some shapes. FindReferences uses a GC tracer to walk the heap, and after the GC it winds up with a garbage value in its worklist (don't know why, but one possibility is a shifting set of conservative roots caused previously reachable things to become unreachable and get collected). Can someone with the right bits remove the s-s?
Updated•13 years ago
|
Group: core-security
Reporter | ||
Comment 2•13 years ago
|
||
I didn't see that FindReferences is involved here. My question would be if FindReferences is generally harmful (and should be deleted in fuzz driver before testing) or if this is a real bug and FindReferences is generally safe.
Comment 3•13 years ago
|
||
(In reply to Christian Holler (:decoder) from comment #2) > I didn't see that FindReferences is involved here. My question would be if > FindReferences is generally harmful (and should be deleted in fuzz driver > before testing) or if this is a real bug and FindReferences is generally > safe. This is a real bug, FindReferences should not be crashing here or anywhere. However, until this gets fixed you might want to blacklist FindReferences from the fuzzer, as even if a GC crashing testcase uses FindReferences there isn't a simple way to tell it is crashing *because* of the FindReferences.
Comment 4•13 years ago
|
||
I can't reproduce this bug myself, but if bhackett's analysis is correct, I'd expect this to fix the problem. Explanation in the comments.
Attachment #573028 -
Flags: review?(bhackett1024)
Comment 5•13 years ago
|
||
(That is, I started with a351ae35f2c4, applied the patch in fff3dc9478ce, build as a 32-bit executable, and then ran the test case according to the README, and didn't get an assertion. Not too surprising, if it indeed is a conservative scanning issue.)
Updated•13 years ago
|
Attachment #573028 -
Flags: review?(bhackett1024) → review+
Comment 6•13 years ago
|
||
https://hg.mozilla.org/integration/mozilla-inbound/rev/d88e2c0f2732
Status: NEW → ASSIGNED
Whiteboard: js-triage-needed → [inbound]
Comment 7•13 years ago
|
||
https://hg.mozilla.org/mozilla-central/rev/d88e2c0f2732
Status: ASSIGNED → RESOLVED
Closed: 13 years ago
Resolution: --- → FIXED
Whiteboard: [inbound]
Target Milestone: --- → mozilla11
Comment 10•13 years ago
|
||
(In reply to Christian Legnitto [:LegNeato] from comment #9) > Do we care about this for Fx9 (with TI) or could we ship as-is? The bug and fix are both in a shell-only debugging function so it doesn't affect Fx9.
You need to log in
before you can comment on or make changes to this bug.
Description
•