[Bug] A possible bug in Verification: Dragonwell skipped an erroneous instruction?

[Instein98]

Description
We made some changes to a class file in the Apache Ant project(ant-launcher/org/apache/tools/ant/launch/Launcher.class), and let several JVMs run it. We found the following discrepancy in the behaviors of Dragonwell (8.2.2, 11.0.5.1) and J9 (8u232, 11.0.5):

Dragonwell8:

Error: A JNI error has occurred, please check your installation and try again
Exception in thread "main" java.lang.VerifyError: (class: org/apache/tools/ant/launch/Launcher, method: setProperty signature: (Ljava/lang/String;Ljava/lang/String;)V) Register 12 contains wrong type
	at java.lang.Class.getDeclaredMethods0(Native Method)
	at java.lang.Class.privateGetDeclaredMethods(Class.java:2701)
	at java.lang.Class.privateGetMethodRecursive(Class.java:3048)
	at java.lang.Class.getMethod0(Class.java:3018)
	at java.lang.Class.getMethod(Class.java:1784)
	at sun.launcher.LauncherHelper.validateMainClass(LauncherHelper.java:544)
	at sun.launcher.LauncherHelper.checkAndLoadMain(LauncherHelper.java:526)

Dragonwell11:

Error: Unable to initialize main class org.apache.tools.ant.launch.Launcher
Caused by: java.lang.VerifyError: (class: org/apache/tools/ant/launch/Launcher, method: setProperty signature: (Ljava/lang/String;Ljava/lang/String;)V) Register 12 contains wrong type

J9 8u232:

Error: A JNI error has occurred, please check your installation and try again
Exception in thread "main" java.lang.VerifyError: JVMVRFY012 stack shape inconsistent; class=org/apache/tools/ant/launch/Launcher, method=setProperty(Ljava/lang/String;Ljava/lang/String;)V, pc=153
Exception Details:
  Location:
    org/apache/tools/ant/launch/Launcher.setProperty(Ljava/lang/String;Ljava/lang/String;)V @153: JBaload
  Reason:
    Type top (current frame, locals[10]) is not assignable to 'reference' type
  Current Frame:
    bci: @153
    flags: { }
    locals: { 'java/io/PrintStream', 'java/lang/String', 'java/lang/String', integer, integer, top, integer, integer, integer, integer, top, top, top, integer }
    stack: { }
	at java.lang.J9VMInternals.prepareClassImpl(Native Method)
	at java.lang.J9VMInternals.prepare(J9VMInternals.java:304)
	at java.lang.Class.getMethodHelper(Class.java:1243)
	at java.lang.Class.getMethod(Class.java:1187)
	at sun.launcher.LauncherHelper.validateMainClass(LauncherHelper.java:544)
	at sun.launcher.LauncherHelper.checkAndLoadMain(LauncherHelper.java:526)

J9 11.0.5

Error: Unable to initialize main class org.apache.tools.ant.launch.Launcher
Caused by: java.lang.VerifyError: JVMVRFY012 stack shape inconsistent; class=org/apache/tools/ant/launch/Launcher, method=setProperty(Ljava/lang/String;Ljava/lang/String;)V, pc=153
Exception Details:
  Location:
    org/apache/tools/ant/launch/Launcher.setProperty(Ljava/lang/String;Ljava/lang/String;)V @153: JBaload
  Reason:
    Type top (current frame, locals[10]) is not assignable to 'reference' type
  Current Frame:
    bci: @153
    flags: { }
    locals: { 'java/io/PrintStream', 'java/lang/String', 'java/lang/String', integer, integer, top, integer, integer, integer, integer, top, top, top, integer }
    stack: { }

The point is, Dragonwell says it is the problem at Register 12, while J9 says it is Register 10 (locals[10]). However, in most other cases, they behave consistently. For example, if you try this case
antVerify1-consistent.zip (reproduce steps is the same), you will find that their reports are consistent (Register 17 and locals[17]).

I used javap to look at the instructions in that buggy function javap-0295-setProperty.log, J9 obviously throw the error at 153: load 10 (as the error message says), while dragonwell throw the error at 189: astore 12 or 206: aload 12 (only these two lines involve Register 12). It seems that Dragonwell just skipped the error at 153: load 10, and just report another error in later lines.

Steps to Reproduce
Steps to reproduce the behavior:

1. Download antVerify2.zip and extract it.
2. In antVerify2 directory, run command java -cp ant-launcher/ org.apache.tools.ant.launch.Launcher compile jar run

Expected behavior
It is expected to throw java.lang.VerifyError: Register 10 contains wrong type, but it throws java.lang.VerifyError: Register 12 contains wrong type.

JDK version

openjdk version "1.8.0_232"
OpenJDK Runtime Environment (Alibaba Dragonwell 8.2.2-b82) (build 1.8.0_232-b09)
OpenJDK 64-Bit Server VM (Alibaba Dragonwell 8.2.2-b82) (build 25.232-b09, mixed mode)

openjdk version "11.0.5.1-preview" 2019-12-29
OpenJDK Runtime Environment (Alibaba Dragonwell) (build 11.0.5.1-preview+7)
OpenJDK 64-Bit Server VM (Alibaba Dragonwell) (build 11.0.5.1-preview+7, mixed mode)

Execution environment

• OS and version: Ubuntu 16.04.6 LTS
• CPU model: Intel(R) Xeon(R) CPU E5-4610 v4 @ 1.80GHz
• Number of CPU cores: 4CPUs, each has 10 cores
• Size of physical memory: 16384 MB * 20
• Inside Linux container? No

[luchsh]

Thanks for reporting!

I tried your testcase with OpenJDK build 8u and 11u, (using docker image 'adoptopenjdk/openjdk11' and 'adoptopenjdk/openjdk8'), and I see exactly the same error messages as Dragonwell. I guess this may be a difference between HotSpot and J9.

Personally speaking, as a JDK developer I care more about specification instead of implementation. OpenJDK is the de facto standard, a.k.a 'reference implementation', if any other implementation (e.g. OpenJ9) behaves differently from OpenJDK (HotSpot), it might mean a potential bug in that implementation (not always :-) ).

So for this particular case, I may not consider it as Dragonwell bug.

Dragonwell derives from OpenJDK, they share most of the code, I think the class verification part ought to be identical. Please use OpenJDK as the baseline to report a Dragonwell bug in your future testing. BTW, are you working on some experimental regarding to class verification/transforming? maybe we can have more casual discussion in the DingTalk group.

Cheers!

[Instein98]

Thanks for your response!

Actually we are performing fuzz testing and differential testing on 8 different JVMs now. As you said, it seems most of the discrepancies of behaviors are caused by the defects in J9, rather than OpenJDK and Dragonwell. We will try more seeds for fuzzing. We hope we can find more bugs and make JVMs better and better!

[Instein98]

By the way, it was also confirmed by Oracle https://bugs.java.com/bugdatabase/view_bug.do?bug_id=JDK-8243483 : )