this.__proto__.x = eval; for (i = 0; i < 16; ++i) delete eval; (function w() { x = 1; })(); triggers Assertion failure: !entry || entry->kpc == ((PCVCAP_TAG(entry->vcap) > 1) ? (jsbytecode *) JSID_TO_ATOM(id) : cx->fp->pc), at jsobj.c:3423

The assertion condition changed in bug 421274. The testcase in this bug still triggers the assertion. Assertion failure: entry->kpc == ((PCVCAP_TAG(entry->vcap) > 1) ? (jsbytecode *) JSID_TO_ATOM(id) : cx->fp->regs->pc), at jsobj.c:3477

See bug 424311 for another way to trigger this assertion.

The shell uses JS_ResolveStandardClass even when JSRESOLVE_ASSIGNING, which is a bug, but not the bug. This means each delete eval reference will resolve via the JSOP_BINDNAME bytecode the 'eval' identifier. This somehow results in a 16-deep prototype chain being created. I didn't have time to debug fully, but it appeared as though js_InitFunctionAndObjectClasses etc. were not suppressing recursion or otherwise being idempotent as before. Igor, could the function changes have broken how JSProto_Function is initialized? /be

WFM.

BUGNUMBER: 416834 STATUS: Do not assert: !entry || entry->kpc == ((PCVCAP_TAG(entry->vcap) > 1) ? (jsbytecode *) JSID_TO_ATOM(id) : cx->fp->pc) Assertion failure: entry->kpc == ((PCVCAP_TAG(entry->vcap) > 1) ? (jsbytecode *) JSID_TO_ATOM(id) : cx->fp->regs->pc), at jsobj.c:3491 Aborted

Why would someone delete eval happen 16 times? Do we know if this is exploitable? Does this only happen if you are fuzzing? Need more info here if we're to block on this.

Marking this blocking 1.9 as it should definitely block final based on conversation with Brendan.

I don't understand this code well enough to know whether this is simply wallpaper or not. It does fix the assertion.

This is an alternative that avoids the assertion. It adds the entry nulling into the most central place.

If we're choosing wallpaper, I think I like mrbkap's better. :)

Comment on attachment 314626 [details] [diff] [review] Alternative Yeah, my bad -- thanks for fixing. Safe 1.9-ready fix. /be

Comment on attachment 314626 [details] [diff] [review] Alternative a1.9=beltzner

jsinterp.c:3.490

Patch for the underlying problem in bug 428366.

/cvsroot/mozilla/js/tests/js1_5/extensions/regress-416834.js,v <-- regress-416834.js initial revision: 1.1

v 1.9.0

/cvsroot/mozilla/js/tests/public-failures.txt,v <-- public-failures.txt new revision: 1.68; previous revision: 1.67