Closed
Bug 581785
Opened 15 years ago
Closed 15 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•15 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•15 years ago
|
Assignee: general → jwalden+bmo
Status: NEW → ASSIGNED
OS: Mac OS X → All
Hardware: x86 → All
Comment 2•15 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•15 years ago
|
||
JSScope::methodWriteBarrier.
/be
| Assignee | ||
Comment 4•15 years ago
|
||
IIRC the patch in bug 559653 fixed this and added some tests for it.
Unbitrotting...
| Assignee | ||
Comment 5•15 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•15 years ago
|
blocking2.0: ? → beta5+
| Assignee | ||
Comment 6•15 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•15 years ago
|
blocking2.0: beta5+ → betaN+
| Reporter | ||
Comment 8•15 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•15 years ago
|
||
WFM?
| Reporter | ||
Comment 10•15 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•15 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•15 years ago
|
Group: core-security
Whiteboard: [sg:critical?]
| Reporter | ||
Comment 12•15 years ago
|
||
For the testcase in comment 11, the opt shell no longer crashes.
Updated•15 years ago
|
Whiteboard: [sg:critical?] → [sg:critical?][hardblocker]
| Assignee | ||
Comment 13•15 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•15 years ago
|
Status: UNCONFIRMED → NEW
Ever confirmed: true
Updated•15 years ago
|
Status: NEW → RESOLVED
Closed: 15 years ago
Resolution: --- → FIXED
Updated•14 years ago
|
Crash Signature: [@ Exception]
Comment 14•14 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•13 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
•