Closed Bug 1134620 Opened 10 years ago Closed 8 years ago

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

Categories

(Toolkit :: Application Update, defect)

Product:
Toolkit
Component:
Application Update
Platform:
x86
Windows NT
Type:
defect
Priority:
Not set
Severity:
critical

Tracking

()

Status:
RESOLVED WORKSFORME
Tracking Flags:
Tracking Status
firefox38 --- affected
firefox-esr45 --- affected
firefox-esr52 --- unaffected

People

(Reporter: phorea, Unassigned)

References

Details

(Keywords: crash)

Crash Data

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.
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.
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
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
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 | WaitForSin…
Crash Signature: , bool) | nsThread::Shutdown()] [@ shutdownhang | WaitForSingleObjectEx | WaitForSingleObject | PR_Wait | mozilla::ReentrantMonitor::Wait | nsThread::ProcessNextEvent | NS_ProcessNextEvent | nsThread::Shutdown] → , bool) | nsThread::Shutdown()] [@ shutdownhang | WaitForSingleObjectEx | WaitForSingleObject | PR_Wait | mozilla::ReentrantMonitor::Wait | nsThread::ProcessNextEvent | NS_ProcessNextEvent | nsThread::Shutdown] [@ shutdownhang | WaitForSingleObjectEx | …
(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)
Note: bugs reports under the signature that are part of this will contain nsUpdateProcessor somewhere in the threads list.
Crash Signature: WaitForSingleObject | PR_Wait | nsThread::ProcessNextEvent | NS_ProcessNextEvent | nsThread::Shutdown] → WaitForSingleObject | PR_Wait | nsThread::ProcessNextEvent | NS_ProcessNextEvent | nsThread::Shutdown] [@ shutdownhang | WaitForSingleObjectEx | WaitForSingleObject | PR_WaitCondVar | nsThread::ProcessNextEvent | NS_ProcessNextEvent | nsThread::Shutdown…
Blocks: 1248837
Depends on: 1296966
Crash Signature: nsThread::ProcessNextEvent | nsThread::Shutdown] → nsThread::ProcessNextEvent | nsThread::Shutdown] [@ shutdownhang | mozilla::CondVar::Wait | nsEventQueue::GetEvent | nsThread::ProcessNextEvent | NS_ProcessNextEvent | nsThread::Shutdown | nsThreadManager::Shutdown ]
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)
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
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
Closed: 8 years 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
Closed: 8 years ago → 8 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.