1616082 - Crash in [@ shutdownhang | nsThread::Shutdown | mozilla::net::WaitForThreadShutdown::Run | nsThread::Shutdown | ProfileResetCleanupResultTask::Run]

Status: RESOLVED WORKSFORME

(Core :: Networking, defect, P3)

Description

[[:philipp]]

This bug is for crash report bp-d382e5c5-3e32-4941-a573-a63a30200217.

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::ThreadEventQueue<mozilla::PrioritizedEventQueue>::GetEvent xpcom/threads/ThreadEventQueue.cpp:208
5 xul.dll nsThread::ProcessNextEvent xpcom/threads/nsThread.cpp:1140
6 xul.dll NS_ProcessNextEvent xpcom/threads/nsThreadUtils.cpp:486
7 xul.dll nsThread::Shutdown xpcom/threads/nsThread.cpp:909
8 xul.dll mozilla::net::WaitForThreadShutdown::Run netwerk/base/nsPACMan.cpp:161
9 xul.dll nsThread::ProcessNextEvent xpcom/threads/nsThread.cpp:1220

these shutdownhang signatures are starting to show up from windows builds since firefox 74. based on the stack or circumstantial evidence i couldn't find any obvious regressing bug that might have triggered this.

Comment 1

[Eric Rahm [:erahm]]

It looks like Sophos has something like 10 threads injected in our process, I'd guess that has something to do with what's going on.

Comment 2

[[:philipp]]

there are other reports with no apparent 3rd party interference as well though, like bp-b1e65f1c-27e2-4f5c-88fa-52efb0200216

Comment 3

[Eric Rahm [:erahm]]

(In reply to [:philipp] from comment #2)

there are other reports with no apparent 3rd party interference as well though, like bp-b1e65f1c-27e2-4f5c-88fa-52efb0200216

Fair enough. It looks like those both have PAC stuff on the stack and the ProxyResolution thread is out in InternetGetConnectedStateExW. Do you see this correlation with other reports?

Comment 4

[[:philipp]]

i sifted through a number of reports - PAC stuff is usually on the stack for the [@ shutdownhang | nsThread::Shutdown | mozilla::net::WaitForThreadShutdown::Run | nsThread::Shutdown | ProfileResetCleanupResultTask::Run] signature, otoh i couldn't spot it in any of the [@ shutdownhang | nsThread::Shutdown | ProfileResetCleanupResultTask::Run] crashes.

Comment 5

[Ethan Tseng [:ethan]]

Nathan, could you triage this bug? Thanks!

Comment 6

[Nathan Froyd [:froydnj]]

Looks like something going wrong with proxy auto-config, redirecting to networking.

Comment 7

[Pascal Chevrel:pascalc]

Volume of crashes is medium-low and decreasing since beta7, wontfix for 74.

Comment 8

[Honza Bambas (:mayhemer)]

This is NOT a new regression, just the signature has changed somehow and popped up. Searching for the mozilla::net::WaitForThreadShutdown::Run signature on the main thread, which is the point we wait for the PAC thread to finish, shows this shutdown crash is long existing. I nearly always find the PAC thread being inside InternetGetConnectedStateExW. That function is known to be problematic, see bug 1366133.

Comment 9

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

Closing because no crashes reported for 12 weeks.