772181 - Flash hang that bsmedberg experienced and caught in a debugger

Status: RESOLVED INCOMPLETE

(Core Graveyard :: Plug-ins, defect)

Description

[Benjamin Smedberg]

I caught this in a debugger while watching a meeting cast with Flash. Here are the stacks:

The stack of the child is... mysterious, but probably Flash is in its own event loop and is then calling NPN_Evaluate (PluginScriptableObjectChild::Evaluate) which is calling CallNPN_Evaluate which then ends up in WaitForMultipleObjects (I'm a bit lost in the intermediate stacks, MSVC isn't walking them usefully at all).

The parent has a good stack:

 	user32.dll!_NtUserMessageCall@28() 	
 	user32.dll!_RealDefWindowProcW@16() 	
 	user32.dll!_DefWindowProcW@16() 	
 	user32.dll!_InternalCallWinProc@20() 	
 	user32.dll!_UserCallWinProcCheckWow@32() 	
 	user32.dll!_CallWindowProcAorW@24() 	
 	user32.dll!_CallWindowProcW@20() 	
>	xul.dll!nsWindow::WindowProcInternal(hWnd=0x01460712, msg=0x00000006, wParam=0x00000002, lParam=0x00b606de)  Line 4332	C++
 	xul.dll!CallWindowProcCrashProtected(wndProc=0x683e66b0, hWnd=0x00460712, msg=0x00000006, wParam=0x00000002, lParam=0x00b606de)  Line 32	C++
 	xul.dll!nsWindow::WindowProc(hWnd=0x00460712, msg=0x00000006, wParam=0x00000002, lParam=0x00b606de)  Line 4267	C++
 	user32.dll!_InternalCallWinProc@20() 	
 	user32.dll!_UserCallWinProcCheckWow@32() 	
 	user32.dll!_DispatchClientMessage@24() 	
 	user32.dll!___fnDWORD@4() 	
 	ntdll.dll!_KiUserCallbackDispatcher@12() 	
 	user32.dll!_NtUserPeekMessage@20() 	
 	user32.dll!__PeekMessage@24() 	
 	user32.dll!_PeekMessageW@20() 	
 	xul.dll!PeekUIMessage(aMsg=0x0028c99c)  Line 88	C++
 	xul.dll!nsAppShell::ProcessNextNativeEvent(mayWait=true)  Line 306	C++
 	xul.dll!nsBaseAppShell::OnProcessNextEvent(thr=0x00c1e100, mayWait=true, recursionDepth=0x00000000)  Line 298	C++
 	xul.dll!nsThread::ProcessNextEvent(mayWait=true, result=0x0028ca99)  Line 586	C++
 	xul.dll!mozilla::ipc::MessagePump::Run(aDelegate=0x00c2e0e0)  Line 116	C++
 	xul.dll!MessageLoop::RunHandler()  Line 202	C++
 	xul.dll!MessageLoop::Run()  Line 176	C++
 	xul.dll!nsBaseAppShell::Run()  Line 165	C++
 	xul.dll!nsAppShell::Run()  Line 232	C++
 	xul.dll!nsAppStartup::Run()  Line 257	C++
 	xul.dll!XREMain::XRE_mainRun()  Line 3787	C++
 	xul.dll!XREMain::XRE_main(argc=0x00000001, argv=0x008e1d08, aAppData=0x00e13508)  Line 3864	C++


In the top nsWindow::WindowProcInternal we're passing on WM_ACTIVATE (msg=0x6) and it appears that we're passing that same message all the way to _NtUserMessageCall. And the window appears to be the main Firefox window.

Comment 1

[Jim Mathies [:jimm]]

The second param is WA_CLICKACTIVE, so the main window is getting activated and likely sending focus related events to child windows. If the plugin is in NPN_Evaluate that means it's locked up in our WaitForNotify loop and isn't processing windowing events.

Comment 2

[Benjamin Smedberg]

Shouldn't it still be hitting the deferred-processing, which does include WM_ACTIVATE?

Comment 3

[Jim Mathies [:jimm]]

(In reply to Benjamin Smedberg  [:bsmedberg] from comment #2)
> Shouldn't it still be hitting the deferred-processing, which does include
> WM_ACTIVATE?

Not for Flash owned windows. We don't hook those.

Comment 4

[Jim Mathies [:jimm]]

(In reply to Jim Mathies [:jimm] from comment #3)
> (In reply to Benjamin Smedberg  [:bsmedberg] from comment #2)
> > Shouldn't it still be hitting the deferred-processing, which does include
> > WM_ACTIVATE?
> 
> Not for Flash owned windows. We don't hook those.

We currently hook the mozilla plugin window they would normally interact with, but now they have added their own. Maybe we should be hooking the new 'GeckoFPSandboxChildWindow' child window flash added to the mix. Unknown what kind of 'yuck' that might cause.

Comment 5

[Jim Mathies [:jimm]]

One other comment - if I remember correctly, they looked long and hard at our hooking and may have implemented their form of it on their end. :)

Comment 6

[Benjamin Smedberg]

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