JDK-5082374 : Plugin can freeze when multiple applets use Thread.setName()
  • Type: Bug
  • Component: deploy
  • Sub-Component: plugin
  • Affected Version: 6
  • Priority: P3
  • Status: Resolved
  • Resolution: Fixed
  • OS: solaris_2.6
  • CPU: generic
  • Submitted: 2004-08-04
  • Updated: 2006-08-15
  • Resolved: 2006-08-15
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
Other JDK 6
1.4.2_14Fixed 6 b96Fixed
Description
A possible deadlock is observed when monitoring the plugin behavior for an application openning multiple applets in the browser simultaneously. The possibility of a deadlock is observed using the Thread Debugger of Borland Optimizeit Suite 6.0

An example scenario from a real customer app is provided below. Thread-78 starts to monitor java.lang.Object 0x224b3dd0 and sun.plugin.Security.Activator.SecurityManager 0x1a5a4e40 sequentially. Client thread CSDUDGrObjWnd grabs the same locks but in a reverse order.  There're many more client threads like CSDUDGrObjWnd in the customer's system starting at various times. This can cause timing dependent deadlocks.

This deadlock can happen during the load or refresh of an HTML page containing multiple applets.

Plugin synchronization needs to be improved to prevent this freeze from happenning. 

Stack Traces:

Thread78 :

sun.applet.AppletSecurity.checkAccess() [ holds sun.plugin.security.ActivatorSecurityManager 0x1a5a4e40 ]
java.lang.ThreadGroup.checkAccess()
java.lang.ThreadGroup.<init>()
sun.applet.AppletThreadGroup.init<>()
sun.applet.AppletThreadGroup.init<>()
sun.applet.AppletClassLoader$4.run()
java.security.AccessController.doPrivileged()
sun.applet.AppletClassLoader.getThreadGroup()
sun.applet.AppletClassLoader.getThreadGroup() [ holds java.lang.Object 0x224b3dd0 ]
sun.applet.AppletClassLoader.grab()
sun.applet.AppletPanel.createAppletThread()
sun.applet.AppletPanel.init()
sun.plugin.AppletViewer.appletInit()
sun.plugin.viewer.LifeCycleManager.initAppletPanel
sun.plugin.bviewer.IExplorerPluginObject$Initer.run()

Thread CSDUDGrObjWnd :

sun.applet.AppletClassLoader.getThreadGroup() [ holds java.lang.Object 0x224b3dd0 ]
sun.applet.AppletSecurity.getThreadGroup()
sun.applet.AppletSecurity.inThreadGroup()
sun.applet.AppletSecurity.inThreadGroup()
sun.applet.AppletSecurity.checkAccess()
sun.applet.AppletSecurity.checkAccess() [ holds sun.plugin.security.ActivatorSecurityManager 0x1a5a4e40 ]
java.lang.Thread.checkAccess()
java.lang.Thread.setName()
jp.co.yokogawa....CSDUDGrObjWnd.setMainThreadName()
jp.co.yokogawa....CSDUDGrObjWnd.init()
sun.applet.AppletPanel.run()
java.lang.Thread.run()
###@###.### 10/13/04 14:03 GMT
Comments
EVALUATION Reopen bug. Received confirmation from support engineer that removing the synchronization from sun.applet.AppletSecurity.checkAccess(Thread t) did indeed fix the deadlock problem seen by Yokogawa when their application opening multiple applets in the browser simultaneously. Will petition to get this fix in to 6.0 b96.
07-08-2006
EVALUATION No information is provided for debug purpose after my last status update left over a month ago. Will close out this bug.
03-08-2006
EVALUATION Also, can customer provide a testcase to reproduce problem now so that in case the patch doesn't fix their problem, I can have some way to work on further debugging? Plus, please submit stack traces (with vm running in verbose) when hang occurs. I do not have any of this info as I inherited this CR from another engineer who's already left the team.
21-06-2006
EVALUATION A temporary patch with removal asynchroneous sun.applet.AppletSecurity.checkAccess() can be provided for customer to test (as I do not have any testcase information on this bug submission). However, will need to know: - Which version of JRE customer needs 1.5.0, 6.0, or 1.4.2. If it's 1.5.0 or 6.0, I can provide the patch. If 1.4.2, will need help from CTE to provide the patch. - which platform/OS? Please get back soon.
21-06-2006
EVALUATION This requires significant changes to the applet startup code. We will address this issue in mustang. ###@###.### 2004-08-04 I found that the sun.applet.AppletSecurity.checkAccess(Thread t) method need not be synchronized, in which case there will be no deadlock. CTE engineer is verifying this with the customer. ###@###.### 2004-11-16 02:30:31 GMT I inherited this bug from Deva. Since we do not have test applet to reproduce this problem, per Deva's advice, CTE should try removing "synchronized" from sun.applet.AppletSecurity.checkAccess(Thread t) and verifying with customer to see if this helps the problem. We've not since heard anything back from CTE. Can we hear a status update? ###@###.### 2005-04-26 20:26:49 GMT I've not heard back from CTE regarding status of trying the fix suggested by Deva on customer system. I'll leave this bug opened for another 2 weeks. Please get back to me within the next two weeks, otherwise I'll close out this bug. ###@###.### 2005-05-19 01:47:13 GMT Still no input from either CTE or submitter on this bug. Will close it. ###@###.### 2005-06-14 18:37:49 GMT
19-05-2005
CONVERTED DATA BugTraq+ Release Management Values COMMIT TO FIX: mustang
27-08-2004