On Mon, 26 Apr 2010, Pratima Shet wrote:
Ya, application is multi threaded, but only one thread will handle
ldap related operations.
The crypto library that you're using may place its own requirements. In
particular, many versions of openssl are only thread-safe if various
callbacks are set before performing operations concurrently in multiple
threads. You may have only one thread doing ldap related operations
(including ldap_start_tls_s()), but perhaps other threads could be doing
crypto or TLS/SSL operations for other tasks or protocols?
I am linking to "libldap" not "libldap_r".
My recall is that libldap_r will set up those openssl thread-safety
callbacks for you while libldap won't.
(That's actually a reason in some cases to *not* use libldap_r, as an
application may have reasons for initializing those before initializing
libldap* or independently of doing so.)
Crash happened only once. Am unabled to reproduce it. So, I dont have
much information regarding the line in the library where it crashed
Yeah, debugging intermittent issues and race-conditions can be (very)
Handle was not NULL, but it was corrupted.
Or the SSL handle inside the LDAP handle was corrupt, or some other static
state was corrupt, or...
Is there any way, to check whether ldap handle is proper or valid
from NULL check ?
In general, no.