805747 - IonMonkey: Assertion failure: [barrier verifier] Unmarked edge: <unknown>,

Status: VERIFIED FIXED

(Core :: JavaScript Engine, defect)

Description

[Gary Kwong [:gkw] [:nth10sd] (NOT official MoCo now)]

Attachment: stack

try {
    x = {}
    y = '';
    (function() {
        toString = (function() {
            x.s += y
        })
    })()
    print(this)
    Object.freeze(x)(verifyprebarriers())
} catch (e) {}
y = 'p'
for (m = 0, print; m < 9; ++m) {
    print(this)
}

asserts js debug and opt shell on m-c changeset 58c8080a1a7c with --ion-eager at Assertion failure: [barrier verifier] Unmarked edge: <unknown>,

s-s because older bugs with similar asserts have also been marked s-s, assuming sec-critical unless otherwise shown.

autoBisect shows this is probably related to the following changeset:

The first bad revision is:
changeset:   111211:2583a19e59ef
user:        Kannan Vijayan
date:        Tue Oct 23 22:18:11 2012 -0400
summary:     Bug 795801 - IC StrictPropertyOp setters in IonMonkey. (r=dvander)

Comment 1

[David Anderson [:dvander] - inactive, e-mail if emergency]

(Stealing w/ permission)

Comment 2

[Kannan Vijayan [:djvj]]

Helping david steal this.

Comment 3

[David Anderson [:dvander] - inactive, e-mail if emergency]

bug 795801 turned out to be a red herring. This is a pre-existing bug, the problem is that our setprop-add ICs don't respect an object's extensibility.

Comment 4

[David Anderson [:dvander] - inactive, e-mail if emergency]

Attachment: fix

Comment 5

[David Anderson [:dvander] - inactive, e-mail if emergency]

Comment on attachment 677160 [details] [diff] [review]
fix

[Security approval request comment]
How easily can the security issue be deduced from the patch?

Extremely difficult.

Do comments in the patch, the check-in comment, or tests included in the patch paint a bulls-eye on the security problem?

No.

Which older supported branches are affected by this flaw?

Firefox 18.

If not all supported branches, which bug introduced the flaw?

IonMonkey.

Do you have backports for the affected branches? If not, how different, hard to create, and risky will they be?

Yes.

How likely is this patch to cause regressions; how much testing does it need?

Extremely unlikely, if anything needs only performance testing.

Comment 6

[David Anderson [:dvander] - inactive, e-mail if emergency]

https://hg.mozilla.org/integration/mozilla-inbound/rev/fb274a7b7b9d

Comment 7

[Ed Morley [:emorley]]

https://hg.mozilla.org/mozilla-central/rev/fb274a7b7b9d

Comment 8

[Christian Holler (:decoder)]

JSBugMon: This bug has been automatically verified fixed.

Comment 9

[bhavana bajaj [:bajaj]]

(In reply to David Anderson [:dvander] from comment #6)
> https://hg.mozilla.org/integration/mozilla-inbound/rev/fb274a7b7b9d

Can we please uplift this on aurora, if it has got the needed bake time/testing ?

Comment 10

[David Anderson [:dvander] - inactive, e-mail if emergency]

Comment on attachment 677160 [details] [diff] [review]
fix

[Approval Request Comment]
Bug caused by (feature/regressing bug #): IonMonkey
User impact if declined: Potential security bug
Testing completed (on m-c, etc.): Yes
Risk to taking this patch (and alternatives if risky): Extremely low
String or UUID changes made by this patch:

Comment 11

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/releases/mozilla-aurora/rev/f22982f4e185

Comment 12

[u279076]

Can this be put in testsuite?