[Date Prev][Date Next]
Re: Status of Connectionless LDAP (cldap)
On Wed, 30 May 2007 18:42:11 -0400
Michael B Allen <email@example.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 (18.104.22.168-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
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.