jdk8u-dev
jdk8u-dev copied to clipboard
8186787: clang-4.0 SIGSEGV in Unsafe_PutByte
This backport fixes failures (segfaults) in following tests which appeared after macos update:
sun/misc/CopyMemory.java
compiler/unsafe/OpaqueAccesses.java
Backport differs from original changeset, because there were significant changes/refactoring in unsafe.
Notes:
- original changeset changes pointer returned by
addr(MemoryAccessclass), to volatile. Otherwise it is basically just refactoring. MemoryAccessis used byUnsafe_{Set,Put}*andUnsafe_{Set,Put}*Volatilefunctions, defined usingDEFINE_GETSETOOPandDEFINE_GETSETOOP_VOLATILEmacros- jdk8 does not have
MemoryAccessclass, so equivalent pointers, in functions mentioned higher, are cast to volatile, to achieve same effect
Testing:
Tier1: OK (fixes sun/misc/CopyMemory.java and compiler/unsafe/OpaqueAccesses.java tests on macos, 1 failure on Linux x86 is timeout - seems unrelated, macos failures explained here: https://github.com/openjdk/jdk8u-dev/pull/544#issuecomment-2250636257)
Progress
- [ ] Change must be properly reviewed (1 review required, with at least 1 Reviewer)
- [ ] JDK-8186787 needs maintainer approval
- [x] Change must not contain extraneous whitespace
- [x] Commit message must refer to an issue
Issue
- JDK-8186787: clang-4.0 SIGSEGV in Unsafe_PutByte (Bug - P2)
Reviewing
Using git
Checkout this PR locally:
$ git fetch https://git.openjdk.org/jdk8u-dev.git pull/553/head:pull/553
$ git checkout pull/553
Update a local copy of the PR:
$ git checkout pull/553
$ git pull https://git.openjdk.org/jdk8u-dev.git pull/553/head
Using Skara CLI tools
Checkout this PR locally:
$ git pr checkout 553
View PR using the GUI difftool:
$ git pr show -t 553
Using diff file
Download this PR as a diff file:
https://git.openjdk.org/jdk8u-dev/pull/553.diff
Webrev
:wave: Welcome back zzambers! 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.
@zzambers This change now passes all automated pre-integration checks.
After integration, the commit message for the final commit will be:
8186787: clang-4.0 SIGSEGV in Unsafe_PutByte
Reviewed-by: adinn, andrew
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 3 new commits pushed to the master branch:
- 8c4a65b99dca01793faa441a958450dfdb54dcba: 8351098: Bump update version of OpenJDK: 8u462
- 6a7d893928b3fde9ee3ebff9782620f9ae1be358: 8350816: [8u] Update TzdbZoneRulesCompiler to ignore HST/EST/MST links
- 8f8531c0a542eab469d21a5557b3ffb9f39d60b7: 8285756: clean up use of bad arguments for
@cleanin langtools tests
Please see this link for an up-to-date comparison between the source branch of this pull request and the master branch.
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.
This backport pull request has now been updated with issue from the original commit.
Log from failing (segfaulting) tests (without fix, for reference): CopyMemory-segfault.log OpaqueAccesses-segfault.log
@zzambers This pull request has been inactive for more than 4 weeks and will be automatically closed if another 4 weeks passes without any activity. To avoid this, simply add a new comment to the pull request. Feel free to ask for assistance if you need help with progressing this pull request towards integration!
keep open
@zzambers This pull request has been inactive for more than 4 weeks and will be automatically closed if another 4 weeks passes without any activity. To avoid this, simply add a new comment to the pull request. Feel free to ask for assistance if you need help with progressing this pull request towards integration!
@zzambers This pull request has been inactive for more than 4 weeks and will be automatically closed if another 4 weeks passes without any activity. To avoid this, simply add a new comment to the pull request. Feel free to ask for assistance if you need help with progressing this pull request towards integration!
@zzambers This pull request has been inactive for more than 4 weeks and will be automatically closed if another 4 weeks passes without any activity. To avoid this, simply add a new comment to the pull request. Feel free to ask for assistance if you need help with progressing this pull request towards integration!
@zzambers This pull request has been inactive for more than 4 weeks and will be automatically closed if another 4 weeks passes without any activity. To avoid this, simply add a new comment to the pull request. Feel free to ask for assistance if you need help with progressing this pull request towards integration!
@zzambers This pull request has been inactive for more than 8 weeks and will now be automatically closed. If you would like to continue working on this pull request in the future, feel free to reopen it! This can be done using the /open pull request command.
/open
@zzambers This pull request is now open
@adinn @tstuefe @theRealAph Could you please help review this? We see crashes of this in GHA, so it looks to fix a real bug. Then again it's fairly late to touch this area in JDK 8u. Thoughts?
Btw, as GHA logs have expired and this is now last remaining issue showing in tier1 on Mac, I have tried to rebase these changes in separate branch (to retest on head). There are no failures except for security_infra tests - which are unrelated
(I can force-push rebased change here if desired)
@jerboaa I think this is fine to backport. Adding a volatile qualifier to the access cannot really do any harm as it has the very limited effect of stopping the C++ compiler from reordering the volatile field access write relative to other volatile field accesses within the current thread's instruction stream. Since that is actually what is required here I cannot see any real risk. My real concern is that the introduction of volatile is clearly flagged in comments and happens at a point where it is most obvious what is going on and why.
@zzambers Please do not rebase or force-push to an active PR as it invalidates existing review comments. Note for future reference, the bots always squash all changes into a single commit automatically as part of the integration. See OpenJDK Developers’ Guide for more information.
@adinn thank you for the review
I added comment, as you have suggested. (As in the end, approach with DEFINE_GETSETOOP is not used, I kept it as it is.) Should I mark you as co-author?
I rebased changes on current master, to avoid some unrelated, already fixed failures in GHA testing.
@zzambers It's fine as it is.
⚠️ @zzambers This change is now ready for you to apply for maintainer approval. This can be done directly in each associated issue or by using the /approval command.
GHA tests: OK (fixes Mac tests)
Failures:
- linux x86 failures (know troublemakers/unstable tests)
gc/concurrentMarkSweep/SystemGCOnForegroundCollector.java(known, see: JDK-8303159)gc/logging/TestGCId.java- timeout (known, occasionally timeouts on linux x86)
jdk/security_infra- unrelated
/approval request Fix to unsafe to avoid tier1 failures (crashes) on Mac, small change, low risk, GHA tests OK
@zzambers 8186787: The approval request has been created successfully.
/approve yes
@gnu-andrew 8186787: The approval request has been approved.
/integrate
Going to push as commit 79124139a676a555511f4365ce6771a7dc920dcf.
Since your change was applied there have been 3 commits pushed to the master branch:
- 8c4a65b99dca01793faa441a958450dfdb54dcba: 8351098: Bump update version of OpenJDK: 8u462
- 6a7d893928b3fde9ee3ebff9782620f9ae1be358: 8350816: [8u] Update TzdbZoneRulesCompiler to ignore HST/EST/MST links
- 8f8531c0a542eab469d21a5557b3ffb9f39d60b7: 8285756: clean up use of bad arguments for
@cleanin langtools tests
Your commit was automatically rebased without conflicts.
@zzambers Pushed as commit 79124139a676a555511f4365ce6771a7dc920dcf.
:bulb: You may see a message that your pull request was closed with unmerged commits. This can be safely ignored.