Closed Bug 701682 Opened 8 years ago Closed 8 years ago

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

Categories

(Core :: JavaScript Engine, defect, critical)

x86_64
Linux
defect
Not set
critical

Tracking

()

VERIFIED FIXED
mozilla11

People

(Reporter: decoder, Assigned: billm)

References

(Blocks 1 open bug)

Details

(Keywords: assertion, testcase, Whiteboard: js-triage-done)

Attachments

(3 files)

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

S-s for now due to GC relatedness.
Attached patch fixSplinter Review
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.
Assignee: general → wmccloskey
Status: NEW → ASSIGNED
Attachment #573967 - Flags: review?(bhackett1024)
Whiteboard: js-triage-needed → js-triage-done
(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.
Attachment #573967 - Flags: review?(bhackett1024)
Attached patch fix v2Splinter Review
Attachment #574345 - Flags: review?(bhackett1024)
Oops, I hit enter by accident.

You're right about the previous patch. It was just a write barrier problem.
Attachment #574345 - Flags: review?(bhackett1024) → review+
Status: ASSIGNED → RESOLVED
Closed: 8 years ago
Resolution: --- → FIXED
Status: RESOLVED → VERIFIED
Group: core-security
You need to log in before you can comment on or make changes to this bug.