Re: ldap_simple_bind blocks in SSL Mode when the DS is in hang state

Rich Megginson <[email protected]> Tue, 01 Sep 2009 08:56:54 -0600
Newsgroups gmane.comp.mozilla.devel.directory
Message-ID <[email protected]>
denish patel wrote:
> Thanks for your reply Mark,
> 
>   I am not sure about whether the prldap library uses
> NSPR to provide thread safety or not.

prldap uses NSPR to provide thread/mutex/condition variable 
functionality.  prldap uses LDAP_OPT_THREAD_FN_PTRS to replace the 
default system thread functions with NSPR.  I'm not sure what you mean 
by "provide thread safety".

> 
> However, the LDAP C-SDK is not thread safe & for that
> purpose we are using the thread callback functions.

Only in a few cases is LDAP C SDK not thread safe.  What cases are you 
talking about?

> 
> Thanks,
> Denish
> 
> On Tue, Sep 1, 2009 at 7:12 PM, Mark Smith <[email protected]> wrote:
> 
>> denish patel wrote:
>>
>>> Hi once again,
>>>
>>> Some more of my observations:
>>>
>>>  When LDAP_OPT_THREAD_FN_PTRS parameter is set the program goes into a
>>> loop.
>>> Debugging more it was found that the get_errno function is invoked by
>>> nsldapi_send_ber_message (Line No. 402 - request.c).
>>>
>>>  402.  int terrno = LDAP_GET_ERRNO( ld );
>>>  403.  if ( NSLDAPI_ERRNO_IO_INPROGRESS( terrno )) {
>>>  404.      if ( async ) {
>>>  405.         rc = -2;
>>>  406.         break;
>>>  407.      }
>>>  408.    } else {
>>>  409.        nsldapi_connection_lost_nolock( ld, sb );
>>>  410.        rc = -1;   /* fatal error */
>>>  411.        break;
>>>  412.   }
>>>
>>> It is from #402 that the get_errno function is invoked. This function
>>> returns 11 as mentioned in an earlier mail.
>>>
>>> The difference between the hanging & the non-hanging program lies here.
>>> When we do not set LDAP_OPT_THREAD_FN_PTRS, the value I see for terrno is
>>> 0,
>>> whereas it's value is 11 when the parameter has been set.
>>> ...
>>>
>> I am not 100% sure what is causing the problem you are experiencing (it
>> seems like your errno callback function is not returning the operating
>> system's errno value).
>>
>> I do not think this is well documented, but it is not a good idea to mix
>> together use of your own thread callback functions and the prldap library
>> (which is always used when you call the Mozilla LDAP C SDK SSL functions).
>>  Do you really need to install your own thread callback functions?  The
>> prldap library uses NSPR to provide thread safety, and NSPR does a very nice
>> job of hiding OS differences, etc.
>>
>> --
>> Mark Smith
>> Pearl Crescent
>> http://pearlcrescent.com/
>>