RFR: JDK-8297184: Test runtime/ErrorHandling/TestSigInfoInHsErrFile.java is failing [v3]
Thomas Stuefe
stuefe at openjdk.org
Thu Nov 17 13:19:12 UTC 2022
On Thu, 17 Nov 2022 13:14:04 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:
>> https://bugs.openjdk.org/browse/JDK-8296906 added a new test that artificially crashes the VM with a known signal/code/crashaddress and checks that we see those informations precisely in the hs-err file. It did this for SIGSEGV and SIGFPE.
>>
>> SIGFPE, however, is problematic. We fall back to pthread_kill() if we cannot trigger a real FPE fault. In that case the code will be SI_KILL and the sending frame will be pthread_kill().
>>
>> Since we cannot guarantee that a real signal is sent, I opted for just removing the part of the test that tests FPE. The other part, testing SIGSEGV, is enough to cover what the test should cover.
>
> Thomas Stuefe has updated the pull request incrementally with one additional commit since the last revision:
>
> removed carefully chosen comment since appearantly it was not careful enough :(
> @tstuefe Please do not rebase or force-push to an active PR as it invalidates existing review comments. All changes will be squashed into a single commit automatically when integrating. See [OpenJDK Developers’ Guide](https://openjdk.org/guide/#working-with-pull-requests) for more information.
I don't understand this nagging. I did not force push.
@dholmes-ora : I broadened the pattern to encompass all possible SEGV si_codes. Originally I was hoping my new crash address was guaranteed to be a mapping error. An alternative would have been to reserve+mprotect a poison page, then it would be guaranteed ACCERR, but that seemed too much hassle.
-------------
PR: https://git.openjdk.org/jdk/pull/11202
More information about the hotspot-runtime-dev
mailing list