Re: bug: Partial results from DB lookup causing parsing problems

I initially hit 'reply' rather than 'reply to all', so I'll re-send this
to the list.

> I don't have an LDAP db handy to test against, so could
> you please test the following change for me to see if
> it helps your problem. If not, I'll dig deeper into the problem.

Many thanks for getting back to me so quickly.  I've patched a clean
version of 1.17.1, and tested. 

> +     if (returns[0])
> +             user_str = &returns[0];
> +     if (returns[1])
> +             server_str = &returns[1];
> +     if (returns[2])
> +             port_str = &returns[2];

The lookup was failing, and I've traced it to the lines above.  These
pointers are directed to &returns, but a few lines later, all the values
of returns are passed to free():

        for (count = 0; count < attrcount; count++)
                if (returns[count] != NULL)
                        free(returns[count]);
        free(returns);

I've replaced the lines quoted above with ones like:

if (returns[1])
        *server_str = strdup(returns[1]);

This works fine, but my C is rusty enough that I don't know if this will
create memory problems over time. 

With strdup() in place, outgoing_server is used if the LDAP directory is
missing either username or server, but port is filled in appropriately
if it is missing. Since a missing username means no entry in LDAP for
that user, and the lookup falls through correctly for a missing server
entry, this is now working as I'd hoped for.


Incidentally, I've ventured into nasty kludge territory to work around a
bug that appears not to be in your code, but either in libldap or
libldap's interaction with Active Directory.  ldap_init, ldap_set_option
and ldap_bind_s are all successful, but ldap_search_s does not return
LDAP_SUCCESS.  Instead, it returns LDAP_SERVER_DOWN, _even if_ the
search was successful. It seems insane, but if I comment out the check
for (err != LDAP_SUCCESS) and just check for returned attributes, all
the data is there.  I can replicate this in my own test program using
libldap both from debian-etch (2.1.30) and the openldap-2.4.11 source
package, so I'm confident the problem isn't in your code, but it's
probably worth knowing about.

Thanks again for your help,

Simon.






-- 
 The Wellcome Trust Sanger Institute is operated by Genome Research 
 Limited, a charity registered in England with number 1021457 and a 
 company registered in England with number 2742969, whose registered 
 office is 215 Euston Road, London, NW1 2BE. 
______________________________________________
Perdition-users mailing list
[email protected]
http://lists.vergenet.net/listinfo/perdition-users