[Bug] A possible bug found in JVM differential testing

[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 that compared to other JVMs, dragonwell8 behaves strangely. It might be a bug in dragonwell8.

Steps to Reproduce
Steps to reproduce the behavior:

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

Expected behavior
dragonwell8 can run it successfully while other JVMs can not.

openjdk8	openjdk9	j9	dragonwell8	dragonwell11
Crash	ClassFormatError	ClassFormatError	Run Successfully	ClassFormatError

JDK version

$ java -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)

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]

Hello @Instein98 , thanks for reporting!

I tried your test locally with OpenJDK 8u232b09, it finished successfully in the same way as Dragonwell8.
Could you please share the detailed OpenJDK version you were testing on?

[Instein98]

Hi!
Here is the version of other JVMs:
openjdk8:

$ java -version
openjdk version "1.8.0-internal-debug"
OpenJDK Runtime Environment (build 1.8.0-internal-debug-mingyuanu_2019_09_21_15_22-b00)
OpenJDK 64-Bit Server VM (build 25.60-b23-debug, mixed mode)

openjdk9:

openjdk version "9-internal"
OpenJDK Runtime Environment (build 9-internal+0-adhoc.mingyuanwu.openjdk9)
OpenJDK 64-Bit Server VM (build 9-internal+0-adhoc.mingyuanwu.openjdk9, mixed mode)

j9:

openjdk version "1.8.0_242"
OpenJDK Runtime Environment (build 1.8.0_242-b08)
Eclipse OpenJ9 VM (build openj9-0.18.1, JRE 1.8.0 Linux amd64-64-Bit Compressed References 20200122_511 (JIT enabled, AOT enabled)
OpenJ9   - 51a5857d2
OMR      - 7a1b0239a
JCL      - 8cf8a30581 based on jdk8u242-b08)

dragonwell11:

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)

[luchsh]

The several jdk8 releases you mentioned in your test looks to be at different update versions.
Please use the same "OpenJDK update version" (I'd like to recommend u232 at this point becuase Dragonwell source has not yet upgraded to u242) to do an apple-to-apple comparison.

[Instein98]

Thanks for your advice! I will change them to the corresponding update versions later.

[Instein98]

I tried this test on openjdk1.8.0_232, and as you said it runs successfully. However, the behavior of openjdk8 and dragonwell8 is still different from dragonwell11. In my view, they should all follow the same JVM specification but they behave differently now. So maybe there are some problems with JVM implementations?

[luchsh]

actually there are different JVM specifications for each JDK releases, see
https://docs.oracle.com/javase/specs/jvms/se8/html/index.html
https://docs.oracle.com/javase/specs/jvms/se11/html/index.html
Subtle behavior differences can be found between different JDK releases.

You may want to compare openjdk 8 and openjdk 11 to determine if the Dragonwell difference comes from upstream OpenJDK code or from Dragonwell enhancement.

[Instein98]

Hi, recently I dug deeper into this discrepancy. I found in the org.apache.tools.ant.launch.Launcher class file, there is an illegal class name in the constant pool, which looks like L...LLLorg/apache/tools/ant/launch/Launcher;;;...;, a fully qualified name with lots of L in the front and lots of ; behind (... indicates there are lots of L and ;).

In https://docs.oracle.com/javase/specs/jvms/se8/html/jvms-4.html#jvms-4.2.1, it says

Class and interface names that appear in class file structures are always represented in a fully qualified form known as binary names (JLS §13.1).
...
In this internal form, the ASCII periods (.) that normally separate the identifiers which make up the binary name are replaced by ASCII forward slashes (/). The identifiers themselves must be unqualified names
...
An unqualified name must contain at least one Unicode code point and must not contain any of the ASCII characters. ; [ / (that is, period or semicolon or left square bracket or forward slash).

Since the last identifier which makes up that class name contains a lot of semicolons, I think openjdk8 and dragonwell8 should treat this class name as an illegal class name. But actually they can run it successfully. Maybe it is be a bug of openjdk8 and dragonwell8?

[luchsh]

Hi, recently I dug deeper into this discrepancy. I found in the org.apache.tools.ant.launch.Launcher class file, there is an illegal class name in the constant pool, which looks like L...LLLorg/apache/tools/ant/launch/Launcher;;;...;, a fully qualified name with lots of L in the front and lots of ; behind (... indicates there are lots of L and ;).

In https://docs.oracle.com/javase/specs/jvms/se8/html/jvms-4.html#jvms-4.2.1, it says

Class and interface names that appear in class file structures are always represented in a fully qualified form known as binary names (JLS §13.1).
...
In this internal form, the ASCII periods (.) that normally separate the identifiers which make up the binary name are replaced by ASCII forward slashes (/). The identifiers themselves must be unqualified names
...
An unqualified name must contain at least one Unicode code point and must not contain any of the ASCII characters. ; [ / (that is, period or semicolon or left square bracket or forward slash).

Since the last identifier which makes up that class name contains a lot of semicolons, I think openjdk8 and dragonwell8 should treat this class name as an illegal class name. But actually they can run it successfully. Maybe it is be a bug of openjdk8 and dragonwell8?

Can you please share the class file mentioned in above comment? so I can take a close look at the issue.

Cheers

[Instein98]

It is the same class file mentioned in the first comment. ant.zip, the class file path is ant-launcher/org/apache/tools/ant/launch/Launcher.class, and the reproduce steps is also mentioned in the first comment.

[Instein98]

It was confirmed by Oracle: https://bugs.java.com/bugdatabase/view_bug.do?bug_id=JDK-8242352

[luchsh]

Dragonwell will try to be compatible with OpenJDK.
So I do not think we should merge this change to Dragonwell 8u unless upstream changes its behavior.

Cheers