Closed
Bug 732719
Opened 11 years ago
Closed 11 years ago
Assertion failure: allocated(), at ../../jsgc.h:495 or Crash [@ markIfUnmarked]
Categories
(Core :: JavaScript Engine, defect)
Tracking
()
VERIFIED
FIXED
mozilla13
Tracking | Status | |
---|---|---|
firefox10 | - | unaffected |
firefox11 | - | unaffected |
firefox12 | - | unaffected |
firefox13 | + | fixed |
firefox-esr10 | - | unaffected |
People
(Reporter: decoder, Assigned: billm)
References
Details
(4 keywords, Whiteboard: [sg:moderate] js-triage-needed [advisory-tracking+])
Crash Data
Attachments
(1 file)
5.01 KB,
patch
|
bhackett1024
:
review+
|
Details | Diff | Splinter Review |
The following test asserts on mozilla-central revision 343ec916dfd5 (options -m -n -a): function TestCase(n, d, e, a) TestCase.prototype.dump = function () {}; function enterFunc (funcName) function writeHeaderToLog( string ) {} gczeal(2); function f() {} try { var BUGNUMBER = 350621; test(); } catch(exc1) {} function test() { enterFunc ( summary = this, test(BUGNUMBER)); function gen1() { } function test_it(RUNS) { } } new TestCase (String([(1),'a22','a23','a24']), String('a11\na22\na23\na24'.match(new RegExp('a..$','g')))); test(); Stepping through the assertion in the debug build only gives me a division by zero: Program received signal SIGFPE, Arithmetic exception. 0x080fa54c in js::gc::Arena::isAligned (thing=4149308864, thingSize=0) at /srv/repos/mozilla-central/js/src/jsgc.h:580 580 return tailOffset % thingSize == 0; However, a less minimized version crashed my opt build: Program received signal SIGSEGV, Segmentation fault. markIfUnmarked (gcmarker=0x8321b98, thing=0xf73e5860) at /srv/repos/mozilla-central/js/src/jsgc.h:674 674 if (*word & mask) (gdb) bt 8 #0 markIfUnmarked (gcmarker=0x8321b98, thing=0xf73e5860) at /srv/repos/mozilla-central/js/src/jsgc.h:674 #1 markIfUnmarked (gcmarker=0x8321b98, thing=0xf73e5860) at /srv/repos/mozilla-central/js/src/jsgc.h:972 #2 js::gc::PushMarkStack (gcmarker=0x8321b98, thing=0xf73e5860) at /srv/repos/mozilla-central/js/src/jsgcmark.cpp:439 #3 0x080ac0a5 in js::gc::MarkInternal<JSObject> (trc=0x8321b98, thing=0xf73e5860) at /srv/repos/mozilla-central/js/src/jsgcmark.cpp:107 #4 0x08185608 in js::StackSpace::markFrameSlots (this=0x8321af0, trc=0x8321b98, fp=0xf7910530, slotsEnd=0xf7910590, pc=0x83514fa "\212") at /srv/repos/mozilla-central/js/src/vm/Stack.cpp:488 #5 0x08185823 in js::StackSpace::mark (this=0x8321af0, trc=0x8321b98) at /srv/repos/mozilla-central/js/src/vm/Stack.cpp:521 #6 0x080a20d5 in js::MarkRuntime (trc=<value optimized out>, useSavedRoots=<value optimized out>) at /srv/repos/mozilla-central/js/src/jsgc.cpp:2397 #7 0x080a270f in BeginMarkPhase (rt=0x8321ad0) at /srv/repos/mozilla-central/js/src/jsgc.cpp:2990 (gdb) x /1i $pc => 0x80a9c04 <js::gc::PushMarkStack(js::GCMarker*, JSObject*)+68>: mov 0x4(%edi,%eax,4),%ebp (gdb) info reg edi eax ebp edi 0xf7300000 -147849216 eax 0x3fe88 261768 ebp 0x1000 0x1000 Bisect: The first bad revision is: changeset: 87140:2a8ceeb27f7c user: Bill McCloskey date: Fri Feb 17 14:35:20 2012 -0800 summary: Bug 641025 - Incremental GC (r=igor,smaug,roc,cdleary,gregor) S-s and sg:critical due to GC related crash/memory hazard.
Assignee | ||
Comment 1•11 years ago
|
||
As we discussed, the problem here is that the DEFLOCALFUN opcode doesn't fill in its result until the opcode finishes. However, the GC assumes that the value will be defined at the start of the opcode. So if we GC in the middle of the DefLocalFun stub, the GC will crash trying to mark an invalid value. This patch (somewhat inelegantly) writes undefined into the slot location before the stub runs. Please let me know if there's a better way to do this. I'm worried about the fact that we're totally circumventing the FrameState here, although maybe that's what needs to happen.
Assignee: general → wmccloskey
Status: NEW → ASSIGNED
Attachment #603103 -
Flags: review?(bhackett1024)
Updated•11 years ago
|
Attachment #603103 -
Flags: review?(bhackett1024) → review+
Updated•11 years ago
|
Blocks: IncrementalGC
Keywords: regression
Whiteboard: js-triage-needed → [sg:moderate] js-triage-needed
Comment 2•11 years ago
|
||
Bill, do you think this is exploitable at all?
status-firefox-esr10:
--- → unaffected
status-firefox10:
--- → unaffected
status-firefox11:
--- → unaffected
status-firefox12:
--- → unaffected
status-firefox13:
--- → affected
tracking-firefox-esr10:
--- → -
tracking-firefox10:
--- → -
tracking-firefox11:
--- → -
tracking-firefox12:
--- → -
tracking-firefox13:
--- → +
Assignee | ||
Comment 3•11 years ago
|
||
This causes us to mark an invalid pointer. So we'll be walking through memory and setting a bit for each bad pointer we encounter. The bit will be sort-of near the pointer we find. It seems possibly exploitable, but since we're only setting a single bit for each pointer, it would be difficult.
Assignee | ||
Comment 4•11 years ago
|
||
https://hg.mozilla.org/integration/mozilla-inbound/rev/45d1588c2c71
Target Milestone: --- → mozilla13
Comment 5•11 years ago
|
||
https://hg.mozilla.org/mozilla-central/rev/45d1588c2c71
Status: ASSIGNED → RESOLVED
Closed: 11 years ago
Resolution: --- → FIXED
Reporter | ||
Updated•11 years ago
|
Status: RESOLVED → VERIFIED
Updated•11 years ago
|
Group: core-security
Updated•11 years ago
|
Whiteboard: [sg:moderate] js-triage-needed → [sg:moderate] js-triage-needed [advisory-tracking+]
Reporter | ||
Comment 6•10 years ago
|
||
Automatically extracted testcase for this bug was committed: https://hg.mozilla.org/mozilla-central/rev/efaf8960a929
Flags: in-testsuite+
You need to log in
before you can comment on or make changes to this bug.
Description
•