8292054: Test runtime/posixSig/TestPosixSig.java fails with 'Test failed, bad output.'

[hseigel]

Please review this fix for JDK-8292054. The existing regression test for JDK-8285792, test/hotspot/jtreg/runtime/posixSig/TestPosixSig.java, intermittently fails because it depends on periodic calls to JVM function os::run_periodic_checks(). This fix replaces test TestPosixSig.java with a gtest that does its own explicit call to os::run_periodic_checks().

The fix was tested by running the new test 150+ times on Linux, Mac OS, and Windows.

---

Progress

• [ ] Change must be properly reviewed (1 review required, with at least 1 Reviewer)
• [x] Change must not contain extraneous whitespace
• [x] Commit message must refer to an issue

Issue

• JDK-8292054: Test runtime/posixSig/TestPosixSig.java fails with 'Test failed, bad output.'

Reviewing

Using git

Checkout this PR locally:
$ git fetch https://git.openjdk.org/jdk pull/9882/head:pull/9882
$ git checkout pull/9882

Update a local copy of the PR:
$ git checkout pull/9882
$ git pull https://git.openjdk.org/jdk pull/9882/head

Using Skara CLI tools

Checkout this PR locally:
$ git pr checkout 9882

View PR using the GUI difftool:
$ git pr show -t 9882

Using diff file

Download this PR as a diff file:
https://git.openjdk.org/jdk/pull/9882.diff

[bridgekeeper[bot]]

:wave: Welcome back hseigel! A progress list of the required criteria for merging this PR into master will be added to the body of your pull request. There are additional pull request commands available for use with this pull request.

[openjdk[bot]]

@hseigel The following label will be automatically applied to this pull request:

• hotspot-runtime

When this pull request is ready to be reviewed, an "RFR" email will be sent to the corresponding mailing list. If you would like to change these labels, use the /label pull request command.

[mlbridge[bot]]

Webrevs

• 03: Full - Incremental (fdef1f1c)
• 02: Full - Incremental (081c8931)
• 01: Full - Incremental (4e9afcd3)
• 00: Full (b56bd913)

[tstuefe]

The problem in JDK-8292054 is that the output appears more than once, right?

The hotspot code warns exactly once per encountered signal change. So if someone changes SIGFPE, then SIGILL, VM should warn twice. That is by design since such changes can be unrelated and equally important, so if they are hours apart one wants to know.

JDK-8285792 changed the behavior somewhat so that if multiple handler changes were encountered in the same check, we only print all signal handlers once. But that part does not always work, since thats a bit racy:

• os::run_periodic_checks()
  • other thread changes signal handler for FPE
  • check signal handler for FPE (8)
    • changed. Disarm future checks for FPE and return true
  • all other handlers still unchanged
  • other thread changes ILL (4)
  • print "Warning SIGFPE changed!"
  • print all handlers
• Next loop:
• os::run_periodic_checks()
  • check signal handler for ILL (4)
    • changed. Disarm future checks for ILL and return true
  • check signal handler for FPE (8) - returns false since already disarmed
  • print "SIGILL changed!"
  • print all handlers again

.. and the test complains over the fact that the signal handler section is printed twice.

---

I'm not sure if transforming the test to a gtest is the right way to do it. Since the test checks the ability of the VM to process -XX:+CheckJNICalls and notice signal handler changes on its own. Calling the function manually removes one aspect of the test.

Could we just make the existing java test more lenient, so that "Warning: SIGILL handler modified!" and "Warning: SIGFPE handler modified!" appear only once?

[hseigel]

@tstuefe Thanks for looking at this change. The purpose of this test, and the test that it is replacing, is to check that os::run_periodic_checks() does not print a complete list of signal handlers every time it finds a changed signal handler. The tests purpose is not to test that -XX:+CheckJNICalls causes the JVM to check for changed signal handlers.

Making existing test TestPosixSig.java more lenient wouldn't help because the test wouldn't know if the multiple Warnings are caused by issues with the fix for JDK-8285792.

How about if we add the gtest proposed here as the fix for JDK-8292054 and open a new RFE to add a test to check that -XX:+CheckJNICalls causes the JVM to check for changed signal handlers? That new test would be similar to TestPosixSig.java.

[openjdk[bot]]

@hseigel This change now passes all automated pre-integration checks.

ℹ️ This project also has non-automated pre-integration requirements. Please see the file CONTRIBUTING.md for details.

After integration, the commit message for the final commit will be:

