JDK-8143320 : Many vm/runtime/defmeth/scenarios/ConflictingDefaults_v50_none_direct_noredefine fail with ICCE, ExitCode: 97
  • Type: Bug
  • Component: hotspot
  • Sub-Component: runtime
  • Affected Version: 9
  • Priority: P2
  • Status: Closed
  • Resolution: Fixed
  • Submitted: 2015-11-19
  • Updated: 2017-08-17
  • Resolved: 2016-06-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 9
9Fixed
Related Reports
Blocks :  
JDK-8147755 - ASM should create correct constant tag for invokestatic on handle point to interface static method
Blocks :  
JDK-8145148 - InterfaceMethod CP entry pointing to a class should cause ICCE
Relates :  
JDK-8145148 - InterfaceMethod CP entry pointing to a class should cause ICCE
Relates :  
JDK-8147419 - Missing check for interface static method referenced by method handle
Relates :  
JDK-8087223 - InterfaceMethod CP entry pointing to a class should cause ICCE
Relates :  
JDK-8158276 - [TESTBUG] Two defmeth tests fail with ICCE
Sub Tasks
JDK-8143324 :  
Backout JDK-8087223 - Resolved
Description
Over 100 hs-nightly tests failed with errors such as these:

[2015-11-19T04:19:31.72] 	Test6_A_C_test_Amethod_ISIMR  : FAILED
[2015-11-19T04:19:31.72] 		Expected exception java.lang.AbstractMethodError, got: class java.lang.IncompatibleClassChangeError: Resolving to non interface method J.m()I

