I think I have found a bug in the threading support of the LDAP C-SDK. In the ldap_memcache_result function (in memcache.c) the function is started with the lines: LDAP_MUTEX_LOCK(ld, LDAP_MEMCACHE_LOCK); LDAP_MEMCACHE_MUTEX_LOCK(ld->ld_memcache); Meaning that the memory cache is locked against multi-threaded entry. However, the function is ended by the lines: LDAP_MEMCACHE_MUTEX_UNLOCK(ld->ld_memcache); LDAP_MUTEX_LOCK(ld, LDAP_MEMCACHE_LOCK); return nRes; In these lines I think that the LDAP_MUTEX_LOCK should be replaced with LDAP_MUTEX_UNLOCK. (this is consistent with the tests that I have done).

Your analysis looks correct to me. The code in question will cause a deadlock if your mutexes are not reentrant. A fix has already been applied to a branch we made for a Netscape internal release of the C LDAP SDK, which we will merge into Mozilla soon.

Reassigning all open Directory / LDAP C SDK bugs to Michael.

Is something keeping the fixed LDAP C SDK in the netscape internal release from being merged into Mozilla?

I don't understand how there is no QA, tever would you QA or find a more appropriate QA? mhein/dmose according to http://lxr.mozilla.org/mozilla/source/directory/c- sdk/ldap/libraries/libldap/request.c The mutexes are added and removed pairwise. So I would think this is fixed.

Michael, do you know anything about this. Who is the qa contact on LDAP C SDK?

Is there anything going on with this bug? http://lxr.mozilla.org/mozilla/source/directory/c-sdk/ldap/libraries/libldap/memcache.c#692 Indicates that the mutex gets locked, a few lines below that (line 715) there is the same LDAP_MUTEX_LOCK() as the reporter said. Comment #1 seems to suggest that it was fixed internally. If all that is needed to be done is to change the mutex lock to an unlock I can create the patch and attach it. Is it unlocked from somewhere else?

I just checked the ldapcsdk_branch_50 on cvs.mozilla.org, and it has been fixed on that branch, so I'm closing this bug out.