Closed Bug 581785 Opened 14 years ago Closed 13 years ago

TM: Crash [@ Exception] or "Assertion failure: isObject(),"

Categories

(Core :: JavaScript Engine, defect)

defect
Not set
critical

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
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
Assignee: general → jwalden+bmo
Status: NEW → ASSIGNED
OS: Mac OS X → All
Hardware: x86 → All
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
JSScope::methodWriteBarrier.

/be
IIRC the patch in bug 559653 fixed this and added some tests for it.

Unbitrotting...
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.
blocking2.0: ? → beta5+
Depends on: 559563
Assignee: nobody → jorendorff
No longer depends on: 559563
Depends on: 559653
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.
blocking2.0: beta5+ → betaN+
(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(),"
WFM?
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.
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();
Group: core-security
Whiteboard: [sg:critical?]
For the testcase in comment 11, the opt shell no longer crashes.
Whiteboard: [sg:critical?] → [sg:critical?][hardblocker]
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]
Status: UNCONFIRMED → NEW
Ever confirmed: true
Status: NEW → RESOLVED
Closed: 13 years ago
Resolution: --- → FIXED
Crash Signature: [@ Exception]
Fixed long ago, opening up. Also marking VERIFIED because tracer has been long gone on trunk.
Group: core-security
Status: RESOLVED → VERIFIED
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.