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