Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

8259392: Zero error reporting is broken after JDK-8255711 #1980



Copy link

@shipilev shipilev commented Jan 7, 2021

This manifests on the following tier1 tests with Linux x86_64 Zero:


00:17:25 #  Internal Error (/home/shade/trunks/jdk/src/hotspot/os_cpu/linux_zero/os_linux_zero.cpp:94), pid=739632, tid=739633
00:17:25 #  Error: ShouldNotCall()
address os::Posix::ucontext_get_pc(const ucontext_t* uc) {
  ShouldNotCallThis(); <---- crash here
  return NULL; // silence compile warnings

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 are ShouldNotCallThis()-ed. Before JDK-8255711, Zero error reporting code was specially crafted to avoid this, apparently.

There are at least two problems:

  1. 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.
  2. generic VMError::report_and_die circles back at Zero's unimplemented os::fetch_frame_from_context. Before JDK-8255711, Zero did fatal() 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.


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


  • JDK-8259392: Zero error reporting is broken after JDK-8255711



$ git fetch pull/1980/head:pull/1980
$ git checkout pull/1980

Copy link

@bridgekeeper bridgekeeper bot commented Jan 7, 2021

👋 Welcome back shade! 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.

Copy link

@openjdk openjdk bot commented Jan 7, 2021

@shipilev 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.

@shipilev shipilev marked this pull request as ready for review Jan 7, 2021
@openjdk openjdk bot added the rfr label Jan 7, 2021
Copy link

@mlbridge mlbridge bot commented Jan 7, 2021


Copy link

@dholmes-ora dholmes-ora left a comment

Hi Aleksey,

Approval in principle but it is a bit too verbose for my liking - suggestions below.


src/hotspot/os/posix/signals_posix.cpp Outdated Show resolved Hide resolved
Copy link

@dholmes-ora dholmes-ora left a comment



Copy link

@openjdk openjdk bot commented Jan 10, 2021

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

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

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

8259392: Zero error reporting is broken after JDK-8255711

Reviewed-by: dholmes

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 master branch:

  • e7c1740: 8258187: IllegalMonitorStateException in ArrayBlockingQueue
  • 11d5b04: 8258217: PriorityBlockingQueue constructor spec and behavior mismatch
  • 65ca5c6: 8048109: JToggleButton does not fire actionPerformed under certain conditions
  • 81db63e: 8259517: Incorrect test path in test cases
  • 270014a: 8234131: Miscellaneous changes imported from jsr166 CVS 2021-01
  • 63e3bd7: 8246677: LinkedTransferQueue and SynchronousQueue synchronization updates
  • 5cfa8c9: 8246585: ForkJoin updates
  • 6472104: 6278172: TextComponent.getSelectedText() throws StringIndexOutOfBoundsException
  • a653928: 8259512: Update --release 16 symbol information for JDK 16 build 31
  • 7e6677b: 8259446: runtime/jni/checked/ fails with stderr not empty
  • ... and 66 more:

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.

@openjdk openjdk bot added the ready label Jan 10, 2021
Copy link
Contributor Author

@shipilev shipilev commented Jan 11, 2021


@openjdk openjdk bot closed this Jan 11, 2021
@openjdk openjdk bot added integrated and removed ready rfr labels Jan 11, 2021
Copy link

@openjdk openjdk bot commented Jan 11, 2021

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

Your commit was automatically rebased without conflicts.

Pushed as commit bb247b0.

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

@shipilev shipilev deleted the shipilev:JDK-8259392-zero-error-report branch Jan 11, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
2 participants