J9(1.8.0_232) and J9(11.0.5): failed to throw VerifyError? #9385
Comments
|
@ChengJin01 can you take a look at this? |
|
Will investigate to see what happened in there. |
|
I reproduced the issue locally with OpenJDK11/Hotspot, OpenJDK8/OpenJ9, OpenJDK9/OpenJ9 and OpenJDK11/OpenJ9 as follows: against the bytecode in question at: Meanwhile, VerifyError never occurred if disable with It seems the code in verifier is likely out of sync or some new changes related to verifier were only merged for OpenJDK8 & OpenJDK11 given that only OpenJDK9/OpenJ9 captured VerifyError. Need to further analyze to see what changes in verifier caused the issue. |
|
Also, I tried disabling |
|
@ChengJin01 Can you post the exception tables from the method you pasted the bytecode for? We need that to see if there's a path that doesn't call super or another ctor of the same class |
|
@DanHeidinga , there is no exception table for the method based on the DDR output: Given that it jumps to the index 56 as locals[5] is 0 at index 22 (22 ifle 56) , the other ctor (including the super) should be skipped in this way. The corresponding class file also shows there is no exception table is the Given the major version is 49 (< 51) , it seems the stackamp along with the exeception table was created via |
|
The bytecode of another |
|
@ChengJin01 I'd start by looking at The other place I'd dig for this is https://github.com/eclipse/openj9/blob/1b35e0a4fd77a8c0c04965af8ac04d21fa4ad659/runtime/bcverify/bcverify.c#L2540 |
|
To figure out why VerifyError was thrown out on OpenJDK9 with v0.9.0-release, I compared the against So the only difference is the check on Even though VerifyError was captured on OpenJDK9/OpenJ9 with the check on on return of the ctor method rather than at which means we need to ensure both this issue and the previous issue in #5676 works with a new fix. |
|
I double-checked the JVM Spec from Java 7 to 11 as to uninitializedThis when invoking invokespecial as follows: and Java 8, 9, 10 & 11 VM Spec (without any change) So the check of Now that my understanding is the expected result (the escape path is from an IF statement rather than an exception) is undocumented in the existing VM spec but actually covered on Hotspot. If so, we might need to figure out how to get this work on the created stackmaps (e.g. in simulateStacks). |
Even though the failing .classes (version = 51) in there comes with stackmap & exception table, the code above also covers the case of generated stackmaps (version < 51).
The only differences is the stackmaps were generated as the failing class version is 46.0 / JDK1.2. But we let it pass by enabling the check of the generated stackmaps to match the RI's behaviour given that the check was ignored on Hotspot.
To sum up,
To match the RI's behaviour in all cases above, we might as well replace the check on generated maps (Java version >= 51) with the check on a decent java version (e.g. Java 5). e.g. |
|
Thanks for your hard work! By the way, may you also check these two issues? #9357 #9336 @DanHeidinga |
|
@fuzzy000 we're still working our way though this one =) The other two are both in the milestone for our next release and will get attention before then. These are tricky issues that take time and discussion to ensure we're implementing the spec correctly and fixing any issues in the best way. They're definitely on the list though! |
ChengJin01
pushed a commit
to ChengJin01/openj9
that referenced
this issue
Jun 19, 2020
The change is to add the check of BCV_SPECIAL when merging & matching stacks to ensure the uninitializedThis flag is correctly set up during the generation of stackmaps so as to match the RI's behavior at runtime verification.[ci skip] Fixes: eclipse-openj9#9385 Signed-off-by: Cheng Jin <[email protected]>
DanHeidinga
pushed a commit
to DanHeidinga/openj9
that referenced
this issue
Jun 19, 2020
The change is to add the check of BCV_SPECIAL when merging & matching stacks to ensure the uninitializedThis flag is correctly set up during the generation of stackmaps so as to match the RI's behavior at runtime verification.[ci skip] Fixes: eclipse-openj9#9385 Signed-off-by: Cheng Jin <[email protected]>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Java -version output
The issue happened in following versions:
Summary of problem
We made some changes to a class file in the JUnit project (org.junit.internal.runners.ErrorReportingRunner), and let several JVMs run the corresponding test file (org.junit.internal.runners.ErrorReportingRunnerTest). Here we only kept two JUnit tests in the test file to focus on the issue.
2) VerifyError
2) VerifyError
2) VerifyError
2) IllegalArgumentException
2) VerifyError
2) IllegalArgumentException
OpenJDK series throws VerifyError, which was caused by the class
ErrorReportingRunner. It looks like J9(1.8.0_232) and J9(11.0.5) just wrongly take the classErrorReportingRunneras a valid class file and execute the tests.There is also a discrepancy in the behaviors of J9(9.0.4) and J9(1.8.0_232), J9(11.0.5). Maybe there are some problems in the verification part of those VMs?
Diagnostic files
ErrorReportingRunnerTest.zip
ErrorReportingRunnerTest, run commandjava -cp sootOutput/junit-junit/:hamcrest-all-1.3.jar org.junit.runner.JUnitCore org.junit.internal.runners.ErrorReportingRunnerTestExecution environment
The text was updated successfully, but these errors were encountered: