1544412 - Crash in [@ shutdownhang | nsThread::Shutdown | `anonymous namespace'::IPCLaunchThreadObserver::Observe]

Status: RESOLVED WORKSFORME

(Core :: IPC, defect, P5)

Description

[[:philipp]]

This bug is for crash report bp-d4a479ac-cab0-4697-a986-4f1d50190415.

Top 10 frames of crashing thread:

0 ntdll.dll KiFastSystemCallRet 
1 ntdll.dll NtWaitForKeyedEvent 
2 ntdll.dll RtlSleepConditionVariableSRW 
3 kernel32.dll SleepConditionVariableSRW 
4 mozglue.dll mozilla::detail::ConditionVariableImpl::wait mozglue/misc/ConditionVariable_windows.cpp:50
5 xul.dll struct already_AddRefed<nsIRunnable> mozilla::ThreadEventQueue<mozilla::PrioritizedEventQueue<mozilla::EventQueue> >::GetEvent xpcom/threads/ThreadEventQueue.cpp:149
6 xul.dll nsThread::ProcessNextEvent xpcom/threads/nsThread.cpp:1107
7 xul.dll NS_ProcessNextEvent xpcom/threads/nsThreadUtils.cpp:482
8 xul.dll nsThread::Shutdown xpcom/threads/nsThread.cpp:880
9 xul.dll nsresult `anonymous namespace'::IPCLaunchThreadObserver::Observe ipc/glue/GeckoChildProcessHost.cpp:526

this shutdownhang signature is hitting firefox windows users since firefox 67 (currently with rather low volume on beta though) - that's presumably due to the changes from bug 1487287.
32bit installations seem to be over-represented in this crash signature.

Comment 1

[Gian-Carlo Pascutto [:gcp]]

This signature can happen if launching a new process takes a very long time (or never finishes), and then we go into shutdown. These are prone to happen together because a user might notice the browsers' new tabs aren't doing anything and then tries to relaunch the browser to fix it.

Because async launch changed how process launch looks, this is likely an existing problem/hang that's now in a different signature because the thread that hangs is different.

Comment 2

[Neha Kochar [:neha]]

Marking fix-optional for 67 (beta cycle) per comment 1.

Comment 3

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

Closing because no crashes reported for 12 weeks.