-
Bug
-
Resolution: Fixed
-
P4
-
11, 16, 17
-
b15
Issue | Fix Version | Assignee | Priority | Status | Resolution | Resolved In Build |
---|---|---|---|---|---|---|
JDK-8292727 | 11.0.18-oracle | David Buck | P4 | Resolved | Fixed | b01 |
JDK-8295129 | 11.0.18 | Goetz Lindenmaier | P4 | Resolved | Fixed | b01 |
We use anonymous Posix semaphores for some synchronization in hotspot.
sem_destroy() can fail on some platforms with EBUSY if the semaphore has still threads waiting on it. The glibc does not care and will happily report success, but other Unices care (eg BSD, AIX) 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.
sem_destroy() can fail on some platforms with EBUSY if the semaphore has still threads waiting on it. The glibc does not care and will happily report success, but other Unices care (eg BSD, AIX) 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.
- backported by
-
JDK-8292727 On sem_destroy() failing we should assert
-
- Resolved
-
-
JDK-8295129 On sem_destroy() failing we should assert
-
- Resolved
-
- links to
-
Commit openjdk/jdk11u-dev/84e52a38
-
Commit openjdk/jdk/5b8233ba
-
Review openjdk/jdk11u-dev/1429
-
Review openjdk/jdk/3089
(1 links to)