Closed Bug 908484 Opened 6 years ago Closed 6 years ago

Assertion failure: canCollect(),

Categories

(Core :: JavaScript Engine, defect, critical)

x86
macOS
defect
Not set
critical

Tracking

()

RESOLVED FIXED
mozilla26

People

(Reporter: mrbkap, Assigned: billm)

Details

(Keywords: assertion)

Attachments

(2 files)

Building b2g-desktop on OSX (debug enabled, optimize disabled) I've randomly been hitting: Assertion failure: canCollect()

I've verified with billm that Ion is on in this build configuration. I don't know what state is useful, so I'm attaching a full backtrace of all threads. I hope something in the information dump is useful.

This is very early in startup (possibly during component registration) on a new DESKTOP=1 gaia profile. I seem to only hit the assertion once in 

If there's anything in particular I should try to get the next time I hit this, let me know and I'll report back.
Attached patch can-collectSplinter Review
Thanks Blake.

There's a zone that's not the atoms zone where gcScheduled is set and it's an exclusive compartment. That's not supposed to happen. I'm guessing what's happening is that gcScheduled is set during StartOffThreadParseScript, in between the zone's creation and setting the usedByExclusiveThread flag. I had been thinking that the AutoSuppressGC would avoid this. However, the gcScheduled flag is set before we decide not to do the GC.

There are a couple ways we could fix this, but this way seems like the most direct to me.
Assignee: general → wmccloskey
Status: NEW → ASSIGNED
Attachment #794348 - Flags: review?(bhackett1024)
Attachment #794348 - Flags: review?(bhackett1024) → review+
https://hg.mozilla.org/mozilla-central/rev/b2fd03274543
Status: ASSIGNED → RESOLVED
Closed: 6 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla26
You need to log in before you can comment on or make changes to this bug.