Browser hung after Flash updated in the background

VERIFIED WORKSFORME

Status

()

Core
Plug-ins
P2
critical
VERIFIED WORKSFORME
6 years ago
4 years ago

People

(Reporter: neil@parkwaycc.co.uk, Unassigned)

Tracking

({hang, reproducible})

17 Branch
x86
Windows XP
hang, reproducible
Points:
---
Bug Flags:
firefox-backlog +

Firefox Tracking Flags

(firefox17 wontfix, firefox18 wontfix, firefox19 wontfix, firefox20 wontfix, firefox-esr17 wontfix, firefox-esr24 ?)

Details

(Whiteboard: p=0 s=it-31c-30a-29b.3 [qa!])

(Reporter)

Description

6 years ago
+++ This bug was initially created as a clone of Bug #783263 +++

Adobe updated Flash (from 11.4 to 11.5) for me while the browser was open, but plugin-container got confused because it was still trying to load the old version. It asserted and quit, but the browser was hung and I had to kill it.
STR:
* install some Flash 11.4 version
* set dom.ipc.plugins.unloadASAP=true
* navigate to youtube or other flash using site
* navigate away from youtube or close tab
* install Flash 11.5 (used "install_flashXXX.exe -install -iv9")
* navigate to youtube

Triggered assertion:
http://hg.mozilla.org/mozilla-central/diff/7a4ca28274ab/dom/plugins/NPAPIPluginChild.cpp

Continuing leads to a hang with the following main thread stack:

    ntdll.dll!_NtWaitForSingleObject@12()  + 0x15 bytes
    ntdll.dll!_NtWaitForSingleObject@12()  + 0x15 bytes
    xul.dll!base::AtomicRefCountDecN(volatile int * ptr, int decrement)  Line 29 + 0xf bytes    C++
    kernel32.dll!_WaitForSingleObjectExImplementation@12()  + 0x43 bytes
    kernel32.dll!_WaitForSingleObject@8()  + 0x12 bytes
    nspr4.dll!_PR_MD_WAIT_CV(_MDCVar * cv, _MDLock * lock, unsigned int timeout)  Line 248 + 0x14 bytes    C
    nspr4.dll!_PR_WaitCondVar(PRThread * thread, PRCondVar * cvar, PRLock * lock, unsigned int timeout)  Line 172 + 0x17 bytes    C
    nspr4.dll!PR_WaitCondVar(PRCondVar * cvar, unsigned int timeout)  Line 515 + 0x17 bytes    C
    xul.dll!mozilla::CondVar::Wait(unsigned int interval)  Line 340 + 0x11 bytes    C++
    xul.dll!mozilla::Monitor::Wait(unsigned int interval)  Line 48    C++
    xul.dll!mozilla::MonitorAutoLock::Wait(unsigned int interval) Line 103    C++
