If you think a bug might affect users in the 57 release, please set the correct tracking and status flags for Release Management.

shutdownhang in nsThread::Shutdown() on restart for applying update with nsUpdateDriver.cpp in the stack

RESOLVED WORKSFORME

Status

()

Toolkit
Application Update
--
critical
RESOLVED WORKSFORME
3 years ago
5 months ago

People

(Reporter: petruta, Unassigned)

Tracking

(Blocks: 1 bug, {crash})

unspecified
x86
Windows NT
crash
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(firefox38 affected, firefox-esr45 affected, firefox-esr52 unaffected)

Details

(crash signature)

(Reporter)

Description

3 years ago
This bug was filed from the Socorro interface and is 
report bp-11c9df42-0a82-4ace-a64c-fc2ba2150219.
=============================================================

I opened Nightly 38.0a1 2015-02-17 with a clean profile and went to Help:About to update it. After the update was downloaded, it crashed when I selected the "Restart Nightly to update button".
After reopening the build was updated to 2015-02-18.
Blocks: 1136891
No longer blocks: 1136891
Filed bug 1136891 for that same signature in ScopedXPCOMStartup::~ScopedXPCOMStartup() and this same crash signature appears in many other parts of the code outside of app update and startup.

Comment 2

3 years ago
We may want to add nsThread::Shutdown to our signature prefix list so that the next frame is appended (even if this makes the signatures really long). Would that help?
Summary: crash in shutdownhang | WaitForSingleObjectEx | WaitForSingleObject | PR_Wait | mozilla::ReentrantMonitor::Wait(unsigned int) | nsThread::ProcessNextEvent(bool, bool*) | NS_ProcessNextEvent(nsIThread*, bool) | nsThread::Shutdown() → shutdownhang in nsThread::Shutdown() on restart for applying update

Comment 3

3 years ago
I hit that crash 5 min ago after updating Nightly to the daily build:
https://crash-stats.mozilla.com/report/index/8bac0f48-8526-49a7-b5ba-ee45f2150320

Updated

