[RFR] 8184328: JDK8u131 socketRead0 hang at SSL read

Rob McKenna rob.mckenna at oracle.com
Fri Sep 15 15:22:30 UTC 2017


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.

    -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