On Tue, 20 Sep 2011, kyle king wrote:

On 09/20/2011 06:21 PM, kyle king wrote:

...

Under heavy threaded use ldap_get_value returns a corrupted memory pointer, not a char pointer pointer that was specified.

I have narrowed the corruption problem down to the file libraries/libldap/get_values.c apoximatly line 80 the ber_scanf in the if statement.

When it work on my machine, it returns pointers for 'vals' such as:

vals pointer: 0x105c920

and when it fails: vals pointer 0x7f6130004c20

Is this a follow up to a previous posting that actually described what you were going? If so, I don't see it in the list archives. So:

What version of OpenLDAP?

Is the client linked against libldap_r or libldap?

What's the model for how threads are using LDAP handles? E.g., - each LDAP handle used by only one thread at a time, from operation to result - each LDAP handle used concurrently by many threads, with app-level locks - each LDAP handle used concurrently by many threads, without app-level locks

Is TLS/SSL involved? If so, are the thread-safety requirements of that library being independently set up by the application? (IIRC, using libldap_r handled that for at least OpenSSL, but I haven't stayed up on whether that's still the case or whether it applies to GNUtls or NSS.)

Philip Guenther

After talking to him in more depth off list it turns out the char** returned by ldap_get_values was being int cast by gcc and thus the higher word was corrupted. This caused it only to work for memory malloced below a specific threshold on his machine. Plus he was using the deprecated ldap_get_values instead of ldap_get_values_len.

Now that he's using ldap_get_values_len everything works as intended.

-William

On 09/23/2011 05:23 PM, Philip Guenther wrote:

On Tue, 20 Sep 2011, kyle king wrote:

...

On 09/20/2011 06:21 PM, kyle king wrote:

...

Under heavy threaded use ldap_get_value returns a corrupted memory pointer, not a char pointer pointer that was specified.

I have narrowed the corruption problem down to the file libraries/libldap/get_values.c apoximatly line 80 the ber_scanf in the if statement.

When it work on my machine, it returns pointers for 'vals' such as:

vals pointer: 0x105c920

and when it fails: vals pointer 0x7f6130004c20

Is this a follow up to a previous posting that actually described what you were going? If so, I don't see it in the list archives. So:

What version of OpenLDAP?

Is the client linked against libldap_r or libldap?

What's the model for how threads are using LDAP handles? E.g.,

• each LDAP handle used by only one thread at a time, from operation to result
• each LDAP handle used concurrently by many threads, with app-level locks
• each LDAP handle used concurrently by many threads, without app-level locks

Is TLS/SSL involved? If so, are the thread-safety requirements of that library being independently set up by the application? (IIRC, using libldap_r handled that for at least OpenSSL, but I haven't stayed up on whether that's still the case or whether it applies to GNUtls or NSS.)

Philip Guenther