The following code asserts on TM tip: gczeal(2); Function.prototype.prototype = function() { return 42; } try { foo(Function); } catch (e) { } Function.prototype.prototype = function() { return 42; } I'm not sure, but this might be related to 623301 (at least Function and properties are used here as well). Security locked this because it seems like a GC problem although in my first test, it didn't crash after the assert. Unlock if it's not a security problem :)

I'm not crashing on this with daaf6a3b8782. Is this the complete testcase, or does comment 0 perhaps contain a mis-paste?

The first bad revision is: changeset: 52d20032116a user: Jason Orendorff date: Thu Dec 09 12:04:35 2010 -0600 summary: Bug 614051 - TM: wrong behavior setting existing properties to joined function object values again. r=brendan.

It asserts for me if I give the testcase to the shell as a file, but not if I paste it into an interactive shell.

The first SETMETHOD defines a method property. The second SETMETHOD reaches this code in js_SetPropertyHelper: if (shape && (defineHow & JSDNP_SET_METHOD)) { /* * JSOP_SETMETHOD is assigning to an existing own property. If it * is an identical method property, do nothing. Otherwise downgrade * to ordinary assignment. Either way, do not fill the property * cache, as the interpreter has no fast path for these unusual * cases. */ bool identical = shape->isMethod() && &shape->methodObject() == &vp->toObject(); if (!identical) { (1) if (!obj->methodShapeChange(cx, *shape)) return false; JS_ASSERT(IsFunctionObject(*vp)); JSObject *funobj = &vp->toObject(); JSFunction *fun = GET_FUNCTION_PRIVATE(cx, funobj); if (fun == funobj) { (2) funobj = CloneFunctionObject(cx, fun, fun->parent); if (!funobj) return JS_FALSE; vp->setObject(*funobj); } } if (defineHow & JSDNP_CACHE_RESULT) { JS_ASSERT_NOT_ON_TRACE(cx); TRACE_2(SetPropHit, JS_NO_PROP_CACHE_FILL, shape); } (3) return identical || js_NativeSet(cx, obj, shape, false, vp); } After (1), shape still points to the old shape. Now *shape is gc-unreachable (the conservative stack scan does not see shape pointers). CloneFunctionObject (2) does GC due to gczeal. This collects the shape and 0xdadadadas it out. js_NativeSet (3) reads that junk and asserts. The fix is to update shape to point to the new property after (1). Easy patch. This should block ff4 final at least.

I could instead just do `shape = obj->lookup(id)` in js_SetPropertyHelper. That would be a smaller patch, but it seems silly to do a lookup when methodWriteBarrier could just return the shape.

Maybe sg:critical? given we might do things to the wrong/deleted shape.

Comment on attachment 503313 [details] [diff] [review] v1 Thanks, r=me. /be

cdleary-bot mozilla-central merge info: http://hg.mozilla.org/mozilla-central/rev/b90090c29571

This part: - obj->methodWriteBarrier(cx, shape->slot, value); + obj->methodWriteBarrier(cx, *shape, value); seems to cause a -j performance regression. See bug 629968.

Fixed for a long time and not affecting old branches, opening this.

Test was landed with fix, marking verified.

A testcase for this bug was automatically identified at js/src/jit-test/tests/basic/bug623863.js.