Well that was a breeze. The attached patch fixes the following assertion when trying to use cldap functionality: io.c:81: ber_write: Assertion `buf != ((void *)0)' failed. Mike On Wed, 30 May 2007 21:14:59 -0400 Michael B Allen <mba2000@ioplex.com> wrote: > On Wed, 30 May 2007 18:42:11 -0400 > Michael B Allen <mba2000@ioplex.com> 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
Attachment:
cldap.patch
Description: Binary data