8292054: Test runtime/posixSig/TestPosixSig.java fails with 'Test failed, bad output.'

Reviewed-by: coleenp, stuefe

You can use pull request commands such as /summary, /contributor and /issue to adjust it as needed.

At the time when this comment was updated there had been 32 new commits pushed to the master branch:

• e8bc87956abc92851de8694c56a78f6ecc546cbd: 8292443: Weak CAS VarHandle/Unsafe tests should test always-failing cases
• 494d3873b1d0f7e3ca0a063b44362e7242298dec: 8280152: AArch64: Reuse runtime call trampolines
• 8b4e6ba01ffef77d5f1b9a9aa3e978f4da431836: 8289332: Auto-generate ids for user-defined headings
• 0fc92637d297d9a1281df33089975bd6d5fdf809: 8291828: Reduce runtime of java.util.stream microbenchmarks
• e81210f5fe03ea3dc9c9fb0dba2be79e1dcc03bc: 8292352: 32-bit Windows build failures after JDK-8290059
• f45b8408a0e66aee22a6ac60e3f24dfc8ac104e5: 8292384: Convert AdapterHandlerTable to ResourceHashtable
• 0c67fba11f444cc3739f66c8a2d57564b5dcca72: 8289049: x86_32 build fails with GCC 11 due to newString646_US warning
• bf7d6d3a0f947ab4a30f27bce6650798289cc7fd: 7132413: [macosx] closed/javax/swing/AbstractButton/5049549/bug5049549.java fails on MacOS
• e230719ad3cc9e70511d7baa6338bb77cd038139: 8292448: Convert BitMapFragmentTable to ResourceHashtable
• f75da2235ab7e33927729fa060ec4d86fdb0240f: 8292395: [testbug] VectorGatherScatterTest.java fails on SVE with -XX:MaxVectorSize=8 after JDK-8288397
• ... and 22 more: https://git.openjdk.org/jdk/compare/aa5b71893307b9fe6137bc3541edccaab73735ac...master

As there are no conflicts, your changes will automatically be rebased on top of these commits when integrating. If you prefer to avoid this automatic rebasing, please check the documentation for the /integrate command for further details.

➡️ To integrate this PR with the above commit message to the master branch, type /integrate in a new comment.

[hseigel]

Thanks Thomas and Coleen for the reviews and help with this test.

/integrate

[openjdk[bot]]

Going to push as commit 0d96546ab93600f17877e5db2770e4125916bcda. Since your change was applied there have been 32 commits pushed to the master branch:

• e8bc87956abc92851de8694c56a78f6ecc546cbd: 8292443: Weak CAS VarHandle/Unsafe tests should test always-failing cases
• 494d3873b1d0f7e3ca0a063b44362e7242298dec: 8280152: AArch64: Reuse runtime call trampolines
• 8b4e6ba01ffef77d5f1b9a9aa3e978f4da431836: 8289332: Auto-generate ids for user-defined headings
• 0fc92637d297d9a1281df33089975bd6d5fdf809: 8291828: Reduce runtime of java.util.stream microbenchmarks
• e81210f5fe03ea3dc9c9fb0dba2be79e1dcc03bc: 8292352: 32-bit Windows build failures after JDK-8290059
• f45b8408a0e66aee22a6ac60e3f24dfc8ac104e5: 8292384: Convert AdapterHandlerTable to ResourceHashtable
• 0c67fba11f444cc3739f66c8a2d57564b5dcca72: 8289049: x86_32 build fails with GCC 11 due to newString646_US warning
• bf7d6d3a0f947ab4a30f27bce6650798289cc7fd: 7132413: [macosx] closed/javax/swing/AbstractButton/5049549/bug5049549.java fails on MacOS
• e230719ad3cc9e70511d7baa6338bb77cd038139: 8292448: Convert BitMapFragmentTable to ResourceHashtable
• f75da2235ab7e33927729fa060ec4d86fdb0240f: 8292395: [testbug] VectorGatherScatterTest.java fails on SVE with -XX:MaxVectorSize=8 after JDK-8288397
• ... and 22 more: https://git.openjdk.org/jdk/compare/aa5b71893307b9fe6137bc3541edccaab73735ac...master

Your commit was automatically rebased without conflicts.

[openjdk[bot]]

@hseigel Pushed as commit 0d96546ab93600f17877e5db2770e4125916bcda.

:bulb: You may see a message that your pull request was closed with unmerged commits. This can be safely ignored.