Bug 114217 - Web/Plugin process deadlock initializing async plugins
Summary: Web/Plugin process deadlock initializing async plugins
Status: RESOLVED INVALID
Alias: None
Product: WebKit
Classification: Unclassified
Component: WebKit2 (show other bugs)
Version: 528+ (Nightly build)
Hardware: All All
: P2 Normal
Assignee: Brady Eidson
URL:
Keywords: InRadar
Depends on:
Blocks:
 
Reported: 2013-04-08 14:13 PDT by Brady Eidson
Modified: 2013-04-11 10:16 PDT (History)
1 user (show)

See Also:


Attachments
Patch v1 (2.74 KB, patch)
2013-04-08 14:15 PDT, Brady Eidson
andersca: review+
Details | Formatted Diff | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Brady Eidson 2013-04-08 14:13:03 PDT
Web/Plugin process deadlock initializing async plugins

Imagine:

-A WebProcess is instantiating a plugin, so it synchronously asks for a new plugin process connection.
-Once it gets the connection, it asynchronously asks for a plugin to initialize.
-While that one is initializing, it's instantiating another plugin.
-It synchronously asks for a new plugin process connection.

In this scenario, when the plugin process finishes up the async initialization, it notifies the web process with a synchronous message.

So it's synchronously waiting on the WebProcess, and the WebProcess is synchronously waiting on the plugin process.

Deadlock.

I think this is an easy fix because I don't now why the plugin process notification to the WebProcess is synchronous - the replies are empty.

In radar as <rdar://problem/13525232>
Comment 1 Brady Eidson 2013-04-08 14:15:32 PDT
Created attachment 196954 [details]
Patch v1
Comment 2 Brady Eidson 2013-04-08 14:30:28 PDT
http://trac.webkit.org/changeset/147953
Comment 3 Brady Eidson 2013-04-08 17:18:24 PDT
This caused platform/mac-wk2/plugins/slow/asynchronous-plugin-initialization-multiple.html to fail.  Looking in to it now.
Comment 4 Brady Eidson 2013-04-08 17:26:34 PDT
Here's what happens in the test:

1 - PluginProcess gets 20 requests to async init.  Those 20 messages are queued up.
2 - It starts the first 1, which takes 0.5 seconds
3 - During that time, the WebProcess tells it to destroy all of them.  These 20 messages are sync messages, and presumably get queued up behind those 20 in step one.

In the working case, those 20 "Destroy" messages are handled immediately after the first plugin is finished initializing, even though there's 19 requests to create waiting.

In the failing case, all 20 requests to create are handled before any of the requests to destroy are handled.
Comment 5 Brady Eidson 2013-04-08 17:38:08 PDT
Skipped in r147968 while I explore this.
Comment 6 Brady Eidson 2013-04-08 17:38:33 PDT
Reopening - the failure shows the patch broke the async plugin feature.
Comment 7 Brady Eidson 2013-04-10 15:57:46 PDT
This probably wasn't necessary, and we should roll it out.
Comment 8 Brady Eidson 2013-04-11 10:16:59 PDT
Rolled out in http://trac.webkit.org/changeset/148214