United StatesChange Country, Oracle Worldwide Web Sites Communities I am a... I want to...
Bug ID: JDK-6358629 SSLSocket.close() and SSLSocket.read() deadlock
JDK-6358629 : SSLSocket.close() and SSLSocket.read() deadlock

Details
Type:
Bug
Submit Date:
2005-12-02
Status:
Closed
Updated Date:
2011-02-16
Project Name:
JDK
Resolved Date:
2008-05-30
Component:
security-libs
OS:
solaris_8,generic
Sub-Component:
javax.net.ssl
CPU:
sparc,generic
Priority:
P3
Resolution:
Won't Fix
Affected Versions:
1.4.2,6
Fixed Versions:
1.4.2_12

Related Reports
Backport:
Backport:
Backport:
Backport:
Duplicate:

Sub Tasks

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

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.
---
                                     
2005-12-03
EVALUATION

Fix has been reintegrated into 1.4.2_17-rev-b14.
                                     
2008-05-30



Hardware and Software, Engineered to Work Together