8252148: vmError::controlled_crash should be #ifdef ASSERT and move tests to gtest

[coleenp]

Moved some unit tests from vmError into a gtest and moved controlled_crash code under #ifdef ASSERT rather than #ifndef PRODUCT since the tests that use this are @requires = vm.debug. This change keeps the ErrorHandlerTest=n option and other handler test options, because there are some tests that use this more but moves them to develop options (they were notproduct). There are some ErrorHandlerTest=n tests that do more thorough hs_err_pid.log file verification that remain.

Tested with tier1-3 with product and fastdebug builds. Built with optimized.

This is for JDK 17.

---

Progress

• Change must not contain extraneous whitespace
• Commit message must refer to an issue
• Change must be properly reviewed

Issue

• JDK-8252148: vmError::controlled_crash should be #ifdef ASSERT and move tests to gtest

Reviewers

• Ioi Lam (@iklam - Reviewer)
• Thomas Stuefe (@tstuefe - Reviewer)

Download

$ git fetch https://git.openjdk.java.net/jdk pull/1723/head:pull/1723
$ git checkout pull/1723

[bridgekeeper]

👋 Welcome back coleenp! 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]

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

• hotspot

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]

Webrevs

• 06: Full - Incremental (8d326e9)
• 05: Full (95f6658)
• 04: Full - Incremental (8a5864e)
• 03: Full - Incremental (ca06a07)
• 02: Full - Incremental (6405181)
• 01: Full - Incremental (e3b6a55)
• 00: Full (fa79540)

[gerard-ziemski]

Very nice cleanup. I like moving the majority of that code to a gtest.

[openjdk]

@coleenp 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:

8252148: vmError::controlled_crash should be #ifdef ASSERT and move tests to gtest

Reviewed-by: iklam, 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 23 new commits pushed to the master branch:

• da2415f: 8257457: Update --release 16 symbol information for JDK 16 build 28
• 36e2097: 8255917: runtime/cds/SharedBaseAddress.java failed "assert(reserved_rgn != 0LL) failed: No reserved region"
• d53ee62: 8255899: Allow uninstallation of jpackage exe bundles
• 65756ab: 8257802: LogCompilation throws couldn't find bytecode on JDK 8 log
• a372be4: 8258244: Shenandoah: Not expecting forwarded object in roots during mark after JDK-8240868
• 568dc29: 8185734: [Windows] Structured Exception Catcher missing around gtest execution
• 3ab1dfe: 8257828: SafeFetch may crash if invoked in non-JavaThreads
• 381021a: Merge
• afc4441: 8258094: AIX build fails after 8257602
• 164c8a6: 8258092: Link to early access platform documentation in TestHtmlTableTags.java
• ... and 13 more: https://git.openjdk.java.net/jdk/compare/15481041e0636291cc3516a48c9250d77ded2594...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.

[tstuefe]

Hi Coleen,

this is a good cleanup, I like this a lot.

About moving ErrorHandlerTest.java to gtest: this is a slick way of doing these tests. However, some things to consider:

• Strictly speaking we now do not test the real error handler output but the artificial output ExecutingUnitTests gives us. The real printing code is now untested. This may have bitten you right here, since I believe in print_error_for_unit_test you miss a va_copy which should have messed up detail_args and garbled the real output later on.
• moving these tests out of jtreg means we give up flexibility (excluding them or moving them to another tier). Do they impact the gtest run time noticeably?

There are also remaining problems with gtest death tests, which I hope we can fix at some point. I don't hold my breath though since we decided to not own the gtest code and cannot make modifications:

• Death tests are easily confused by stderr output. See: https://bugs.openjdk.java.net/browse/JDK-8257229. So whenever we have unconditional stderr output in the VM (eg if some large page alloc failed) these death tests fail too.
• Death tests don't tell you the assert message which happened if it did not match their expectations. Thats plain annoying. See https://bugs.openjdk.java.net/browse/JDK-8257227.

[coleenp]

I posted a comment on https://bugs.openjdk.java.net/browse/JDK-8257227. I don't know how to deal with https://bugs.openjdk.java.net/browse/JDK-8257229. These tests would fail because of that also. The assert message tests are nice and imo better than having crashing jtreg tests, but they have these limitations.

[iklam]

I posted a comment on https://bugs.openjdk.java.net/browse/JDK-8257227. I don't know how to deal with https://bugs.openjdk.java.net/browse/JDK-8257229. These tests would fail because of that also. The assert message tests are nice and imo better than having crashing jtreg tests, but they have these limitations.

JDK-8257229 is being fixed in #1748

[tstuefe]

Hi Coleen, sorry for forgetting to mention va_end too. That's still missing, otherwise we leak the copied va_list. Otherwise this looks nice, this is a good cleanup.

Thanks, Thomas

[tstuefe]

Thanks, looks good now.

..Thomas

[tstuefe]

Hi Coleen,

sorry, found another issue. In print_error_for_unit_test multiple threads may race and overwrite each others _detail_fmt buffer. Later on we block all threads but the first to report an error. But not here yet. So, maybe just use a C-heap allocated buffer or a stack buffer. I also don't think it has to be 1024, I guess 128 or so would be enough. We can make it larger if needed.

Cheers, Thomas

[coleenp]

Hi Thomas, thank you for finding the "last" bug in this. I made the buffer stack allocated and 256. That should be enough and it passes all the gtests. Thanks again.

[tstuefe]

Hi Thomas, thank you for finding the "last" bug in this. I made the buffer stack allocated and 256. That should be enough and it passes all the gtests. Thanks again.

Thanks Coleen! Looks good now.

[coleenp]

Thanks Thomas, Ioi and Gerard. I remerged with JDK-8257229: gtest death tests fail with unrecognized stderr output to make sure they still worked together.

[coleenp]

So it turns out that I only tested with linux-x64-debug and not windows and macosx which have slightly different rules for pattern matching. Some of the patterns in the assert(some expression) failed: message didn't match, so I just added .* to the expected message and that worked better. Now I've tested them everywhere.

[iklam]

LGTM

[tstuefe]

Looks good!

[coleenp]

Thanks for re-reviewing Ioi and Thomas.
/integrate

[openjdk]

@coleenp Since your change was applied there have been 24 commits pushed to the master branch:

• 2273f95: 8234930: Use MAP_JIT when allocating pages for code cache on macOS
• da2415f: 8257457: Update --release 16 symbol information for JDK 16 build 28
• 36e2097: 8255917: runtime/cds/SharedBaseAddress.java failed "assert(reserved_rgn != 0LL) failed: No reserved region"
• d53ee62: 8255899: Allow uninstallation of jpackage exe bundles
• 65756ab: 8257802: LogCompilation throws couldn't find bytecode on JDK 8 log
• a372be4: 8258244: Shenandoah: Not expecting forwarded object in roots during mark after JDK-8240868
• 568dc29: 8185734: [Windows] Structured Exception Catcher missing around gtest execution
• 3ab1dfe: 8257828: SafeFetch may crash if invoked in non-JavaThreads
• 381021a: Merge
• afc4441: 8258094: AIX build fails after 8257602
• ... and 14 more: https://git.openjdk.java.net/jdk/compare/15481041e0636291cc3516a48c9250d77ded2594...master

Your commit was automatically rebased without conflicts.

Pushed as commit c37eabe.

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