-
Bug
-
Resolution: Fixed
-
P4
-
21, 22, 23
-
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