Emmanuel Dreyfus wrote:

Hello

I have thread-safety problems with libldap_r. My program uses libcurl to access a LDAP URL. When I attempt to fetch LDAP URL from multiple threads at once, I crash.

I suspect there could be thread-safety issues with libldap_r. for instance, a nm shows it references gethostbyname, and not gethostname_r. Does it has any chance to be thread-safe if it uses gethostbyname?

The configure script checks for reentrant interfaces like gethostbyname_r. If it didn't find them, then libldap_r will use mutexes to protect the non-reentrant functions. Note that gethostname is not the same as gethostbyname.

If your version of libldap_r is not using the re-entrant APIs then something went wrong during configure to prevent it from finding those APIs. You should check your config.log...

That aside, libldap_r is (intentionally) undocumented; you use it at your own risk. We've made it reliable enough for slapd's purposes. If you're using it in any way differently from how slapd uses it, you're on your own.

Emmanuel Dreyfus wrote:

Howard Chu hyc@symas.com wrote:

...

If your version of libldap_r is not using the re-entrant APIs then something went wrong during configure to prevent it from finding those APIs. You should check your config.log...

Is there a simple way to instruct configure that it will find the re-entrant versions in libbind?

You might try reading the INSTALL file that is included with the source distribution. Section 2. Set the LIBS variable.

...

That aside, libldap_r is (intentionally) undocumented; you use it at your own risk. We've made it reliable enough for slapd's purposes. If you're using it in any way differently from how slapd uses it, you're on your own.

I use it through libcurl.

Which essentially means you have no idea how it is getting used.

As I said in my previous message - when we're forced to use a non-reentrant function, we protect it with a mutex. But that mutex only protects calls from our code. If there are other threads in other software calling the same libc functions, they will not be guarded by our mutexes, and so their behavior is indeterminate. This is one reason why we cannot guarantee support for libldap_r in arbitrary code.

Emmanuel Dreyfus wrote:

Howard Chu hyc@symas.com wrote:

...

As I said in my previous message - when we're forced to use a non-reentrant function, we protect it with a mutex. But that mutex only protects calls from our code. If there are other threads in other software calling the same libc functions, they will not be guarded by our mutexes, and so their behavior is indeterminate. This is one reason why we cannot guarantee support for libldap_r in arbitrary code.

Well, it seems to me that you could garantee that, if libldap_r only used thread-safe functions. A configure flag to request libldap_r build to use only thread-safe function or fail would be very helpful.

Feel free to submit a patch.

Note that such a flag doesn't enhance libldap_r's usefulness to slapd in any way, so there's very little motivation for anyone else to create this patch for you. If you want it, write it.

Emmanuel Dreyfus writes:

Well, it seems to me that you could garantee that, if libldap_r only used thread-safe functions. A configure flag to request libldap_r build to use only thread-safe function or fail would be very helpful.

If you implement such a flag, I suggest you let the user choose between two possible actions if it doesn't find a thread-safe function it wants: Either let configure fail, or disable the feature(s) which need that function (and report this during configure).