701682 - Assertion failure: cell->compartment() == comp || cell->compartment() == comp->rt->atomsCompartment, at ../../gc/Barrier-inl.h:184

Status: VERIFIED FIXED

(Core :: JavaScript Engine, defect)

Description

[Christian Holler (:decoder)]

Attachment: shell testcase, unpack, chdir and run main.js with options "-n -m"

The attached test asserts on mozilla-central revision 50c1bcb49c76 (options -m -n).

S-s for now due to GC relatedness.

Comment 1

[Bill McCloskey [inactive unless it's an emergency] (:billm)]

Attachment: fix

Here's what was happening. Normally, if a dense array has dynamic slots, its fixed slots contain garbage and they're not scanned by the GC. During array slowification, they become scannable once we switch the class. We eventually overwrite them with good values, but there's an interval where the GC could see bad values. (The GC can be invoked here through the various add props, I think.)

This tripped an assert in the write barrier code, but I'm guessing it's been a bug for a while.

Comment 2

[Brian Hackett [Laid off!]]

(In reply to Bill McCloskey (:billm) from comment #1)
> Created attachment 573967 [details] [diff] [review] [diff] [details] [review]
> fix
> 
> Here's what was happening. Normally, if a dense array has dynamic slots, its
> fixed slots contain garbage and they're not scanned by the GC. During array
> slowification, they become scannable once we switch the class. We eventually
> overwrite them with good values, but there's an interval where the GC could
> see bad values. (The GC can be invoked here through the various add props, I
> think.)
> 
> This tripped an assert in the write barrier code, but I'm guessing it's been
> a bug for a while.

I don't think this diagnosis is right.  The GC only scans up to the object's slot span, and makeDenseArraySlow fills in the object slots immediately before updating the slot span, so the GC should never try to access those uninitialized slots.

Comment 3

[Bill McCloskey [inactive unless it's an emergency] (:billm)]

Attachment: fix v2

Comment 4

[Bill McCloskey [inactive unless it's an emergency] (:billm)]

Oops, I hit enter by accident.

You're right about the previous patch. It was just a write barrier problem.

Comment 5

[Bill McCloskey [inactive unless it's an emergency] (:billm)]

https://hg.mozilla.org/integration/mozilla-inbound/rev/920c5da54a5c

Comment 6

[Ian Melven :imelven]

from edmorley : https://hg.mozilla.org/mozilla-central/rev/920c5da54a5c