-
Notifications
You must be signed in to change notification settings - Fork 737
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[linux_390] SE80_GIT decompileAtMethodResolve_0 Illegal instruction at Compiled_method=com/ibm/jvmti/tests/decompileAtMethodResolve/ResolveTest1Super.test()V #9876
Comments
@PushkarBettadpur could you please help take a look at this one? I suspect it is another instance of VICOM emulation not being properly represented in the JIT. We can check with Joe whether this machine was added recently. First step I'd say is to hop on and try and get a reproduction, or run a grinder. |
Tested this internally over the last few days. A grinder was unable to reproduce the issue, however, based on some of his previous work Rahil suspected that the Added a JIT-Hack to unilaterally emit an |
Can you print the contents of |
@fjeremic the output of
Yes, I tried running the test on a non SVL machine and it passes. |
Ok so |
More internal illegal instruction failures running Java 8 testing, @VermaSh looked at these and associated them with this issue. |
Unfortunately, I was unable to reproduce the issue locally on those machines. I believe it's because they have been restarted since the failures were reported. We'll have to wait until the failure resurfaces. For future reference, here is a unit test to reproduce the failure locally (Thanks to @r30shah):
cmd: |
@joransiu fyi Another internal failure on lnxec417.
|
I launched a grinder and was able to reproduce this on |
Another one in the next build on the same machine. I'm disabling the machine for now. |
I did try out the unit test we have written in C to reproduce failure, it fails
|
Thanks Rahil for the unit test! My unit test was a JIT hack, unfortunately I don't have that build handy. It seems to be a VICOM emulation issue. I know our previous VICOM emulation related failure for I'll try to get some context (a comparison with non-VICOM machine) into why this is failing on VICOM. Hopefully we can take it to the VICOM team for a fix. |
Unfortunately the machine has disappeared. The infra team is looking into the disappearance. internal issue |
The machine is back, but the c unit test no longer fails. We just might have to wait until it starts failing again. To be sure, I am going to get a build with unit test in #9876 (comment) Personal build with JIT hack: /job/jvm.29.personal/31835/ |
Another one in an internal test - lnxec402 |
Another one on fyrlx10u |
Another one on fyrlx107 |
Another one on lnxec403 |
Another Illegal instruction on lnxec383 which is a better match to #9514, but I'm assuming all the Illegal instruction failures are similar. If this isn't the case let me know. [Linux S390] 80 VM_Sanity.TestRefreshGCSpecialClassesCache_BCI_EXTENDED_HCR.Mode107
|
Internal test 1
Internal test 2
|
internal build
|
Internal build
|
[linux_390] SE80_GIT decompileAtMethodResolve_0(
|
Based on the comment : #19495 (comment) |
Closing as per #9876 (comment) |
Failure link
From an internal build
acceptance build 449148
:Optional info
Failure output (captured from console output)
Only one occurrence in a 100x grinder.
The text was updated successfully, but these errors were encountered: