584488 - hang after attaching to external monitor, seemed to be waiting for zombie plugin-container process

Status: RESOLVED INCOMPLETE

(Core Graveyard :: Plug-ins, defect)

Description

[Mike Beltzner [:beltzner, not reading bugmail]]

I plugged my mac back into an external monitor and Firefox beachballed. I attached Shark, and jrmuizel helped me understand that the only samples were the general watchdog thread, watchdogging.

So then we attached gdb (I'm learning so much!) and got this stack:

(gdb) bt
#0  0x90909066 in __semwait_signal ()
#1  0x90908d22 in _pthread_cond_wait ()
#2  0x90908875 in pthread_cond_timedwait$UNIX2003 ()
#3  0x0262b0f9 in pt_TimedWait ()
#4  0x0262be4f in PR_WaitCondVar ()
#5  0x00c5f1a6 in mozilla::ipc::SyncChannel::WaitForNotify ()
#6  0x00c5ca34 in mozilla::ipc::RPCChannel::Call ()
#7  0x00c6af67 in mozilla::plugins::PPluginInstanceParent::CallNPP_HandleEvent ()
#8  0x00c423e4 in mozilla::plugins::PluginInstanceParent::NPP_HandleEvent ()
#9  0x00c47c71 in mozilla::plugins::PluginModuleParent::NPP_HandleEvent ()
#10 0x00aaa4ac in nsNPAPIPluginInstance::HandleEvent ()
#11 0x0023692a in nsPluginInstanceOwner::ProcessEvent ()
#12 0x002394ba in nsObjectFrame::HandleEvent ()
#13 0x001d5c3c in nsPresShellEventCB::HandleEvent ()
#14 0x0045f08f in nsEventTargetChainItem::HandleEventTargetChain ()
#15 0x0045fc1e in nsEventDispatcher::Dispatch ()
#16 0x001d047d in PresShell::HandleEventInternal ()
#17 0x001d0df6 in PresShell::HandleEvent ()
#18 0x0057fa4e in nsViewManager::DispatchEvent ()
#19 0x0057a0af in HandleEvent ()
#20 0x00bbc975 in nsChildView::DispatchEvent ()
#21 0x00bb3642 in nsChildView::DispatchWindowEvent ()
#22 0x00bc2d6d in -[ChildView updatePluginTopLevelWindowStatus:] ()
#23 0x00bb5067 in -[ChildView windowResignedMain:] ()
#24 0x961831c3 in _nsnote_callback ()
#25 0x98dc73c3 in __CFXNotificationPost ()
#26 0x98dc6dca in _CFXNotificationPostNotification ()
#27 0x96178090 in -[NSNotificationCenter postNotificationName:object:userInfo:] ()
#28 0x9618546d in -[NSNotificationCenter postNotificationName:object:] ()
#29 0x96e84f73 in -[NSWindow resignMainWindow] ()
#30 0x96f446df in endKeyAndMain ()
#31 0x96debd8b in -[NSApplication sendEvent:] ()
#32 0x96d805bb in -[NSApplication run] ()
#33 0x00ba707a in nsAppShell::Run ()
#34 0x00a238b7 in nsAppStartup::Run ()
#35 0x0000cc47 in XRE_main ()
#36 0x00001d48 in main ()

Then we said:

(gdb) c
Continuing.

And my browser started responding again. However - no plugin content seemed to work. There was no OOPsie UI, just black space where plugin content should be. Further, I noticed:

host-125:~ beltzner$ ps aux | grep plugin
beltzner  4068   0.2  0.0  2425520    172 s001  R+    4:36pm   0:00.00 grep plugin
beltzner   397   0.0  0.0        0      0   ??  Z    Mon01pm   0:00.00 (plugin-container)

Killing the zombie process didn't help, nor did reloading the tab. Restarting the browser was the only way out of the state.

For your consideration!

Comment 1

[Benoit Girard (:BenWa)]

I'm surprised that the OOPsie UI doesn't come up after the timeout. I believe nightlies should have the timeout activated while debug builds do not. If that is true this might also be a bug with the IPC mechanism as well as a bug with the out-of-process event.

I'm going to investigate what the event is and where it's getting hung up on.

Comment 2

[Benoit Girard (:BenWa)]

I tried reproducing with a few versions of flash with the latest nightly and I was unable to reproduce the issue. Here is my standard configuration:

STR:
1) Start a youtube.com video.
2) Plug in external monitor

Also tried:
1) Have external monitor plugged in.
2) Start youtube.com video
3) Unplug external monitor

Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:2.0b4pre) Gecko/20100808 Minefield/4.0b4pre

File: Flash Player.plugin
Version: 10.0.45.2
Shockwave Flash 10.0 r45

It would be great if other people can comment their results noting their UA and Flash version.

Comment 3

[Mike Beltzner [:beltzner, not reading bugmail]]

If it happens again, I'll be sure to do so. Any other debugging information I can dig into?

Comment 4

[Benoit Girard (:BenWa)]

Attaching gdb to the plugin-container and looking at the backtrace (bt) might tell us what it got hung up on.

Looking carefully at the trace for the browser we can see that the NPCocoaEventWindowFocusChanged event, generated by updatePluginTopLevelWindowStatus, made the plug-in process hang. I'll review how we handle that event in the plug-in process. 

Bug 584965 fixed several event crashes so I wouldn't be surprised if this issue disappeared but it's worth taking a look.

Comment 5

[Mike Beltzner [:beltzner, not reading bugmail]]

Why did the severity get changed here?

Comment 6

[Wayne Mery (:wsmwk)]

Hi beltzner. Sorry if I made a mistake. Do I misunderstand that your browser was *not* hung?

Comment 7

[Mike Beltzner [:beltzner, not reading bugmail]]

Browser was totally hung, yes. Didn't know that meant severity goes to "critical", though. It's only happened the once.

Comment 8

[Wayne Mery (:wsmwk)]

>0 + hang => critical in my book. 
Adding frequency to the equation/judgment just complicates the definition IMO :)

Comment 9

[Benjamin Smedberg]

Resolving old bugs which are likely not relevant any more, since NPAPI plugins are deprecated.