New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 32797 link

Starred by 24 users

Issue metadata

Status: Duplicate
Merged: issue 43617
Email to this user bounced
Closed: May 2010
EstimatedDays: ----
NextAction: ----
OS: Linux
Pri: 2
Type: Bug

  • Only users with Commit permission may comment.

Sign in to add a comment

Deadlock when calling NPN_GetProperty from plugin

Reported by, Jan 21 2010

Issue description

Chrome Version       : tested on official builds ( (Official 
Build 34537)) and local ones (4.0.303.0 (Developer Build 36024)

Plugin affected: Moonlight

When loading the Moonlight plugin on any page (i.e., http://, it 
deadlocks 99% of the time. It happens on several machines, 32 and 64 bit, 
with debug and official builds. Occasionally it will load, normally when 
attaching debuggers or if it's the first time it's loading after a reboot, 
it's extremely timing-sensitive. Traces for the plugin and renderer 
processes are attached.

Let me know if you need more info, I can get you non-xpi debug builds of 
moonlight if you need them.
6.0 KB View Download
3.5 KB View Download
it turns out it's extremely easy to deadlock chrome. Attached is a little plugin 
test case that does it by calling NPN_GetProperty inside SetWindow

To test:
running make install will copy a small loader ( on ~/.mozilla/
plugins, which just loads (the real plugin). should be on 
the lib path or local dir. the plugin does nothing until the SetWindow call.

Use the attached test.html to repro this
331 KB Download
561 bytes Download

Comment 2 by, Jan 22 2010

Labels: -Area-Undefined Area-Internals
Yeah this looks bad.  Thanks a lot for the good repro case!
There was a symbol missing in the test case... would blow up if it didn't deadlock :P
updated test case attached
331 KB Download

Comment 4 by, Jan 22 2010

Labels: OS-Linux
I can't reproduce this on Windows.  Evan: are you still working on Linux plugins?  If 
so can you take a look?

Comment 5 by, Jan 24 2010

Status: Assigned
I'll take a look tomorrow.  Thanks for the awesome bug report.

Comment 6 by, Jan 25 2010

Hey John,
By "can't reproduce this on Windows", did you mean you tried what the plugin did?  Or 
did you just mean that Silverlight is ok?  In the latter case, Moonlight is an 
entirely separate codebase.

Here's what I *think* happens, so any corrections you could make would help.  It 
seems this shouldn't be Linux-specific.  But I kinda have most of this plugin stuff 
swapped out of my head so I forget how where e.g. WebPluginDelegateProxy lives or 
what it's supposed to be doing.  :(

On setup, the renderer in updateGeometry first calls SetWindow(R->P), and kicks off a 
task to run OnDownloadPluginSrcUrl immediately afterwards.

Here's the deadlock:

plugin: in its SetWindow it handler synchronously calls NPN_GetProperty(P->R).  (This 
behavior is specific to this particular plugin.)

renderer: meanwhile it starts its queued OnDownloadPluginSrcUrl, which tries to get a 
ResourceClientProxy and ends up synchronously calling PluginMsg_HandleURLRequestReply(R->P).

The renderer and plugin are now both waiting for a sync response from the other.
by reproducing this on windows, I meant copying the code the author had in their test 
plugin and putting it in a test plugin on Windows.

regarding the scenario you give, it should be fine.  If the plugin is making a sync 
call to the renderer and the renderer makes a sync call to it, the sync call at the 
plugin process will get dispatched.

Comment 8 by, Jan 25 2010

How do the bidirectional sync calls work?  I have in debuggers right now a hung renderer/plugin, each 
stuck inside a call to Send().  Perhaps some code in SyncChannel doesn't yet exist on Linux?

#7  0x0000000000b86c52 in ResourceClientProxy::Initialize (this=0x4a72a00, resource_id=6, url=..., 
    notify_data=0, existing_stream=0) at chrome/renderer/
93          channel_->Send(new PluginMsg_HandleURLRequestReply(instance_id_, params));

#9  0x0000000002022a5a in WebPluginProxy::GetWindowScriptNPObject (this=
    0x7fffe80ca460) at chrome/plugin/
156           route_id_, npobject_route_id, &success, &npobject_ptr));


