120406 - can't use more than 127 threads with SSL or NSPR

Status: RESOLVED FIXED

(Directory Graveyard :: LDAP C SDK, defect, P1)

Description

[Mark Smith [:mcs]]

If an application tries to use more than 128 LDAP session handles with SSL or
when using the PRLDAP layer (always used with SSL), the application will crash
inside libprldap.

The root of the problem is that we are using the NSPR thread-private data
interface incorrectly. Instead of allocating one NSPR thread-private data index
for each LDAP session handle we need to allocate one NSPR thread-private data
index for all of libldap (or at least all of libprldap).

Comment 1

[Mark Smith [:mcs]]

Attachment: Proposed fix

Comment 2

[Mark Smith [:mcs]]

Attachment: Revised ldappr-threads.c source file.

Comment 3

[Mark Smith [:mcs]]

I have a fix in hand. The new code is all at the end of ldappr-threads.c. I
still need to run it through Purify and check for problems.

One outstanding issue is that the PRLDAP_TPDMap structures are never freed (that
was true with the old code too). We allocate one PRLDAP_TPDMap struct per active
LDAP *, and these are reused as new LDAP *'s are allocated but none of them are
ever freed.

Comment 4

[Michael Hein]

Looks good to me.....and a bit tricky.  As soon as you feel that there are no 
major leaks I would say to just put it back........then we'll give a whirl with 
the test program.

Michael

Comment 5

[Mark Smith [:mcs]]

Fix committed after testing under Purify.

/mozilla/directory/c-sdk/ldap/libraries/libprldap/ldappr-threads.c
  new revision: 1.1.2.1.2.3; previous revision: 1.1.2.1.2.2
Fix bug # 120406 - can't use more than 127 threads with SSL or NSPR.
    Previously, we allocated one NSPR thread-private data index for
    each active LDAP *. Now we only allocate one for the entire prldap
    library (this library now has its own thread-private data layer).