xul.dll!mozilla::ipc::GeckoChildProcessHost::SyncLaunch(std::vector<std::basic_string<char,std::char_traits<char>,std::allocator<char> >,std::allocator<std::basic_string<char,std::char_traits<char>,std::allocator<char> > > > aExtraOpts, int aTimeoutMs, base::ProcessArchitecture arch)  Line 302    C++
    xul.dll!mozilla::plugins::PluginProcessParent::Launch(int timeoutMs)  Line 78 + 0x1e bytes    C++
    xul.dll!mozilla::plugins::PluginModuleParent::LoadModule(const char * aFilePath)  Line 81 + 0x1d bytes    C++
    xul.dll!GetNewPluginLibrary(nsPluginTag * aPluginTag)  Line 396 + 0x11 bytes    C++
    xul.dll!nsNPAPIPlugin::CreatePlugin(nsPluginTag * aPluginTag, nsNPAPIPlugin * * aResult)  Line 417 + 0x9 bytes    C++
    xul.dll!CreateNPAPIPlugin(nsPluginTag * aPluginTag, nsNPAPIPlugin * * aOutNPAPIPlugin)  Line 1662 + 0xd bytes    C++
    xul.dll!nsPluginHost::EnsurePluginLoaded(nsPluginTag * aPluginTag)  Line 1671 + 0x21 bytes    C++
    xul.dll!nsPluginHost::GetPlugin(const char * aMimeType, nsNPAPIPlugin * * aPlugin)  Line 1703 + 0xc bytes    C++
    xul.dll!nsPluginHost::TrySetUpPluginInstance(const char * aMimeType, nsIURI * aURL, nsPluginInstanceOwner * aOwner)  Line 1229    C++
    xul.dll!nsPluginHost::SetUpPluginInstance(const char * aMimeType, nsIURI * aURL, nsPluginInstanceOwner * aOwner) Line 1158 + 0x14 bytes    C++
    xul.dll!nsPluginHost::InstantiateEmbeddedPluginInstance(const char * aMimeType, nsIURI * aURL, nsObjectLoadingContent * aContent, nsPluginInstanceOwner * * aOwner)  Line 1019 + 0x1c bytes    C++
    xul.dll!nsObjectLoadingContent::InstantiatePluginInstance() Line 727 + 0x54 bytes    C++
    xul.dll!nsObjectLoadingContent::SyncStartPluginInstance()  Line 2249 + 0xb bytes    C++
    xul.dll!nsAsyncInstantiateEvent::Run()  Line 131    C++
    xul.dll!nsThread::ProcessNextEvent(bool mayWait, bool * result)  Line 627 + 0x19 bytes    C++
    xul.dll!NS_ProcessNextEvent_P(nsIThread * thread, bool mayWait)  Line 221 + 0x17 bytes    C++
xul.dll!mozilla::ipc::MessagePump::Run(base::MessagePump::Delegate * aDelegate)  Line 82 + 0xe bytes    C++
    xul.dll!MessageLoop::RunInternal()  Line 216    C++
    xul.dll!MessageLoop::RunHandler()  Line 209    C++
    xul.dll!MessageLoop::Run()  Line 183    C++
    xul.dll!nsBaseAppShell::Run()  Line 165    C++
    xul.dll!nsAppShell::Run()  Line 232 + 0x9 bytes    C++
    xul.dll!nsAppStartup::Run()  Line 291 + 0x1c bytes    C++
    xul.dll!XREMain::XRE_mainRun()  Line 3824 + 0x22 bytes    C++
    xul.dll!XREMain::XRE_main(int argc, char * * argv, const nsXREAppData * aAppData)  Line 3891 + 0x8 bytes    C++
    xul.dll!XRE_main(int argc, char * * argv, const nsXREAppData * aAppData, unsigned int aFlags)  Line 4089 + 0x17 bytes

Updated

