United StatesChange Country, Oracle Worldwide Web Sites Communities I am a... I want to...
Bug ID: 5082374 Plugin can freeze when multiple applets use Thread.setName()
5082374 : Plugin can freeze when multiple applets use Thread.setName()

Details
Type:
Bug
Submit Date:
2004-08-04
Status:
Resolved
Updated Date:
2006-08-15
Project Name:
JDK
Resolved Date:
2006-08-15
Component:
deploy
OS:
solaris_2.6
Sub-Component:
plugin
CPU:
generic
Priority:
P3
Resolution:
Fixed
Affected Versions:
6
Fixed Versions:
6

Related Reports
Backport:
JDK-2141424 - Plugin can freeze when multiple applets use Thread.setName()
Backport:
JDK-2141423 - Plugin can freeze when multiple applets use Thread.setName()

Sub Tasks

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.
2006-08-07 
EVALUATION

No information is provided for debug purpose after my last status update left over a month ago.
Will close out this bug.
2006-08-03 
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.
2006-06-21 
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.
2006-06-21 
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
2005-05-19 
CONVERTED DATA

BugTraq+ Release Management Values

COMMIT TO FIX:
mustang
2004-08-27


Hardware and Software, Engineered to Work Together