Closed Bug 1488091 Opened 6 years ago Closed 11 months ago

Crash in shutdownhang | nsThread::Shutdown | nsThreadPool::Shutdown

Categories

(Core :: XPCOM, defect)

Unspecified
Windows
defect

Tracking

()

RESOLVED INCOMPLETE
Tracking Status
firefox-esr60 --- affected
firefox62 --- wontfix
firefox63 --- wontfix
firefox64 --- wontfix
firefox65 --- affected
firefox66 --- affected

People

(Reporter: gsvelto, Unassigned)

Details

(Keywords: crash, Whiteboard: qa-not-actionable)

Crash Data

This bug was filed from the Socorro interface and is
report bp-5e37ca85-f41c-4f05-9e19-539f60180902.
=============================================================

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:58
4 xul.dll mozilla::CondVar::Wait xpcom/threads/CondVar.h:66
5 xul.dll mozilla::ThreadEventQueue<mozilla::PrioritizedEventQueue<mozilla::EventQueue> >::GetEvent xpcom/threads/ThreadEventQueue.cpp:155
6 xul.dll nsThread::ProcessNextEvent xpcom/threads/nsThread.cpp:994
7 xul.dll NS_ProcessNextEvent xpcom/threads/nsThreadUtils.cpp:519
8 xul.dll nsThread::Shutdown xpcom/threads/nsThread.cpp:810
9 xul.dll nsThreadPool::Shutdown xpcom/threads/nsThreadPool.cpp:345

=============================================================

Filing this because we don't have a bug for this shutdown hang signature yet. Many reports seem to have this a little further up in the stack so it could be network-related:

https://hg.mozilla.org/releases/mozilla-release/annotate/975058795980dfbba1daedfe5fc82d1abcb5638b/netwerk/base/nsStreamTransportService.cpp#l309

I'm filing under general because this does not cover all the stack traces so there might be more to this one.
Is this a generic shutdown hang signature? My friend hits this shutdown hang in nsStreamTransportService.cpp every day in Firefox 62. I'm waiting to hear whether Firefox Safe Mode fixes the hang.

bp-b270eb0e-8338-4d2c-94b9-aa4560180917
bp-90e71b34-d63f-4100-81f4-8d93f0180913

This signature appears only Windows (unless that's just an artifact of the signature name mangling). All Windows versions are affected.
OS: Windows 10 → Windows
(In reply to Chris Peterson [:cpeterson] from comment #1)
> Is this a generic shutdown hang signature? My friend hits this shutdown hang
> in nsStreamTransportService.cpp every day in Firefox 62. I'm waiting to hear
> whether Firefox Safe Mode fixes the hang.
> 
> bp-b270eb0e-8338-4d2c-94b9-aa4560180917
> bp-90e71b34-d63f-4100-81f4-8d93f0180913
> 
> This signature appears only Windows (unless that's just an artifact of the
> signature name mangling). All Windows versions are affected.

The signature is fairly generic but those two crashes have similar stacks to the first ones I encountered. One interesting tidbit is thread 22: it's trying to open a file to save the preferences. Maybe we're getting stuck in I/O while shutting down and we detect it as a hang and crash. Nicholas, do you think that'll be possible? The stack in that thread looks like this:


0 	ntdll.dll 	NtCreateFile 	
1 	KERNELBASE.dll 	CreateDirectoryW 	
2 	xul.dll 	nsLocalFile::Create(unsigned int, unsigned int) 	xpcom/io/nsLocalFileWin.cpp:1280
3 	xul.dll 	nsLocalFile::CreateUnique(unsigned int, unsigned int) 	xpcom/io/nsLocalFileCommon.cpp:153
4 	xul.dll 	nsAtomicFileOutputStream::DoOpen() 	netwerk/base/nsFileStreams.cpp:843
5 	xul.dll 	nsFileStreamBase::MaybeOpen(nsIFile*, int, int, bool) 	netwerk/base/nsFileStreams.cpp:317
6 	xul.dll 	NS_NewSafeLocalFileOutputStream(nsIOutputStream**, nsIFile*, int, int, int) 	netwerk/base/nsNetUtil.cpp:1458
7 	xul.dll 	mozilla::PreferencesWriter::Write(nsIFile*, nsTArray<nsTString<char> >&) 	modules/libpref/Preferences.cpp:2720
8 	xul.dll 	mozilla::PWRunnable::Run() 	modules/libpref/Preferences.cpp:2815
9 	xul.dll 	nsThreadPool::Run() 	xpcom/threads/nsThreadPool.cpp:231
10 	xul.dll 	nsThread::ProcessNextEvent(bool, bool*) 	xpcom/threads/nsThread.cpp:1051
...
Forgot the NI?, see comment 2.
Flags: needinfo?(n.nethercote)
Maybe? PreferencesWriter::Write() creates a new temporary file, saves the data to it, and if that succeeded, it overwrites the prefs file. The stack in comment 2 is in the middle of creating that temporary file.
Flags: needinfo?(n.nethercote)
Component: General → XPCOM
(In reply to Gabriele Svelto [:gsvelto] from comment #2)
> The signature is fairly generic but those two crashes have similar stacks to
> the first ones I encountered. One interesting tidbit is thread 22: it's
> trying to open a file to save the preferences. Maybe we're getting stuck in
> I/O while shutting down and we detect it as a hang and crash. Nicholas, do
> you think that'll be possible? The stack in that thread looks like this:

That is similar to what's happening in bug 1498782.
We could try using the same approach here (using nsIThreadPool.shutdownWithTimeout - bug 1500861)
Crash Signature: [@ shutdownhang | nsThread::Shutdown | nsThreadPool::Shutdown] → [@ shutdownhang | nsThread::Shutdown | nsThreadPool::Shutdown] [@ shutdownhang | ntdll.dll | nsThread::Shutdown | nsThreadPool::Shutdown] [@ shutdownhang | ntdll.dll | kernel32.dll | nsThread::Shutdown | nsThreadPool::Shutdown]
Whiteboard: qa-not-actionable
Severity: critical → S2

The signature here probably changed when I changed how nsThreadPool::Shutdown is implemented in bug 1747526, meaning that if this issue still exists, it should have a different signature going forward.

Status: NEW → RESOLVED
Closed: 11 months ago
Resolution: --- → INCOMPLETE
You need to log in before you can comment on or make changes to this bug.