-
Notifications
You must be signed in to change notification settings - Fork 5.7k
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
JDK-8263871: On sem_destroy() failing we should assert #3089
Conversation
👋 Welcome back stuefe! A progress list of the required criteria for merging this PR into |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good and trivial.
I just hope we don't find sem_destroy has been silently failing :)
Thanks,
David
@tstuefe 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:
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 11 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. ➡️ To integrate this PR with the above commit message to the |
Thanks David! I hope so too. /integrate |
@tstuefe Since your change was applied there have been 11 commits pushed to the
Your commit was automatically rebased without conflicts. Pushed as commit 5b8233b. 💡 You may see a message that your pull request was closed with unmerged commits. This can be safely ignored. |
This is rather trivial.
We use anonymous Posix semaphores for some synchronization in hotspot.
sem_destroy()
can fail on some platforms with EBUSY if the semaphore has outstanding waiters. The glibc does not care, will happily wipe the sem_t structure and report success. But other Unices care (eg BSD, AIX, HP-UX) and refuse to close the semaphore, leaving the sem_t structure untouched.It then happened for us that a new semaphore was created at the exact location of the old, still unclosed semaphore, and the unchanged sem_t structure was fed to sem_init(), which would fail with the same EBUSY error and trigger a guarantee.
One simple thing we should do is to assert success after closing a semaphore, as we do on all other semaphore operations. Granted, we won't see anything on Linux with glibc, but maybe shake loose errors on other platforms.
Progress
Issue
Reviewers
Download
To checkout this PR locally:
$ git fetch https://git.openjdk.java.net/jdk pull/3089/head:pull/3089
$ git checkout pull/3089
To update a local copy of the PR:
$ git checkout pull/3089
$ git pull https://git.openjdk.java.net/jdk pull/3089/head