Closed Bug 584626 Opened 14 years ago Closed 7 years ago

plugin container process survives after shutdown?

Categories

(Core Graveyard :: Plug-ins, defect)

Product:
Core Graveyard
Component:
Plug-ins
Version:
Other Branch
Platform:
x86
Windows Vista
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(blocking2.0 -)

Status:
RESOLVED INCOMPLETE
Tracking Flags:
Tracking Status
blocking2.0 --- -

People

(Reporter: gal, Unassigned)

Details

Attachments

(1 file)

zombie
3.02 KB, text/plain
Details 
I was helping a friend with her computer and noticed that the firefox plugin process occasionally survives after shutdown and just sits around sucking up resources and CPU time. OS is Windows Vista Home. Is this a known issue? Can we make sure that when firefox quits we kill -9 -whatever -I_really_mean_it the plugin process?
OS: Mac OS X → Windows Vista
Lame.
blocking2.0: --- → ?
Is there anything I can do to diagnose this?
This certainly shouldn't be happening, we kill it off somewhere in this block: http://mxr.mozilla.org/mozilla-central/source/xpcom/build/nsXPComInit.cpp#718

Unless somehow the Firefox process is exiting without going through NS_ShutdownXPCOM.
(In reply to comment #3)
> Unless somehow the Firefox process is exiting without going through
> NS_ShutdownXPCOM.

Which can happen.

We need to kill any old container on restart (do we do that?).

The container process should also detect when its parent is dead and exit.

/be
The normal shutdown path (through ShutdownXPCOM) should end somewhere in here http://mxr.mozilla.org/mozilla-central/source/ipc/chromium/src/chrome/common/process_watcher_win.cc#18 .  If "polite" shutdown fails, we do kill -9 or its windows equivalent.

If the browser process dies unexpectedly, the child process is supposed to hit this code http://mxr.mozilla.org/mozilla-central/source/dom/plugins/PluginModuleChild.cpp#567 .

(In reply to comment #4)
> We need to kill any old container on restart (do we do that?).
> 

No.  In the presence of multiple firefox instances, I would be nervous trying that even with process tree info, and on windows we don't even have that.

> The container process should also detect when its parent is dead and exit.
> 

It should be doing that in the code above.

I'll poke around on my win7 VM later today and see if anything turns up.
(In reply to comment #5)
> The normal shutdown path (through ShutdownXPCOM) should end somewhere in here
> http://mxr.mozilla.org/mozilla-central/source/ipc/chromium/src/chrome/common/process_watcher_win.cc#18
> .  If "polite" shutdown fails, we do kill -9 or its windows equivalent.
> 
> If the browser process dies unexpectedly, the child process is supposed to hit
> this code
> http://mxr.mozilla.org/mozilla-central/source/dom/plugins/PluginModuleChild.cpp#567

Who calls ActorDestroy? I couldn't find any calls outside of tests at

http://mxr.mozilla.org/mozilla-central/ident?i=ActorDestroy

> > We need to kill any old container on restart (do we do that?).
> 
> No.  In the presence of multiple firefox instances, I would be nervous trying
> that even with process tree info, and on windows we don't even have that.

Yeah, we would need something to know it was orphaned. No such data on Windows?

/be
(In reply to comment #6)
> (In reply to comment #5)
> > The normal shutdown path (through ShutdownXPCOM) should end somewhere in here
> > http://mxr.mozilla.org/mozilla-central/source/ipc/chromium/src/chrome/common/process_watcher_win.cc#18
> > .  If "polite" shutdown fails, we do kill -9 or its windows equivalent.
> > 
> > If the browser process dies unexpectedly, the child process is supposed to hit
> > this code
> > http://mxr.mozilla.org/mozilla-central/source/dom/plugins/PluginModuleChild.cpp#567
> 
> Who calls ActorDestroy? I couldn't find any calls outside of tests at
> 
> http://mxr.mozilla.org/mozilla-central/ident?i=ActorDestroy
> 

One route to there (through generated C++, so won't be in mxr) is

http://mxr.mozilla.org/mozilla-central/source/ipc/glue/AsyncChannel.cpp#346

which is delivered when the socket or pipe closes unexpectedly.

> > > We need to kill any old container on restart (do we do that?).
> > 
> > No.  In the presence of multiple firefox instances, I would be nervous trying
> > that even with process tree info, and on windows we don't even have that.
> 
> Yeah, we would need something to know it was orphaned. No such data on Windows?
> 

I don't know.
I bet Rob Arnold knows...

/be
So there are two ways to solve this - have the child process kill itself when the parent dies or on restart we can look for plugin-container.exe processes and kill the orphaned ones.

The former is super easy in Windows. The child process gets a handle to its parent, and spawns a thread whose only job is to WaitForSingleObject on the parent and invoke ActorDestroy when that call returns.

For the latter option, this will of course work only if the orphaned processes belong to the same user as the restarted process.

No data on the process tree can be found in an officially documented manner for userspace programs. NT keeps track of the PID of the parent but PIDs can of course be recycled so there's no guarantee it's the right process. However, it's probably right given the low number of processes on Windows (about 14 bits of PID-space).

This information lives in the KPROCESS structure and the information is obtainable via a explicitly unsupported (yet documented) call (NtQueryInformationProcess). The exact field is for whatever reason, the userspace definition of the struct (PROCESS_BASIC_INFORMATION) doesn't include the field with the right name - it's called Reserved3 and the struct is defined in winternl.h.

Child suicide seems like a better solution than orphan killing - do we know why the pipe/socket notification isn't working?
Seems to me we need some kind of solution here, so blocking.
blocking2.0: ? → betaN+
Looking into why children are failing to commit suicide.
Assignee: nobody → jones.chris.g
(In reply to comment #0)
> I was helping a friend with her computer and noticed that the firefox plugin
> process occasionally survives after shutdown and just sits around sucking up
> resources and CPU time. OS is Windows Vista Home. Is this a known issue? Can we
> make sure that when firefox quits we kill -9 -whatever -I_really_mean_it the
> plugin process?

I played around with killing firefox-bin using the Windows task manager, and plugin-container committed suicide each time (for flash and our testplugin).  Do you have more detailed STR?
I did a regular quit with command q. I can probably reproduce on that laptop. It happened on most shutdowns.
We don't have a cmd-Q equivalent on Windows, in fact.
Er yeah, Ctrl-w.  Just double-checking that this was a problem on Vista.
Typing on an iPhone here. I did a regular shutdown. Probably menu or whatever. Or even more likely the x on the window.
And yes vista home. Clean profile but flash and virus scanners active. Flash brings its own mcafee one.
Tried a few more scenarios in an opt build (debug before) to make sure it wasn't an opt/debug discrepancy.  Can't repro.
Assignee: jones.chris.g → nobody
How can I help diagnose if I can reproduce it?
Find out which plugin it is, list steps to make it zombie, and if you can, get the MSVC equivalent of |thread apply all bt| in plugin-container.  Also if you can, checking the Process Explorer (http://technet.microsoft.com/en-us/sysinternals/bb896653.aspx) tree might reveal if the plugin spawned other processes that might be keeping it alive.  I doubt antivirus stuff would show up in that tree, though.
You can install WinDBG on her laptop and get a stack using the symbol server:
https://developer.mozilla.org/en/How_to_get_a_stacktrace_with_WinDbg
Alright, I will try to do this today.
for info, I just filed bug 602650 which might be related but refers to Mac. (the plugin container keeps running after manually killing the browser, when the Java plugin has crashed it due to a buggy applet.)
Attached file zombie — 
Spotted this today on my machine. Here are the stacks of the two active threads.
Er ... that's a jetpack process, early in startup.

bsmedberg, any idea what might be going on there?
blocking2.0: betaN+ → -
Resolving old bugs which are likely not relevant any more, since NPAPI plugins are deprecated.
Status: NEW → RESOLVED
Closed: 7 years ago
Resolution: --- → INCOMPLETE
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: