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
Kyle A. King Quentus Technologies, INC Cell Phone: 703-635-9512 Work Phone: 253-218-6030 Email: kyle.king@quentustech.com
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
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.
Your original email hasn't shown up, so some context for your question is missing. Also, it doesn't appear that your question belongs on this list; it should be on openldap-technical.
But it sounds like you're accessing an LDAP handle without making sure it is thread safe. You can continue this discussion on the -technical list.
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
-
Howard Chu -
kyle king -
Philip Guenther -
William King