Closed
Bug 581785
Opened 14 years ago
Closed 13 years ago
TM: Crash [@ Exception] or "Assertion failure: isObject(),"
Categories
(Core :: JavaScript Engine, defect)
Core
JavaScript Engine
Tracking
()
VERIFIED
FIXED
Tracking | Status | |
---|---|---|
blocking2.0 | --- | betaN+ |
People
(Reporter: gkw, Assigned: jorendorff)
References
Details
(4 keywords, Whiteboard: [sg:critical][hardblocker][fixed-in-tracemonkey])
Crash Data
function f() { this.b = function() {}; this.b = Object.e; Object.defineProperty(this, "b", {}) } for (a in [0, 0, 0, 0]) { new f } asserts js debug shell on TM tip with -j at Assertion failure: isObject(), at ../jsvalue.h:531 Program received signal EXC_BAD_ACCESS, Could not access memory. Reason: KERN_PROTECTION_FAILURE at address: 0x00000000 0x0015d363 in JS_Assert (s=0x1f8b60 "isObject()", file=0x1efb28 "../jsvalue.h", ln=531) at ../jsutil.cpp:81 81 *((int *) NULL) = 0; /* To continue from here in GDB: "return" then "continue". */ (gdb) bt #0 0x0015d363 in JS_Assert (s=0x1f8b60 "isObject()", file=0x1efb28 "../jsvalue.h", ln=531) at ../jsutil.cpp:81 #1 0x0014f5bf in js::Value::toObject (this=0xbfffe1c0) at jsvalue.h:531 #2 0x000ccf6b in js_NativeGet (cx=0x809400, obj=0x6026c8, pobj=0x6026c8, sprop=0x866d90, getHow=2, vp=0xbfffe1c0) at ../jsobj.cpp:4712 #3 0x000cf511 in DefinePropertyOnObject (cx=0x809400, obj=0x6026c8, desc=@0xbfffe2b4, throwError=true, rval=0xbfffe2eb) at ../jsobj.cpp:2143 #4 0x000d022e in DefineProperty (cx=0x809400, obj=0x6026c8, desc=@0xbfffe2b4, throwError=true, rval=0xbfffe2eb) at ../jsobj.cpp:2367 #5 0x000d1026 in js_DefineOwnProperty (cx=0x809400, obj=0x6026c8, id={asBits = 2206000}, descriptor=@0xbfffe360, bp=0xbfffe334) at ../jsobj.cpp:2380 #6 0x000d11b0 in obj_defineProperty (cx=0x809400, argc=3, vp=0xbfffe3a0) at ../jsobj.cpp:2406 #7 0x003eff56 in ?? () #8 0x001816f0 in js::ExecuteTrace (cx=0x809400, f=0x864244, state=@0xbfffe458) at ../jstracer.cpp:6598 #9 0x0018e0db in js::ExecuteTree (cx=0x809400, f=0x864244, inlineCallCount=@0xbfffecf0, innermostNestedGuardp=0xbfffe534, lrp=0xbfffe538) at ../jstracer.cpp:6699 #10 0x0019fd22 in js::MonitorLoopEdge (cx=0x809400, inlineCallCount=@0xbfffecf0, reason=js::Record_Branch) at ../jstracer.cpp:7186 #11 0x000909ad in js::Interpret (cx=0x809400) at ../jsinterp.cpp:2919 #12 0x000b3588 in js::Execute (cx=0x809400, chain=0x602000, script=0x40d0c0, down=0x0, flags=0, result=0xbffff680) at jsinterp.cpp:904 #13 0x00017cae in JS_ExecuteScript (cx=0x809400, obj=0x602000, script=0x40d0c0, rval=0xbffff680) at ../jsapi.cpp:4662 #14 0x0000cc36 in Process (cx=0x809400, obj=0x602000, filename=0x0, forceTTY=0) at ../../shell/js.cpp:532 #15 0x0000d60d in ProcessArgs (cx=0x809400, obj=0x602000, argv=0xbffff84c, argc=1) at ../../shell/js.cpp:853 #16 0x0000d726 in shell (cx=0x809400, argc=1, argv=0xbffff84c, envp=0xbffff854) at ../../shell/js.cpp:4949 #17 0x0000d84a in main (argc=1, argv=0xbffff84c, envp=0xbffff854) at ../../shell/js.cpp:5036
Reporter | ||
Comment 1•14 years ago
|
||
The testcase used to assert at "Assertion failure: sprop->methodValue() == *vp," autoBisect shows this is probably related to the following changeset: The first bad revision is: changeset: 36651:766a6b2e74e7 user: Jeff Walden date: Fri Jun 05 12:56:45 2009 -0700 summary: Bug 430133 - Implement ES3.1's Object.defineProperty and Object.defineProperties. r=jorendorff
Blocks: 430133
Updated•14 years ago
|
Assignee: general → jwalden+bmo
Status: NEW → ASSIGNED
OS: Mac OS X → All
Hardware: x86 → All
Comment 2•14 years ago
|
||
Simpler, without irrelevant feature uses (at least pretty sure not, should still test both examples to be certain), definitely no longer my purview: [jwalden@find-waldo-now src]$ dbg/js -j js> var z = 0; js> function f() { this.b = function() {}; this.b = undefined; if (z++ > 3) this.b(); } js> for (var i = 0; i < 10; i++) new f(); Assertion failure: isObject(), at ../jsvalue.h:531 Brendan, what removes JSScopeProperty::METHOD here when assigning undefined, or changes the property tree to use a new property for b? I see nothing, so we trip over an assertion that a method-valued property's slot value equals the method in question.
Assignee: jwalden+bmo → nobody
Comment 3•14 years ago
|
||
JSScope::methodWriteBarrier. /be
Assignee | ||
Comment 4•14 years ago
|
||
IIRC the patch in bug 559653 fixed this and added some tests for it. Unbitrotting...
Assignee | ||
Comment 5•14 years ago
|
||
OK, I have posted an unbitrotted version of the patch in bug 559653. It fixes this bug and adds some tests. But see that bug for the catch.
Updated•14 years ago
|
blocking2.0: ? → beta5+
Assignee | ||
Comment 6•14 years ago
|
||
This got assigned to me, but I really don't have a ton of spare time to hack on this. The patch exists, but it needs some profiling.
Updated•14 years ago
|
blocking2.0: beta5+ → betaN+
Reporter | ||
Comment 8•14 years ago
|
||
(function () { try { v = eval("(function(){x})")(); for (e in v) function() {} } catch(r) {} })() window = new Error for each(c in(new window)) function(){} asserts js debug shell on TM changeset at Assertion failure: isObject(), and crashes js opt shell at Exception
Keywords: crash
Summary: TM: "Assertion failure: isObject()," → TM: Crash [@ Exception] or "Assertion failure: isObject(),"
Comment 9•14 years ago
|
||
WFM?
Reporter | ||
Comment 10•14 years ago
|
||
Not sure if this is the real fix: autoBisect shows this is probably related to the following changeset: The first good revision is: changeset: 52487:9e7fa574c491 user: David Anderson date: Thu Aug 05 18:04:21 2010 -0700 summary: [JAEGER] Increase HOTLOOP to 4; blacklist after 300 execs.
Assignee | ||
Comment 11•14 years ago
|
||
This is not fixed; a slight variation of the test in comment 2 still causes an assertion. HOTLOOP = 8; var z = 0; function f() { this.b = function() {}; this.b = undefined; if (z++ > HOTLOOP) this.b(); } for (var i = 0; i < HOTLOOP + 2; i++) new f();
Updated•14 years ago
|
Group: core-security
Whiteboard: [sg:critical?]
Reporter | ||
Comment 12•14 years ago
|
||
For the testcase in comment 11, the opt shell no longer crashes.
Updated•14 years ago
|
Whiteboard: [sg:critical?] → [sg:critical?][hardblocker]
Assignee | ||
Comment 13•13 years ago
|
||
Yep, the patch for bug 559653 fixed this. I committed the test, for good measure: http://hg.mozilla.org/tracemonkey/rev/d6182fbb43bd
Status: ASSIGNED → UNCONFIRMED
Ever confirmed: false
Whiteboard: [sg:critical?][hardblocker] → [sg:critical][hardblocker][fixed-in-tracemonkey]
Assignee | ||
Updated•13 years ago
|
Status: UNCONFIRMED → NEW
Ever confirmed: true
Updated•13 years ago
|
Status: NEW → RESOLVED
Closed: 13 years ago
Resolution: --- → FIXED
Updated•13 years ago
|
Crash Signature: [@ Exception]
Comment 14•12 years ago
|
||
Fixed long ago, opening up. Also marking VERIFIED because tracer has been long gone on trunk.
Group: core-security
Status: RESOLVED → VERIFIED
Comment 15•11 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
•