JDK-8161700 : Deadlock in Java Web Start application involving JNLPClassLoader
  • Type: Bug
  • Component: deploy
  • Sub-Component: webstart
  • Affected Version: 7u111,8u102
  • Priority: P2
  • Status: Resolved
  • Resolution: Fixed
  • OS: windows
  • Submitted: 2016-07-19
  • Updated: 2018-09-24
  • Resolved: 2016-08-09
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 7 JDK 8
7u111Fixed 8u111Fixed
Related Reports
Duplicate :  
Duplicate :  
Description
FULL PRODUCT VERSION :
JRE 8u102 b14, JRE 7u111 b13

ADDITIONAL OS VERSION INFORMATION :
MS Windows 10 OS, MS Windows 7 OS

A DESCRIPTION OF THE PROBLEM :
Java Web Start application, which sets a custom class loader as its threads' context class loader, hangs, because of the deadlock between "JNLPClassLoader" and the application's custom class loader which occurs in the method "com.sun.deploy.security.DeployURLClassPath.getLoader".

STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
1. Upload JAR, JNLP files of the minimal test case attached to the bug as the file "DeadlockWithCustomAndJNLPClassLoaders.zip" to the same directory on an accessible web server.
2. Edit "codebase" attribute value in the uploaded JNLP file "DeadlockWithCustomAndJNLPClassLoaders.jnlp" to reflect a URL to the directory, where the file was uploaded.
3. Install JRE 8 or JRE 7 to be tested.
4. Go to "Java Control Panel -> Advanced" and:

  a. Switch on the options: "Enable tracing", "Enable logging", "Show applet lifecycle exceptions" in "Debugging" group.
  b. Set "Java console" to "Show console".

5. Open Internet Explorer (IE) web browser and load JNLP file of the test case uploaded to the web server, Java Web Start application should run. If the following 2 messages are not displayed in Java Console window, the deadlock is reproduced.

  a. "JAVAWSAPP_TRACE: Creation of instances of 'B' classes finished."
  b. "JAVAWSAPP_TRACE: Loading of 'A' classes finished."

6. If the bug is reproduced, then exit IE, start "taskmgr.exe" and terminate the remaining "jp2launcher.exe" process containing the deadlock in "Processes" tab of the shown "Windows Task Manager" window.

ERROR MESSAGES/STACK TRACES THAT OCCUR :

---------- Call stacks of 2 threads blocking each other from the attached thread dump "ThreadDumpWithDeadlockIn8u102b14.txt" ----------
Found one Java-level deadlock:
=============================
"Thread-24":
  waiting to lock monitor 0x199d1b1c (object 0x0a969fa0, a mainpkg.DeadlockWithCustomAndJNLPClassLoaders$1),
  which is held by "javawsApplicationMain"
"javawsApplicationMain":
  waiting to lock monitor 0x172ad784 (object 0x0a227158, a com.sun.jnlp.JNLPClassLoader),
  which is held by "Thread-24"

Java stack information for the threads listed above:
===================================================
"Thread-24":
        at com.sun.deploy.security.DeployURLClassPath.getLoader(Unknown Source)
        - waiting to lock <0x0a969fa0> (a mainpkg.DeadlockWithCustomAndJNLPClassLoaders$1)
        at com.sun.deploy.security.DeployURLClassPath.getResource(Unknown Source)
        at java.net.URLClassLoader$1.run(Unknown Source)
        at java.net.URLClassLoader$1.run(Unknown Source)
        at java.security.AccessController.doPrivileged(Native Method)
        at java.net.URLClassLoader.findClass(Unknown Source)
        at com.sun.jnlp.JNLPClassLoader.findClass(Unknown Source)
        at java.lang.ClassLoader.loadClass(Unknown Source)
        - locked <0x0a26b3e0> (a com.sun.jnlp.JNLPClassLoader)
        at com.sun.jnlp.JNLPClassLoader.loadClass(Unknown Source)
        at java.lang.ClassLoader.loadClass(Unknown Source)
        - locked <0x0a227158> (a com.sun.jnlp.JNLPClassLoader)
        at com.sun.jnlp.JNLPClassLoader.loadClass(Unknown Source)
        at java.lang.ClassLoader.loadClass(Unknown Source)
        at mainpkg.DeadlockWithCustomAndJNLPClassLoaders$2.run(DeadlockWithCustomAndJNLPClassLoaders.java:65)
        at java.lang.Thread.run(Unknown Source)
"javawsApplicationMain":
        at mainpkg.DeadlockWithCustomAndJNLPClassLoaders$1.loadClass(DeadlockWithCustomAndJNLPClassLoaders.java:42)
        at java.lang.ClassLoader.loadClass(Unknown Source)
        at java.lang.ClassLoader.defineClass1(Native Method)
        at java.lang.ClassLoader.defineClass(Unknown Source)
        at java.security.SecureClassLoader.defineClass(Unknown Source)
        at java.net.URLClassLoader.defineClass(Unknown Source)
        at java.net.URLClassLoader.access$100(Unknown Source)
        at java.net.URLClassLoader$1.run(Unknown Source)
        at java.net.URLClassLoader$1.run(Unknown Source)
        at java.security.AccessController.doPrivileged(Native Method)
        at java.net.URLClassLoader.findClass(Unknown Source)
        at java.lang.ClassLoader.loadClass(Unknown Source)
        - locked <0x0a969fa0> (a mainpkg.DeadlockWithCustomAndJNLPClassLoaders$1)
        at mainpkg.DeadlockWithCustomAndJNLPClassLoaders$1.loadClass(DeadlockWithCustomAndJNLPClassLoaders.java:53)
        at java.lang.ClassLoader.loadClass(Unknown Source)
        at java.lang.Class.forName0(Native Method)
        at java.lang.Class.forName(Unknown Source)
        at mainpkg.DeadlockWithCustomAndJNLPClassLoaders.main(DeadlockWithCustomAndJNLPClassLoaders.java:99)
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
        at java.lang.reflect.Method.invoke(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
UR SQE OK to take the fix of regression caused by JDK-8151703 to CPU16_04.
16-08-2016

The minimal test case was created and attached to the bug record as "DeadlockWithCustomAndJNLPClassLoaders.zip" file. Also the bug was reproduced using the created minimal test case with JRE 7u111 b13, JRE 7u111 b01, the bug could not be reproduced with JRE 7u101 b14. The bug is caused by synchronization on the thread context class loader added to the method "com.sun.deploy.security.DeployURLClassPath.getLoader" by the fix JDK-8151703.
08-08-2016

The deadlock was reproduced on MS Windows 7 OS using the provided by the user test case with JRE 8u102 b14. The deadlock could not be reproduced on the same host with JRE 8u101 b13. Was able to reproduce the deadlock with JDK 8 compiled from the latest version of the development source code. It was practically proven that reversion of the fix for the bug JDK-8151703 from this JDK 8 source code allows to eliminate the issue. Thus the bug is caused by the fix JDK-8151703. Studying thread dumps generated in my local environment and the source code of the user's custom class loader. Also working on identification of the second lock which is involved in the deadlock.
26-07-2016