kurt(a)OpenLDAP.org wrote:
> Full_Name: Kurt Zeilenga
> Version: 2.3.38
> OS: Linux
> URL:
ftp://ftp.openldap.org/incoming/
> Submission from: (NULL) (75.141.229.206)
>
>
> Here's a stack trace; the command was:
> % ldapsearch -x -E pr=2/noprompt -b "o=test2,o=test" -s one
"cn=*" cn
> .
> .
> (gdb) where
> #0 0x005303d4 in _int_free () from /lib/tls/libc.so.6
> #1 0x0053172b in free () from /lib/tls/libc.so.6
> #2 0x004201e3 in ber_memfree_x (p=0x805405d, ctx=0x0) at memory.c:149
> #3 0x001d85e8 in ldap_control_free (c=0xbfe3ecd0) at controls.c:260
> #4 0x001d8669 in ldap_controls_free (controls=0x9c801c8) at controls.c:285
> #5 0x0804f703 in tool_server_controls (ld=0x9c76550, extra_c=0xbfe3ece0,
> count=-1) at common.c:1250
> #6 0x0804b910 in main (argc=14, argv=0xbfe40e44) at ldapsearch.c:794
>
> It's done the bind ok by this stage but never gets as far as sending the search
> request.
I think this could be a consequence of fixing ITS#5100: probably,
ldapsearch's call of ldap_control_free() was incorrectly relying on its
broken behavior.
That doesn't make any sense, the fix for ITS#5100 is not in 2.3.38.
--
-- Howard Chu
Chief Architect, Symas Corp.