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 >
