On Wed, 30 May 2007 18:42:11 -0400
Michael B Allen <mba2000(a)ioplex.com> wrote:
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.
$ gdb cldap
GNU gdb Red Hat Linux (220.127.116.11-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
(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
#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
#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
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_build_search_req (tries to use ldo_peer here but ...)
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
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.