JDK-6187048 : WHILE USING JNDI, it goes to DEADLOCK and dumps CORE
  • Type: Bug
  • Component: core-libs
  • Sub-Component: javax.naming
  • Affected Version: 1.4.2_06
  • Priority: P2
  • Status: Closed
  • Resolution: Duplicate
  • OS: windows_2000
  • CPU: x86
  • Submitted: 2004-10-29
  • Updated: 2010-05-10
  • Resolved: 2005-09-30
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
Other
1.4.2_06Resolved
Related Reports
Duplicate :  
JDK-4892070 - java gets hung in com.sun.jndi.ldap.LdapName$TypeAndValue.unescapeValue()
Description
This was seen last worked in 1.3.1_08. Testcase is attached.

While usig JNDI and uploadig some entries on to LDAP Server(Operation is similar to ldapadd using JNDI), we got the core dump as pasted below:

Exception Is Pasted Below:
===========================
com.sun.jndi.ldap.LdapName$TypeAndValue.getUnescapedValue(LdapName.java:730)
        at com.sun.jndi.ldap.LdapName$Rdn.toAttributes(LdapName.java:650)
        at com.sun.jndi.ldap.LdapCtx.addRdnAttributes(LdapCtx.java:891)
        at com.sun.jndi.ldap.LdapCtx.c_createSubcontext(LdapCtx.java:769)
        at
 com.sun.jndi.toolkit.ctx.ComponentDirContext.p_createSubcontext(ComponentDirContext.java:31)
        at
 com.sun.jndi.toolkit.ctx.PartialCompositeDirContext.createSubcontext(
 PartialCompositeDirContext.java:248)
        at
 com.sun.jndi.toolkit.ctx.PartialCompositeDirContext.createSubcontext(
 PartialCompositeDirContext.java:236)
        at
 javax.naming.directory.InitialDirContext.createSubcontext(InitialDirC
 ontext.java:176)
oracle.mail.install.ESDSInstallLDIFLoader.loadLDIF(ESDSInstallLDIFLoa
 der.java:138)
        at
 oracle.mail.install.ESDSInstallComputersConfig.validateAndCreate(ESDS
 InstallComputersConfig.java:70)
        at
 oracle.mail.install.ESDSInstallComputersConfig.main(ESDSInstallComput
 ersConfig.java:97)
 .
 "VM Thread" prio=5 tid=0x002e2dc0 nid=0xcb4 runnable
 .
 "VM Periodic Task Thread" prio=10 tid=0x002feed0 nid=0xba0 waiting on
 condition
 .
 "Suspend Checker Thread" prio=10 tid=0x002a35e0 nid=0xce4 runnable

=========================================================================
java -version
    java version "1.4.2_04"
    Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2_04-b05)
    Java HotSpot(TM) Client VM (build 1.4.2_04-b05, mixed mode)
