[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: ldap_get_value returns corrupt pointer

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
>