743876 - Assertion failure: (ptrBits & 0x7) == 0, at ../../jsval.h:763 or Crash [@ js::gc::Cell::compartment] or [@ js_GetMethod]

Status: VERIFIED FIXED

(Core :: JavaScript Engine, defect)

Description

[Christian Holler (:decoder)]

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

[David Bolter [:davidb] (NeedInfo me for attention)]

Setting affected 14 for now. Gary will grab a window.

Comment 2

[Gary Kwong [:gkw] [:nth10sd] (NOT official MoCo now)]

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.

Comment 3

[Jeff Walden [:Waldo]]

I can't reproduce this on 64-bit Linux.  :-(

Comment 4

[Gary Kwong [:gkw] [:nth10sd] (NOT official MoCo now)]

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.

Comment 5

[Gary Kwong [:gkw] [:nth10sd] (NOT official MoCo now)]

> 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

[Daniel Veditz [:dveditz]]

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.

Comment 7

[Lukas Blakk [:lsblakk] use ?needinfo]

[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.

Comment 8

[Daniel Veditz [:dveditz]]

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.

Comment 9

[Christian Holler (:decoder)]

JSBugMon: This bug has been automatically verified fixed.

Comment 10

[Christian Holler (:decoder)]

JSBugMon: This bug has been automatically verified fixed.

Comment 11

[Christian Holler (:decoder)]

JSBugMon: This bug has been automatically verified fixed.

Comment 12

[Jason Orendorff [:jorendorff]]

Does anybody know if this bug has been automatically verified fixed or not?

Comment 13

[Christian Holler (:decoder)]

Seems like Bugzilla responded with an error while setting VERIFIED which caused the script to comment multiple times.

Comment 14

[Christian Holler (:decoder)]

Automatically extracted testcase for this bug was committed:

https://hg.mozilla.org/mozilla-central/rev/efaf8960a929