On Mon, 26 Apr 2010, Pratima Shet wrote: > Ya, application is multi threaded, but only one thread will handle all > 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 > exactly. Yeah, debugging intermittent issues and race-conditions can be (very) frustrating. > 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 apart > from NULL check ? In general, no. Philip Guenther
