Details
-
Bug
-
Resolution: Fixed
-
P2
-
9
-
JRE 8u66: works fine
JRE 9-ea: problem happens always (Windows 7)
JRE 9-ea: problem happens often (Windows 8)
-
b97
-
x86_64
-
windows_7
-
Not verified
Description
Apparently there is a deadlock happening in JRE 9 which does not appear to happen in JRE 8u66. Hence I assume this to be a new bug introduced by JRE 9. The bug is happening sporadically, and apparently it looks like it happens more often on Windows 7 (64 Bit) and less often on Windows 8 (64 Bit) according to several weeks of manual testing. As the bug only happens sporadically, no automatic test is possible for this.
Steps to reproduce:
* Open SSLSocket.
* Several threads write into the socket.
* Keep the application running
* Put Windows in hibernation mode
* Wait for about 24 hours
* Resume Windows from hibernation mode
* Thread A tries to write into the socket
* Thread B tries to close the socket
Expected behaviour:
* Thread A will throw an exception as the TCP connection is broken due to timeout while the PC was hibernated
* Thread B will succeed as it shouldn't be a problem to explicitly close a socket which is invalid due to the OS's timeout.
Actual behaviour:
* A deadlock accurs between thread A and thread B.
* See attached stack trace / deadlock report
Note: A real-world application was used for about one month in daily field use, both on JRE 8u66 and JRE 9-ea on several PCs. The problem never happened on JRE 8u66. The problem ALWAYS happened on JRE 9-ea (Windows 7). The problem OFTEN happened on JRE 9-ea (Windows 8).
I assume a race condition and / or mixed sequence of locks: One lock might be set by the OS, another lock by the JRE. Depending on the champion of the race, there might be a deadlock between .close() and .write(), or not.
Steps to reproduce:
* Open SSLSocket.
* Several threads write into the socket.
* Keep the application running
* Put Windows in hibernation mode
* Wait for about 24 hours
* Resume Windows from hibernation mode
* Thread A tries to write into the socket
* Thread B tries to close the socket
Expected behaviour:
* Thread A will throw an exception as the TCP connection is broken due to timeout while the PC was hibernated
* Thread B will succeed as it shouldn't be a problem to explicitly close a socket which is invalid due to the OS's timeout.
Actual behaviour:
* A deadlock accurs between thread A and thread B.
* See attached stack trace / deadlock report
Note: A real-world application was used for about one month in daily field use, both on JRE 8u66 and JRE 9-ea on several PCs. The problem never happened on JRE 8u66. The problem ALWAYS happened on JRE 9-ea (Windows 7). The problem OFTEN happened on JRE 9-ea (Windows 8).
I assume a race condition and / or mixed sequence of locks: One lock might be set by the OS, another lock by the JRE. Depending on the champion of the race, there might be a deadlock between .close() and .write(), or not.