Nick Geron wrote:
Howard Chu wrote:
Your stack trace is a bit odd, because I can't find anywhere in the source tree that uses the function "slap_freeself_cb()". Are you using any custom overlays? It appears that your stack trace is still missing a lot of details. You should compile with -g and without any optimization, and make sure you're testing with the unstripped binary.
The only overlays I'm using are those found in the openldap tarball. I found that function referenced in result.c
It is defined in result.c, but it is not referenced anywhere.
It does look like I had stripped binaries though. I've removed optimization and verified that the -g option is being given. It took a bit to track down where stripping was being set, but 'file' now tells me the binaries are not stripped.
Here's the latest backtrace:
regex_matches: string: uid=syncrepl,ou=ldap,dc=corenap,dc=com
=> regex_matches: rc: 1 no matches ldap_read: want=8, got=7 0000: 30 05 02 01 03 42 00 0....B. ber_get_next: tag 0x30 len 5 contents: ber_get_next ldap_read: want=8, got=0
ber_get_next on fd 21 failed errno=0 (Success) connection_closing: readying conn=1 sd=21 for close connection_close: deferring conn=1 sd=21 conn=1 op=2 do_unbind connection_resched: attempting closing conn=1 sd=21 connection_close: conn=1 sd=21 slapd: connection.c:676: connection_state_closing: Assertion `c->c_struct_state == 0x02' failed.
Program received signal SIGABRT, Aborted. [Switching to Thread 1107310912 (LWP 17114)] 0x00000030ae430055 in raise () from /lib64/libc.so.6 (gdb) bt #0 0x00000030ae430055 in raise () from /lib64/libc.so.6 #1 0x00000030ae431af0 in abort () from /lib64/libc.so.6 #2 0x00000030ae429756 in __assert_fail () from /lib64/libc.so.6 #3 0x000000000043854a in connection_state_closing (c=0xa35ef60) at connection.c:676 #4 0x000000000044dc38 in send_ldap_ber (conn=0xa35ef60, ber=0x42002410) at result.c:153 #5 0x000000000045173d in slap_send_search_entry (op=0x420029a0, rs=0x420026c0) at result.c:1187 #6 0x000000000051072f in syncprov_sendresp (op=0x420029a0, opc=0x42002780, so=0xa882b80, e=0x420027d8, mode=2) at syncprov.c:809 #7 0x0000000000510a8d in syncprov_qplay (op=0x420029a0, on=0xa094690, so=0xa882b80) at syncprov.c:878 #8 0x0000000000510c54 in syncprov_qtask (ctx=0x42002dc0, arg=0x2aaac4111500) at syncprov.c:923 #9 0x00002aaaaaabc605 in ldap_int_thread_pool_wrapper (xpool=0xa0466d0) at tpool.c:625 #10 0x00000030aec062f7 in start_thread () from /lib64/libpthread.so.0 #11 0x00000030ae4ce85d in clone () from /lib64/libc.so.6 (gdb)
This trace looks the same as ITS#5401. Apparently syncprov is trying to send a persistent search response after the psearch consumer has closed the connection. Obviously this should never happen; when a connection is closed all the outstanding operations on it are abandoned.
You should probably send further replies to ITS#5401. Can you please provide, in addition to the above trace, the output from frame 3 print *c