JDK-8211921 : AssertionError in MethodHandles$Lookup.defineClass
  • Type: Bug
  • Component: core-libs
  • Sub-Component: java.lang.invoke
  • Affected Version: 12
  • Priority: P2
  • Status: Resolved
  • Resolution: Fixed
  • Submitted: 2018-10-09
  • Updated: 2023-12-25
  • Resolved: 2018-10-10
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 12
12 b16Fixed
Related Reports
Relates :  
JDK-8181443 - Replace usages of jdk.internal.misc.Unsafe with MethodHandles.Lookup.defineClass
Relates :  
JDK-8211850 - test/jdk/javax/naming/module/RunBasic.java fails intermittently
Description
stderr: [Exception in thread "main" java.lang.AssertionError
	at java.base/java.lang.invoke.MethodHandles$Lookup.defineClass(MethodHandles.java:972)
	at java.base/java.lang.invoke.ClassSpecializer$Factory$1.run(ClassSpecializer.java:585)
	at java.base/java.lang.invoke.ClassSpecializer$Factory$1.run(ClassSpecializer.java:581)
	at java.base/java.security.AccessController.doPrivileged(Native Method)
	at java.base/java.lang.invoke.ClassSpecializer$Factory.generateConcreteSpeciesCode(ClassSpecializer.java:581)
	at java.base/java.lang.invoke.ClassSpecializer$Factory.loadSpecies(ClassSpecializer.java:489)
	at java.base/java.lang.invoke.ClassSpecializer.findSpecies(ClassSpecializer.java:193)
	at java.base/java.lang.invoke.BoundMethodHandle$SpeciesData.extendWith(BoundMethodHandle.java:352)
	at java.base/java.lang.invoke.LambdaFormEditor.newSpeciesData(LambdaFormEditor.java:388)
	at java.base/java.lang.invoke.LambdaFormEditor.bindArgumentForm(LambdaFormEditor.java:451)
	at java.base/java.lang.invoke.LambdaFormEditor.bindArgumentI(LambdaFormEditor.java:402)
	at java.base/java.lang.invoke.BoundMethodHandle.bindArgumentI(BoundMethodHandle.java:100)
	at java.base/java.lang.invoke.MethodHandles.insertArgumentPrimitive(MethodHandles.java:3537)
	at java.base/java.lang.invoke.MethodHandles.insertArguments(MethodHandles.java:3518)
	at java.base/java.lang.invoke.StringConcatFactory$MethodHandleInlineCopyStrategy.generate(StringConcatFactory.java:1621)
	at java.base/java.lang.invoke.StringConcatFactory.generate(StringConcatFactory.java:756)
	at java.base/java.lang.invoke.StringConcatFactory.doStringConcat(StringConcatFactory.java:665)
	at java.base/java.lang.invoke.StringConcatFactory.makeConcatWithConstants(StringConcatFactory.java:581)
	at java.base/java.lang.invoke.BootstrapMethodInvoker.invoke(BootstrapMethodInvoker.java:99)
	at java.base/java.lang.invoke.CallSite.makeSite(CallSite.java:307)
	at java.base/java.lang.invoke.MethodHandleNatives.linkCallSiteImpl(MethodHandleNatives.java:258)
	at java.base/java.lang.invoke.MethodHandleNatives.linkCallSite(MethodHandleNatives.java:248)
	at java.naming/com.sun.naming.internal.VersionHelper.lambda$getJavaHomeConfStream$3(VersionHelper.java:201)
	at java.base/java.security.AccessController.doPrivileged(Native Method)
	at java.naming/com.sun.naming.internal.VersionHelper.getJavaHomeConfStream(VersionHelper.java:208)
	at java.naming/com.sun.naming.internal.ResourceManager.getApplicationResources(ResourceManager.java:530)
	at java.naming/com.sun.naming.internal.ResourceManager.getInitialEnvironment(ResourceManager.java:188)
	at java.naming/javax.naming.InitialContext.init(InitialContext.java:232)
	at java.naming/javax.naming.InitialContext.<init>(InitialContext.java:208)
	at java.naming/javax.naming.directory.InitialDirContext.<init>(InitialDirContext.java:101)
	at test/test.StoreRemote.main(StoreRemote.java:108)
java.net.SocketException: Socket is closed
	at java.base/java.net.ServerSocket.accept(ServerSocket.java:515)
	at test/test.LDAPServer.<init>(LDAPServer.java:69)
	at test/test.StoreRemote$1.run(StoreRemote.java:82)
	at java.base/java.lang.Thread.run(Thread.java:835)
Comments
URL: https://github.com/openjdk/jdk/commit/5a36050cfda56a332e3df811eff53a54fd8a48c1 Author: Mandy Chung <mchung@openjdk.org> Date: Wed Oct 10 15:19:34 2018 -0700
25-12-2023
URL: http://hg.openjdk.java.net/jdk/jdk/rev/fc52ccf451cd User: mchung Date: 2018-10-10 22:19:59 +0000
10-10-2018
[~chegar] thanks for reproducing the intermittent test failure with my patch. This helps proving my hypothesis (two different PD instances but both are AllPermission). I think this assertion is not strictly needed. stderr: [Exception in thread "main" java.lang.Error: lookup: java.lang.invoke.BoundMethodHandle loader: null protection domain: ProtectionDomain null null <no principals> java.security.Permissions@63c12fb0 ( ("java.security.AllPermission" "<all permissions>" "<all actions>") ) defined class PD: ProtectionDomain null null <no principals> java.security.Permissions@b1a58a3 ( ("java.security.AllPermission" "<all permissions>" "<all actions>") )
10-10-2018
Class::getProtectionDomain doesn't guarantee that it returns the same PD when the class is in null protection domain. Lookup::lookupClassProtectionDomain is the same. The assertion that the PD objects are == is therefore not reliable but it can be replaced with an alternative check for the null protection domain case.
10-10-2018
Most likely related to JDK-8181443.
09-10-2018