https://bugs.openldap.org/show_bug.cgi?id=9305
Issue ID: 9305 Summary: ldap_connect_to_host: Return code from getaddrinfo() discarded, troubleshooting difficult Product: OpenLDAP Version: 2.4.46 Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: --- Component: client tools Assignee: bugs@openldap.org Reporter: minfrin@sharp.fm Target Milestone: ---
When the ldap_connect_to_host() function sees a failure from getaddrinfo(), the meaningless return code -1 is returned.
This makes troubleshooting difficult on a webserver, where the low level printf debugging is not practical.
(gdb) step ldap_connect_to_host (ld=ld@entry=0x7fffc4002e10, sb=0x7fffc400b240, proto=1, srv=srv@entry=0x7fffc400b2f0, async=async@entry=0) at os-ip.c:543 543 { (gdb) next 546 ber_socket_t s = AC_SOCKET_INVALID; (gdb) 562 if ( srv->lud_host == NULL || *srv->lud_host == 0 ) { (gdb) 568 port = srv->lud_port; (gdb) 570 if( !port ) { (gdb) 578 switch(proto) { (gdb) 580 osip_debug( ld, (gdb) warning: Source file is more recent than executable. 71 return __builtin___memset_chk (__dest, __ch, __len, __bos0 (__dest)); (gdb) 598 hints.ai_flags = AI_ADDRCONFIG; (gdb) 601 hints.ai_socktype = socktype; (gdb) 602 snprintf(serv, sizeof serv, "%d", port ); (gdb) 605 LDAP_MUTEX_LOCK(&ldap_int_resolv_mutex); (gdb) 607 err = getaddrinfo( host, serv, &hints, &res ); (gdb) 609 LDAP_MUTEX_UNLOCK(&ldap_int_resolv_mutex); (gdb) 611 if ( err != 0 ) { (gdb) 612 osip_debug(ld, "ldap_connect_to_host: getaddrinfo failed: %s\n", (gdb) print host $3 = <optimized out> (gdb) print serv $4 = "636\000\000\000" (gdb) next 614 return -1; (gdb)
The ldap_connect_to_host() function needs to return proper error codes.
https://bugs.openldap.org/show_bug.cgi?id=9305
--- Comment #1 from Howard Chu hyc@openldap.org --- (In reply to minfrin@sharp.fm from comment #0)
The ldap_connect_to_host() function needs to return proper error codes.
There are no suitable error codes defined in the LDAP API to give more specific feedback. Just returning the getaddrinfo error code directly would be non-portable and ambiguous. (What happens if libldap was built using gethostbyaddr instead? That has a completely different set of error codes. How is the caller supposed to know what they mean?)
https://bugs.openldap.org/show_bug.cgi?id=9305
Quanah Gibson-Mount quanah@openldap.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Target Milestone|--- |2.6.0
--- Comment #2 from Quanah Gibson-Mount quanah@openldap.org --- Generally:
Need to find all places returning -1 in libldap and replace them with symbolic error codes defined in ldap.h with our own new LDAP_X_ codes, and set message text in ld->ld_error.
Tentatively scheduling for 2.6
https://bugs.openldap.org/show_bug.cgi?id=9305
Quanah Gibson-Mount quanah@openldap.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Target Milestone|2.6.0 |2.7.0
https://bugs.openldap.org/show_bug.cgi?id=9305
Quanah Gibson-Mount quanah@openldap.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Severity|normal |enhancement
https://bugs.openldap.org/show_bug.cgi?id=9305
--- Comment #3 from Ondřej Kuzník ondra@mistotebe.net --- Not sure a completely new set of error codes is needed, might just be a case of passing the right strings to ld_error and leaving it at that.