Closed
Bug 1488091
Opened 6 years ago
Closed 11 months ago
Crash in shutdownhang | nsThread::Shutdown | nsThreadPool::Shutdown
Categories
(Core :: XPCOM, defect)
Tracking
()
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.
Comment 1•6 years ago
|
||
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.
status-firefox62:
--- → affected
status-firefox63:
--- → affected
status-firefox64:
--- → affected
status-firefox-esr60:
--- → affected
OS: Windows 10 → Windows
Reporter | ||
Comment 2•6 years ago
|
||
(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 ...
Comment 4•6 years ago
|
||
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)
Updated•6 years ago
|
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)
Updated•5 years ago
|
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]
status-firefox65:
--- → affected
status-firefox66:
--- → affected
Updated•3 years ago
|
Whiteboard: qa-not-actionable
Updated•2 years ago
|
Severity: critical → S2
Comment 6•11 months ago
|
||
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.
Description
•