United StatesChange Country, Oracle Worldwide Web Sites Communities I am a... I want to...
Bug ID: JDK-6744822 Race condition in JavawsSysRun
JDK-6744822 : Race condition in JavawsSysRun

Details
Type:
Bug
Submit Date:
2008-09-04
Status:
Closed
Updated Date:
2010-09-17
Project Name:
JDK
Resolved Date:
2008-10-02
Component:
deploy
OS:
generic,windows_xp
Sub-Component:
webstart
CPU:
x86,generic
Priority:
P2
Resolution:
Fixed
Affected Versions:
6,6u10,7
Fixed Versions:
6u10 (b33)

Related Reports
Backport:
Duplicate:
Duplicate:

Sub Tasks

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
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.
                                     
2008-09-04
SUGGESTED FIX

http://orgrimmar.russia.sun.com/~in81039/WSrace/

or see diff attached
                                     
2008-09-04
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).
                                     
2008-09-09
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.
                                     
2008-09-09
SUGGESTED FIX

Updated fix:
http://orgrimmar.russia.sun.com/~in81039/6744822/
                                     
2008-09-09



Hardware and Software, Engineered to Work Together