Uploaded image for project: 'JDK'
  1. JDK
  2. JDK-6569529

Deadlock in com.sun.net.ssl.internal.ssl.SSLSocketImpl

XMLWordPrintable

    • Icon: Bug Bug
    • Resolution: Duplicate
    • Icon: P4 P4
    • None
    • 6
    • security-libs

      FULL PRODUCT VERSION :
      Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_10-b03)
      Java HotSpot(TM) Server VM (build 1.5.0_10-b03, mixed mode)

      ADDITIONAL OS VERSION INFORMATION :
      SunOS c002495 5.8 Generic_117350-46 sun4u sparc SUNW,Sun-Fire-480R

      A DESCRIPTION OF THE PROBLEM :
      This deadlock can occur when the java ssl client closes the connection simultaneously with the peer and the ssl client invokes close() in a different thread than the read operation which handles the close of the peer.

      Reader Thread (Thread-903):
       - when the server closes the connection, readDataRecord() locks the monitor of this and closeInternal() is called.
       - closeInternal() tries to lock the closeLock monitor and afterwards the monitor of this but that is not possible when the close lock is already held by the close thread.

      Close Thread (Thread-900):
       - close() invokes closeInternal()
       - closeInternal() locks the closeLock monitor and tries to lock the monitor of this but this is not possible when the monitor is held by the reader thread.

      -> The deadlock occurs because the monitor of this and the closeLock monitor are not locked always in the same order.

      The situation of using different threads using the same SSLSocketImpl described above is in fact common when the sun ldap JNDI implementation is used as visible in the stack trace.


      ACTUAL -

      2007/06/04 08:14:51 | Full thread dump Java HotSpot(TM) Server VM (1.5.0_10-b03 mixed mode):
      ...
      2007/06/04 08:14:51 | Found one Java-level deadlock:
      2007/06/04 08:14:51 | =============================
      2007/06/04 08:14:51 | "Thread-903":
      2007/06/04 08:14:51 | waiting to lock monitor 0x00153aa8 (object 0xf0f454d8, a java.lang.Object),
      2007/06/04 08:14:51 | which is held by "Thread-900"
      2007/06/04 08:14:51 | "Thread-900":
      2007/06/04 08:14:51 | waiting to lock monitor 0x00153af0 (object 0xf0f41e60, a com.sun.net.ssl.internal.ssl.SSLSocketImpl),
      2007/06/04 08:14:51 | which is held by "Thread-903"
      2007/06/04 08:14:51 |
      2007/06/04 08:14:51 | Java stack information for the threads listed above:
      2007/06/04 08:14:51 | ===================================================
      2007/06/04 08:14:51 | "Thread-903":
      2007/06/04 08:14:51 | at com.sun.net.ssl.internal.ssl.SSLSocketImpl.closeInternal(SSLSocketImpl.java:1308)
      2007/06/04 08:14:51 | - waiting to lock <0xf0f454d8> (a java.lang.Object)
      2007/06/04 08:14:51 | at com.sun.net.ssl.internal.ssl.SSLSocketImpl.recvAlert(SSLSocketImpl.java:1566)
      2007/06/04 08:14:51 | at com.sun.net.ssl.internal.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:866)
      2007/06/04 08:14:51 | - locked <0xf0f41e60> (a com.sun.net.ssl.internal.ssl.SSLSocketImpl)
      2007/06/04 08:14:51 | - locked <0xf0f454d0> (a java.lang.Object)
      2007/06/04 08:14:51 | at com.sun.net.ssl.internal.ssl.SSLSocketImpl.readDataRecord(SSLSocketImpl.java:680)
      2007/06/04 08:14:51 | at com.sun.net.ssl.internal.ssl.AppInputStream.read(AppInputStream.java:75)
      2007/06/04 08:14:51 | - locked <0xf0f455c0> (a com.sun.net.ssl.internal.ssl.AppInputStream)
      2007/06/04 08:14:51 | at java.io.BufferedInputStream.fill(BufferedInputStream.java:218)
      2007/06/04 08:14:51 | at java.io.BufferedInputStream.read1(BufferedInputStream.java:256)
      2007/06/04 08:14:51 | at java.io.BufferedInputStream.read(BufferedInputStream.java:313)
      2007/06/04 08:14:51 | - locked <0xf0f41e28> (a java.io.BufferedInputStream)
      2007/06/04 08:14:51 | at com.sun.jndi.ldap.Connection.run(Connection.java:784)
      2007/06/04 08:14:51 | at java.lang.Thread.run(Thread.java:595)
      2007/06/04 08:14:51 | "Thread-900":
      2007/06/04 08:14:51 | at com.sun.net.ssl.internal.ssl.SSLSocketImpl.closeInternal(SSLSocketImpl.java:1315)
      2007/06/04 08:14:51 | - waiting to lock <0xf0f41e60> (a com.sun.net.ssl.internal.ssl.SSLSocketImpl)
      2007/06/04 08:14:51 | - locked <0xf0f454d8> (a java.lang.Object)
      2007/06/04 08:14:51 | at com.sun.net.ssl.internal.ssl.SSLSocketImpl.close(SSLSocketImpl.java:1219)
      2007/06/04 08:14:51 | at com.sun.jndi.ldap.Connection.cleanup(Connection.java:605)
      2007/06/04 08:14:51 | - locked <0xf0f41d20> (a com.sun.jndi.ldap.Connection)
      2007/06/04 08:14:51 | at com.sun.jndi.ldap.LdapClient.close(LdapClient.java:415)
      2007/06/04 08:14:51 | - locked <0xf0f41ee8> (a com.sun.jndi.ldap.LdapClient)
      2007/06/04 08:14:51 | at com.sun.jndi.ldap.LdapCtx.closeConnection(LdapCtx.java:2701)
      2007/06/04 08:14:51 | at com.sun.jndi.ldap.LdapCtx.close(LdapCtx.java:2489)
      2007/06/04 08:14:51 | - locked <0xf0f42768> (a com.sun.jndi.ldap.LdapCtx)
      2007/06/04 08:14:51 | at javax.naming.InitialContext.close(InitialContext.java:490)
      2007/06/04 08:14:51 | at sun.reflect.GeneratedMethodAccessor50.invoke(Unknown Source)
      2007/06/04 08:14:51 | at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
      2007/06/04 08:14:51 | at java.lang.reflect.Method.invoke(Method.java:585)
      2007/06/04 08:14:51 | at com.winterthur.jackpot.service.RemoteInvocationHandler.invoke(RemoteInvocationHandler.java:273)
      2007/06/04 08:14:51 | at $Proxy25.close(Unknown Source)
      2007/06/04 08:14:51 | at javax.naming.InitialContext.close(InitialContext.java:490)
      2007/06/04 08:14:51 | at com.winterthur.ldapupdater.LDAPConnection.disconnect(LDAPConnection.java:108)
      2007/06/04 08:14:51 | at com.winterthur.ldapupdater.threads.LDAPUpdaterThread.closeLDAPConnection(LDAPUpdaterThread.java:132)
      2007/06/04 08:14:51 | at com.winterthur.ldapupdater.threads.MappingThread.run(MappingThread.java:250)
      2007/06/04 08:14:51 |

       


      REPRODUCIBILITY :
      This bug can be reproduced occasionally.

      CUSTOMER SUBMITTED WORKAROUND :
      Not closing the ldap JNDI context and let the garbage collector clean up the resources.

            Unassigned Unassigned
            ndcosta Nelson Dcosta (Inactive)
            Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

              Created:
              Updated:
              Resolved:
              Imported:
              Indexed: