JDK-8004967 : Default method cause java.lang.VerifyError: Illegal use of nonvirtual function call
  • Type: Bug
  • Component: hotspot
  • Sub-Component: runtime
  • Affected Version: hs25,8
  • Priority: P2
  • Status: Closed
  • Resolution: Fixed
  • Submitted: 2012-12-12
  • Updated: 2017-05-17
  • Resolved: 2013-02-08
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 8 Other
8Fixed hs25Fixed
Related Reports
Blocks :  
JDK-8001667 - Comparator combinators and extension methods
Blocks :  
JDK-8005051 - default methods for Iterator
Duplicate :  
JDK-8006291 - nightly-tl build can not launch tomcat 5.5 server because of some security class
Sub Tasks
JDK-8007888 :  
JDK changes to fix - Default method cause java.lang.VerifyError: Illegal use of nonvirtual function call - Resolved
JDK-8008185 :  
Remove failing tests from ProblemList.txt - Resolved
Description
Extend an interface with default method, existing code using that interface build with -target 1.5 will cause throwing java.lang.VerifyError with "Illegal use of nonvirtual function call".

Attached is a test case to illustrate the bug.

Build TestInterface.java + MyInterface.java.1.5(rename to MyInterface.java) with
$ cp MyInterface.java.1.5 MyInterface.java
$ javac -source 1.5 -target 1.5 TestInterface.java
$java TestInterface
foo

Now replace MyInterface with new version,

$ cp MyInterface.java.1.8 MyInterface.java
$ javac MyInterace.java
$ java TestInterface
Exception in thread "main" java.lang.VerifyError: (class: TestInterface$1, method: bar signature: ()V) Illegal use of nonvirtual function call
	at TestInterface.main(TestInterface.java:3)


