OPERATING SYSTEM
----------------
All

FULL JDK VERSION
----------------
All

DESCRIPTION from LICENSEE:
--------------------------
Consider the creation of a SocketAdaptor instance using code like this:

    InetAddress loopback = InetAddress.getByName("192.168.1.1");
    SocketChannel sc = SocketChannel.open();
    
    InetSocketAddress addr = new InetSocketAddress(loopback,80);
    sc.socket().connect(addr);

If we subsequently attempt close the SocketAdaptor:
 
    sc.socket().close();

but the close() fails with an IOException (which can happen as per the API spec), the SocketAdaptor will rethrow the Exception as an Error:

    java.lang.Error: Untranslated exception
        at sun.nio.ch.Net.translateToSocketException(Net.java:91)
        at sun.nio.ch.SocketAdaptor.close(SocketAdaptor.java:403)
        ...

In practice this happens quite rarely, but when it does happen this unhandled Error causes the thread (or even the process) to die, and there is no real means of handling it, other than adding a very nasty catch(Throwable t) block.

The problem occurs because the SocketAdaptor class does not translate the IOException, and the default action is to throw an Error in this scenario. The relevant code, in SocketAdaptor.close(), looks like this:

    public void close() throws IOException {
        try {
            sc.close();
        } catch (Exception x) {
     ----> Net.translateToSocketException(x); <----
        }
    }

The IOException would be translated appropriately if the code was changed to this:

    public void close() throws IOException {
        try {
            sc.close();
        } catch (Exception x) {
     ----> Net.translateException(x); <----
        }
    }

Note that the code in ServerSocketAdaptor.close() already looks like the fix suggestion above. Also note essentially the same issue used to exist for BindExceptions in SocketAdaptor.bind() (CR 6303753) - this was fixed in exactly the way suggested above.

Unfortunately there is no easy way to test this, although the failing code looks something like this:

----
InetAddress loopback = InetAddress.getByName("192.168.1.1");
SocketChannel sc = SocketChannel.open();
   
InetSocketAddress addr = new InetSocketAddress(loopback,80);
sc.socket().connect(addr);
sc.socket().close(); <-- IOException needs to be thrown here
----

Following the execution path through the JDK source the IOException can only be thrown by the code below, in FileDispatcher.c (this is from the Solaris source):

----
static void closeFileDescriptor(JNIEnv *env, int fd) {
    if (fd != -1) {
        int result = close(fd);
        if (result < 0)
            JNU_ThrowIOExceptionWithLastError(env, "Close failed");
    }
}
----

The problem, in terms of recreation, is working out an artificial way of forcing the IOException to be thrown when close() is called.

Our customer is on Z/OS, and they are seeing the IOException with the message "EDC5112I Resource temporarily unavailable.". This is the Z/OS equivalent of the POSIX error "EAGAIN", so exactly the same issue could occur on Solaris/Linux under the right circumstances (i.e. where the file descriptor could not be accessed by the OS when close() is called).

As mentioned in the report, in production the IOException is highly intermittent, but when it does occur it's unnecessarily catastrophic because it ends up being translated to an Error by the SocketAdaptor code. If it was translated properly the Exception could be caught and handled accordingly.