JDK-8228671 : Fastdebug VM throws InternalError when publicLookup.in(T) is used to resolve a member
  • Type: Bug
  • Component: core-libs
  • Sub-Component: java.lang.invoke
  • Affected Version: 14
  • Priority: P1
  • Status: Closed
  • Resolution: Fixed
  • Submitted: 2019-07-26
  • Updated: 2020-04-29
  • Resolved: 2019-07-27
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 14
14 b08Fixed
Related Reports
Relates :  
JDK-8173977 - Unify access checks or make lookup mode available to VM
Relates :  
JDK-8173978 - Lookup.in should allow teleporting from a lookup class in a named module without dropping all access
Relates :  
JDK-8244090 - public lookup should find public members of public exported types
Description
(provisional synopsis, please change as you see fit)

After JDK-8173978 was pushed, tier1 tests started to fail:

$ CONF=linux-x86_64-server-fastdebug make images run-test TEST=java/lang/invoke/AccessControlTest.java

[TestNG] Running:
  java/lang/invoke/AccessControlTest.java

loaders = [jdk.internal.loader.ClassLoaders$AppClassLoader@6587524c]
filled in 99 cases from 9 original cases in 3 rounds
test test.java.lang.invoke.AccessControlTest.test(): failure
java.lang.InternalError: test.java.lang.invoke.AccessControlTest
	at java.base/java.lang.invoke.MethodHandleNatives.resolve(Native Method)
	at java.base/java.lang.invoke.MemberName$Factory.resolve(MemberName.java:1078)

$ CONF=linux-x86_64-server-fastdebug make images run-test TEST=java/lang/invoke/modules/Driver.java

test p1.Main.testPublicLookupToBaseModule(): failure
java.lang.InternalError: p1.Type1
	at java.base/java.lang.invoke.MethodHandleNatives.resolve(Native Method)
	at java.base/java.lang.invoke.MemberName$Factory.resolve(MemberName.java:1078)
	at java.base/java.lang.invoke.MemberName$Factory.resolveOrFail(MemberName.java:1106)
	at java.base/java.lang.invoke.MethodHandles$Lookup.resolveOrFail(MethodHandles.java:2750)
Comments
URL: https://hg.openjdk.java.net/jdk/jdk/rev/5e637f790bb8 User: mchung Date: 2019-07-27 21:49:35 +0000
27-07-2019
publicLookup().in(T) creates a new Lookup on T while it is still a public lookup. In debug build, VM performs access check using T as the caller when the new lookup is used to look up a member of another class; and skip this access check if the caller is Object (previously the sole class representing publicLookup). A quick fix is to pass Object.class for resolution for a Lookup object with UNCONDITIONAL mode. diff --git a/src/java.base/share/classes/java/lang/invoke/MethodHandles.java b/src/java.base/share/classes/java/lang/invoke/MethodHandles.java --- a/src/java.base/share/classes/java/lang/invoke/MethodHandles.java +++ b/src/java.base/share/classes/java/lang/invoke/MethodHandles.java @@ -1329,7 +1329,14 @@ // This is just for calling out to MethodHandleImpl. private Class<?> lookupClassOrNull() { - return (allowedModes == TRUSTED) ? null : lookupClass; + if (allowedModes == TRUSTED) { + return null; + } + if (allowedModes == UNCONDITIONAL) { + // use Object as the caller to pass to VM doing resolution + return Object.class; + } + return lookupClass; }
26-07-2019
tier1 has been passing from our internal CI system. This test passes in my local product build as well. I reproduce the failures with fastdebug build. Looking into it now. Something might go wrong that this tier1 test failure were not reported.
26-07-2019