The test failed on the second run with IPv6 on the loopback
This appears to be a deadlock, but the thread that holds the monitor has apparently disappeared. This should not be possible.

Found one Java-level deadlock:
=============================
"Thread-14":
  waiting to lock monitor 0x0000fffee4001ff0 (object 0x00000000d0092700, a sun.security.ssl.SSLSocketOutputRecord),
  which is held by UNKNOWN_owner_addr=0x00000000edb06d88

Java stack information for the threads listed above:
===================================================
"Thread-14":
at java.io.ByteArrayOutputStream.write(java.base@22-ea/ByteArrayOutputStream.java:112)
- waiting to lock <0x00000000d0092700> (a sun.security.ssl.SSLSocketOutputRecord)
at sun.security.ssl.SSLSocketOutputRecord.encodeAlert(java.base@22-ea/SSLSocketOutputRecord.java:68)
at sun.security.ssl.TransportContext.fatal(java.base@22-ea/TransportContext.java:414)
at sun.security.ssl.TransportContext.fatal(java.base@22-ea/TransportContext.java:321)
at sun.security.ssl.TransportContext.fatal(java.base@22-ea/TransportContext.java:316)
at sun.security.ssl.SSLSocketImpl.handleException(java.base@22-ea/SSLSocketImpl.java:1709)
at sun.security.ssl.SSLSocketImpl.startHandshake(java.base@22-ea/SSLSocketImpl.java:470)
at sun.security.ssl.SSLSocketImpl.startHandshake(java.base@22-ea/SSLSocketImpl.java:426)
at sun.net.www.protocol.https.HttpsClient.afterConnect(java.base@22-ea/HttpsClient.java:586)
at sun.net.www.protocol.https.AbstractDelegateHttpsURLConnection.connect(java.base@22-ea/AbstractDelegateHttpsURLConnection.java:187)
at sun.net.www.protocol.http.HttpURLConnection.getInputStream0(java.base@22-ea/HttpURLConnection.java:1677)
at sun.net.www.protocol.http.HttpURLConnection.getInputStream(java.base@22-ea/HttpURLConnection.java:1601)
at sun.net.www.protocol.https.HttpsURLConnectionImpl.getInputStream(java.base@22-ea/HttpsURLConnectionImpl.java:223)
at Test9a$ClientThread.run(Test9a.java:160)

Found 1 deadlock.