1160140 - [e10s] Windows content processes wait for UI events in MessageChannel::WaitForInterruptNotify() for plugin ipc

Status: RESOLVED WONTFIX

(Core :: DOM: Content Processes, defect)

Description

[Jim Mathies [:jimm]]

Deferred message protection appears to be on for this side of the connection, but I don't think we need it.

where we get caught up in:
http://hg.mozilla.org/mozilla-central/annotate/8aff0d2a7bc7/ipc/glue/WindowsMessageLoop.cpp#l1116

where we want to be:
http://hg.mozilla.org/mozilla-central/annotate/8aff0d2a7bc7/ipc/glue/WindowsMessageLoop.cpp#l1032

hang stack I noticed this on:

CONTENT
-----------------------------------------------------------------------------------
0 NtWaitForMultipleObjects
1 RtlAnsiStringToUnicodeString
2 TF_Notify
3 __crtCompareStringA_stat
4 WaitForMultipleObjectsExImplementation
5 CallHookWithSEH
6 _fnHkINLPMSG
7 _crtCompareStringA
8 RealMsgWaitForMultipleObjectsEx
9 ZwUserPeekMessage
10 MsgWaitForMultipleObjectsEx
11 PeekMessageW
12 MsgWaitForMultipleObjects
13 PR_Unlock src
14 mozilla::ipc::MessageChannel::WaitForInterruptNotify() src
15 mozilla::ipc::MessageChannel::Call(IPC::Message *,IPC::Message *) src
16 mozilla::plugins::PPluginScriptableObjectParent::CallHasProperty(mozilla::plugins::PluginIdentifier const &,bool *) src
17 mozilla::plugins::PluginScriptableObjectParent::ScriptableHasProperty(NPObject *,void *) src
18 NPObjWrapper_Resolve src
19 js::jit::ComputeGetPropResult src
20 js::jit::DoGetPropFallback src
21 unknown: offset=unknown function=unknown

Comment 2

[Jim Mathies [:jimm]]

Attachment: patch v.1

This turns off deferred processing between the content and plugin processes.

Comment 3

[Bill McCloskey [inactive unless it's an emergency] (:billm)]

Comment on attachment 8617525 [details] [diff] [review]
patch v.1

Review of attachment 8617525 [details] [diff] [review]:
-----------------------------------------------------------------

Are you sure we can eliminate these calls? Can something like this happen?

1. Plugin sends sync or rpc message to content process.
2. Content process sends sync message to chrome process.
3. Chrome process does something to its window that somehow sends a Windows message that must be processed synchronously by the plugin's event queue.

Step 3 is a little hazy since I forgot how all this stuff works. But it seems like we might still be able to deadlock.

Also, it's probably better that Aaron reviews this. I don't feel comfortable with all this Window event queue stuff.

Comment 4

[(No longer employed by Mozilla) Aaron Klotz]

Do you have any additional information about the hang that inspired this bug? Any chance I could see the original crash report (or similar)?

Comment 5

[Jim Mathies [:jimm]]

(In reply to Bill McCloskey (:billm) from comment #3)
> Comment on attachment 8617525 [details] [diff] [review]
> patch v.1
> 
> Review of attachment 8617525 [details] [diff] [review]:
> -----------------------------------------------------------------
> 
> Are you sure we can eliminate these calls? Can something like this happen?
> 
> 1. Plugin sends sync or rpc message to content process.
> 2. Content process sends sync message to chrome process.
> 3. Chrome process does something to its window that somehow sends a Windows
> message that must be processed synchronously by the plugin's event queue.

Seems plausible. I haven't seen any evidence of this, although I probably wouldn't see much without this turned off. We can keep this overhead and wontfix this I guess.