50074 - LDAP_OPT_ASYNC_CONNECT broken under linux

Status: RESOLVED DUPLICATE of bug 79509

(Directory :: LDAP C SDK, defect, P3)

Description

[Dan Mosedale (:dmosedale, :dmose)]

This bug is against LDAPCSDK_40_BRANCH...

Mark Smith wrote:
> 
> Dan Mosedale wrote:
> >
> > Now for this scheme to really guarantee that the UI thread is not
> > gonna hang if something goes wrong during connect(), I think the code
> > would need to be using LDAP_OPT_ASYNC_CONNECT (mcs, can you confirm
> > this?).  However, in my cursory tests, it didn't appear to be doing
> > the right thing on Linux.  If it turns out that LDAP_OPT_ASYNC_CONNECT
> > is not workable, the just-checked-in architecture could be modified
> > somewhat to use an nsIEventQueue and force all the calls to happen on
> > the connection thread.  But my gut feeling at the moment is that the
> > making LDAP_OPT_ASYNC_CONNECT work is more of the Right Thing.  Anyone
> > have thoughts on this?
> 
> I think we should try to get LDAP_OPT_ASYNC_CONNECT to work.  But the
> person who wrote that code likely only tested it on Windows, and I don't
> know of anybody that uses it.  What did you observe when you tried to
> use it on Linux?

In some previous incarnation of the code, I was experiencing hangs when
using LDAP_OPT_ASYNC_CONNECT on linux.  Currently, though, I'm seeing
core dumps.  Specifically:

#0  0x41cf3e6c in ber_flush (sb=0x8674400, ber=0xa601e801, freeit=0)
    at
/home/dmose/s/browser-main/mozilla/directory/c-sdk/ldap/libraries/liblber/io.c:306
        towrite = 140985344
        rc = -1092616568
#1  0x41cdfc80 in nsldapi_ber_flush (ld=0x865e460, sb=0x8674400, 
    ber=0xa601e801, freeit=0, async=1)
    at
/home/dmose/s/browser-main/mozilla/directory/c-sdk/ldap/libraries/libldap/request.c:346
        ld = (LDAP *) 0x865e460
        sb = (Sockbuf *) 0x8674400
        terrno = -1092616568
#2  0x41ce2319 in wait4msg (ld=0x865e460, msgid=-1, all=0,
unlock_permitted=1, 
    timeout=0x0, result=0xbedffd00)
    at
/home/dmose/s/browser-main/mozilla/directory/c-sdk/ldap/libraries/libldap/result.c:411
        ld = (LDAP *) 0x865e460
        rc = -2
        tv = {tv_sec = 1, tv_usec = -1092617860}
        tvp = (struct timeval *) 0x0
        start_time = 0
        tmp_time = 0
        lc = (LDAPConn *) 0x86bdff8        nextlc = (LDAPConn *) 0x0
        lr = (LDAPRequest *) 0x4021f81d
#3  0x41ce15c8 in nsldapi_result_nolock (ld=0x865e460, msgid=-1, all=0, 
    unlock_permitted=1, timeout=0x0, result=0xbedffd00)
    at
/home/dmose/s/browser-main/mozilla/directory/c-sdk/ldap/libraries/libldap/result.c:135
        ld = (LDAP *) 0x865e460
        rc = -1092617572
#4  0x41ce14d9 in ldap_result (ld=0x865e460, msgid=-1, all=0,
timeout=0x0, 
    result=0xbedffd00)
    at
/home/dmose/s/browser-main/mozilla/directory/c-sdk/ldap/libraries/libldap/result.c:94
        ld = (LDAP *) 0x865e460
        rc = -1092616568
        ret = -1092616568
#5  0x41cbf385 in nsLDAPConnection::Run (this=0x87af9d0)
    at
/home/dmose/s/browser-main/mozilla/directory/xpcom/base/src/nsLDAPConnection.cpp:304
        rv = 0
        returnCode = 0
        msgHandle = (LDAPMessage *) 0x0
        msg = {mRawPtr = 0x0}
        errString = 0x0

Crawling back up the stack a bit, it turns out that at the
nsldapi_ber_flush() call on line 411, lr is uninitialized.  This is
happening because wait4msg() is called with LDAP_RES_ANY, and the only
code that could initialize it is in an if clause starting at line 314,
which is guarded in part by "msgid != LDAP_RES_ANY".  

Interestingly, the code seems to work on Windows and Mac.  It's unclear
to me how this could be, though.  Perhaps the Windows and Mac compilers
are initializing automatics (i.e. lr) to NULL, so the call to
nsldapi_ber_flush() never happens?  That seems unlikely, though, since
when I manually changed the code to always initialize lr to NULL at the
beginning of wait4msg(), linux just spins and the connect never
completes (which is what I would expect from reading the code).

Comment 1

[Mark Smith [:mcs]]

Dan, is this still a problem?

Comment 2

[Dan Mosedale (:dmosedale, :dmose)]

The next version of the 79509 patch will address this.

*** This bug has been marked as a duplicate of 79509 ***