2 years ago
Crash Signature: [@ shutdownhang | WaitForSingleObjectEx | WaitForSingleObject | PR_Wait | mozilla::ReentrantMonitor::Wait(unsigned int) | nsThread::ProcessNextEvent(bool, bool*) | NS_ProcessNextEvent(nsIThread*, bool) | nsThread::Shutdown()] → [@ shutdownhang | WaitForSingleObjectEx | WaitForSingleObject | PR_Wait | mozilla::ReentrantMonitor::Wait(unsigned int) | nsThread::ProcessNextEvent(bool, bool*) | NS_ProcessNextEvent(nsIThread*, bool) | nsThread::Shutdown()] [@ shutdownhang | Wai…

Comment 4

2 years ago
¡Hola Robert!

Should this one cover these as well?

Top beta crash #18 for the past week https://crash-stats.mozilla.com/report/list?product=Firefox&range_value=7&range_unit=days&date=2015-10-20&signature=shutdownhang+%7C+WaitForSingleObjectEx+%7C+WaitForSingleObject+%7C+PR_Wait+%7C+nsThread%3A%3AProcessNextEvent+%7C+NS_ProcessNextEvent+%7C+nsThread%3A%3AShutdown&version=Firefox%3A42.0b

Top beta crash #33 for the past week https://crash-stats.mozilla.com/report/list?product=Firefox&range_value=7&range_unit=days&date=2015-10-20&signature=shutdownhang+%7C+WaitForSingleObjectEx+%7C+WaitForSingleObject+%7C+PR_Wait+%7C+nsThread%3A%3AProcessNextEvent%28bool%2C+bool%2A%29+%7C+NS_ProcessNextEvent%28nsIThread%2A%2C+bool%29+%7C+mozilla%3A%3ASharedThreadPool%3A%3ASpinUntilEmpty%28%29&version=Firefox%3A42.0b

¡Gracias!
Flags: needinfo?(robert.strong.bugs)

Updated

2 years ago
Crash Signature: [@ shutdownhang | WaitForSingleObjectEx | WaitForSingleObject | PR_Wait | mozilla::ReentrantMonitor::Wait(unsigned int) | nsThread::ProcessNextEvent(bool, bool*) | NS_ProcessNextEvent(nsIThread*, bool) | nsThread::Shutdown()] [@ shutdownhang | Wai… → [@ shutdownhang | WaitForSingleObjectEx | WaitForSingleObject | PR_Wait | mozilla::ReentrantMonitor::Wait(unsigned int) | nsThread::ProcessNextEvent(bool, bool*) | NS_ProcessNextEvent(nsIThread*, bool) | nsThread::Shutdown()] [@ shutdownhang | Wai…
(In reply to alex_mayorga from comment #4)
> ¡Hola Robert!
> 
> Should this one cover these as well?
> 
> Top beta crash #18 for the past week
> https://crash-stats.mozilla.com/report/
> list?product=Firefox&range_value=7&range_unit=days&date=2015-10-
> 20&signature=shutdownhang+%7C+WaitForSingleObjectEx+%7C+WaitForSingleObject+%
> 7C+PR_Wait+%7C+nsThread%3A%3AProcessNextEvent+%7C+NS_ProcessNextEvent+%7C+nsT
> hread%3A%3AShutdown&version=Firefox%3A42.0b
I looked at the first 5 crashes on Win 7 (version with the highest percentage of crashes) for this link and only one of them was for this bug. Also, it appears that the root of this bug is actually outside of app update.

> Top beta crash #33 for the past week
> https://crash-stats.mozilla.com/report/
> list?product=Firefox&range_value=7&range_unit=days&date=2015-10-
> 20&signature=shutdownhang+%7C+WaitForSingleObjectEx+%7C+WaitForSingleObject+%
> 7C+PR_Wait+%7C+nsThread%3A%3AProcessNextEvent%28bool%2C+bool%2A%29+%7C+NS_Pro
> cessNextEvent%28nsIThread%2A%2C+bool%29+%7C+mozilla%3A%3ASharedThreadPool%3A%
> 3ASpinUntilEmpty%28%29&version=Firefox%3A42.0b
I looked at the first 5 crashes on Win 7 (version with the highest percentage of crashes) for this link and none of them are for this bug.
Flags: needinfo?(robert.strong.bugs)

Comment 6

2 years ago
A more recent example from nightly bp-ebe4979f-5aaa-416f-81d2-72d4a2160116
Thread 20 is the blocker.
http://hg.mozilla.org/mozilla-central/annotate/c33f30666b37/toolkit/xre/nsUpdateDriver.cpp#l1255
Blame patch is from quite old bug 307181

Comment 7

2 years ago
Note: bugs reports under the signature that are part of this will contain
nsUpdateProcessor
somewhere in the threads list.
Crash Signature: [@ shutdownhang | WaitForSingleObjectEx | WaitForSingleObject | PR_Wait | mozilla::ReentrantMonitor::Wait(unsigned int) | nsThread::ProcessNextEvent(bool, bool*) | NS_ProcessNextEvent(nsIThread*, bool) | nsThread::Shutdown()] [@ shutdownhang | Wai… → [@ shutdownhang | WaitForSingleObjectEx | WaitForSingleObject | PR_Wait | mozilla::ReentrantMonitor::Wait(unsigned int) | nsThread::ProcessNextEvent(bool, bool*) | NS_ProcessNextEvent(nsIThread*, bool) | nsThread::Shutdown()] [@ shutdownhang | Wai…

Updated

2 years ago
Duplicate of this bug: 1136891

Updated

2 years ago
Blocks: 1248837

Updated

a year ago
Depends on: 1296966

Updated

a year ago
Crash Signature: [@ shutdownhang | WaitForSingleObjectEx | WaitForSingleObject | PR_Wait | mozilla::ReentrantMonitor::Wait(unsigned int) | nsThread::ProcessNextEvent(bool, bool*) | NS_ProcessNextEvent(nsIThread*, bool) | nsThread::Shutdown()] [@ shutdownhang | Wai… → [@ shutdownhang | WaitForSingleObjectEx | WaitForSingleObject | PR_Wait | mozilla::ReentrantMonitor::Wait(unsigned int) | nsThread::ProcessNextEvent(bool, bool*) | NS_ProcessNextEvent(nsIThread*, bool) | nsThread::Shutdown()] [@ shutdownhang | Wai…
Jonathan, I went through several of the crash reports referenced by the crash signatures you associated to this bug and didn't find any of them associated to application update code. Can you provide a crash report that shows that association? Thanks!
Flags: needinfo?(jonathan)

Comment 10

a year ago
Only the bottom is the current relevant one for 49+, rest are historic.
Not going to occur on crash report from latest build, still no guarantee being old of matching this bug.

bp-67f685be-acff-4778-869d-4a4f02160906
bp-a3b7ade8-9363-4c93-beec-8f0c72160903

All you get out is that it is waiting for the update process to finish.
Flags: needinfo?(jonathan)
I ran intermittently into [@ shutdownhang | mozilla::CondVar::Wait | nsEventQueue::GetEvent | nsThread::ProcessNextEvent | mozilla::ipc::MessageChannel::AssertWorkerThread | mozilla::ipc::MessageChannel::ExitedCxxStack ] (https://crash-stats.mozilla.com/report/index/18f3c3df-aa97-46dc-ac0e-523f32161005) following these steps: 
1. Launch Firefox
2. Go to https://opentokrtc.com/ and enter in a call
3. Unplug the headset
4. Connect back the headset (the connection can't be restored even after refresh)
5. Restart the browser in order to reestablish the call (the browser doesn't restart; after ~1 min, Mozilla Crash Reporter shows up)
Is this signature related to this bug? 

I reproduced the crash on 50.0b4 (20161003155957), using Windows 8.1, Plantronics Audio 355 headset, Microsoft LifeCam HD 3000 / Logitech HD Pro Webcam C920 and the call peer using Windows 7 x64.
Flags: needinfo?(jonathan)
Iulia, please file a new bug. This one is specifically when restarting to apply an update.
Component: Application Update → XUL Widgets
Summary: shutdownhang in nsThread::Shutdown() on restart for applying update → shutdownhang in nsThread::Shutdown() on restart for applying update with nsUpdateDriver.cpp in the stack

Updated

a year ago
Flags: needinfo?(jonathan)
I'm marking this bug as WORKSFORME as bug crashlog signature didn't appear from a long time (over half year) in Firefox (except some obsolete Fx <50, no crashes starting since Fx 50).
Status: NEW → RESOLVED
Last Resolved: 6 months ago
status-firefox-esr45: --- → affected
status-firefox-esr52: --- → unaffected
Resolution: --- → WORKSFORME
Ups, my bad and due to ( bug #1348631 ) looks like there are sill crashes, so reopening.
Status: RESOLVED → REOPENED
Resolution: WORKSFORME → ---
Component: XUL Widgets → Application Update
Going back one week the only crashes I see related to this is on Win XP using Firefox Beta 49.0b5 and Aurora 49.0a2 both with the following signature
[@ shutdownhang | mozilla::CondVar::Wait | nsEventQueue::GetEvent | nsThread::ProcessNextEvent | NS_ProcessNextEvent | nsThread::Shutdown | nsThreadManager::Shutdown ]


https://crash-stats.mozilla.com/report/index/781e25dd-e14b-4ba3-98e9-981b72170417#allthreads

Going back two weeks I only see another week the only crashes I see related to app update are also on 49.x of which there were very few.

Since there are no recent crashes using anything greater than 49 with nsUpdateDriver.cpp or nsUpdateProcessor in the stack I'm marking this a wfm.
Status: REOPENED → RESOLVED
Last Resolved: 6 months ago5 months ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.