JDK-8087223 : InterfaceMethod CP entry pointing to a class should cause ICCE
  • Type: Bug
  • Component: hotspot
  • Sub-Component: runtime
  • Affected Version: 9
  • Priority: P3
  • Status: Closed
  • Resolution: Fixed
  • Submitted: 2015-06-11
  • Updated: 2016-06-14
  • Resolved: 2015-11-18
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
9 b96Fixed
Related Reports
Cloners :  
Duplicate :  
Relates :  
Relates :  
Relates :  
Relates :  
Description
The following invoke instructions are successfully executed:
   invokestatic    #3; //InterfaceMethod C.foo:()V  
   invokestatic    #3; //Method I.foo:()V

where
  class C {...}
  interface I {...}  

JVMS-5.4.3.3 Method Resolution:
 " If C is an interface, method resolution throws an IncompatibleClassChangeError."
JVMS-5.4.3.4 Interface Method Resolution:
 "If C is not an interface, interface method resolution throws an IncompatibleClassChangeError"

Test case attached(IntfMethod.java):
$ java -Xverify:all IntfMethod
testSpecialIntf: FAILED (no exception)
testStaticIntf: FAILED (no exception)
testSpecialClass: FAILED (no exception)
testStaticClass: FAILED (no exception)

Comments
Verifying as "Fix Failed".
01-12-2015

The fix for this bug has been backed out due to JDK-8143320 Many vm/runtime/defmeth/scenarios/ConflictingDefaults_v50_none_direct_noredefine fail with ICCE, ExitCode: 97
30-11-2015

To check if resolve a correct method with the correct constant method tag, a tag needed to be carried for resolve_invoke functions. The call for resolve_invoke are from interpreter, compiler, reflect and MethodHandle. For interpreter and compiler we could carry constantTag which got based on constant pool index at the moment the method invoked. For reflection, we should not care about that since it should get the method based on class/method name/method signature correctly. For MethodHandle, there is not a workable way when call from Java to get the constant pool index at the time. It should be addressed in another bug.
11-11-2015

Method/interface method resolution caused by method handle resolution is also affected (for MH kinds REF_invokeStatic, REF_invokeSpecial, REF_newInvokeSpecial). Test cases are attached. $ asmtools jasm -d out/ BadInterfaceMethodRef.jasm $ java -cp out/ BadInterfaceMethodRef invokestatic invokespecial $ asmtools jasm -d out/ BadMethodRef.jasm <unrelated warnings here due to CODETOOLS-7901521> $ java -cp out/ BadMethodRef invokestatic invokespecial Exception in thread "main" java.lang.InstantiationException: BadMethodRef at sun.misc.Unsafe.allocateInstance(Native Method) at java.lang.invoke.DirectMethodHandle.allocateInstance(DirectMethodHandle.java:404) at BadMethodRef.main(BadMethodRef.jasm)
06-10-2015

