JDK18 DaaLoadTest FAILED - Cannot invoke "jdk.internal.reflect.DirectMethodHandleAccessor.invokeImpl #14395
Comments
|
Internal test (0.31 m1) /job/Test_openjdk18_j9_special.system_ppc64_aix_testList_2/8 /job/Test_openjdk18_j9_special.system_ppc64le_linux_testList_1/8 testFailure: testNegativeNumBytesBigEndian(net.openj9.test.binaryData.TestInteger2ByteArrayNumBytes) |
pshipton
changed the title
|
There are a lot of these failures in the jdk18 special.system build on all platforms, I'm setting as a blocker. Subset of failure modes, some are the default modes. I didn't list the failures for all platforms, see the build links above. xlinux: zlinux: mac: alinux: |
|
@0xdaryl Any suggestions for somebody to triage? |
|
@nbhuiyan : could you triage these failures please? There seem to similar failures across platforms, so please pick whichever platform you are most comfortable with. |
|
This test failure can be easily reproduced locally. This issue has shown up as a result of of JDK18 using method handles for reflection (JEP 416). The failure can be avoided by disabling MH usage in reflection using The IllegalArgumentException originates from here. Trying to call |
|
Having examined the JIT logs and the compiled code for the caller of the Forcing |
|
Even with every optimization disabled, inlining |
Are you suggesting then that |
|
|
|
I have continued my investigation of this issue over the past week. My investigation over the last week involved trying to run the test in a debugger, with a break inserted at at the start of @jdmpapin , and I investigated cores obtained via The error reported: This NPE, when thrown in This meant that the NPE is not actually thrown in Looking at the Currently, we are working on narrowing down to the smallest set of methods we need to compile for the failure to happen, and continuing our investigation from there. |
|
@nbhuiyan Any new news on the proposed workaround? |
|
@vij-singh : the workaround proposed above just treats the symptom of the problem and not the cause. Unfortunately, we don't know the cause yet despite some heroic efforts to diagnose this. I'm not comfortable applying a workaround until we understand why it causes the problem to not occur. |
|
@babsingh, @JasonFengJ9, since you were involved in the JEP 416 work, I was wondering if you could share some insight into the problem we are seeing here. In the JIT-ed code, the NPE is thrown in the inner-most frame in the stack trace in the Java core above, However, this |
|
I did a little experiment by changing the code here before: after:
|
|
@babsingh can you take a look at what Nazim mentioned above |
The reflection API has not changed. The behaviour should be the same with JEP416 enabled. The In #14395 (comment), I still see the frames which should have been hidden by #3627. In this case, the methods in the frames are compiled. @nbhuiyan Can you confirm if the difference between the interpreter and JIT paths is the absence of those frames? If so, follow on JIT changes will be needed to hide those frames when the methods are compiled. |
|
@nbhuiyan Would know the location of the test source code: |
|
No more changes are needed to the stack walkers - hopefully I would have caught that when I reviewed the code. Do you have something specific in mind that I may have overlooked? |
I assumed more changes are needed just by observation. In #14395 (comment), I still see the following hidden frames which should have been skipped by #3627: |
It is located in the openj9-systemtest repo: There are many other |
|
All of the reporting goes via |
|
I think there needs to be a similar change made to the exception backtrace decoder. The changes made only affect the walk of the stack - exception backtraces contain only a single PC for a compiled frame, which may contain any number of inlined frames. The code as it stands would eliminate all of the frames if the outer method was marked, which would result in incorrectly missing frames if the inlined methods were not marked. I think we need to remove the skip hidden frames option from exception backtrace creation and handle it in the backtrace decode logic. |
|
#3627 added a new stackwalk flag |
|
I would recommend against removing any frames from javacores - they need to be as detailed and accurate as possible. |
|
@gacholio Can you point us to the code for |
Looking at the implementation of |
|
Remove the changes in openj9/runtime/vm/exceptiondescribe.c Lines 222 to 236 in e21b7d8 The other option is to leave the decode logic alone and add the check in the appropriate callers, but it seems cleaner to add the option here. |
@nbhuiyan If you look at the impl of Junit's I dont see how -Xint could fail with the changes to |
The way |
|
re #14395 (comment):
I did few experiments. With Afterwards, I was unable to reproduce the failure just with Other observations:
In addition to Jack's justification in #14395 (comment), GAC's feedback in #14395 (comment) is also important. It suggests that
The next step is to try GAC's suggestions: #14395 (comment), #14395 (comment) and #14395 (comment). |
|
If the failure is caused by a bad interaction between hidden methods and JIT frames, -Xint should prevent the failure regardless of -Xshareclasses options, shouldn't it? With -Xint the JIT library isn't even loaded, so we should never have JIT frames |
|
Test target: It's worth noting that the test is run with The |
|
Rightmost option wins between -Xjit and -Xint so there should be no difference between the first and last runs above. |
|
|
|
I realized that the way I set up my options did not disable the JIT as the |
|
I also mixed my test runs with |
|
Given comments above, then the only case which fails is due to issue Gac has pointed out in #14395 (comment). |
|
I've also noticed that openj9/runtime/rasdump/javadump.cpp Line 4443 in 2375a97 iterateStackTrace or does this case not affect the issue here
|
My feeling is that we should not skip hidden frames in the javacore, but others may have a different opinion. @tajila @keithc-ca |
Yes, all |
For clarity, I agree with GAC's earlier comment that all stack frames should be included in javacore files. |
I just want to mention that I think this also explains why -Xdump was triggered when |
Failure link
From an internal build
job/Test_openjdk18_j9_special.system_aarch64_linux_testList_0/6/(ub18-aarch64-7):Rerun in Grinder - Change TARGET to run only the failed test targets.
Optional info
Failure output (captured from console output)
50x grinder -
job/Grinder/20524/- 49/50 failed.50x grinder w/
-Xint-job/Grinder/20610/The text was updated successfully, but these errors were encountered: