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