[RFR] 8184328: JDK8u131 socketRead0 hang at SSL read

Xuelei Fan xuelei.fan at oracle.com
Fri Sep 15 23:32:23 UTC 2017

On 9/15/2017 8:22 AM, Rob McKenna wrote:
> This test calls close directly. (3rd last line in the stack)
> I believe this is the only possible stack (with the new parameter) once
> autoclose is set to false. If autoclose is true we'd skip the call to
> waitForClose and just go directly to Socket.close() unless I'm mistaken.
I did not find the call to fatal() in the current implementation.  I 
think you mean you added the call to fatal() in your update so that when 
timeout, a fatal() will always get called?

Thinking about two things:
1. application have to set receiving timeout in order to  get receiving 
I have a concern about it, as described in other comments.

2. can we close the super socket?
It is a surprise to me to close super socket even we don't allocate it. 
It does not feel right to me, but this is the current behavior.  All 
right, I get your point.


>      -Rob
> On 15/09/17 07:55, Xuelei Fan wrote:
>> On 9/15/2017 7:41 AM, Rob McKenna wrote:
>>> On 15/09/17 07:07, Xuelei Fan wrote:
>>>> On 9/15/2017 7:00 AM, Rob McKenna wrote:
>>>>> When we call close() on the SSLSocket that calls close() on the
>>>>> underlying java Socket which closes the native socket.
>>>> Sorry, I did not get the point.  Please see the close() implementation of
>>>> SSLSocket (sun.security.ssl.SSLSocketImpl.close()) about the details.
>>> Running my original test against an instrumented 8u-dev produces the
>>> following:
>>> java.lang.Exception: Stack trace
>>> 	at java.lang.Thread.dumpStack(Thread.java:1336)
>>> 	at java.net.Socket.close(Socket.java:1491)
>>> 	at sun.security.ssl.BaseSSLSocketImpl.close(BaseSSLSocketImpl.java:624)
>>> 	at sun.security.ssl.SSLSocketImpl.closeSocket(SSLSocketImpl.java:1579)
>>> 	at sun.security.ssl.SSLSocketImpl.fatal(SSLSocketImpl.java:1980)
>>> 	at sun.security.ssl.SSLSocketImpl.waitForClose(SSLSocketImpl.java:1793)
>>> 	at sun.security.ssl.SSLSocketImpl.closeSocket(SSLSocketImpl.java:1592)
>>> 	at sun.security.ssl.SSLSocketImpl.closeInternal(SSLSocketImpl.java:1726)
>>> 	at sun.security.ssl.SSLSocketImpl.close(SSLSocketImpl.java:1615)
>>> 	at ssl.SSLClient.close(SSLClient.java:143)
>>> 	at ssl.SocketTimeoutCloseHang.ReadHang.testSSLServer(ReadHang.java:77)
>> It is just one possible stacks of many.  There are cases where no fatal()
>> get called.  For example, application call close() method directly.
>> Xuelei

More information about the security-dev mailing list