[2015-11-19T04:19:32.57] 		Expected exception java.lang.AbstractMethodError, got: class java.lang.IncompatibleClassChangeError: Resolving to non interface method J.m()I
[2015-11-19T04:19:32.57] ConflictingDefaultsTest.testShadow
Comments
Recommendation: the fix should use the correct methodRef or interfaceMethodRef rather than changing the expected failure where possible.
30-03-2016
The ASM fix is in hs-rt. The last part of this change for ClassFileGenerator.java needs to be integrated, right? I ran the defmeth tests with Yumin's original patch (without missing checks) and two failed: vm/runtime/defmeth/scenarios/Stress_noredefine vm/runtime/defmeth/scenarios/Stress_redefine philli% more *.eout Testlist size: 864 Seed: 2095706055 Spawning 5 workers... 60s left: [0, 0, 0, 0, 0] Worker #1/5: FAILED: DefaultVsAbstractTest{ver=51; flags=32; redefine=false; execMode=INVOKE_GENERIC } (executed: 4) Worker #2/5: PASSED (executed: 3) Worker #3/5: FAILED: ConflictingDefaultsTest{ver=51; flags=32; redefine=false; execMode=INVOKE_GENER IC} (executed: 0) Worker #4/5: PASSED (executed: 4) Worker #5/5: FAILED: StaticMethodsTest{ver=51; flags=2048; redefine=false; execMode=INDY} (executed: 1) Which seems different.
25-03-2016
With 8147755 resolved from ASM5.1, the new Handle.java constructor with an extra boolean parameter indicating that the handle is pointing to an interface method (or field). The new patch used this newly added ctor to create Handle, solved the problem mentioned above.
04-02-2016
The test will still fail when 8145148 fixed --- basically same as 8087223. The failures here need to be corrected in defmeth.
15-12-2015
I think this bug was being used to fix the defmeth tests.
14-12-2015
This will be fixed as part of JDK-8145148
14-12-2015
The above data was wrong --- I double checked, the original pool data already screwed up, but keep for record without deleting it from comment. Further analysis shows that the defmeth has problem with creating default static method call of interface for MethodHandle invocation: It generated static invoke but interface invoke for method handle. The former uses Methodref which will violate jvm spec: JVMS-5.4.3.3 Method Resolution: " If C is an interface, method resolution throws an IncompatibleClassChangeError." Here invoking interface with Methodref.
10-12-2015
Basically, 8087223 fix is checking constant pool consistency. The fix itself has no problem --- but the testcases have for the fix. The defmeth tests failed 8087223 on three kinds: 1) ConflictingDefaults: CallSite did not set interface call with JVM_CONSTANT_InterfaceMethodref, instead, it used JVM_CONSTANT_Methodref. This can be modified in the test case use correct tag. Since the fix, also need to throw VE in all lower versions (<52) due to the version check. 2) DefaultVsAbstractTest: The expected Error is IAE (IllegalAccessError), but before we get IAE, ICCE thrown as interception. So should change to expect ICCE in the test cases like testInvokeInterfaceClassDefaultMethod 3) StaticMethodsTest: This is most confused failures. The agent has changed class bytes, i.e: public class Test1_I__m minor version: 0 major version: 52 flags: ACC_PUBLIC, ACC_SUPER Constant pool: #1 = Utf8 Test1_I__m #2 = Class #1 // Test1_I__m #3 = Utf8 java/lang/Object #4 = Class #3 // java/lang/Object #5 = Utf8 <init> #6 = Utf8 ()V #7 = NameAndType #5:#6 // "<init>":()V #8 = Methodref #4.#7 // java/lang/Object."<init>":()V #9 = Utf8 test #10 = Utf8 I #11 = Class #10 // I #12 = Utf8 m #13 = Utf8 ()I #14 = NameAndType #12:#13 // m:()I #15 = InterfaceMethodref #11.#14 // I.m:()I #16 = Utf8 nsk/share/test/TestUtils #17 = Class #16 // nsk/share/test/TestUtils #18 = Utf8 assertEquals #19 = Utf8 (II)V #20 = NameAndType #18:#19 // assertEquals:(II)V #21 = Methodref #17.#20 // nsk/share/test/TestUtils.assertEquals:(II)V #22 = Utf8 Code Note: public Test1_I__m(); descriptor: ()V flags: ACC_PUBLIC ... public static void test(); descriptor: ()V flags: ACC_PUBLIC, ACC_STATIC Code: stack=2, locals=0, args_size=0 0: invokestatic #15 // InterfaceMethod I.m:()I 3: bipush 1 5: invokestatic #21 // Method nsk/share/test/TestUtils.assertEquals:(II)V 8: return According to the pool content, #15 is correct. But it failed on "Inconsistent constant data for I.m()I at index 16" See below, after transformed, the tag for m()I became Methodref. 1 : 1 2 : 100 3 : 1 4 : 100 5 : 1 6 : 1 7 : 12 8 : 10 9 : 1 10 : 1 11 : 100 12 : 1 13 : 1 14 : 12 15 : 10 <---- methodref 16 : 15 <---- handle, 17 : 1 18 : 100 19 : 1 20 : 12 21 : 10 22 : 1 23 : 100 24 : 1 25 : 1 26 : 12 27 : 10 28 : 1 The problem occurred in the transform, it should not change the method tag.
02-12-2015
Took data from one failure: Test6_A_C_test_Amethod_ISIMR 0: new #15 // class C 3: dup 4: invokespecial #16 // Method C."<init>":()V 7: astore_1 8: aload_1 9: invokevirtual #21 // Method A.test_Amethod_ISIMR:()V 12: new #23 // class nsk/share/TestFailure 15: dup 16: ldc #25 // String No exception was thrown ... This is A a = new C(); a.test_Amethod_ISIMR:(); A: public void test_Amethod_ISIMR(); descriptor: ()V flags: ACC_PUBLIC Code: stack=1, locals=1, args_size=1 0: aload_0 1: invokespecial #17 // Method J.m:()I 4: pop 5: return Note #17 in constant pool: #17 = Methodref #6.#16 // J.m:()I So when resolving the method, with fix of 8087223, resolving it to non interface method will cause ICCE, which caught first. For the passed case, like Test5_C_C_test_Cmethod_ISMR: 0: new #15 // class C 3: dup 4: invokespecial #16 // Method C."<init>":()V 7: astore_1 8: aload_1 9: invokevirtual #19 // Method C.test_Cmethod_ISMR:()V It calls C.test_Cmethod_ISMR:()V C: public void test_Cmethod_ISMR(); descriptor: ()V flags: ACC_PUBLIC Code: stack=1, locals=1, args_size=1 0: aload_0 1: invokespecial #13 // Method m:()I 4: pop 5: return Here, C.m is first as a class method resolution, not interface, so it can catch AME first. The fix of 8087223 changed the order of catching Error, it throws ICCE first. this is why it fails on ICCE but AME.
24-11-2015