js1_8/extensions/regress-452913.js shell Assertion failure: JS_PROPERTY_CACHE(cx).disabled, at jsinterp.c:97 regressed (or uncovered) by bug 434837. See also bug 462991.

(In reply to comment #0) > regressed (or uncovered) by bug 434837. this is wrong, sorry. I'm not sure of the regressor at the moment.

If we regressed this during this cycle, we should block on it. Otherwise, we can take it in 1.9.0.7.

the full assert is: Assertion failure: JS_PROPERTY_CACHE(cx).disabled == fp->pcDisabledSave, at jsinterp.c:69q76

looks like bug 322889 is the winner. The test wasn't added until 2008-11-21, but the first failure didn't appear until 2008-11-16. Even then it only occurred a dozen or so times out of hundreds of test runs. While trying to bisect it, the failure was very dependent on how well the objdir was clobbered between builds. The most reliable method was to just remove the objdir altogether.

err, didn't appear until 2008-12-16

Since this has been broken the whole life of Firefox 3 we probably don't need to block a 3.0.x release on it, and will take it when it gets fixed on trunk/3.1 Or does this only happen on the 1.9.0 branch? What's the security implication of this assertion?

just 1.9.0

Removing blocking1.9.1 nom per comment 7

dveditz: any reason to keep this private now that bug 452913 is open?

Never got an answer to my main question in comment 6, how bad is this as a potential security problem. If it is one then let's keep this private and think about making bug 452913 comment 44 private.

I'm not really sure what the answer is -- it *seems* like this could lead to two objects with different shapes seeming to have the same shape, which could lead to [sg:crit] bugs, but I don't know if that's possible in practice. Brendan?

Since this one's been tough to triage and there is the potential for critical exploits per comment 11, I'm putting this one on our Top Security Bugs list. Please treat this as a priority.

This is not exploitable -- the bug is that rt->shapeGen overflows so js_GC leaves the property cache disabled. It can't be reenabled, but the assertion botching is the only effect. Suggest WONTFIX, or a targeted backport of changes from bugs such as bug 419091. /be

The patch for bug 487039 removed JSStackFrame::pcDisabledSave and fixed real bugs which are unpatched in 1.9.0.x -- I'm making this bug depend on that one pending a better idea. /be

Igor, should patches be back-ported? Sayre may have an opinion too. This is one of the bugs in bsterne's automated report, but it is not obviously exploitable and it is not hard to fix. /be

We should try to backport the bug 487039. Surely the assert in this bug is not exploitable, but the bug 487039 could be.

(In reply to comment #16) > We should try to backport the bug 487039. Surely the assert in this bug is not > exploitable, but the bug 487039 could be. assigning to igor for the backport.

The bug is on no longer supported branch.