-
Bug
-
Resolution: Fixed
-
P3
-
8
-
b01
Issue | Fix Version | Assignee | Priority | Status | Resolution | Resolved In Build |
---|---|---|---|---|---|---|
JDK-8239161 | openjdk8u252 | Anton Kozlov | P3 | Resolved | Fixed | b03 |
JDK-8235886 | openjdk8u242 | Anton Kozlov | P3 | Resolved | Fixed | b05 |
JDK-8226997 | 8u221 | Robert Mckenna | P3 | Resolved | Fixed | master |
JDK-8222858 | 8u212 | Robert Mckenna | P3 | Closed | Fixed | b32 |
JDK-8229601 | emb-8u231 | Robert Mckenna | P3 | Resolved | Fixed | b01 |
Thread A has called FileSystems.getDefault() which is doing <clinit> of DefaultFileSystemHolder, which in turn leads to Runtime.loadLibrary0 which needs to lock the Runtime instance.
Thread B is already doing a loadLibrary and holds the Runtime lock, the loadLibrary code then needs to do FileSystems.getDefault() which has to load and initialize DefaultFileSystemHolder, but that initialization is already in progress so internally the thread does a wait().
So Thread B is waiting for Thread A to finish initialization, but holds the monitor lock that Thread A needs to finish the initialization. Deadlock.
- backported by
-
JDK-8226997 Deadlock involving FileSystems.getDefault and System.loadLibrary call
- Resolved
-
JDK-8229601 Deadlock involving FileSystems.getDefault and System.loadLibrary call
- Resolved
-
JDK-8235886 Deadlock involving FileSystems.getDefault and System.loadLibrary call
- Resolved
-
JDK-8239161 Deadlock involving FileSystems.getDefault and System.loadLibrary call
- Resolved
-
JDK-8222858 Deadlock involving FileSystems.getDefault and System.loadLibrary call
- Closed
- duplicates
-
JDK-8217884 File system iniitialization deadlock
- Closed
-
JDK-8220367 Investigate Deadlock involving FileSystems.getDefault and System.loadLibrary call
- Closed
- relates to
-
JDK-8231584 Deadlock with ClassLoader.findLibrary and System.loadLibrary call
- Closed