812235 - "Assertion failure: needsBarrier_,"

Status: RESOLVED FIXED

(Core :: JavaScript Engine, defect)

Description

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

Attachment: stack

gc()
schedulegc(this)
gcslice(2)
function f() {
    this["x"] = this["x"] = {}
}
new f()

asserts js debug shell on m-c changeset a37525d304d9 with --ion-eager at Assertion failure: needsBarrier_,

s-s and assuming sec-critical because this involves gc.

autoBisect shows this is probably related to the following changeset:

The first bad revision is:
changeset:   113229:6ba78023b367
user:        Brian Hackett
date:        Wed Nov 14 06:46:31 2012 -0800
summary:     Eagerly generate a single copy of Ion stubs and wrappers, bug 786146. r=dvander

Comment 1

[Brian Hackett [Laid off!]]

Attachment: patch

Oops, didn't notice that the preBarrier lazily generated on an IonCompartment uses the compartment itself.  This isn't necessary though, all it uses the compartment for is getting the barrier tracer, which is associated with the runtime itself.

Comment 2

[Brian Hackett [Laid off!]]

Bogus assert, not s-s.

Comment 3

[Andrew McCreight [:mccr8]]

Don't need to track a bogus assert.

Comment 4

[Brian Hackett [Laid off!]]

https://hg.mozilla.org/integration/mozilla-inbound/rev/74d500724519

Comment 5

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/mozilla-central/rev/74d500724519

Comment 6

[u279076]

Can/should the included testcase be put in-testsuite?

Comment 7

[Christian Holler (:decoder)]

Automatically extracted testcase for this bug was committed:

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

Comment 8

[Paul Silaghi, QA [:pauly]]

QA- based on comment 7