JDK-8065194 : custom non-parallel classloader deadlock, when kerberos authentication is used
  • Type: Bug
  • Component: core-libs
  • Sub-Component: java.net
  • Affected Version: 8u25
  • Priority: P3
  • Status: Resolved
  • Resolution: Cannot Reproduce
  • OS: other
  • CPU: x86
  • Submitted: 2014-11-12
  • Updated: 2015-03-30
  • Resolved: 2015-03-30
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
tbd_majorResolved
Related Reports
Duplicate :  
JDK-8032832 - Applet/browser deadlocks, when IIS integrated authentication is used
Description
FULL PRODUCT VERSION :


ADDITIONAL OS VERSION INFORMATION :
Any OS.

A DESCRIPTION OF THE PROBLEM :
As result of http://bugs.java.com/bugdatabase/view_bug.do?bug_id=8032832 we have several deadlocks ��� https://youtrack.jetbrains.com/issue/IDEA-132532, https://youtrack.jetbrains.com/issue/IDEA-131621

Problem: Custom class loader is not parallel, but NegotiateAuthentication locks class loader.

REGRESSION.  Last worked in version 8u5

STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
1) Clone https://github.com/develar/__test-proxy.git
2) Open project in IDEA (or another IDE).
3) Run TestProxy run configuration (or TestProxy class if you don't use IDEA).

You need to use proxy server with Kerberos authentication (Proxy-Authenticate: Kerberos). To simplify I implemented small test proxy just to reproduce the bug.

4) Run Client run configuration.

EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
No deadlock.
ACTUAL -
"AWT-EventQueue-0@1097" prio=6 tid=0xf nid=NA waiting for monitor entry
  java.lang.Thread.State: BLOCKED
	 waiting for main@1 to release lock on <0x4bf> (a org.jetbrains.testProxy.Client$1)
	  at java.lang.ClassLoader.loadClass(ClassLoader.java:406)
	  at java.lang.ClassLoader.loadClass(ClassLoader.java:357)
	  at org.jetbrains.testProxy.Client$2$1.run(Client.java:26)
	  at java.awt.event.InvocationEvent.dispatch(InvocationEvent.java:301)
	  at java.awt.EventQueue.dispatchEventImpl(EventQueue.java:744)
	  at java.awt.EventQueue.access$400(EventQueue.java:97)
	  at java.awt.EventQueue$3.run(EventQueue.java:697)
	  at java.awt.EventQueue$3.run(EventQueue.java:691)
	  at java.security.AccessController.doPrivileged(AccessController.java:-1)
	  at java.security.ProtectionDomain$1.doIntersectionPrivilege(ProtectionDomain.java:75)
	  at java.awt.EventQueue.dispatchEvent(EventQueue.java:714)
	  at java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:201)
	  at java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:116)
	  at java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:105)
	  at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:101)
	  at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:93)
	  at java.awt.EventDispatchThread.run(EventDispatchThread.java:82)

REPRODUCIBILITY :
This bug can be reproduced always.

CUSTOMER SUBMITTED WORKAROUND :
Set thread context loader to fake class loader (see https://github.com/JetBrains/intellij-community/commit/16f81a97df32444689811cba068aafb3e4b02d70#diff-ffd6472c4e25ed3a15cb659209821f13R73). 

Or implement parallel custom classloader. It is not real option because it is dangerous change.
Comments
Is there more to do here? The IDEA-133187 comments indicate the issue doesn't reproduce with 9.
26-01-2015
Reopened to consider user analysis with JDK 9ea and reference url: https://youtrack.jetbrains.com/issue/IDEA-133187
10-12-2014
Response from the submitter: ���Looks like issue not reproducing with JDK 9, thank you!��� (https://youtrack.jetbrains.com/issue/IDEA-133187#comment=27-856571), I cannot ��� "AWT-EventQueue-0@1142" prio=6 tid=0xe nid=NA waiting for monitor entry java.lang.Thread.State: BLOCKED waiting for main@1 to release lock on <0x484> (a org.jetbrains.testProxy.Client$1) at java.lang.ClassLoader.loadClass(ClassLoader.java:405) at java.lang.ClassLoader.loadClass(ClassLoader.java:356) at org.jetbrains.testProxy.Client$2$1.run(Client.java:23) at java.awt.event.InvocationEvent.dispatch(InvocationEvent.java:301) at java.awt.EventQueue.dispatchEventImpl(EventQueue.java:752) at java.awt.EventQueue.access$500(EventQueue.java:97) at java.awt.EventQueue$3.run(EventQueue.java:705) at java.awt.EventQueue$3.run(EventQueue.java:699) at java.security.AccessController.doPrivileged(AccessController.java:-1) at java.security.ProtectionDomain$1.doIntersectionPrivilege(ProtectionDomain.java:76) at java.awt.EventQueue.dispatchEvent(EventQueue.java:722) at java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:190) at java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:115) at java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:104) at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:100) at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:92) at java.awt.EventDispatchThread.run(EventDispatchThread.java:81) jdk-9-ea-bin-b39-macosx-x86_64-12_nov_2014. As I can see, class loader is still used as lock object. public static boolean isSupported(HttpCallerInfo var0) { ClassLoader var1 = null; try { var1 = Thread.currentThread().getContextClassLoader(); } catch (SecurityException var5) { if(logger.isLoggable(Level.FINER)) { logger.finer("NegotiateAuthentication: Attempt to get the context class loader failed - " + var5); } } if(var1 != null) { synchronized(var1) { return isSupportedImpl(var0); } } else { return isSupportedImpl(var0); } }
24-11-2014
This seems a duplicate of JDK-8032832. Asked customer to verify fix with JDK 9.
18-11-2014