-
Notifications
You must be signed in to change notification settings - Fork 729
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
openJcePlusTests_0 TestRSAPSSInterop>BaseTestRSAPSSInterop.testRSASignatureWithPSSMultiByteSize_IBM2BC2:265 Segmentation error vmState=0x00020019 #20947
Comments
Crash in GC code during object allocation. I am going to triage it. |
crash stack:
This crash occur because of an attempt to allocate byte array 0x187F (6271) elements (see During memory search in the
The garbage in Actually there is the object written at the place where Linked Free List element expected to be:
This object is complete (with header). It means it is allocated either by GC itself out-of-line (hard to believe - this is core Memory Pool functionality has not been changed for years and, if broken, should manifest itself much more often) or, alternatively by JIT as inline allocated object. The scenario in this case might be: this object was about to be allocated in TLH by JIT and proposed allocation address was stored somewhere in the native but Global GC occur. It triggered flush TLH for the thread and adding TLH reminder to free memory linked list. However internally stored memory address survived and JIT continued allocation process over newly written Linked Free Header and corrupted it.
@hzongaro Would you please take a look? |
I do see another hypothetical scenario for this failure. If there is code copied heap content somewhere and returned it back, and it operates with significantly larger chunk as expected it can create this pattern. We can not detect it for alive objects (still be at it's own place even rewritten) but newly created Linked Free Element can be overwritten by object use to be on this place before. I noticed that for array written over there are first 208 elements filled by 0x61 with zeroes in remaining part. I looked to examples of similar arrays in the heap, for example |
I guess there are more scenarios if, for example, native security code violates fundamental rules, like respect to VM Access etc. |
Failure link
From internal Test_openjdk17_j9_extended.functional_ppc64le_linux_fips140_3_openjceplusfips (rtj-sles15le-svl-test-sik33-1)
Rerun in Grinder - Change TARGET to run only the failed test targets
Optional info
Failure output (captured from console output)
50x internal Grinder - there were timeouts, but no failure was reproduced.
FYI @jasonkatonica
The text was updated successfully, but these errors were encountered: