-
Notifications
You must be signed in to change notification settings - Fork 732
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
Test_openjdk8_j9_extended.functional_s390x_linux testDDRExt_JITExt_openj9_0 CorruptDataException thrown walking stack #5449
Comments
That looks like a J9Class->eyecatcher being used as an index |
@theresa-m Can you take a look at this? |
On further inspection of a core dump These tests were enabled and run for the first time in OpenJ9 only recently #5137 so there aren't any obvious changes to the stackwalker that I can find that might have caused this. @pshipton should these tests be excluded until this is resolved? |
It's only failed once so far, I think we should keep the test running unless the failure starts to occur more often. |
https://ci.eclipse.org/openj9/job/Test_openjdk8_j9_extended.functional_s390x_linux_Nightly/13 This failure continues to occur, but I'm not going to keep reporting them. |
So far I've seen that a failing At the point of the extra iteration I'm not too familiar with how the stack walks over jit frames, so I'm not sure where I should look next. Any suggestions? |
Connect with @gacholio to get details on how to walk jit stackframes |
I have a suspicion that this is just a poorly-written test - it's looking for a random JIT frame and then trying to start a walk there, but it has ignored the ELS, which is one of the roots. |
Rather than fixing the test, it might be better to test something more deterministic. Can you update the core generator to fork a thread specifically for this test? Basically, we want to ensure a JIT frame at the top of stack so the exiting test will work (once it's changed to target this specific thread rather than searching). |
To ensure a compiled method, use Compiler.compileClass. I would suggest a thread which ends with a jitted method that calls wait(). |
Also, once the test is targetting the known thread, it should succeed if a jitted method is not found (the test was run in a mode which prevented jitting for whatever reason). |
https://ci.eclipse.org/openj9/job/Test_openjdk8_j9_extended.functional_s390x_linux_Nightly/1
The text was updated successfully, but these errors were encountered: