JDK-6744822 : Race condition in JavawsSysRun
  • Type: Bug
  • Component: deploy
  • Sub-Component: webstart
  • Affected Version: 6,6u10,7
  • Priority: P2
  • Status: Closed
  • Resolution: Fixed
  • OS: generic,windows_xp
  • CPU: generic,x86
  • Submitted: 2008-09-04
  • Updated: 2010-09-17
  • Resolved: 2008-10-02
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.
JDK 6 JDK 7
6u10 b33Fixed 7Fixed
Related Reports
Duplicate :  
JDK-6702582 - javaws.exe not cleared from memory
Duplicate :  
JDK-6726716 - Webstart intermittently fails to launch application
Description
Java WS may hang on startup with the following stack trace (WinXP): 

"javawsApplicationMain" prio=6 tid=0x0db0a000 nid=0xa78 in Object.wait() [0x0e17f000..0x0e17fa94]
   java.lang.Thread.State: WAITING (on object monitor)
        at java.lang.Object.wait(Native Method)
        - waiting on <0x22edc6e8> (a java.lang.Object)
        at java.lang.Object.wait(Object.java:485)
        at com.sun.javaws.ui.JavawsSysRun.delegate(Unknown Source)
        - locked <0x22edc6e8> (a java.lang.Object)
        - locked <0x22ec4788> (a com.sun.javaws.ui.JavawsSysRun)
        at com.sun.deploy.util.DeploySysRun.execute(Unknown Source)
        at com.sun.deploy.util.DeploySysRun$1.run(Unknown Source)
        at java.security.AccessController.doPrivileged(Native Method)
        at com.sun.deploy.util.DeploySysRun.executePrivileged(Unknown Source)
        at com.sun.deploy.ui.UIFactory.hideProgressDialog(Unknown Source)
        at com.sun.javaws.ui.DownloadWindow.setVisible(Unknown Source)
        at com.sun.javaws.ui.DownloadWindow.disposeWindow(Unknown Source)
        at com.sun.javaws.Launcher.executeApplication(Unknown Source)
        at com.sun.javaws.Launcher.executeMainClass(Unknown Source)
        at com.sun.javaws.Launcher.doLaunchApp(Unknown Source)
        at com.sun.javaws.Launcher.run(Unknown Source)
        at java.lang.Thread.run(Unknown Source)
Comments
SUGGESTED FIX Updated fix: http://orgrimmar.russia.sun.com/~in81039/6744822/
09-09-2008
EVALUATION I was too hasty with original suggested fix. It turns out that DummyDialog was not useless. It is modal dialog and for such dialogs new event pump is started. So application UI is not frozen until action is executed. I've attached reworked fix that also deals with cases when we have more than one requests at time (currently it does not work correctly if we have there are 2 requests from the same EDT. Also, UI is blocked if secure thread is busy with non EDT request and EDT request comes). BTW, I've noticed that plugin solution for this problem is different - new secure thread is started per every request (they also use DummyDialogs and this part seems to be vulnerable to multiple requests from same EDT).
09-09-2008
EVALUATION I've attached testcase that can be used to reproduce problem. Run it using regular java with havaws.jar and deploy.jar in classpath. Problems that may occur (you may need to start test several times or increase number of actions if you have multicpu box.): 1) first it starts bunch of very short actions from non EDT thread in separate threads. This may hit problem reported originally (manifestation: some of short actions will be never executed and their threads will stay waiting). 2) if you are lucky and all short and long actions are done (or you can comment them in the sources) press on "start" button. This will start delegate() call from EDT and another recursive delegate call from the same EDT. (imagine that event queue have some pending events triggering delegate() calls). 3) You may also try pressing button while initial short/long actions are being executed. This tests how it behave under mixed load.
09-09-2008
EVALUATION The reason of the hang is race condition in JavawsSysRun. It is possible that secureThread used to run "actions" finishes it work and sends notifyAll() BEFORE application thread reaches wait(). In such case application thread may wait forever. Proposed solution is attached. Note that it seems that DummyDialog logic can be completely removed because it does not seem it could have ever worked. It current logic is as follows: 1) DummyDialog is used ONLY if request to execute action is coming from application EDT. 2) In such case we create new dialog and want to notify secureThread about new action from listener 3) After creation of dialog and displaying it application thread waits for notification from secure thread. However, listeners are executed on EDT. In this particular case onWindowCreated is supposed to be called on the same application EDT where this dialog was created. Note that actual call of listener may happen only when EDT will finish processing all events that happened before and in particular current function (delegate()) has to exit! But this can not happen until t.wait() is over .... That's why i suggest to remove this logic or rewrite it. To rewrite we need to understand what was original intent of this code. The only thing that comes to my mind is to avoid blocking it on application EDT but it is unclear why this is needed. Unfortunatelly comments in the sccs history and code do not shred any light on this.
04-09-2008
SUGGESTED FIX http://orgrimmar.russia.sun.com/~in81039/WSrace/ or see diff attached
04-09-2008