6 years ago
Severity: major → critical
Keywords: reproducible
The behaviour in 17 is the same, i realized though that the browser only hangs until dom.ipc.plugins.timeoutSec elapses and then kills it. So we have two issues:
* apparently trying to use a plugin file that doesn't exist anymore
* we're waiting for the plugin-container even though that one should have erred out or crashed
Assignee: nobody → georg.fritzsche
Version: unspecified → 17 Branch
(In reply to Georg Fritzsche [:gfritzsche] from comment #1)
> Triggered assertion:
> http://hg.mozilla.org/mozilla-central/diff/7a4ca28274ab/dom/plugins/
> NPAPIPluginChild.cpp

... and that should have been: 
http://hg.mozilla.org/mozilla-central/diff/7a4ca28274ab/dom/plugins/NPAPIPluginChild.cpp#l1.95
status-firefox17: --- → affected
status-firefox18: --- → affected
status-firefox19: --- → affected
status-firefox20: --- → affected
status-firefox-esr17: --- → affected
tracking-firefox18: --- → ?
tracking-firefox19: --- → ?
tracking-firefox20: --- → ?
tracking-firefox-esr17: --- → ?

Comment 4

6 years ago
Are you suggesting that there has been a recent Firefox regression that makes this behavior worse than previously? If not, we don't need to track for upcoming releases. We'd instead uplift a low risk solution when ready, however.
(In reply to Alex Keybl [:akeybl] from comment #4)
> Are you suggesting that there has been a recent Firefox regression that
> makes this behavior worse than previously? If not, we don't need to track
> for upcoming releases. We'd instead uplift a low risk solution when ready,
> however.

Ok, sorry. Shouldn't i nominate for tracking for existing bugs/issues too?
I'm assuming this to not be a Firefox regression and instead be caused by a behavioral change of the Flash installer (the one that lead to bug 686335).
tracking-firefox18: ? → ---
tracking-firefox19: ? → ---
tracking-firefox20: ? → ---
tracking-firefox-esr17: ? → ---

Comment 6

6 years ago
We don't normally track issues for specific releases unless they are a regression in that release or otherwise affect lots of users. This bug is likely pretty unusual; we should fix it, but it's not something release drivers need to track.
(Reporter)

Comment 7

6 years ago
(In reply to Georg Fritzsche from comment #2)
> The behaviour in 17 is the same, i realized though that the browser only
> hangs until dom.ipc.plugins.timeoutSec elapses and then kills it.
Bah, debug builds don't have a timeout, so I have to kill the process :-(
(In reply to neil@parkwaycc.co.uk from comment #7)
> (In reply to Georg Fritzsche from comment #2)
> > The behaviour in 17 is the same, i realized though that the browser only
> > hangs until dom.ipc.plugins.timeoutSec elapses and then kills it.
> Bah, debug builds don't have a timeout, so I have to kill the process :-(

Hm, i think the process-killing for out-of-process-plugins should be the same in debug builds (should be dom.ipc.plugins.processLaunchTimeoutSecs though, not timeoutSec as this happens while launching the child process).

Comment 9

6 years ago
http://hg.mozilla.org/mozilla-central/annotate/43d65f5d22b2/modules/libpref/src/init/all.js#l1778 disables the timeout in debug builds on the theory that if you're running a debug build, you're capable of using a debugger or profiler to help figure out what's going on.
(Reporter)

Comment 10

6 years ago
Sure, I can find out what's happened, but there's no way of recovering.
Priority: -- → P2
Assignee: georg.fritzsche → nobody
Flags: firefox-backlog?

Updated

4 years ago
Flags: firefox-backlog? → firefox-backlog+
Hi Anthony, could you verify if this bug is still an issue?  It was reviewed in the Desktop estimation meeting and noted it may be resolved.
Flags: needinfo?(anthony.s.hughes)
Whiteboard: [qa?]
Paul, can you please test this to see if it reproduces? Thanks.
status-firefox17: affected → wontfix
status-firefox18: affected → wontfix
status-firefox19: affected → wontfix
status-firefox20: affected → wontfix
status-firefox28: --- → ?
status-firefox29: --- → ?
status-firefox30: --- → ?
status-firefox31: --- → ?
status-firefox-esr17: affected → wontfix
status-firefox-esr24: --- → ?
Flags: needinfo?(anthony.s.hughes)
Keywords: qawanted
QA Contact: paul.silaghi
Whiteboard: [qa?]
(In reply to Georg Fritzsche [:gfritzsche] from comment #1)
> STR:
> * install some Flash 11.4 version
> * set dom.ipc.plugins.unloadASAP=true
> * navigate to youtube or other flash using site
> * navigate away from youtube or close tab
> * install Flash 11.5 (used "install_flashXXX.exe -install -iv9")
> * navigate to youtube
Couldn't reproduce any hang by updating Flash 12.0.0.77 to 13.0.0.182, both on Win XP x86 and Win 7 x64, Nightly 31.0a1(2014-04-14).
Thanks Paul.
Status: NEW → RESOLVED
Last Resolved: 4 years ago
Resolution: --- → WORKSFORME

Updated

4 years ago
Status: RESOLVED → VERIFIED
Whiteboard: p=0 s=it-31c-30a-29b.3 [qa+]
status-firefox28: ? → ---
status-firefox29: ? → ---
status-firefox30: ? → ---
status-firefox31: ? → ---
Keywords: qawanted
Whiteboard: p=0 s=it-31c-30a-29b.3 [qa+] → p=0 s=it-31c-30a-29b.3 [qa!]
You need to log in before you can comment on or make changes to this bug.