393929 - NullPointerException in LDAPConnection.search call to checkSearchMsg

Status: RESOLVED WONTFIX

(Directory Graveyard :: LDAP Java SDK, defect)

Description

[Joey Paskhay]

User-Agent:       Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; .NET CLR 1.1.4322; .NET CLR 2.0.50727; .NET CLR 3.0.04506.30)
Build Identifier: ldapsdk_java_20000505 (4.1) but looks like problem may happen in latest release (ldapsdk_java_20020819 [4.17])

This issue has been seen twice on our system. Below is the relavant stack trace.

java.lang.NullPointerException
        at netscape.ldap.LDAPConnection.checkSearchMsg(LDAPConnection.java:2621)
        at netscape.ldap.LDAPConnection.search(LDAPConnection.java:2554)
        at netscape.ldap.LDAPConnection.search(LDAPConnection.java:2402)

It looks like there is a possibility that the LDAPMessage object will be returned as null in the call to myListener.completeSearchOperation below. This then leads to the null pointer access when it is passed to checkSearchMsg, which assumes it is non-null and tries to get its message ID.

// --- Begin code-snippet of search method in LDAPConnection.java

            /* Synchronous search if all requested at once */
            try {
                /* Block until all results are in */
                LDAPMessage response = myListener.completeSearchOperation();
                Enumeration results = myListener.getAllMessages().elements();

                try {
                    checkSearchMsg(returnValue, response, cons, base, scope,
                                   filter, attrs, attrsOnly);
                } catch ( LDAPException ex ) {
                    /* Was the exception caused by a bad referral? */
                    JDAPProtocolOp op = response.getProtocolOp();
                    if ( (op instanceof JDAPSearchResultReference) ||
                         (op instanceof JDAPSearchResult) ){
                        System.err.println( "LDAPConnection.checkSearchMsg: " +
                                            "ignoring bad referral" );
                    } else {
                        throw ex;
                    }
                }

// ----- End code-snippet of search method in LDAPConnection.java

Although I realize we are not running the latest release, it looks like the exception can happen in the latest version as well.

Reproducible: Couldn't Reproduce

Steps to Reproduce:
Steps to reproduce are not currently known. Our logging was set to a minimal setting at the time it happened, but from what I could see it appeared that the LDAP server had restarted a few seconds prior to this occurring while applications were trying to connect to it.

Comment 1

[Mark Smith [:mcs]]

Thank you for reporting this bug.  Nathan or Rich, have you ever seen a problem like this?  I am not familiar with this code.

Comment 2

[Rich Megginson]

We've probably seen this in the past as sporadic unreproducible failures, but I don't think it has ever been investigated.  Your explanation does sound plausible.  We would really appreciate it if you could figure out how to make this reproducible and attach instructions to this bug.  Also, if you are a Java hacker, patches are welcome :-)

Comment 3

[Glenn Filson]

I think we've figured out what's going on here.  As part of a local project here using the SDK we were able to repro this pretty consistently.  We put together a debug binary to investigate the situation and found out that there appears to be some thread unsafe code in the LDAPConnection class.

It appears that the LDAPMessageQueue class is responsible for being a repository for various inbound and outbound LDAP messages.  In our case, for example, we would see that class adding messages for both a search request and a search response.  The LDAPConnection class then tasked with handling each of these messages in the queue.

For whatever reason it's possible for the threading to be handled in such a way that LDAPConnection object is called on to 'process' the search response *before* it's called on to process the search request.  Unfortunately, in this case, the LDAPConnection calls a reset() on the LDAPMessageQueue object as soon as it's done processing the search response.  Thus, when the LDAPConnection goes to process the search request immediately after, all of the LDAPMessageQueue values have been completely wiped out and we end up with the NullPointerException when running checkSearchMsg() method.

We found that this was reproducible when a new LDAPConnection object was created for every single LDAP operation as that seemed to make it much more likely that the search response thread would get picked up before the search request thread.

Note, of course, that the actual over-the-wire operations are still happening in the correct order, it's simply the post processing on the messages in the LDAPMessageQueue object that is happening out of order and causing the NPE.

Comment 4

[Sylvestre Ledru [:Sylvestre]]

Not activity for at least 6 years, closing.