On Wed, 30 May 2007 18:42:11 -0400 Michael B Allen <[EMAIL PROTECTED]> wrote:
> Hi, > > What's the status of the client oriented connectionless code? I'm getting > an abort. I'm tracking it down now and I'm willing to put some work into > this so if anyone has some advice I'd appreciate it. > > Mike > > $ gdb cldap > GNU gdb Red Hat Linux (6.3.0.0-1.132.EL4rh) > Copyright 2004 Free Software Foundation, Inc. > GDB is free software, covered by the GNU General Public License, and you are > welcome to change it and/or distribute copies of it under certain conditions. > Type "show copying" to see the conditions. > There is absolutely no warranty for GDB. Type "show warranty" for details. > This GDB was configured as "i386-redhat-linux-gnu"...Using host libthread_db > library "/lib/tls/libthread_db.so.1". > > (gdb) run cldap://dc1.example.com > Starting program: /home/miallen/cldap cldap://dc1.example.com > cldap: io.c:81: ber_write: Assertion `buf != ((void *)0)' failed. > > Program received signal SIGABRT, Aborted. > 0x0025d7a2 in _dl_sysinfo_int80 () from /lib/ld-linux.so.2 > (gdb) bt > #0 0x0025d7a2 in _dl_sysinfo_int80 () from /lib/ld-linux.so.2 > #1 0x0029d7f5 in raise () from /lib/tls/libc.so.6 > #2 0x0029f199 in abort () from /lib/tls/libc.so.6 > #3 0x00296dd1 in __assert_fail () from /lib/tls/libc.so.6 > #4 0x009b0722 in ber_write () from > /home/miallen/openldap/lib/liblber-2.3.so.0 > #5 0x0061926a in ldap_build_search_req () from > /home/miallen/openldap/lib/libldap-2.3.so.0 > #6 0x00618ff3 in ldap_search_ext () from > /home/miallen/openldap/lib/libldap-2.3.so.0 > #7 0x00619087 in ldap_search_ext_s () from > /home/miallen/openldap/lib/libldap-2.3.so.0 > #8 0x0804959b in run (url=0xbff90c04 "cldap://dc1.example.com";) at cldap.c:23 > #9 0x08049767 in main (argc=0, argv=0xbff21914) at cldap.c:83 > (gdb) Well the problem is that the ldap_search_ext function calls ldap_build_search_req which calls ber_write(ber, ld->ld_options.ldo_peer, sizeof(struct sockaddr), 0); but ldo_peer is NULL because it hasn't been connected yet. This is best illustrated with the following call sequence outline: ldap_search_ext ldap_build_search_req (tries to use ldo_peer here but ...) ldap_send_inital_request ldap_send_server_request ldap_new_connection ldap_int_open_connection ldap_connect_to_host calls getaddrinfo ldap_pvt_connect (ldo_peer initialized here) Clearly the ldap_build_search_req function is not in a good position to know the address of the target. That would be the responsibility of the transport layer. So I believe the best solution is to simply skip those 4 bytes and let one of the send functions encode the target address. I'll prepare a patch. Mike
