Re: null_callbacks after initial sync

[Howard Chu <hyc@symas.com>]

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

--
  -- Howard Chu
  Chief Architect, Symas Corp.  http://www.symas.com
  Director, Highland Sun        http://highlandsun.com/hyc/
  Chief Architect, OpenLDAP     http://www.openldap.org/project/