1691230 - Crash in [@ IPCError-browser | ShutDownKill | mozilla::CycleCollectedJSContext::PerformMicroTaskCheckPoint]

Status: RESOLVED WORKSFORME

(Core :: XPCOM, defect)

Description

[alex_mayorga]

Maybe Fission related. (DOMFissionEnabled=1)

Crash report: https://crash-stats.mozilla.org/report/index/0db001c6-44a6-4131-a81b-28e8f0210206

Reason: EXCEPTION_BREAKPOINT

Top 10 frames of crashing thread:

0 xul.dll mozilla::CycleCollectedJSContext::PerformMicroTaskCheckPoint xpcom/base/CycleCollectedJSContext.cpp:585
1 xul.dll XPCJSContext::AfterProcessTask js/xpconnect/src/XPCJSContext.cpp:1471
2 xul.dll nsThread::ProcessNextEvent xpcom/threads/nsThread.cpp:1195
3 xul.dll mozilla::ipc::MessagePump::Run ipc/glue/MessagePump.cpp:109
4 xul.dll MessageLoop::RunHandler ipc/chromium/src/base/message_loop.cc:328
5 xul.dll MessageLoop::Run ipc/chromium/src/base/message_loop.cc:310
6 xul.dll nsBaseAppShell::Run widget/nsBaseAppShell.cpp:137
7 xul.dll nsAppShell::Run widget/windows/nsAppShell.cpp:602
8 xul.dll XRE_RunAppShell toolkit/xre/nsEmbedFunctions.cpp:902
9 xul.dll MessageLoop::RunHandler ipc/chromium/src/base/message_loop.cc:328

Comment 1

[Chris Peterson [:cpeterson]]

This is not a Fission bug. Out of almost a thousand crash reports over the last six months, only two had Fission enabled.

Comment 2

[Jed Davis [:jld] ⟨⏰|UTC-7⟩ ⟦he/him⟧]

I don't know if this is the root cause for why the content process fails to finish shutting down before the ShutDownKill timer fires, but I notice several JS Helper threads busily parsing JS.

Comment 3

[BugBot [:suhaib / :marco/ :calixte]]

The component has been changed since the backlog priority was decided, so we're resetting it.
For more information, please visit auto_nag documentation.

Comment 4

[Nicolas B. Pierron [:nbp]]

(In reply to Jed Davis [:jld] ⟨⏰|UTC-7⟩ ⟦he/him⟧ from comment #2)

I don't know if this is the root cause for why the content process fails to finish shutting down before the ShutDownKill timer fires, but I notice several JS Helper threads busily parsing JS.

To be precise, here is one crash where this can be observed:
https://crash-stats.mozilla.org/report/index/0db001c6-44a6-4131-a81b-28e8f0210206#tab-rawdump

Where 2 JS Helper threads are running under js::Frontend::BytecodeEmitter::emitTree.
These helper threads parsing tasks are triggered when loading a document.

Based on the low volume, this is unlikely to be a priority.
However, I will still ask Tooru whether one of the stacks reported in the mini-dump suggest one location which could have a loop by not advancing the tree traversal.

Comment 5

[Andrew McCreight [:mccr8]]

The crash report in comment 4 has a IPCShutdownState value of "SendFinishShutdown (sent)", so at least in theory we could detect that we've about to shutdown and change our behavior because of it.

Comment 6

[Tooru Fujisawa [:arai]]

I don't see much correlation with BytecodeEmitter here. (only one crash so far?)
I'll wait for more reports.

Comment 7

[Nicolas B. Pierron [:nbp]]

(In reply to Tooru Fujisawa [:arai] from comment #6)

I don't see much correlation with BytecodeEmitter here. (only one crash so far?)
I'll wait for more reports.

This is a shutdown kill, which likely means that some things were holding the program from shutting down or that the shutdown was taking too long. Therefore, this is by looking at other threads and not only the crashing thread that I noticed multiple JS Helper threads running with the Bytecode emitter.

However, I agree, I do not see any threads with the BytecodeEmitter in newer crashes.

Forwarding this bug to the XPCOM component.

Comment 8

[BugBot [:suhaib / :marco/ :calixte]]

Closing because no crashes reported for 12 weeks.