Open Bug 906001 Opened 6 years ago Updated 11 months ago

Intermittent PROCESS-CRASH | application crashed [@ js::gc::ArenaLists::allocateFromArenaInline(JS::Zone*, js::gc::AllocKind)][@ JS::Zone::runtimeFromMainThread()] after Assertion failure: CurrentThreadCanAccessRuntime(runtime_), js/src/gc/Zone.h:118

Categories

(Core :: JavaScript Engine, defect, P3, critical)

26 Branch
defect

Tracking

()

People

(Reporter: cbook, Unassigned)

References

()

Details

(Keywords: assertion, crash, intermittent-failure, Whiteboard: [leave open])

Attachments

(2 files)

Rev3 Fedora 12x64 mozilla-inbound debug test mochitest-browser-chrome on 2013-08-16 04:39:13 PDT for push 106dba161a79

slave: talos-r3-fed64-064

https://tbpl.mozilla.org/php/getParsedLog.php?id=26633180&tree=Mozilla-Inbound

Assertion failure: CurrentThreadCanAccessRuntime(runtime_), at ../../../js/src/gc/Zone.h:118
Brian could this be related to bug 897655 maybe? Just a wild guess based on the JS changes that landed recently.
Flags: needinfo?(bhackett1024)
https://tbpl.mozilla.org/php/getParsedLog.php?id=26621515&tree=Mozilla-Inbound
Summary: Assertion failure: CurrentThreadCanAccessRuntime(runtime_), at ../../../js/src/gc/Zone.h:118 → Intermittent PROCESS-CRASH | application crashed [@ js::gc::ArenaLists::allocateFromArenaInline(JS::Zone*, js::gc::AllocKind)] after Assertion failure: CurrentThreadCanAccessRuntime(runtime_), at ../../../js/src/gc/Zone.h:118
https://tbpl.mozilla.org/php/getParsedLog.php?id=26630039&tree=Mozilla-Inbound
Severity: normal → critical
Keywords: crash
OS: Linux → All
Hardware: x86 → All
Summary: Intermittent PROCESS-CRASH | application crashed [@ js::gc::ArenaLists::allocateFromArenaInline(JS::Zone*, js::gc::AllocKind)] after Assertion failure: CurrentThreadCanAccessRuntime(runtime_), at ../../../js/src/gc/Zone.h:118 → Intermittent PROCESS-CRASH | application crashed [@ js::gc::ArenaLists::allocateFromArenaInline(JS::Zone*, js::gc::AllocKind)][@ JS::Zone::runtimeFromMainThread()] after Assertion failure: CurrentThreadCanAccessRuntime(runtime_), js/src/gc/Zone.h:118
Attached patch potential patchSplinter Review
The stack that I looked at seemed to indicate we were allocating from an atoms zone on which a GC has started.  The atoms zone can't be collected from while off thread parsing is going on, and while we check for this when triggering the parse there isn't anything I can see to prevent the collection from starting while the parse is in progress.
Attachment #791474 - Flags: review?(wmccloskey)
Flags: needinfo?(bhackett1024)
Comment on attachment 791474 [details] [diff] [review]
potential patch

I thought there was some other way to prevent this, but maybe not.
Attachment #791474 - Flags: review?(wmccloskey) → review+
Attached patch round 2Splinter Review
Hmm, there still might be some gaps here, we can trigger an off thread parse when the atoms zone wasGCStarted() or isGCScheduled() but not needsBarrier().  I don't know if that is actually possible, but if it is then this patch should handle the case.  If not, this also adds enough assertions to ensure that we at least bust an assert somewhere else in a spot that should be easier to debug.
Attachment #791609 - Flags: review?(wmccloskey)
Comment on attachment 791609 [details] [diff] [review]
round 2

Review of attachment 791609 [details] [diff] [review]:
-----------------------------------------------------------------

This looks good. Sorry I didn't catch the fact earlier that needsBarrier is insufficient.
Attachment #791609 - Flags: review?(wmccloskey) → review+
Assignee: general → nobody
Bulk assigning P3 to all open intermittent bugs without a priority set in Firefox components per bug 1298978.
Priority: -- → P3
You need to log in before you can comment on or make changes to this bug.