1650348 - Crash in [@ IPCError-browser | ShutDownKill | mozilla::TaskController::GetRunnableForMTTask]

Status: RESOLVED FIXED

(Core :: XPCOM, defect)

Description

[Simon Giesecke [:sg] [he/him]]

This bug is for crash report bp-5d6da799-4b47-4187-acda-f810c0200703.

Top 10 frames of crashing thread:

0 ntdll.dll NtWaitForAlertByThreadId 
1 ntdll.dll RtlSleepConditionVariableSRW 
2 kernelbase.dll SleepConditionVariableSRW 
3 mozglue.dll mozilla::detail::ConditionVariableImpl::wait mozglue/misc/ConditionVariable_windows.cpp:50
4 xul.dll mozilla::TaskController::GetRunnableForMTTask xpcom/threads/TaskController.cpp:242
5 xul.dll nsThread::ProcessNextEvent xpcom/threads/nsThread.cpp:1148
6 xul.dll mozilla::ipc::MessagePump::Run ipc/glue/MessagePump.cpp:109
7 xul.dll MessageLoop::RunHandler ipc/chromium/src/base/message_loop.cc:327
8 xul.dll MessageLoop::Run ipc/chromium/src/base/message_loop.cc:309
9 xul.dll nsBaseAppShell::Run widget/nsBaseAppShell.cpp:137

This seems to have started with landing https://phabricator.services.mozilla.com/D74673, nightly build id 20200701093012.

Comment 1

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

Set release status flags based on info from the regressing bug 1606706

Comment 2

[Bas Schouten (:bas.schouten)]

This is not a new crash but just because the intermediate stack frame changed, not sure what the 'old equivalent bug' is, having a hard time figuring out how to search for it in crash stats :).

Comment 3

[Jim Mathies [:jimm]]

content shutdown hang reports.

Comment 4

[Marco Zehe (:MarcoZ)]

I was able to reproduce this crash with NVDA using the steps in this Github issue. My crash report is:
bp-1e9221ac-bcac-415a-b4bb-129a10200708

Jamie, this may or may not be related to bug 1650590. It also is a content process crash, but unlike the other, it generates crash reports.

Comment 5

[jongund]

Here is another potential example for the bug in the ARIA Authoring practices example for a combobox date picker ARIA APG issue 1440:

Comment 6

[James Teh [:Jamie]]

My patch for bug 1650590 does appear to fix this.

Comment 7

[Marco Zehe (:MarcoZ)]

This is fixed by bug 1650590, confirmed in Firefox Nightly 80.0a1 (20200709213735).

Comment 8

[Marco Zehe (:MarcoZ)]

Bug 1650590 has landed on beta and will be in 79.0b6.

Comment 9

[Marco Zehe (:MarcoZ)]

Verified that the fix landed properly on 79.0b6. The above mentioned test case no longer crashes in 79.0b6 with both NVDA and JAWS.

Comment 10

[Pascal Chevrel:pascalc (PTO until April 26)]

I am not seeing a decrease of crashes with this signature since the patch landed on Nightly 6 days ago, it is on the contrary increasing with +200 crashes per day.

Comment 11

[Simon Giesecke [:sg] [he/him]]

Yes, this still happens on recent Nightly builds. Maybe there are different root causes for this?

Comment 12

[Marco Zehe (:MarcoZ)]

Possibly. The situation that caused crashes with this signature for me, are definitely fixed by bug 1650590. But perhaps there are other areas of the Windows IPC code that AccessibleHandler doesn't touch, that uses the wrong MemAlloc/MemFree combination in some circumstances. Feel free to take some leads from the patch and comment in bug 1650590.

Comment 13

[James Teh [:Jamie]]

I don't think this crash necessarily relates to memory corruption at all or even Windows IPC. I'm not familiar with the task scheduler code, but I'm guessing this is a generic signature for a content process hang where the main thread was last waiting for a task; i.e. the hang occurred for some reason other than the main thread getting stuck. The fix discussed in comment 4, comment 6, etc. deals with an a11y specific instance of this. Clearly, there are other instances.