Stephen Donner found this bug, I reduced it and Jesse Ruderman helped to reduce it even more. This causes js opt shell to crash at 0x00000000fffffff0 and debug js shell to show this assertion "Assertion failure: 0, at jsopcode.c:1852". this.__defineGetter__('y', ({}).watch); var g = (function () { (yield 3) + (this.y); })(); g.next(); g.next(); I nominate this bug for blocking1.9 because it crashes at 0x00000000fffffff0, so it is likely to be exploitable. Bug 407230 and bug 380432 trigger the same assertion in debug builds, but in opt builds, those bugs don't cause a crash. This bug (both the assertion happening with this testcase, and the crash) is a regression from within the last three days or so.

The assertion is a regression from bug 420919's patch -- should block until we know more. /be

If bug 420919 isn't a blocker, wouldn't we just back the other one out rather than make this one a blocker?

I still feel (as I argued there) that bug deserved blocker-status.

Shaver, care to address Crowder's plea for blocking status on bug 420919 and therefor this one?

Ignoring the comment fixes (I was led on a merry chase through js_Invoke re-learning how the offending value is decompiled for the "is not a function" error from obj_watch), this fix just leaves JSOP_GETTHISPROP handled by its own case in the rewrite-op-if-up-against-dvgfence logic, which case does not rewrite op to JSOP_THIS. The result for this bug's reduced testcase from comment 0 is slighly confusing, but much better than crashing, and better still than "(void 0) is not a function": typein:10: TypeError: this.y is not a function Might want to say "this.y is not a watchpoint function". Even better would be something like "this.y has a getter that calls Object.prototype.watch with too few arguments" but I'll save that for next time. /be

Let's move forward. The mistake made in the patch for bug 420919 is trivial to correct. The assertion did its job and smoked out the forgotten way that a getter can call a native function such as obj_watch in a way that reports an error, in the course of which the faulting pc's opcode is blamed -- requiring that that op have a case of its own in the switch patched here in jsopcode.c. Bug 420919 is important since common errors should decompile the value-generating expression for bad values such as null and undefined, not say "null is not a function" or "(void 0) is not a function". JS developers prefer Firefox in part due to better diagnostics, and we see competing browsers working to catch up and overtake. This can be a ride-along non-blocker if such a thing is possible. Main point is to move forward, not backward. There won't be a followup for another regression here. How JSOP_GETTHISPROP is handled is the only issue. /be

Non-blocking, but we should take the fix if it reviews and tests well. Diagnostics are a big differentiator and productivity enhancement for developers, and this is a low-risk patch.

(If we don't take it for 1.9, we should be sure to take it in 1.9.0.1.)

Sorry, flag-click-o.

Comment on attachment 318524 [details] [diff] [review] Don't rewrite JSOP_GETTHISPROP when it is against the dvgfence a1.9+=damons

Filed followup bug 431569 (to be fixed post-mozilla1.9) and commented about it in jsopcode.c. /be

Fixed: js/src/jsinterp.c 3.496 js/src/jsopcode.c 3.315 /be

I'm still getting Assertion failure: 0, at mozilla/js/src/jsopcode.c:1863 on mac os x i386 at least.

(In reply to comment #14) > I'm still getting Assertion failure: 0, at mozilla/js/src/jsopcode.c:1863 on > mac os x i386 at least. You have out of date source -- the patched line is 1873. /be

confirmed luser error.

v 1.9.0

when this bug is opened, the test should be checked in.