8259392: Zero error reporting is broken after JDK-8255711 #1980
Conversation
|
Webrevs
|
Hi Aleksey, Approval in principle but it is a bit too verbose for my liking - suggestions below. Thanks, |
LGTM! Thanks. |
@shipilev This change now passes all automated pre-integration checks. After integration, the commit message for the final commit will be:
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 76 new commits pushed to the
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.
|
/integrate |
@shipilev Since your change was applied there have been 79 commits pushed to the
Your commit was automatically rebased without conflicts. Pushed as commit bb247b0. |
This manifests on the following
tier1
tests with Linux x86_64 Zero:runtime/ErrorHandling/ErrorFileRedirectTest.java
runtime/ErrorHandling/SecondaryErrorTest.java
runtime/memory/ReadFromNoaccessArea.java
runtime/Unsafe/InternalErrorTest.java
runtime/Safepoint/TestAbortVMOnSafepointTimeout.java
I believe the generification in JDK-8255711 applies to Zero awkwardly.
Zero is awkward in the sense it is too generic for its own good. It does not have any access to crash context decoders, and that is why
ucontext_*
parsers areShouldNotCallThis()
-ed. Before JDK-8255711, Zero error reporting code was specially crafted to avoid this, apparently.There are at least two problems:
ucontext_get_pc
in unimplemented, so we can special-case those for Zero. Instead of returning a bogus value from Zero implementation, I decided to just special-case at its critical use in error reporting.VMError::report_and_die
circles back at Zero's unimplementedos::fetch_frame_from_context
. Before JDK-8255711, Zero didfatal()
that avoided this trouble. The patch ignores the context to match that behavior.While the regression starts at JDK 16, it affects the path when VM is already crashing, so should not affect product quality per se. Therefore, I would prefer to get it to JDK 17 for some testing, and then maybe consider it for 16.0.{1,2}.
Also, this changeset kills the cat.
Progress
Issue
Reviewers
Download
$ git fetch https://git.openjdk.java.net/jdk pull/1980/head:pull/1980
$ git checkout pull/1980