-
Type:
Bug
-
Resolution: Fixed
-
Priority:
P4
-
Affects Version/s: 21, 22, 23
-
Component/s: core-libs
-
b11
-
Verified
| Issue | Fix Version | Assignee | Priority | Status | Resolution | Resolved In Build |
|---|---|---|---|---|---|---|
| JDK-8330553 | 22.0.2 | Richard Reingruber | P4 | Resolved | Fixed | b04 |
| JDK-8333777 | 21.0.5 | Richard Reingruber | P4 | Resolved | Fixed | b01 |
Thread A.........................Thread B
enters ServerSocketChannelImpl::accept
enters AbstractInterruptibleChannel::begin
enters B.interrupt
reads B.nioBlocker -> null
writes B.nioBlocker = AbstractInterruptibleChannel.interruptor
reads B.interrupted -> false
writes B.interrupted = true
leaves AbstractInterruptibleChannel::begin
[...]
enters Net.accept
Result: B successfully calls accept and remains there even though it was interrupted.
How to reproduce:
- apply decide_race_in_thread_interrupt.patch (attached)
- run ThreadInterruptRace.java (also attached) like this
java ThreadInterruptRace.java dosleep
The issue was found analyzing failures of jck test api/java_net/ServerSocket/AcceptInterruptibleTests_PlatformThreads
Potential fix: write `interrupted` field before reading `nioBlocker` in Thread::interrupt
- backported by
-
JDK-8330553 Race: Thread::interrupt vs. AbstractInterruptibleChannel.begin
-
- Resolved
-
-
JDK-8333777 Race: Thread::interrupt vs. AbstractInterruptibleChannel.begin
-
- Resolved
-
- links to
-
Commit
openjdk/jdk21u-dev/8204bd74
-
Commit
openjdk/jdk22u/1188d404
-
Commit
openjdk/jdk/4018b2b1
-
Review
openjdk/jdk21u-dev/451
-
Review
openjdk/jdk21u-dev/578
-
Review
openjdk/jdk22u/130
-
Review
openjdk/jdk/17444