=========================================================================

 Here is the complete thread dump:-
 ==================================
 Full thread dump Java HotSpot(TM) Client VM (1.4.2_04-b05 mixed mode):
 .
 "Thread-2" daemon prio=5 tid=0x1866f0f0 nid=0x630 runnable [18d9f000..18d9fd88]
        at java.net.SocketInputStream.socketRead0(Native Method)
        at java.net.SocketInputStream.read(SocketInputStream.java:129)
        at java.io.BufferedInputStream.fill(BufferedInputStream.java:183)
        at java.io.BufferedInputStream.read1(BufferedInputStream.java:222)
        at java.io.BufferedInputStream.read(BufferedInputStream.java:277)
        - locked <0x105db730> (a java.io.BufferedInputStream)
        at com.sun.jndi.ldap.Connection.run(Connection.java:780)
        at java.lang.Thread.run(Thread.java:534)
 .
 "Thread-1" daemon prio=5 tid=0x1837aab8 nid=0xbc4 runnable [18d5f000..18d5fd88]
        at java.net.SocketInputStream.socketRead0(Native Method)
        at java.net.SocketInputStream.read(SocketInputStream.java:129)
        at java.io.BufferedInputStream.fill(BufferedInputStream.java:183)
        at java.io.BufferedInputStream.read1(BufferedInputStream.java:222)
        at java.io.BufferedInputStream.read(BufferedInputStream.java:277)
        - locked <0x105dc830> (a java.io.BufferedInputStream)
        at com.sun.jndi.ldap.Connection.run(Connection.java:780)
        at java.lang.Thread.run(Thread.java:534)
 .
 "Signal Dispatcher" daemon prio=10 tid=0x002a4348 nid=0xcc4 runnable [0..0]
 .
 "Finalizer" daemon prio=9 tid=0x002a13c0 nid=0x524 in Object.wait() [1816f000..1816fd88]
        at java.lang.Object.wait(Native Method)
        - waiting on <0x10503310> (a java.lang.ref.ReferenceQueue$Lock)
        at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:111)
        - locked <0x10503310> (a java.lang.ref.ReferenceQueue$Lock)
        at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:127)
        at java.lang.ref.Finalizer$FinalizerThread.run(Finalizer.java:159)
 .
 "Reference Handler" daemon prio=10 tid=0x0029ff78 nid=0xc14 in Object.wait() [1812f000..1812fd88]
        at java.lang.Object.wait(Native Method)
        - waiting on <0x10503378> (a java.lang.ref.Reference$Lock)
        at java.lang.Object.wait(Object.java:429)
        at java.lang.ref.Reference$ReferenceHandler.run(Reference.java:115)
        - locked <0x10503378> (a java.lang.ref.Reference$Lock)
 .
 "main" prio=5 tid=0x002343f0 nid=0xbf8 waiting on condition [6f000..6fc3c]
        at
 com.sun.jndi.ldap.LdapName$TypeAndValue.unescapeValue(LdapName.java:870)
###@###.### 10/29/04 21:32 GMT
###@###.### 10/29/04 21:35 GMT
###@###.### 11/2/04 21:56 GMT
Comments
EVALUATION The attached test code that's hanging is making use of the following JNDI composite name: cn="T:\Oracle",cn=Oraclecontext There are no characters here being treated specially by JNDI, so this in turn gets converted into an identical LDAP DN: cn="T:\Oracle",cn=Oraclecontext This is not, however, a valid DN. Double quotes are an LDAP v2 escape mechanism, and cannot be used reliably with modern LDAP v3 servers. Even where v2 names are accepted, the double quotes above are superfluous. The way to escape a backslash in LDAP (v2 or v3) is with another backslash: cn=T:\\Oracle,cn=Oraclecontext The JDK implementation is reacting to this invalid DN by going into an infinite loop. This was fixed in JDK 5.0: it now throws a more information exception: IllegalArgumentException: Not a valid attribute string value:"T:\Oracle", improper usage of backslash That was bugid 4892070: java gets hung in com.sun.jndi.ldap.LdapName$TypeAndValue.unescapeValue(). I intend to close this bug as a dup of that one. Note that the submitter here does not need the fix for 4892070. Rather, the submitter needs to fix the code that's generating the bad DN. In the attached test code, this line: DirContext result = dctx.createSubcontext("cn=\"T:\\Oracle\",cn=Oraclecontext", attrs); could be replaced by: Name n = new CompositeName().add("cn=T:\\\\Oracle,cn=Oraclecontext"); dctx.createSubcontext(n, attrs); I used the "CompositeName.add idiom" to minimize the risk that someone modifying this code for their own purposes will run into problems with characters that are special to each of Java, JNDI, and LDAP. For a discussion of this see: http://java.sun.com/products/jndi/tutorial/beyond/names/syntax.html ###@###.### 11/3/04 03:41 GMT I should mention that J2SE 5 includes a new API for creating and manipulating LDAP names that can do all of this escaping (and unescaping) for you. See javax.naming.ldap.LdapName and javax.naming.ldap.Rdn. ###@###.### 11/3/04 03:50 GMT
03-11-2004
WORK AROUND If we use java version "1.3.1_08", we will hit this issue, it proceeds smoothly. ###@###.### 10/29/04 21:32 GMT
29-10-2004