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

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