JDK-6358629 : SSLSocket.close() and SSLSocket.read() deadlock
  • Type: Bug
  • Component: security-libs
  • Sub-Component: javax.net.ssl
  • Affected Version: 1.4.2,6
  • Priority: P3
  • Status: Closed
  • Resolution: Won't Fix
  • OS: generic,solaris_8
  • CPU: generic,sparc
  • Submitted: 2005-12-02
  • Updated: 2011-02-16
  • Resolved: 2008-05-30
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
Other Other JDK 6
1.4.2_18-revFixed 1.4.2_19Fixed 6Fixed
Related Reports
Duplicate :  
JDK-6569529 - Deadlock in com.sun.net.ssl.internal.ssl.SSLSocketImpl
Description
Customer experiences a deadlock when different threads are calling SSLSocketImpl.read() and SSLSocketImpl.close() on the same SSLSocket.  Below we have listed the thread dump. 
 
Thread 1:    the user code is something like
                                           
_input = _sslSocket.getInputStream();
...
_input.read(bytes, offset, length);
 
at com.sun.net.ssl.internal.ssl.SSLSocketImpl.b(DashoA6275)
- waiting to lock <0xef5862e8> (a java.lang.Object)
at com.sun.net.ssl.internal.ssl.SSLSocketImpl.b(DashoA6275)
at com.sun.net.ssl.internal.ssl.SSLSocketImpl.a(DashoA6275)
- locked <0xef5862f0> (a com.sun.net.ssl.internal.ssl.SSLSocketImpl)
- locked <0xef586398> (a java.lang.Object)
at com.sun.net.ssl.internal.ssl.SSLSocketImpl.a(DashoA6275)
at com.sun.net.ssl.internal.ssl.AppInputStream.read(DashoA6275)
- locked <0xef5863a0> (a com.sun.net.ssl.internal.ssl.AppInputStream)

Thread 2:  the user code is :
                  _sslSocket.close();

at com.sun.net.ssl.internal.ssl.SSLSocketImpl.h(DashoA6275)
- waiting to lock <0xef5862f0> (a com.sun.net.ssl.internal.ssl.SSLSocketImpl)
at com.sun.net.ssl.internal.ssl.SSLSocketImpl.b(DashoA6275)
- locked <0xef5862e8> (a java.lang.Object)
at com.sun.net.ssl.internal.ssl.SSLSocketImpl.close(DashoA6275)
at com.borland.security.csiv2.SSLConnection.close(SSLConnection.java:925)
at com.inprise.vbroker.GIOP.GiopConnection.close(GiopConnection.java:647)
- locked <0xef58fdf8> (a com.inprise.vbroker.util.IntMap)
at com.inprise.vbroker.GIOP.GiopProtocolAdapter.close(GiopProtocolAdapter

It is possible to call socket.read() and socket.close() at the same time for plain/normal socket. This should be also possible for SSLSocket.

Customer is creating SSLSockets by calling the sslSocketFactory.createSocket(socket, host, port, autoClose) method.

Customer is setting autoClose as "true" in their product, but it doesn't help.
Comments
EVALUATION Fix has been reintegrated into 1.4.2_17-rev-b14.
30-05-2008
EVALUATION This deadlock can occur if one thread calls sslSocket.close() at the same time another thread reads a close_notify message from the remote peer via inputStream.read(). The problematic locks are the closeLock and the SSLSocketImpl object. This issue is unrelated to layered sockets. An unobfuscated stacktraced obtained from an instrumented Mustang build is shown below. It is not clear what the best way to fix this problem is. It might be possible to eliminate closeLock completely, which is only used in the two places involved in this deadlock. --- Found one Java-level deadlock: ============================= "closer": waiting to lock monitor 0x000fe6f8 (object 0xf41f4848, a com.sun.net.ssl.internal.ssl.SSLSocketImpl), which is held by "main" "main": waiting to lock monitor 0x000fe760 (object 0xf4202950, a com.sun.net.ssl.internal.ssl.SSLSocketImpl$CloseLock), which is held by "closer" Java stack information for the threads listed above: =================================================== "closer": at com.sun.net.ssl.internal.ssl.SSLSocketImpl.getConnectionState(SSLSocketImpl.java:589) - waiting to lock <0xf41f4848> (a com.sun.net.ssl.internal.ssl.SSLSocketImpl) at com.sun.net.ssl.internal.ssl.SSLSocketImpl.closeInternal(SSLSocketImpl.java:1322) - locked <0xf4202950> (a com.sun.net.ssl.internal.ssl.SSLSocketImpl$CloseLock) at com.sun.net.ssl.internal.ssl.SSLSocketImpl.close(SSLSocketImpl.java:1230) at Test$2.run(Test.java:67) at java.lang.Thread.run(Thread.java:626) "main": at com.sun.net.ssl.internal.ssl.SSLSocketImpl.closeInternal(SSLSocketImpl.java:1319) - waiting to lock <0xf4202950> (a com.sun.net.ssl.internal.ssl.SSLSocketImpl$CloseLock) at com.sun.net.ssl.internal.ssl.SSLSocketImpl.recvAlert(SSLSocketImpl.java:1588) at com.sun.net.ssl.internal.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:877) - locked <0xf41f4848> (a com.sun.net.ssl.internal.ssl.SSLSocketImpl) - locked <0xf41f48d0> (a com.sun.net.ssl.internal.ssl.SSLSocketImpl$ReadLock) at com.sun.net.ssl.internal.ssl.SSLSocketImpl.readDataRecord(SSLSocketImpl.java:689) at com.sun.net.ssl.internal.ssl.AppInputStream.read(AppInputStream.java:75) - locked <0xf41f4940> (a com.sun.net.ssl.internal.ssl.AppInputStream) at com.sun.net.ssl.internal.ssl.AppInputStream.read(AppInputStream.java:50) - locked <0xf41f4940> (a com.sun.net.ssl.internal.ssl.AppInputStream) at Test.main(Test.java:86) Found 1 deadlock. ---
03-12-2005