Closed
Bug 821252
Opened 12 years ago
Closed 10 years ago
Browser hung after Flash updated in the background
Categories
(Core Graveyard :: Plug-ins, defect, P2)
Tracking
(firefox17 wontfix, firefox18 wontfix, firefox19 wontfix, firefox20 wontfix, firefox-esr17 wontfix, firefox-esr24 ?)
People
(Reporter: neil, Unassigned)
Details
(Keywords: hang, reproducible, Whiteboard: p=0 s=it-31c-30a-29b.3 [qa!])
+++ 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.
Comment 1•12 years ago
|
||
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•12 years ago
|
Severity: major → critical
Keywords: reproducible
Comment 2•12 years ago
|
||
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
Comment 3•12 years ago
|
||
(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
Updated•12 years ago
|
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•12 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.
Comment 5•12 years ago
|
||
(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).
Updated•12 years ago
|
tracking-firefox18:
? → ---
tracking-firefox19:
? → ---
tracking-firefox20:
? → ---
tracking-firefox-esr17:
? → ---
Comment 6•12 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•11 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 :-(
Comment 8•11 years ago
|
||
(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•11 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•11 years ago
|
||
Sure, I can find out what's happened, but there's no way of recovering.
Updated•11 years ago
|
Priority: -- → P2
Updated•10 years ago
|
Assignee: georg.fritzsche → nobody
Flags: firefox-backlog?
Updated•10 years ago
|
Flags: firefox-backlog? → firefox-backlog+
Comment 11•10 years ago
|
||
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?]
Comment 12•10 years ago
|
||
Paul, can you please test this to see if it reproduces? Thanks.
status-firefox28:
--- → ?
status-firefox29:
--- → ?
status-firefox30:
--- → ?
status-firefox31:
--- → ?
status-firefox-esr24:
--- → ?
Flags: needinfo?(anthony.s.hughes)
Keywords: qawanted
QA Contact: paul.silaghi
Whiteboard: [qa?]
Comment 13•10 years ago
|
||
(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).
Comment 14•10 years ago
|
||
Thanks Paul.
Status: NEW → RESOLVED
Closed: 10 years ago
Resolution: --- → WORKSFORME
Updated•10 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!]
Updated•2 years ago
|
Product: Core → Core Graveyard
You need to log in
before you can comment on or make changes to this bug.
Description
•