void SyncChannel::WaitForReply will loop waiting for the reply when a caller makes a 
sync call.  "if (result == 0 /* dispatch event */) {" is hit when an incoming sync 
call comes and "context->DispatchMessages();" will dispatch it.

If this didn't work on Linux before, we'd have seen tons of hangs.  I'd be really 
surprised if it's broken (at least, all the time).  It should also be tested in 
ipc_tests (that runs on Linux I hope?).
 Issue 31215  has been merged into this issue.
While working on the Intensity Engine plugin ( 
I also ran into this issue. In our case, the deadlock occurs in NPN_Invoke, not NPN_GetProperty, but the symptoms and settings are otherwise identical: Deadlocks, on 
Linux, also in SetWindow, etc. This is on Chromium 5.0.317.0 (38075) on Ubuntu 9.10.

- kripken

Comment 12 by, May 10 2010

Plugin process deadlocks Chrome on Windows XP. 

When calling  NPN_GetValue(instance, NPNVWindowNPObject) from inside NPP_SetWindow
()  Chrome plugin process  deadlocks. 

We  were using Chrome production version We have not attempted 
building source code, but API trace shows that WaitForMultipleObjects () in 
WaitableEvent::WaitMany() never returns. Attached is a bare bone plugin and test 
html page.  It is important that  HTML page calls some plugin method; without that 
call crash is not happening . It seems that plugin process calls NPP_GetValue while 
waiting for NPN_GetValue result . 

You have to register plugin with regsvr32 before using it. Regsvr32 –u removes all 
registry entries.

Please note that to recreate the problem you may need to reload the test page for 
about 15-20 times. Deadlock happens more often when using debug version of the  
plugin. Zip file also has plugin crash screen shot. Let me know if you need anything 
99 KB Download

Comment 13 by, May 17 2010

Mergedinto: 43617
Status: Duplicate

Comment 14 by, May 17 2010

shana.ufie: sorry we didn't get to this earlier, but it sounds like we may have fixed 
the bug.  When you get a chance, can you try a Chrome build after r47063 and see if 
the problem still occurs?  You can read  issue 43617  for more info.
@evan: thanks for the update. it's nice timing, I was just about to poke at chrome 
again to see if things were better, I'll get back to you on this.
Yep, it's fixed, thanks. Interesting to note that for 4 months nothing was done on this, 
with a reliable test case, and suddenly when flash shows the same symptoms, this bug is the 
one marked dup and things are fixed in a few days. Good to know which keywords get priority 
around here.
> this bug is the one marked dup

Because all the debugging and the checkin comment were in the other bug, before I was even aware of this bug. 
(every project I've ever worked on will forward-dup if the newer bug has the bulk of the activity). I'm primarily 
working on the Mac; the fact that I wasn't aware of this bug isn't a personal slight.

> Good to know which keywords get priority around here.

It has nothing to do with keywords. I was investigating a bug that was affecting every single Mac Chrome user, on 
a lot of very popular sites, because it was rendering the Mac version completely unlivable. I'm sorry that you find 
it unfair that we prioritize bugs by the scale and severity of the impact--(% of sites with Flash content) x (100% 
install base of Flash on the Mac) >> (% sites with Silverlight content) x (% install base of Moonlight on Linux)--but 
we don't have unlimited resources, so that's the reality. I'm willing to bet that Moonlight doesn't fix bug in strict 
age order either.

Comment 19 by, May 26 2010

+1 to stuart.  also note that I took your sample plugin and compiled it on Windows, and 
couldn't repro.  The Flash hang couldn't be repro'd on Windows either.  It's only 
thanks to Stuart who figured out how to repro and trace what's happening that it's 
Project Member

Comment 20 by, Oct 12 2012

Labels: Restrict-AddIssueComment-Commit
Mergedinto: chromium:43617
This issue has been closed for some time. No one will pay attention to new comments.
If you are seeing this bug or have new data, please click New Issue to start a new bug.
Project Member

Comment 21 by, Mar 10 2013

Labels: -Area-Internals Cr-Internals

Sign in to add a comment