Details
-
Bug
-
Resolution: Fixed
-
P4
-
11, 13, 14, 15, 17, 21
-
b16
Backports
Issue | Fix Version | Assignee | Priority | Status | Resolution | Resolved In Build |
---|---|---|---|---|---|---|
JDK-8331326 | 22.0.2 | Alexey Ivanov | P4 | Resolved | Fixed | b05 |
JDK-8331483 | 21.0.5-oracle | Alexey Ivanov | P4 | Resolved | Fixed | b01 |
JDK-8333416 | 21.0.5 | Martin Doerr | P4 | Resolved | Fixed | b01 |
JDK-8333254 | 17.0.13-oracle | Alexey Ivanov | P4 | Resolved | Fixed | b01 |
JDK-8334001 | 17.0.13 | Martin Doerr | P4 | Resolved | Fixed | b01 |
JDK-8333286 | 11.0.25-oracle | Alexey Ivanov | P4 | Resolved | Fixed | b01 |
JDK-8334312 | 11.0.25 | Martin Doerr | P4 | Resolved | Fixed | b01 |
JDK-8333535 | 8u431 | Alexey Ivanov | P4 | Resolved | Fixed | b01 |
Description
The code in BasicDirectoryModel.java acquires synchronization objects in different orders. One acquires DoChangeContents.this and then fileCache, the other acquires fileCache and then DoChangeContents.this.
Acquiring synchronization objects in different orders can cause a circular wait (deadlock).
Here is the first order: (1) first acquire DoChangeContents.this and then fileCache:
enter public method run() at line 524
acquire synchronization on DoChangeContents.this at entry to run() because run() is a synchronized method --- see line 524
acquire synchronization on fileCache at line 528
Here is the second order: (2) first acquire fileCache and then DoChangeContents.this:
enter public method renameFile() at line 176
acquire synchronization on fileCache at line 177
call validateFileCache() at line 179
call cancelRunnables() at line 157
call cancelRunnables(Vector) at line 397
call cancel() at line 392
acquire synchronization on DoChangeContents.this at entry to cancel() because cancel() is a synchronized method --- see line 520
A straight-forward fix always acquires synchronization in only one order: first fileCache and then DoChangeContents.this. Swap the order of synchronized (this) and synchronized (fileCache) at lines 524 and 528.
Removing the synchronized keyword from the method signature and replacing it with synchronized (this) ensures the same behavior.
public void run() { <<<<<<<<<<<<<<<<<<<<<<<<<<<<< removed synchronized from here and moved it to synchronized (this) 2 lines below
synchronized(fileCache) { <<<<<<<<<<<<<<<<<<<<<<< added this statement instead of the same statement 5 lines below
synchronized(this) { <<<<<<<<<<<<<<<<<<<<< added this instead of the synchronized keyword in the method signature 2 lines above
if (fetchID == fid && doFire) {
int remSize = (remFiles == null) ? 0 : remFiles.size();
int addSize = (addFiles == null) ? 0 : addFiles.size();
synchronized(fileCache) { <<<<<<<<<<<<<<<< ***remove*** from here and moved it 5 lines above
... ... ... ... ... ... ... ...
}
}
}
The downside is that the fileCache synchronized region is larger than before.
Attachments
Issue Links
- backported by
-
JDK-8331326 BasicDirectoryModel getDirectories and DoChangeContents.run can deadlock
- Resolved
-
JDK-8331483 BasicDirectoryModel getDirectories and DoChangeContents.run can deadlock
- Resolved
-
JDK-8333254 BasicDirectoryModel getDirectories and DoChangeContents.run can deadlock
- Resolved
-
JDK-8333286 BasicDirectoryModel getDirectories and DoChangeContents.run can deadlock
- Resolved
-
JDK-8333416 BasicDirectoryModel getDirectories and DoChangeContents.run can deadlock
- Resolved
-
JDK-8333535 BasicDirectoryModel getDirectories and DoChangeContents.run can deadlock
- Resolved
-
JDK-8334001 BasicDirectoryModel getDirectories and DoChangeContents.run can deadlock
- Resolved
-
JDK-8334312 BasicDirectoryModel getDirectories and DoChangeContents.run can deadlock
- Resolved
- duplicates
-
JDK-8238568 Basic Directory Model has a deadlock bug
- Closed
- relates to
-
JDK-8325179 Race in BasicDirectoryModel.validateFileCache
- Resolved
- links to
-
Commit openjdk/jdk11u-dev/2e4179b9
-
Commit openjdk/jdk17u-dev/bc5639a8
-
Commit openjdk/jdk21u-dev/4b3df73b
-
Commit openjdk/jdk22u/e6ba0ee4
-
Commit openjdk/jdk/e66788c1
-
Review openjdk/jdk11u-dev/2768
-
Review openjdk/jdk17u-dev/2539
-
Review openjdk/jdk17u-dev/2558
-
Review openjdk/jdk21u-dev/633
-
Review openjdk/jdk22u/164
-
Review openjdk/jdk/18111