Closed
Bug 743876
Opened 13 years ago
Closed 13 years ago
Assertion failure: (ptrBits & 0x7) == 0, at ../../jsval.h:763 or Crash [@ js::gc::Cell::compartment] or [@ js_GetMethod]
Categories
(Core :: JavaScript Engine, defect)
Tracking
()
VERIFIED
FIXED
Tracking | Status | |
---|---|---|
firefox12 | --- | unaffected |
firefox13 | - | wontfix |
firefox14 | + | fixed |
firefox-esr10 | --- | unaffected |
People
(Reporter: decoder, Assigned: luke)
References
Details
(5 keywords, Whiteboard: [advisory-tracking+] fixed by bug 740446)
Crash Data
The following test asserts/crashes on mozilla-central revision 434f50e70815 (options -m -n -a):
var lfcode = new Array();
lfcode.push("3");
lfcode.push("\
evaluate(\"mjitChunkLimit(5)\");\
function slice(a, b) {\
return slice(index, ++(ArrayBuffer));\
}\
");
lfcode.push("0");
lfcode.push("var arr = [0, 1, 2, 3, 4];\
function replacer() {\
assertEq(arguments.length, 2);\
var key = arguments[0], value = arguments[1];\
return value;\
}\
assertEq(JSON.stringify(arr, replacer), '[0,1,2,3,4]');\
");
while (true) {
var file = lfcode.shift(); if (file == undefined) { break; }
loadFile(file);
}
function loadFile(lfVarx) {
if (!isNaN(lfVarx)) {
lfRunTypeId = parseInt(lfVarx);
} else {
switch (lfRunTypeId) {
case 0: evaluate(lfVarx); break;
case 3: function newFunc(x) { new Function(x)(); }; newFunc(lfVarx); break;
}
}
}
Crash Trace when stepping through assertion:
Program received signal SIGSEGV, Segmentation fault.
0x0000000000405350 in js::gc::Cell::compartment (this=0x7fff00000002) at ../../jsgc.h:984
984 return arenaHeader()->compartment;
(gdb) bt
#0 0x0000000000405350 in js::gc::Cell::compartment (this=0x7fff00000002) at ../../jsgc.h:984
#1 0x000000000042503f in js::CompartmentChecker::check (this=0x7fffffffa6c0, obj=0x7fff00000002) at ../jscntxtinlines.h:180
#2 0x00000000004250d6 in js::CompartmentChecker::check (this=0x7fffffffa6c0, v=...) at ../jscntxtinlines.h:190
#3 0x00000000004f5971 in js::CompartmentChecker::check (this=0x7fffffffa6c0, args=...) at ../jscntxtinlines.h:207
#4 0x0000000000510f90 in js::assertSameCompartment<js::CallArgs> (cx=0xb77a80, t1=...) at ../jscntxtinlines.h:254
#5 0x00000000004f59df in js::CallJSNative (cx=0xb77a80, native=0x409cca <AssertEq(JSContext*, unsigned int, jsval*)>, args=...) at ../jscntxtinlines.h:313
#6 0x0000000000739cd8 in js::mjit::CallCompiler::generateNativeStub (this=0x7fffffffb0a0) at /srv/repos/mozilla-central/js/src/methodjit/MonoIC.cpp:811
#7 0x000000000073abe7 in js::mjit::ic::NativeCall (f=..., ic=0xb8abb8) at /srv/repos/mozilla-central/js/src/methodjit/MonoIC.cpp:1041
#8 0x00007ffff7f4728a in ?? ()
#9 0x00007ffff7f46eb0 in ?? ()
#10 0x0000000000000000 in ?? ()
Opt Crash:
Program received signal SIGSEGV, Segmentation fault.
js_GetMethod (cx=0x8de820, obj=0x7fff00000002, id=140737322830464, getHow=0, vp=0x7fffffffbac0) at /srv/repos/mozilla-central/js/src/jsobj.cpp:5144
5144 GenericIdOp op = obj->getOps()->getGeneric;
(gdb) bt
#0 js_GetMethod (cx=0x8de820, obj=0x7fff00000002, id=140737322830464, getHow=0, vp=0x7fffffffbac0) at /srv/repos/mozilla-central/js/src/jsobj.cpp:5144
#1 0x00000000004d9757 in js_ValueToSource (cx=0x8de820, v=...) at /srv/repos/mozilla-central/js/src/jsstr.cpp:3315
#2 0x0000000000412580 in JS_ValueToSource (cx=<value optimized out>, v=...) at /srv/repos/mozilla-central/js/src/jsapi.cpp:533
#3 0x00000000004082ec in ToSource (cx=0x8de820, argc=2, vp=0x7ffff63fb2a0) at /srv/repos/mozilla-central/js/src/shell/js.cpp:1160
#4 AssertEq (cx=0x8de820, argc=2, vp=0x7ffff63fb2a0) at /srv/repos/mozilla-central/js/src/shell/js.cpp:1190
#5 0x00000000005db576 in CallJSNative (this=0x7fffffffc370) at ../jscntxtinlines.h:314
#6 js::mjit::CallCompiler::generateNativeStub (this=0x7fffffffc370) at /srv/repos/mozilla-central/js/src/methodjit/MonoIC.cpp:811
#7 0x00000000005dbe23 in js::mjit::ic::NativeCall (f=..., ic=0x8edcf8) at /srv/repos/mozilla-central/js/src/methodjit/MonoIC.cpp:1041
#8 0x00007ffff7f470f2 in ?? ()
#9 0x00007ffff7f46d50 in ?? ()
#10 0x0000000000000000 in ?? ()
S-s and sg:critical due to gc-related memory safety problem.
Comment 1•13 years ago
|
||
Setting affected 14 for now. Gary will grab a window.
status-firefox14:
--- → affected
tracking-firefox14:
--- → +
Updated•13 years ago
|
tracking-firefox13:
--- → ?
Comment 2•13 years ago
|
||
This seems not to reproduce on 32-bit Mac, but I could reproduce on 64-bit Linux.
autoBisect shows this is probably related to the following changeset:
The first bad revision is:
changeset: 87695:f4e955f78de9
user: Jeff Walden
date: Fri Feb 03 18:53:29 2012 -0800
summary: Bug 720316 - Use uint32_t indexes for JOF_ATOM opcodes. r=jorendorff
I think this means Firefox 13 is affected.
Blocks: 720316
Comment 3•13 years ago
|
||
I can't reproduce this on 64-bit Linux. :-(
Comment 4•13 years ago
|
||
I just rechecked and it seems like it got fixed by bug 740446 on mozilla-central tip.
autoBisect shows this is probably related to the following changeset:
The first good revision is:
changeset: 91358:fa24b215d49e
user: Luke Wagner
date: Mon Apr 02 08:58:30 2012 -0700
summary: Bug 740446 - make 'arguments' more like a normal local binding (r=bhackett)
Bug 740446 should be backported, but the patches there are very large (~150kb).
A spot-fix for this in Firefox 13 should be needed. Updating flags accordingly.
status-firefox-esr10:
--- → unaffected
status-firefox12:
--- → unaffected
Comment 5•13 years ago
|
||
> A spot-fix for this in Firefox 13 should be needed. Updating flags
> accordingly.
Confirming to still fail on mozilla-aurora (13) changeset e158b91dd28a, but does not fail on mozilla-beta (12) changeset e6be81269d27.
Tested on Mac 64-bit js opt shells.
Comment 6•13 years ago
|
||
I don't know that it makes sense to back-port the fix for bug 740446 to fix this bug. I guess we'd have another cycle to fix any regressions if it landed now in Aurora, but that seems riskier than simply waiting another six weeks for the problem to resolve itself. Trying to disentangle some small part of that bug's patch to fix this problem seems equally risky.
status-firefox13:
--- → affected
Depends on: 740446
Comment 7•13 years ago
|
||
[Triage Comment]
Setting to track for now, will check with Dan to determine if we want to take the risk when Aurora gets to Beta of detangling some of this.
Updated•13 years ago
|
Assignee: general → luke
Comment 8•13 years ago
|
||
Fixed on trunk. This may not be worth fixing on Firefox 13
- esr10 branch unaffected, so we're not driven to create a spot-fix
to meet our enterprise committments
- may not be a reliable testcase
- known/tested patch is bigger than we'd want to back-port
- fixes itself by waiting another 6 weeks.
Reporter | ||
Comment 9•13 years ago
|
||
JSBugMon: This bug has been automatically verified fixed.
Reporter | ||
Comment 10•13 years ago
|
||
JSBugMon: This bug has been automatically verified fixed.
Reporter | ||
Comment 11•13 years ago
|
||
JSBugMon: This bug has been automatically verified fixed.
Comment 12•13 years ago
|
||
Does anybody know if this bug has been automatically verified fixed or not?
Reporter | ||
Comment 13•13 years ago
|
||
Seems like Bugzilla responded with an error while setting VERIFIED which caused the script to comment multiple times.
Status: RESOLVED → VERIFIED
Updated•12 years ago
|
Whiteboard: [sg:critical] js-triage-needed → [sg:critical][advisory-tracking+] js-triage-needed
Updated•12 years ago
|
Keywords: sec-critical
Whiteboard: [sg:critical][advisory-tracking+] js-triage-needed → [advisory-tracking+] fixed by bug 740446
Updated•12 years ago
|
Group: core-security
Reporter | ||
Comment 14•12 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
•