Note that build to target 1.6 works as expected.
Comments
Tests successfully run with the fixes : closed/sun/management/snmp/* and the attached TestInterface + MyInterface test.
13-02-2013
Hotspot changes not yet in jdk8/tl/hotspot tree. Hence changes to the jdk8/tl tree not in yet. So, these failures will be seen till the this push is done. Keeping the bug open.
08-02-2013
The fix to this issue is two-fold - one in hotspot tree and the other in jdk tree. Changes to hotspot were checked in http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/815957d0203e. Changes to the jdk8/tl tree can only be done once the hotspot changes make it to the jdk8/tl/hotspot tree. So, these failures will be seen till the second push is done. Hence reopening.
07-02-2013
UTE bigapps/Weblogic+medrec is affected by this, and must be run with -noverify. The affected class (weblogic/security/principal/WLSKernelIdentity) is inside ${UTE}/local/common/testbase/bigapps/Weblogic+medrec/modules/com.bea.core.weblogic.security.identity_1.1.2.1.jar Initializing WebLogic Scripting Tool (WLST) ... Welcome to WebLogic Server Administration Scripting Shell Type help() for help on available commands Connecting to t3://localhost:7011 with userid weblogic ... This Exception occurred at Tue Feb 05 08:32:45 PST 2013. java.lang.VerifyError: (class: weblogic/security/principal/WLSKernelIdentity, method: implies signature: (Ljavax/security/auth/Subject;)Z) Illegal use of nonvirtual function call at weblogic.security.service.SubjectManagerImpl.initializeKernelID(SubjectManagerImpl.java:288) at weblogic.security.service.SubjectManagerImpl.<clinit>(SubjectManagerImpl.java:29) at weblogic.security.service.SecurityManager.<clinit>(SecurityManager.java:24) at weblogic.security.service.GetKernelIdentityAction.run(GetKernelIdentityAction.java:25) at java.security.AccessController.doPrivileged(Native Method) at weblogic.jndi.WLSJNDIEnvironmentImpl.<clinit>(WLSJNDIEnvironmentImpl.java:56) at java.lang.Class.forName0(Native Method) at java.lang.Class.forName(Class.java:182) .....
05-02-2013
The fix to this issue is two-fold - one in hotspot tree and the other in jdk tree. Changes to hotspot were checked in http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/815957d0203e. Changes to the jdk8/tl tree can only be done once the hotspot changes make it to the jdk8/tl/hotspot tree. So, these failures will be seen till the second push is done. Hence reopening.
01-02-2013
Java DB will be blocked by this bug very soon. We are working around it right now, but we expect to exhaust our workarounds in a week or two. Now that JDBC 4.2 has been checked in, Java DB no longer runs on Java 8. Trying to get a Java DB connection now trips across this VerifyError because of default methods which JDBC 4.2 added to java.sql.DatabaseMetaData.
28-01-2013
Following tests fail too Match result for aurora nighlty: These two testcase failed with: Exception in thread "main" java.lang.VerifyError: (class: com/rsa/cryptoj/c/lh, method: isDestroyed signature: ()Z) Illegal use of nonvirtual function call [2013-01-24T13:57:19.96] at com.rsa.cryptoj.c.aW.a(Unknown Source) [2013-01-24T13:57:19.96] at com.rsa.cryptoj.c.fH.engineTranslateKey(Unknown Source) [2013-01-24T13:57:19.96] at java.security.KeyFactory.translateKey(KeyFactory.java:450) [2013-01-24T13:57:19.96] at TestDSAKeyTranslateSunVsCryptoJ_usingDSAGenParameterSpec.testDSA(TestDSAKeyTranslateSunVsCryptoJ_usingDSAGenParameterSpec.java:96) [2013-01-24T13:57:19.96] at TestDSAKeyTranslateSunVsCryptoJ_usingDSAGenParameterSpec.main(TestDSAKeyTranslateSunVsCryptoJ_usingDSAGenParameterSpec.java:72) NSASuiteB/TestDSAKeyTranslateSunVsCryptoJ NSASuiteB/TestDSAKeyTranslateSunVsCryptoJ_usingDSAGenParameterSpec
25-01-2013
It looks like WLS is blocked by this.
24-01-2013
I have a change currently in the code review process on the hotspot-runtime-dev and core-libs mailing lists. I also have submitted a CCC to allow me to push the changes.
22-01-2013
What is the status of this bug? The patch by Keith(http://hg.openjdk.java.net/lambda/lambda/jdk/rev/a6d1367431c0) is not yet in TL, and it is not clear to me whether this bug caused problem reported by Sean or the patch cause problem.
22-01-2013
This is causing a new failure in nightly-tl build when trying to start a tomcat server: see JDK-8006291.
15-01-2013
jdk8/tl has the changes for JDK-8004967 and is running into this VerifyError with several applications. As fix to JDK-8004967 is becoming very urgent as it will likely impact the testing of promoted builds very soon.
15-01-2013
I just added the above tests to the test/closed/ProblemList (see 8006009) until this issue is resolved. Ideally, these tests should be removed from the ProblemList as part of this fix.
10-01-2013
Regarding the test failures in closed/sun/management/snmp: The classes causing the exception are from test/closed/sun/management/snmp/testlib/jdmk/lib/jsnmpapi.jar which is compiled with JDK 1.2 (source version 46).
10-01-2013
The following tests in jdk/test/closed repo are currently impacted by this issue: FAILED: closed/sun/management/snmp/bootstrap/SnmpBootstrapTest.sh FAILED: closed/sun/management/snmp/bootstrap/SnmpNotifBootstrapTest.sh FAILED: closed/sun/management/snmp/generic/GenericTest.sh FAILED: closed/sun/management/snmp/jvmClassLoading/ClassLoadingTest.sh FAILED: closed/sun/management/snmp/jvmClassLoading/ClassVerboseTest.sh FAILED: closed/sun/management/snmp/jvmMemory/JvmMemGCTest.sh FAILED: closed/sun/management/snmp/jvmMemory/JvmMemMgrTest.sh FAILED: closed/sun/management/snmp/jvmMemory/JvmMemPoolTest.sh FAILED: closed/sun/management/snmp/jvmMemory/JvmMemoryTest.sh FAILED: closed/sun/management/snmp/jvmThreading/JvmThreadingTest.sh FAILED: closed/sun/management/snmp/notifications/NotificationTest.sh FAILED: closed/sun/management/snmp/snmpCounter64/SnmpCounter64Test.sh
10-01-2013
The necessary change to address this situation and a corresponding test were checked into the Lambda-JDK repository by Keith (http://hg.openjdk.java.net/lambda/lambda/jdk/rev/a6d1367431c0) in June 2012. I have ported these changes to the TL tree and tested successfully. Someone needs to push it to TL. I do not yet have the privileges to do so.
08-01-2013
Robert guided to collect some more diagnosis, the problem exist for class file version 49(generated with -target 1.5) but not 50(generated with -target 1.6). The problematic main program javap output, $ javap -v TestInterface.class Classfile /home/hjen/test/java/TestInterface.class Last modified Dec 12, 2012; size 386 bytes MD5 checksum 714b3f086191d2196e7fd2b013ab201a Compiled from "TestInterface.java" public class TestInterface SourceFile: "TestInterface.java" InnerClasses: static #2; //class TestInterface$1 minor version: 0 major version: 49 flags: ACC_PUBLIC, ACC_SUPER Constant pool: #1 = Methodref #6.#17 // java/lang/Object."<init>":()V #2 = Class #18 // TestInterface$1 #3 = Methodref #2.#17 // TestInterface$1."<init>":()V #4 = InterfaceMethodref #19.#20 // MyInterface.foo:()V #5 = Class #21 // TestInterface #6 = Class #22 // java/lang/Object #7 = Utf8 #8 = Utf8 InnerClasses #9 = Utf8 <init> #10 = Utf8 ()V #11 = Utf8 Code #12 = Utf8 LineNumberTable #13 = Utf8 main #14 = Utf8 ([Ljava/lang/String;)V #15 = Utf8 SourceFile #16 = Utf8 TestInterface.java #17 = NameAndType #9:#10 // "<init>":()V #18 = Utf8 TestInterface$1 #19 = Class #23 // MyInterface #20 = NameAndType #24:#10 // foo:()V #21 = Utf8 TestInterface #22 = Utf8 java/lang/Object #23 = Utf8 MyInterface #24 = Utf8 foo { public TestInterface(); flags: ACC_PUBLIC Code: stack=1, locals=1, args_size=1 0: aload_0 1: invokespecial #1 // Method java/lang/Object."<init>":()V 4: return LineNumberTable: line 1: 0 public static void main(java.lang.String[]); flags: ACC_PUBLIC, ACC_STATIC Code: stack=2, locals=2, args_size=1 0: new #2 // class TestInterface$1 3: dup 4: invokespecial #3 // Method TestInterface$1."<init>":()V 7: astore_1 8: aload_1 9: invokeinterface #4, 1 // InterfaceMethod MyInterface.foo:()V 14: return LineNumberTable: line 3: 0 line 9: 8 line 10: 14 } $ javap -v 'TestInterface$1.class' Classfile /home/hjen/test/java/TestInterface$1.class Last modified Dec 12, 2012; size 530 bytes MD5 checksum e75676caff87fde544f28cfb3f0c0166 Compiled from "TestInterface.java" final class TestInterface$1 implements MyInterface SourceFile: "TestInterface.java" EnclosingMethod: #16.#17 // TestInterface.main InnerClasses: static #5; //class TestInterface$1 minor version: 0 major version: 49 flags: ACC_FINAL, ACC_SUPER Constant pool: #1 = Methodref #6.#18 // java/lang/Object."<init>":()V #2 = Fieldref #19.#20 // java/lang/System.out:Ljava/io/PrintStream; #3 = String #12 // foo #4 = Methodref #21.#22 // java/io/PrintStream.println:(Ljava/lang/String;)V #5 = Class #23 // TestInterface$1 #6 = Class #26 // java/lang/Object #7 = Class #27 // MyInterface #8 = Utf8 <init> #9 = Utf8 ()V #10 = Utf8 Code #11 = Utf8 LineNumberTable #12 = Utf8 foo #13 = Utf8 SourceFile #14 = Utf8 TestInterface.java #15 = Utf8 EnclosingMethod #16 = Class #28 // TestInterface #17 = NameAndType #29:#30 // main:([Ljava/lang/String;)V #18 = NameAndType #8:#9 // "<init>":()V #19 = Class #31 // java/lang/System #20 = NameAndType #32:#33 // out:Ljava/io/PrintStream; #21 = Class #34 // java/io/PrintStream #22 = NameAndType #35:#36 // println:(Ljava/lang/String;)V #23 = Utf8 TestInterface$1 #24 = Utf8 #25 = Utf8 InnerClasses #26 = Utf8 java/lang/Object #27 = Utf8 MyInterface #28 = Utf8 TestInterface #29 = Utf8 main #30 = Utf8 ([Ljava/lang/String;)V #31 = Utf8 java/lang/System #32 = Utf8 out #33 = Utf8 Ljava/io/PrintStream; #34 = Utf8 java/io/PrintStream #35 = Utf8 println #36 = Utf8 (Ljava/lang/String;)V { TestInterface$1(); flags: Code: stack=1, locals=1, args_size=1 0: aload_0 1: invokespecial #1 // Method java/lang/Object."<init>":()V 4: return LineNumberTable: line 3: 0 public void foo(); flags: ACC_PUBLIC Code: stack=2, locals=1, args_size=1 0: getstatic #2 // Field java/lang/System.out:Ljava/io/PrintStream; 3: ldc #3 // String foo 5: invokevirtual #4 // Method java/io/PrintStream.println:(Ljava/lang/String;)V 8: return LineNumberTable: line 5: 0 line 6: 8 } The javap output of the interface with default method, $ javap -v 'MyInterface.class' Classfile /home/hjen/test/java/MyInterface.class Last modified Dec 12, 2012; size 209 bytes MD5 checksum 482eedfbefb42fb8c7f4eef21d77dbae Compiled from "MyInterface.java" interface MyInterface SourceFile: "MyInterface.java" minor version: 0 major version: 52 flags: ACC_INTERFACE, ACC_ABSTRACT Constant pool: #1 = InterfaceMethodref #2.#11 // MyInterface.foo:()V #2 = Class #12 // MyInterface #3 = Class #13 // java/lang/Object #4 = Utf8 foo #5 = Utf8 ()V #6 = Utf8 bar #7 = Utf8 Code #8 = Utf8 LineNumberTable #9 = Utf8 SourceFile #10 = Utf8 MyInterface.java #11 = NameAndType #4:#5 // foo:()V #12 = Utf8 MyInterface #13 = Utf8 java/lang/Object { public abstract void foo(); flags: ACC_PUBLIC, ACC_ABSTRACT public void bar(); flags: ACC_PUBLIC Code: stack=1, locals=1, args_size=1 0: aload_0 1: invokeinterface #1, 1 // InterfaceMethod foo:()V 6: return LineNumberTable: line 4: 0 }
12-12-2012
FWIW, this change set in lambda repo works for the problem. http://hg.openjdk.java.net/lambda/lambda/jdk/rev/a6d1367431c0
12-12-2012
8001667 extends Comparator interface, testng is built with -target 1.5 and using Collections.sort() with Comparator. This bug prevents test from running.
12-12-2012