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

On Wed, 30 May 2007 19:44:16 -0700 Quanah Gibson-Mount quanah@zimbra.com wrote:

--On Wednesday, May 30, 2007 10:00 PM -0400 Michael B Allen mba2000@ioplex.com wrote:

...

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.

Patches should be submitted via the ITS process.

Hi Quanah,

Ok, will do.

But the cldap code still isn't right. The transport layer doesn't retry or timeout. It also hangs if there's no response. I'll look into that but the query I'm doing works over TCP too so I'm thinking about just going with that for now. UDP would be nice for determining if servers are alive.

Mike