I have Java Plug-in 1.6.0_10 installed, and was testing Chrome under vista.

(No comment was entered for this change.)

Similar behavior have been observed with Chrome 2.0.172.30. Afther killing the java
plugin Chrome does not keep hanging though.

While Chrome is hung the main window suddenly gets normal window border drawn a
couple of seconds before the plugin hang detector dialog. After clicking yes on the
dialog Chrome gets its own Window border back.

Chrome: 2.0.172.30
OS: Windows XP SP2
Java Plug-In: 1.6.0_13

I did a little debugging of this on ToT. Ran 'chrome/Debug/chrome
--plugin-startup-dialog' and navigated to
.http://java.sun.com/javase/6/webnotes/6u10/plugin2/liveconnect/LiveConnectTests/.
When the plugin startup dialog appeared attached to the plug-in processes. Placed a
break point in FindProxyForUrl in plugin_thread.cc on 'if (IsPluginProcess()) {'
stepping from there it seems that the Send call on the next line never returns.

The reason for suspecting PluginProcessHostMsg_ResolveProxy came from looking at what
appeards on about:ipc when the plug-in got stuck.

The same is the case for http://www.nse-india.com/ (http://crbug.com/11152).

Wth a timely help from Ananta I think I know what the issue is. This involves two 
plugin instances with second instance making sync calls to the renderer while the 
first one is still servicing an incoming sync request.

Our logic to unblock the renderer during the sync call fails since the 'in_dispatch_' 
counter is maintained per plugin channel (each plugin instance uses its own separate 
channel). Making 'in_dispatch_' counter static member of PluginChannelBase fixes this 
deadlock.

I think  the key difference here is that when a method is invoked on a plugin 
instance, unrelated plugin instances can issue requests within that context. This is 
probably because Java plugin is attempting to do things in parallel and whenever it 
is called with a instance method, thats the only time it gets control to resolve 
proxy or cookies so that it can start loading Java applets.

Add label: Assigned.

(No comment was entered for this change.)

 Issue 10008  has been merged into this issue.

one of these bugs is a crash and another is a hang, is the bug description off?

yes. I verified with Amit's fix that it does fix the other bug

The pogo site mentioned in the  bug 10008  gets stuck with very similar call stack as 
this bug. I guess a user eventually gets the plugin hung dialog and hence the resulting 
'crash'.

The following revision refers to this bug:
    http://src.chromium.org/viewvc/chrome?view=rev&revision=17492 

------------------------------------------------------------------------
r17492 | amit@chromium.org | 2009-06-03 10:33:29 -0700 (Wed, 03 Jun 2009) | 18 lines
Changed paths:
   M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/plugin/plugin_channel_base.cc?r1=17492&r2=17491
   M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/plugin/plugin_channel_base.h?r1=17492&r2=17491
   A http://src.chromium.org/viewvc/chrome/trunk/src/chrome/test/data/npapi/multiple_instances_sync_calls.html
   M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/test/ui/npapi_uitest.cc?r1=17492&r2=17491
   M http://src.chromium.org/viewvc/chrome/trunk/src/webkit/glue/plugins/test/plugin_client.cc?r1=17492&r2=17491
   M http://src.chromium.org/viewvc/chrome/trunk/src/webkit/glue/plugins/test/plugin_windowless_test.cc?r1=17492&r2=17491
   M http://src.chromium.org/viewvc/chrome/trunk/src/webkit/glue/plugins/test/plugin_windowless_test.h?r1=17492&r2=17491

Fix browser hang due to plugin deadlock

This involves two plugin instances with second instance making 
sync calls to the renderer while the first one is still servicing
an incoming sync request.

Our logic to unblock the renderer during the sync call fails 
since the 'in_dispatch_' counter is maintained per plugin channel 
(each plugin instance uses its own separate channel). Making 
'in_dispatch_' counter static member of PluginChannelBase fixes this 
deadlock.

Added a new NPAPI UI test for this scenario.

BUG=12624
TEST=MultipleInstancesSyncCalls

Review URL: http://codereview.chromium.org/119052
------------------------------------------------------------------------

(No comment was entered for this change.)

(No comment was entered for this change.)