The generated C.class (dumped as hex format): itf (see above comment) is indicator of interface C1.hex <=> C.class --- itf = false C2.hex <=> C.class --- itf = true -bash-4.1$ cat C1.hex 0000000: CAFE BABE 0000 0034 0018 0100 0143 0700 .......4.....C.. 0000010: 0101 0010 6A61 7661 2F6C 616E 672F 4F62 ....java/lang/Ob 0000020: 6A65 6374 0700 0301 0001 4907 0005 0100 ject......I..... 0000030: 063C 696E 6974 3E01 0003 2829 560C 0007 .<init>...()V... 0000040: 0008 0A00 0400 0901 000F 7465 7374 5370 ..........testSp 0000050: 6563 6961 6C49 6E74 6601 0002 6631 0C00 ecialIntf...f1.. 0000060: 0C00 080A 0006 000D 0100 0E74 6573 7453 ...........testS 0000070: 7461 7469 6349 6E74 6601 0002 6632 0C00 taticIntf...f2.. 0000080: 1000 080A 0006 0011 0100 1074 6573 7453 ...........testS 0000090: 7065 6369 616C 436C 6173 730B 0002 000D pecialClass..... 00000a0: 0100 0F74 6573 7453 7461 7469 6343 6C61 ...testStaticCla 00000b0: 7373 0B00 0200 1101 0004 436F 6465 0021 ss........Code.! 00000c0: 0002 0004 0001 0006 0000 0006 0001 0007 ................ 00000d0: 0008 0001 0017 0000 0011 0001 0001 0000 ................ 00000e0: 0005 2AB7 000A B100 0000 0000 0100 0B00 ..*............. 00000f0: 0800 0100 1700 0000 1100 0100 0100 0000 ................ 0000100: 052A B700 0EB1 0000 0000 0001 000F 0008 .*.............. 0000110: 0001 0017 0000 0010 0001 0001 0000 0004 ................ 0000120: B800 12B1 0000 0000 0001 0013 0008 0001 ................ 0000130: 0017 0000 0011 0001 0001 0000 0005 2AB7 ..............*. 0000140: 0014 B100 0000 0000 0900 1000 0800 0100 ................ 0000150: 1700 0000 0D00 0000 0100 0000 01B1 0000 ................ 0000160: 0000 0001 0015 0008 0001 0017 0000 0010 ................ 0000170: 0001 0001 0000 0004 B800 16B1 0000 0000 ................ 0000180: 0000 .. -bash-4.1$ cat C2/C2.hex 0000000: CAFE BABE 0000 0034 0018 0100 0143 0700 .......4.....C.. 0000010: 0101 0010 6A61 7661 2F6C 616E 672F 4F62 ....java/lang/Ob 0000020: 6A65 6374 0700 0301 0001 4907 0005 0100 ject......I..... 0000030: 063C 696E 6974 3E01 0003 2829 560C 0007 .<init>...()V... 0000040: 0008 0A00 0400 0901 000F 7465 7374 5370 ..........testSp 0000050: 6563 6961 6C49 6E74 6601 0002 6631 0C00 ecialIntf...f1.. 0000060: 0C00 080B 0006 000D 0100 0E74 6573 7453 ...........testS 0000070: 7461 7469 6349 6E74 6601 0002 6632 0C00 taticIntf...f2.. 0000080: 1000 080B 0006 0011 0100 1074 6573 7453 ...........testS 0000090: 7065 6369 616C 436C 6173 730A 0002 000D pecialClass..... 00000a0: 0100 0F74 6573 7453 7461 7469 6343 6C61 ...testStaticCla 00000b0: 7373 0A00 0200 1101 0004 436F 6465 0021 ss........Code.! 00000c0: 0002 0004 0001 0006 0000 0006 0001 0007 ................ 00000d0: 0008 0001 0017 0000 0011 0001 0001 0000 ................ 00000e0: 0005 2AB7 000A B100 0000 0000 0100 0B00 ..*............. 00000f0: 0800 0100 1700 0000 1100 0100 0100 0000 ................ 0000100: 052A B700 0EB1 0000 0000 0001 000F 0008 .*.............. 0000110: 0001 0017 0000 0010 0001 0001 0000 0004 ................ 0000120: B800 12B1 0000 0000 0001 0013 0008 0001 ................ 0000130: 0017 0000 0011 0001 0001 0000 0005 2AB7 ..............*. 0000140: 0014 B100 0000 0000 0900 1000 0800 0100 ................ 0000150: 1700 0000 0D00 0000 0100 0000 01B1 0000 ................ 0000160: 0000 0001 0015 0008 0001 0017 0000 0010 ................ 0000170: 0001 0001 0000 0004 B800 16B1 0000 0000 ................ 0000180: 0000 .. The only difference is two constant index: -bash-4.1$ diff C1.hex C2/C2.hex 7c7 < 0000060: 0C00 080A 0006 000D 0100 0E74 6573 7453 ...........testS --- > 0000060: 0C00 080B 0006 000D 0100 0E74 6573 7453 ...........testS 9,10c9,10 < 0000080: 1000 080A 0006 0011 0100 1074 6573 7453 ...........testS < 0000090: 7065 6369 616C 436C 6173 730B 0002 000D pecialClass..... --- > 0000080: 1000 080B 0006 0011 0100 1074 6573 7453 ...........testS > 0000090: 7065 6369 616C 436C 6173 730A 0002 000D pecialClass..... 12c12 < 00000b0: 7373 0B00 0200 1101 0004 436F 6465 0021 ss........Code.! --- > 00000b0: 7373 0A00 0200 1101 0004 436F 6465 0021 ss........Code.! 0A = 10 = CONSTANT_Methodref 0B = 11 = CONSTANT_InterfaceMethodref That is method indices in cp.
06-10-2015

With trace turned on, for testSpecialIntf: invokeinterface resolved method: caller-class:C, compile-time-class:I, method:I.f1()V, method_holder:I, access_flags: public default invokespecial resolved method: caller-class:C, compile-time-class:I, method:I.f1()V, method_holder:I, access_flags: public default invokespecial selected method: resolved-class:I, compile-time-class:I, method:I.f1()V, method_holder:I, access_flags: public default testSpecialInft says: mv.visitVarInsn(ALOAD, 0); mv.visitMethodInsn(INVOKESPECIAL, "I", "f1", "()V", /*itf=*/false); Given instance of C, call f1(), C is not an interface. The resolution shows, first, we resolve to invokeinterface then invokespecial and finally selected method is I.f1(). It looks itf = false (not interface) has no effect to the resulted bytecodes. If changed itf = true: invokeinterface resolved method: caller-class:C, compile-time-class:I, method:I.f1()V, method_holder:I, access_flags: public default invokespecial resolved method: caller-class:C, compile-time-class:I, method:I.f1()V, method_holder:I, access_flags: public default invokespecial selected method: resolved-class:I, compile-time-class:I, method:I.f1()V, method_holder:I, access_flags: public default Same resolution result. We have checking for invokeinterface for ICCE if non interface invoked. But for this case, instrument asm to have above case need more insight on the link/resolve process.
06-10-2015