openldap-bugs

openldap-bugs@openldap.org

1 participants
20967 discussions

Re: (ITS#5489) Assert failed in slapd_clr_write()
by hyc＠symas.com 30 Apr '08

30 Apr '08

rein(a)OpenLDAP.org wrote: > Full_Name: Rein Tollevik > Version: CVS head > OS: > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (81.93.160.250) > Submitted by: rein > > > We have seen a case where "assert(SLAP_SOCK_IS_ACTIVE(s))" in > slapd_clr_write() failed, see the stack trace at the end. The > last log message (at loglevel stat) related to the socket was > "fd=657 closed (connection lost on write)". The comment where > slapd_daemon_task() calls connection_write() makes me believe > that slapd_clr_write() should not have use assert here. Remove > it or include it as a condition in the following if statement? How frequently can you reproduce this? I'm tempted to say move the assert into the if (SLAP_SOCK_IS_WRITE()) block, and see if it still triggers. > > Rein Tollevik > Basefarm AS > > > Program terminated with signal 6, Aborted. > (gdb) where > #0 0xb7fe97a2 in _dl_sysinfo_int80 () from /lib/ld-linux.so.2 > #1 0xb7b777a5 in raise () from /lib/tls/libc.so.6 > #2 0xb7b79209 in abort () from /lib/tls/libc.so.6 > #3 0xb7b70d91 in __assert_fail () from /lib/tls/libc.so.6 > #4 0x0806da8f in slapd_clr_write (s=657, wake=0) at daemon.c:931 > #5 0x080726d7 in connection_write (s=657) at connection.c:1814 > #6 0x080717bc in slapd_daemon_task (ptr=0x0) at daemon.c:2414 > #7 0xb7c80371 in start_thread () from /lib/tls/libpthread.so.0 > #8 0xb7c17ffe in clone () from /lib/tls/libc.so.6 > > > -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

(ITS#5490) accesslog_response segfault
by quanah＠zimbra.com 30 Apr '08

30 Apr '08

Full_Name: Quanah Gibson-Mount Version: 2.3.41 OS: Linux 2.6 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (24.23.156.219) Repeated coredumps from slapd, in the accesslog_response function. Core #1: Core was generated by `/opt/zimbra/openldap/libexec/slapd -l LOCAL0 -4 -u zimbra -h ldap://zimbra-adm.'. Program terminated with signal 11, Segmentation fault. (gdb) thr apply all bt Thread 10 (process 7511): #0 0x000000376980714b in ?? () #1 0x0000003769807010 in ?? () #2 0x0000000040800d28 in ?? () #3 0x0000000000000000 in ?? () Thread 9 (process 12519): #0 0x0000003768fc790c in ?? () #1 0x000000000042894b in slapd_daemon_task (ptr=0x0) at daemon.c:2174 #2 0x0000003769806137 in ?? () #3 0x0000000000000000 in ?? () Thread 8 (process 12520): #0 0x000000376980af8b in ?? () #1 0x0000000040fff920 in ?? () #2 0x0000000040fff6e0 in ?? () #3 0x0000003769807d54 in ?? () #4 0x0000002a97597257 in bdb_cache_entry_db_unlock (env=0xdd7818, lock=0xe611c0) at cache.c:151 #5 0x0000002a97aada34 in accesslog_op_mod (op=0xd97c900, rs=0x41000ce0) at accesslog.c:1267 #6 0x000000000049b8dd in overlay_op_walk (op=0xd97c900, rs=0x41000ce0, which=op_modify, oi=0xdde8c0, on=0xdde540) at backover.c:640 #7 0x000000000049bb39 in over_op_func (op=0xd97c900, rs=0x41000ce0, which=op_modify) at backover.c:702 #8 0x000000000049bc17 in over_op_modify (op=0xd97c900, rs=0x41000ce0) at backover.c:736 #9 0x0000000000448303 in fe_op_modify (op=0xd97c900, rs=0x41000ce0) at modify.c:395 #10 0x00000000004475ec in do_modify (op=0xd97c900, rs=0x41000ce0) at modify.c:200 #11 0x000000000042bd9c in connection_operation (ctx=0x41000e10, arg_v=0xd97c900) at connection.c:1133 #12 0x000000000042c28c in connection_read_thread (ctx=0x41000e10, argv=0x38) at connection.c:1261 #13 0x0000002a956c3bd7 in ldap_int_thread_pool_wrapper (xpool=0x8a8f00) at tpool.c:478 #14 0x0000003769806137 in ?? () #15 0x0000000000000000 in ?? () Thread 7 (process 12521): #0 0x000000376980af8b in ?? () #1 0x0000000041800920 in ?? () #2 0x00000000418006e0 in ?? () #3 0x0000003769807d54 in ?? () #4 0x0000002a97597257 in bdb_cache_entry_db_unlock (env=0xdd7818, lock=0xe61888) at cache.c:151 #5 0x0000002a97aada34 in accesslog_op_mod (op=0xd97c600, rs=0x41801ce0) at accesslog.c:1267 #6 0x000000000049b8dd in overlay_op_walk (op=0xd97c600, rs=0x41801ce0, which=op_modify, oi=0xdde8c0, on=0xdde540) at backover.c:640 #7 0x000000000049bb39 in over_op_func (op=0xd97c600, rs=0x41801ce0, which=op_modify) at backover.c:702 #8 0x000000000049bc17 in over_op_modify (op=0xd97c600, rs=0x41801ce0) at backover.c:736 #9 0x0000000000448303 in fe_op_modify (op=0xd97c600, rs=0x41801ce0) at modify.c:395 #10 0x00000000004475ec in do_modify (op=0xd97c600, rs=0x41801ce0) at modify.c:200 #11 0x000000000042bd9c in connection_operation (ctx=0x41801e10, arg_v=0xd97c600) at connection.c:1133 #12 0x000000000042c28c in connection_read_thread (ctx=0x41801e10, argv=0x30) at connection.c:1261 #13 0x0000002a956c3bd7 in ldap_int_thread_pool_wrapper (xpool=0x8a8f00) at tpool.c:478 #14 0x0000003769806137 in ?? () #15 0x0000000000000000 in ?? () Thread 6 (process 12524): #0 0x000000376980af8b in ?? () #1 0x0000000042802920 in ?? () #2 0x00000000428026e0 in ?? () #3 0x0000003769807d54 in ?? () #4 0x0000002a97597257 in bdb_cache_entry_db_unlock (env=0xdd7818, lock=0xe64a48) at cache.c:151 #5 0x0000002a97aada34 in accesslog_op_mod (op=0x7768c00, rs=0x42803ce0) at accesslog.c:1267 #6 0x000000000049b8dd in overlay_op_walk (op=0x7768c00, rs=0x42803ce0, which=op_modify, oi=0xdde8c0, on=0xdde540) at backover.c:640 #7 0x000000000049bb39 in over_op_func (op=0x7768c00, rs=0x42803ce0, which=op_modify) at backover.c:702 #8 0x000000000049bc17 in over_op_modify (op=0x7768c00, rs=0x42803ce0) at backover.c:736 #9 0x0000000000448303 in fe_op_modify (op=0x7768c00, rs=0x42803ce0) at modify.c:395 #10 0x00000000004475ec in do_modify (op=0x7768c00, rs=0x42803ce0) at modify.c:200 #11 0x000000000042bd9c in connection_operation (ctx=0x42803e10, arg_v=0x7768c00) at connection.c:1133 #12 0x000000000042c28c in connection_read_thread (ctx=0x42803e10, argv=0x3f) at connection.c:1261 #13 0x0000002a956c3bd7 in ldap_int_thread_pool_wrapper (xpool=0x8a8f00) at tpool.c:478 #14 0x0000003769806137 in ?? () #15 0x0000000000000000 in ?? () Thread 5 (process 12525): #0 0x000000000045569b in slap_acl_mask (a=0x8b4000, mask=0x430040d8, op=0x43004ab0, e=0xd768eb0, desc=0x883700, val=0x0, nmatch=100, matches=0x43003da0, count=1, state=0x0) at acl.c:1496 #1 0x00000000004538ca in access_allowed_mask (op=0x43004ab0, e=0xd768eb0, desc=0x883700, val=0x0, access=ACL_READ, state=0x0, maskp=0x0) at acl.c:698 #2 0x000000000043fa48 in slap_send_search_entry (op=0x43004ab0, rs=0x43004780) at result.c:737 #3 0x0000002a979a0647 in syncprov_sendresp (op=0x43004ab0, opc=0x43004850, so=0x791ff30, e=0x430048b8, mode=1) at syncprov.c:784 #4 0x0000002a979a09a2 in syncprov_qplay (op=0x43004ab0, on=0xddec40, so=0x791ff30) at syncprov.c:853 #5 0x0000002a979a0be6 in syncprov_qtask (ctx=0x43004e10, arg=0x2178f00) at syncprov.c:898 #6 0x0000002a956c3bd7 in ldap_int_thread_pool_wrapper (xpool=0x8a8f00) at tpool.c:478 #7 0x0000003769806137 in ?? () #8 0x0000000000000000 in ?? () Thread 4 (process 14050): #0 0x000000376980af8b in ?? () #1 0x0000000043804920 in ?? () #2 0x00000000438046e0 in ?? () #3 0x0000003769807d54 in ?? () #4 0x0000002a97597257 in bdb_cache_entry_db_unlock (env=0xdd7818, lock=0x22e2d90) at cache.c:151 #5 0x0000002a97aada34 in accesslog_op_mod (op=0x23d0900, rs=0x43805ce0) at accesslog.c:1267 #6 0x000000000049b8dd in overlay_op_walk (op=0x23d0900, rs=0x43805ce0, which=op_modify, oi=0xdde8c0, on=0xdde540) at backover.c:640 #7 0x000000000049bb39 in over_op_func (op=0x23d0900, rs=0x43805ce0, which=op_modify) at backover.c:702 #8 0x000000000049bc17 in over_op_modify (op=0x23d0900, rs=0x43805ce0) at backover.c:736 #9 0x0000000000448303 in fe_op_modify (op=0x23d0900, rs=0x43805ce0) at modify.c:395 #10 0x00000000004475ec in do_modify (op=0x23d0900, rs=0x43805ce0) at modify.c:200 #11 0x000000000042bd9c in connection_operation (ctx=0x43805e10, arg_v=0x23d0900) at connection.c:1133 #12 0x000000000042c28c in connection_read_thread (ctx=0x43805e10, argv=0x3c) at connection.c:1261 #13 0x0000002a956c3bd7 in ldap_int_thread_pool_wrapper (xpool=0x8a8f00) at tpool.c:478 #14 0x0000003769806137 in ?? () #15 0x0000000000000000 in ?? () Thread 3 (process 14051): #0 0x000000376980bf1c in ?? () #1 0x0000000000000000 in ?? () Thread 2 (process 14052): #0 0x000000376980af8b in ?? () #1 0x0000000044806920 in ?? () #2 0x00000000448066e0 in ?? () #3 0x0000003769807d54 in ?? () #4 0x0000002a97597257 in bdb_cache_entry_db_unlock (env=0xdd7818, lock=0x214e6c8) at cache.c:151 #5 0x0000002a97aada34 in accesslog_op_mod (op=0x7657c00, rs=0x44807ce0) at accesslog.c:1267 #6 0x000000000049b8dd in overlay_op_walk (op=0x7657c00, rs=0x44807ce0, which=op_modify, oi=0xdde8c0, on=0xdde540) at backover.c:640 #7 0x000000000049bb39 in over_op_func (op=0x7657c00, rs=0x44807ce0, which=op_modify) at backover.c:702 #8 0x000000000049bc17 in over_op_modify (op=0x7657c00, rs=0x44807ce0) at backover.c:736 #9 0x0000000000448303 in fe_op_modify (op=0x7657c00, rs=0x44807ce0) at modify.c:395 #10 0x00000000004475ec in do_modify (op=0x7657c00, rs=0x44807ce0) at modify.c:200 #11 0x000000000042bd9c in connection_operation (ctx=0x44807e10, arg_v=0x7657c00) at connection.c:1133 #12 0x000000000042c28c in connection_read_thread (ctx=0x44807e10, argv=0x36) at connection.c:1261 #13 0x0000002a956c3bd7 in ldap_int_thread_pool_wrapper (xpool=0x8a8f00) at tpool.c:478 #14 0x0000003769806137 in ?? () #15 0x0000000000000000 in ?? () Thread 1 (process 12522): #0 0x0000002a97aac75a in accesslog_response (op=0xd97c000, rs=0x42002ce0) at accesslog.c:918 #1 0x0000002a97aad947 in accesslog_mod_cleanup (op=0xd97c000, rs=0x42002ce0) at accesslog.c:1246 #2 0x000000000043e6a9 in send_ldap_response (op=0xd97c000, rs=0x42002ce0) at result.c:458 #3 0x000000000043ee26 in slap_send_ldap_result (op=0xd97c000, rs=0x42002ce0) at result.c:574 #4 0x0000002a975847d3 in bdb_modify (op=0xd97c000, rs=0x42002ce0) at modify.c:593 #5 0x000000000049b971 in overlay_op_walk (op=0xd97c000, rs=0x42002ce0, which=op_modify, oi=0xdde8c0, on=0x0) at backover.c:650 #6 0x000000000049bb39 in over_op_func (op=0xd97c000, rs=0x42002ce0, which=op_modify) at backover.c:702 #7 0x000000000049bc17 in over_op_modify (op=0xd97c000, rs=0x42002ce0) at backover.c:736 #8 0x0000000000448303 in fe_op_modify (op=0xd97c000, rs=0x42002ce0) at modify.c:395 #9 0x00000000004475ec in do_modify (op=0xd97c000, rs=0x42002ce0) at modify.c:200 #10 0x000000000042bd9c in connection_operation (ctx=0x42002e10, arg_v=0xd97c000) at connection.c:1133 #11 0x000000000042c28c in connection_read_thread (ctx=0x42002e10, argv=0x23) at connection.c:1261 #12 0x0000002a956c3bd7 in ldap_int_thread_pool_wrapper (xpool=0x8a8f00) at tpool.c:478 #13 0x0000003769806137 in ?? () #14 0x0000000000000000 in ?? () Core #2: Thread 10 (process 11473): #0 0x000000376980714b in ?? () #1 0x0000003769807010 in ?? () #2 0x0000000040800d28 in ?? () #3 0x0000000000000000 in ?? () Thread 9 (process 15458): #0 0x0000003768fc790c in ?? () #1 0x000000000042894b in slapd_daemon_task (ptr=0x0) at daemon.c:2174 #2 0x0000003769806137 in ?? () #3 0x0000000000000000 in ?? () Thread 8 (process 15460): #0 0x000000376980af8b in ?? () #1 0x0000000041800920 in ?? () #2 0x00000000418006e0 in ?? () #3 0x0000003769807d54 in ?? () #4 0x0000002a97597257 in bdb_cache_entry_db_unlock (env=0xdd7818, lock=0xe61888) at cache.c:151 #5 0x0000002a97aada34 in accesslog_op_mod (op=0xcadbc00, rs=0x41801ce0) at accesslog.c:1267 #6 0x000000000049b8dd in overlay_op_walk (op=0xcadbc00, rs=0x41801ce0, which=op_modify, oi=0xdde8c0, on=0xdde540) at backover.c:640 #7 0x000000000049bb39 in over_op_func (op=0xcadbc00, rs=0x41801ce0, which=op_modify) at backover.c:702 #8 0x000000000049bc17 in over_op_modify (op=0xcadbc00, rs=0x41801ce0) at backover.c:736 #9 0x0000000000448303 in fe_op_modify (op=0xcadbc00, rs=0x41801ce0) at modify.c:395 #10 0x00000000004475ec in do_modify (op=0xcadbc00, rs=0x41801ce0) at modify.c:200 #11 0x000000000042bd9c in connection_operation (ctx=0x41801e10, arg_v=0xcadbc00) at connection.c:1133 #12 0x000000000042c28c in connection_read_thread (ctx=0x41801e10, argv=0x32) at connection.c:1261 #13 0x0000002a956c3bd7 in ldap_int_thread_pool_wrapper (xpool=0x8a8f00) at tpool.c:478 #14 0x0000003769806137 in ?? () #15 0x0000000000000000 in ?? () Thread 7 (process 15461): #0 0x000000376980af8b in ?? () #1 0x0000000042001920 in ?? () #2 0x00000000420016e0 in ?? () #3 0x0000003769807d54 in ?? () #4 0x0000002a97597257 in bdb_cache_entry_db_unlock (env=0xdd7818, lock=0xe64380) at cache.c:151 #5 0x0000002a97aada34 in accesslog_op_mod (op=0x34d2300, rs=0x42002ce0) at accesslog.c:1267 #6 0x000000000049b8dd in overlay_op_walk (op=0x34d2300, rs=0x42002ce0, which=op_modify, oi=0xdde8c0, on=0xdde540) at backover.c:640 #7 0x000000000049bb39 in over_op_func (op=0x34d2300, rs=0x42002ce0, which=op_modify) at backover.c:702 #8 0x000000000049bc17 in over_op_modify (op=0x34d2300, rs=0x42002ce0) at backover.c:736 #9 0x0000000000448303 in fe_op_modify (op=0x34d2300, rs=0x42002ce0) at modify.c:395 #10 0x00000000004475ec in do_modify (op=0x34d2300, rs=0x42002ce0) at modify.c:200 #11 0x000000000042bd9c in connection_operation (ctx=0x42002e10, arg_v=0x34d2300) at connection.c:1133 #12 0x000000000042c28c in connection_read_thread (ctx=0x42002e10, argv=0x2b) at connection.c:1261 #13 0x0000002a956c3bd7 in ldap_int_thread_pool_wrapper (xpool=0x8a8f00) at tpool.c:478 #14 0x0000003769806137 in ?? () #15 0x0000000000000000 in ?? () Thread 6 (process 15463): #0 0x000000376980af8b in ?? () #1 0x0000000042802920 in ?? () #2 0x00000000428026e0 in ?? () #3 0x0000003769807d54 in ?? () #4 0x0000002a97597257 in bdb_cache_entry_db_unlock (env=0xdd7818, lock=0xe64a48) at cache.c:151 #5 0x0000002a97aada34 in accesslog_op_mod (op=0x34d2900, rs=0x42803ce0) at accesslog.c:1267 #6 0x000000000049b8dd in overlay_op_walk (op=0x34d2900, rs=0x42803ce0, which=op_modify, oi=0xdde8c0, on=0xdde540) at backover.c:640 #7 0x000000000049bb39 in over_op_func (op=0x34d2900, rs=0x42803ce0, which=op_modify) at backover.c:702 #8 0x000000000049bc17 in over_op_modify (op=0x34d2900, rs=0x42803ce0) at backover.c:736 #9 0x0000000000448303 in fe_op_modify (op=0x34d2900, rs=0x42803ce0) at modify.c:395 #10 0x00000000004475ec in do_modify (op=0x34d2900, rs=0x42803ce0) at modify.c:200 #11 0x000000000042bd9c in connection_operation (ctx=0x42803e10, arg_v=0x34d2900) at connection.c:1133 #12 0x000000000042c28c in connection_read_thread (ctx=0x42803e10, argv=0x30) at connection.c:1261 #13 0x0000002a956c3bd7 in ldap_int_thread_pool_wrapper (xpool=0x8a8f00) at tpool.c:478 #14 0x0000003769806137 in ?? () #15 0x0000000000000000 in ?? () Thread 5 (process 15724): #0 0x000000376980af8b in ?? () #1 0x0000000043003920 in ?? () #2 0x00000000430036e0 in ?? () #3 0x0000003769807d54 in ?? () #4 0x0000002a97597257 in bdb_cache_entry_db_unlock (env=0xdd7818, lock=0x7616dc8) at cache.c:151 #5 0x0000002a97aada34 in accesslog_op_mod (op=0xcb75900, rs=0x43004ce0) at accesslog.c:1267 #6 0x000000000049b8dd in overlay_op_walk (op=0xcb75900, rs=0x43004ce0, which=op_modify, oi=0xdde8c0, on=0xdde540) at backover.c:640 #7 0x000000000049bb39 in over_op_func (op=0xcb75900, rs=0x43004ce0, which=op_modify) at backover.c:702 #8 0x000000000049bc17 in over_op_modify (op=0xcb75900, rs=0x43004ce0) at backover.c:736 #9 0x0000000000448303 in fe_op_modify (op=0xcb75900, rs=0x43004ce0) at modify.c:395 #10 0x00000000004475ec in do_modify (op=0xcb75900, rs=0x43004ce0) at modify.c:200 #11 0x000000000042bd9c in connection_operation (ctx=0x43004e10, arg_v=0xcb75900) at connection.c:1133 #12 0x000000000042c28c in connection_read_thread (ctx=0x43004e10, argv=0x31) at connection.c:1261 #13 0x0000002a956c3bd7 in ldap_int_thread_pool_wrapper (xpool=0x8a8f00) at tpool.c:478 #14 0x0000003769806137 in ?? () #15 0x0000000000000000 in ?? () Thread 4 (process 15725): #0 0x000000376980af8b in ?? () #1 0x0000000043804920 in ?? () #2 0x00000000438046e0 in ?? () #3 0x0000003769807d54 in ?? () #4 0x0000002a97597257 in bdb_cache_entry_db_unlock (env=0xdd7818, lock=0x7616fc0) at cache.c:151 #5 0x0000002a97aada34 in accesslog_op_mod (op=0xcb75c00, rs=0x43805ce0) at accesslog.c:1267 #6 0x000000000049b8dd in overlay_op_walk (op=0xcb75c00, rs=0x43805ce0, which=op_modify, oi=0xdde8c0, on=0xdde540) at backover.c:640 #7 0x000000000049bb39 in over_op_func (op=0xcb75c00, rs=0x43805ce0, which=op_modify) at backover.c:702 #8 0x000000000049bc17 in over_op_modify (op=0xcb75c00, rs=0x43805ce0) at backover.c:736 #9 0x0000000000448303 in fe_op_modify (op=0xcb75c00, rs=0x43805ce0) at modify.c:395 #10 0x00000000004475ec in do_modify (op=0xcb75c00, rs=0x43805ce0) at modify.c:200 #11 0x000000000042bd9c in connection_operation (ctx=0x43805e10, arg_v=0xcb75c00) at connection.c:1133 #12 0x000000000042c28c in connection_read_thread (ctx=0x43805e10, argv=0x2f) at connection.c:1261 #13 0x0000002a956c3bd7 in ldap_int_thread_pool_wrapper (xpool=0x8a8f00) at tpool.c:478 #14 0x0000003769806137 in ?? () #15 0x0000000000000000 in ?? () Thread 3 (process 16249): #0 0x000000376980af8b in ?? () #1 0x0000000044005920 in ?? () #2 0x00000000440056e0 in ?? () #3 0x0000003769807d54 in ?? () #4 0x0000002a97597257 in bdb_cache_entry_db_unlock (env=0xdd7818, lock=0xcb1ff50) at cache.c:151 #5 0x0000002a97aada34 in accesslog_op_mod (op=0xcbccc00, rs=0x44006ce0) at accesslog.c:1267 #6 0x000000000049b8dd in overlay_op_walk (op=0xcbccc00, rs=0x44006ce0, which=op_modify, oi=0xdde8c0, on=0xdde540) at backover.c:640 #7 0x000000000049bb39 in over_op_func (op=0xcbccc00, rs=0x44006ce0, which=op_modify) at backover.c:702 #8 0x000000000049bc17 in over_op_modify (op=0xcbccc00, rs=0x44006ce0) at backover.c:736 #9 0x0000000000448303 in fe_op_modify (op=0xcbccc00, rs=0x44006ce0) at modify.c:395 #10 0x00000000004475ec in do_modify (op=0xcbccc00, rs=0x44006ce0) at modify.c:200 #11 0x000000000042bd9c in connection_operation (ctx=0x44006e10, arg_v=0xcbccc00) at connection.c:1133 #12 0x000000000042c28c in connection_read_thread (ctx=0x44006e10, argv=0x24) at connection.c:1261 #13 0x0000002a956c3bd7 in ldap_int_thread_pool_wrapper (xpool=0x8a8f00) at tpool.c:478 #14 0x0000003769806137 in ?? () #15 0x0000000000000000 in ?? () Thread 2 (process 16251): #0 0x000000376980af8b in ?? () #1 0x0000000044806920 in ?? () #2 0x00000000448066e0 in ?? () #3 0x0000003769807d54 in ?? () #4 0x0000002a97597257 in bdb_cache_entry_db_unlock (env=0xdd7818, lock=0xdcd06c8) at cache.c:151 #5 0x0000002a97aada34 in accesslog_op_mod (op=0x7661c00, rs=0x44807ce0) at accesslog.c:1267 #6 0x000000000049b8dd in overlay_op_walk (op=0x7661c00, rs=0x44807ce0, which=op_modify, oi=0xdde8c0, on=0xdde540) at backover.c:640 #7 0x000000000049bb39 in over_op_func (op=0x7661c00, rs=0x44807ce0, which=op_modify) at backover.c:702 #8 0x000000000049bc17 in over_op_modify (op=0x7661c00, rs=0x44807ce0) at backover.c:736 #9 0x0000000000448303 in fe_op_modify (op=0x7661c00, rs=0x44807ce0) at modify.c:395 #10 0x00000000004475ec in do_modify (op=0x7661c00, rs=0x44807ce0) at modify.c:200 #11 0x000000000042bd9c in connection_operation (ctx=0x44807e10, arg_v=0x7661c00) at connection.c:1133 #12 0x000000000042c28c in connection_read_thread (ctx=0x44807e10, argv=0x35) at connection.c:1261 #13 0x0000002a956c3bd7 in ldap_int_thread_pool_wrapper (xpool=0x8a8f00) at tpool.c:478 #14 0x0000003769806137 in ?? () #15 0x0000000000000000 in ?? () Thread 1 (process 15459): #0 0x0000002a97aac75a in accesslog_response (op=0x34d2c00, rs=0x41000ce0) at accesslog.c:918 #1 0x0000002a97aad947 in accesslog_mod_cleanup (op=0x34d2c00, rs=0x41000ce0) at accesslog.c:1246 #2 0x000000000043e6a9 in send_ldap_response (op=0x34d2c00, rs=0x41000ce0) at result.c:458 #3 0x000000000043ee26 in slap_send_ldap_result (op=0x34d2c00, rs=0x41000ce0) at result.c:574 #4 0x0000002a975847d3 in bdb_modify (op=0x34d2c00, rs=0x41000ce0) at modify.c:593 #5 0x000000000049b971 in overlay_op_walk (op=0x34d2c00, rs=0x41000ce0, which=op_modify, oi=0xdde8c0, on=0x0) at backover.c:650 #6 0x000000000049bb39 in over_op_func (op=0x34d2c00, rs=0x41000ce0, which=op_modify) at backover.c:702 #7 0x000000000049bc17 in over_op_modify (op=0x34d2c00, rs=0x41000ce0) at backover.c:736 #8 0x0000000000448303 in fe_op_modify (op=0x34d2c00, rs=0x41000ce0) at modify.c:395 #9 0x00000000004475ec in do_modify (op=0x34d2c00, rs=0x41000ce0) at modify.c:200 #10 0x000000000042bd9c in connection_operation (ctx=0x41000e10, arg_v=0x34d2c00) at connection.c:1133 #11 0x000000000042c28c in connection_read_thread (ctx=0x41000e10, argv=0x2e) at connection.c:1261 #12 0x0000002a956c3bd7 in ldap_int_thread_pool_wrapper (xpool=0x8a8f00) at tpool.c:478 #13 0x0000003769806137 in ?? () #14 0x0000000000000000 in ?? () 2 more cores that looks similar if desired.

1 0

(ITS#5489) Assert failed in slapd_clr_write()
by rein＠OpenLDAP.org 30 Apr '08

30 Apr '08

Full_Name: Rein Tollevik Version: CVS head OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (81.93.160.250) Submitted by: rein We have seen a case where "assert(SLAP_SOCK_IS_ACTIVE(s))" in slapd_clr_write() failed, see the stack trace at the end. The last log message (at loglevel stat) related to the socket was "fd=657 closed (connection lost on write)". The comment where slapd_daemon_task() calls connection_write() makes me believe that slapd_clr_write() should not have use assert here. Remove it or include it as a condition in the following if statement? Rein Tollevik Basefarm AS Program terminated with signal 6, Aborted. (gdb) where #0 0xb7fe97a2 in _dl_sysinfo_int80 () from /lib/ld-linux.so.2 #1 0xb7b777a5 in raise () from /lib/tls/libc.so.6 #2 0xb7b79209 in abort () from /lib/tls/libc.so.6 #3 0xb7b70d91 in __assert_fail () from /lib/tls/libc.so.6 #4 0x0806da8f in slapd_clr_write (s=657, wake=0) at daemon.c:931 #5 0x080726d7 in connection_write (s=657) at connection.c:1814 #6 0x080717bc in slapd_daemon_task (ptr=0x0) at daemon.c:2414 #7 0xb7c80371 in start_thread () from /lib/tls/libpthread.so.0 #8 0xb7c17ffe in clone () from /lib/tls/libc.so.6

1 0

(ITS#5488) syncrepl received contextCSN not passed on to syncprov consumers
by rein＠OpenLDAP.org 30 Apr '08

30 Apr '08

Full_Name: Rein Tollevik Version: CVS head OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (81.93.160.250) Submitted by: rein When syncrepl and syncprov are both used on a glue database, the contextCSN received from the syncrepl producers are not passed on to the syncprov consumers when changes in subordinate databases are received. The reason is that syncrepl queues the CSNs in the glue backend, while syncprov fetches them from the backend where the changes are made. As a consequence, the consumers will be passed a cookie without any csn value. My first attempt at fixing this was to change syncprov to fetch the queued csn values from the glue backend where it was used. But that failed as other modules queues the csn values in their own backend when they changes things. Instead I changed ctxcsn.c so that it always queues them in the glue backend where syncprov is used. But I don't feel that my understanding of this stuff is good enough to be sure that this is the optimal solution.. Btw, in syncprov_checkpoint() there is a similar SLAP_GLUE_SUBORDINATE test, should that have included an overlay_is_inst() clause as well? Rein Tollevik Basefarm AS Index: OpenLDAP/servers/slapd/ctxcsn.c diff -u OpenLDAP/servers/slapd/ctxcsn.c:1.1.1.11 OpenLDAP/servers/slapd/ctxcsn.c:1.2 --- OpenLDAP/servers/slapd/ctxcsn.c:1.1.1.11 Sat Mar 22 16:47:49 2008 +++ OpenLDAP/servers/slapd/ctxcsn.c Wed Apr 30 19:44:25 2008 @@ -37,67 +37,78 @@ ) { struct slap_csn_entry *csne, *committed_csne = NULL; + Backend *be = op->o_bd; if ( maxcsn ) { BER_BVZERO( maxcsn ); } - ldap_pvt_thread_mutex_lock( op->o_bd->be_pcl_mutexp ); + if ( SLAP_GLUE_SUBORDINATE( be ) && !overlay_is_inst( be, "syncprov" )) + be = select_backend( &be->be_nsuffix[0], 1 ); + ldap_pvt_thread_mutex_lock( be->be_pcl_mutexp ); - LDAP_TAILQ_FOREACH( csne, op->o_bd->be_pending_csn_list, ce_csn_link ) { + LDAP_TAILQ_FOREACH( csne, be->be_pending_csn_list, ce_csn_link ) { if ( csne->ce_opid == op->o_opid && csne->ce_connid == op->o_connid ) { csne->ce_state = SLAP_CSN_COMMIT; break; } } - LDAP_TAILQ_FOREACH( csne, op->o_bd->be_pending_csn_list, ce_csn_link ) { + LDAP_TAILQ_FOREACH( csne, be->be_pending_csn_list, ce_csn_link ) { if ( csne->ce_state == SLAP_CSN_COMMIT ) committed_csne = csne; if ( csne->ce_state == SLAP_CSN_PENDING ) break; } if ( committed_csne && maxcsn ) *maxcsn = committed_csne->ce_csn; - ldap_pvt_thread_mutex_unlock( op->o_bd->be_pcl_mutexp ); + ldap_pvt_thread_mutex_unlock( be->be_pcl_mutexp ); } void slap_rewind_commit_csn( Operation *op ) { struct slap_csn_entry *csne; + Backend *be = op->o_bd; - ldap_pvt_thread_mutex_lock( op->o_bd->be_pcl_mutexp ); + if ( SLAP_GLUE_SUBORDINATE( be ) && !overlay_is_inst( be, "syncprov" )) + be = select_backend( &be->be_nsuffix[0], 1 ); + ldap_pvt_thread_mutex_lock( be->be_pcl_mutexp ); - LDAP_TAILQ_FOREACH( csne, op->o_bd->be_pending_csn_list, ce_csn_link ) { + LDAP_TAILQ_FOREACH( csne, be->be_pending_csn_list, ce_csn_link ) { if ( csne->ce_opid == op->o_opid && csne->ce_connid == op->o_connid ) { csne->ce_state = SLAP_CSN_PENDING; break; } } - ldap_pvt_thread_mutex_unlock( op->o_bd->be_pcl_mutexp ); + ldap_pvt_thread_mutex_unlock( be->be_pcl_mutexp ); } void slap_graduate_commit_csn( Operation *op ) { struct slap_csn_entry *csne; + Backend *be; if ( op == NULL ) return; if ( op->o_bd == NULL ) return; + be = op->o_bd; + if ( SLAP_GLUE_SUBORDINATE( be ) && !overlay_is_inst( be, "syncprov" )) + be = select_backend( &be->be_nsuffix[0], 1 ); + #if 0 /* it is NULL when we get here from the frontendDB; * alternate fix: initialize frontendDB like all other backends */ - assert( op->o_bd->be_pcl_mutexp != NULL ); + assert( be->be_pcl_mutexp != NULL ); #endif - if ( op->o_bd->be_pcl_mutexp == NULL ) return; + if ( be->be_pcl_mutexp == NULL ) return; - ldap_pvt_thread_mutex_lock( op->o_bd->be_pcl_mutexp ); + ldap_pvt_thread_mutex_lock( be->be_pcl_mutexp ); - LDAP_TAILQ_FOREACH( csne, op->o_bd->be_pending_csn_list, ce_csn_link ) { + LDAP_TAILQ_FOREACH( csne, be->be_pending_csn_list, ce_csn_link ) { if ( csne->ce_opid == op->o_opid && csne->ce_connid == op->o_connid ) { - LDAP_TAILQ_REMOVE( op->o_bd->be_pending_csn_list, + LDAP_TAILQ_REMOVE( be->be_pending_csn_list, csne, ce_csn_link ); Debug( LDAP_DEBUG_SYNC, "slap_graduate_commit_csn: removing %p %s\n", csne->ce_csn.bv_val, csne->ce_csn.bv_val, 0 ); @@ -110,7 +121,7 @@ } } - ldap_pvt_thread_mutex_unlock( op->o_bd->be_pcl_mutexp ); + ldap_pvt_thread_mutex_unlock( be->be_pcl_mutexp ); return; } @@ -161,22 +172,25 @@ struct berval *csn ) { struct slap_csn_entry *pending; + Backend *be = op->o_bd; pending = (struct slap_csn_entry *) ch_calloc( 1, sizeof( struct slap_csn_entry )); Debug( LDAP_DEBUG_SYNC, "slap_queue_csn: queing %p %s\n", csn->bv_val, csn->bv_val, 0 ); - ldap_pvt_thread_mutex_lock( op->o_bd->be_pcl_mutexp ); + if ( SLAP_GLUE_SUBORDINATE( be ) && !overlay_is_inst( be, "syncprov" )) + be = select_backend( &be->be_nsuffix[0], 1 ); + ldap_pvt_thread_mutex_lock( be->be_pcl_mutexp ); ber_dupbv( &pending->ce_csn, csn ); ber_bvreplace_x( &op->o_csn, &pending->ce_csn, op->o_tmpmemctx ); pending->ce_connid = op->o_connid; pending->ce_opid = op->o_opid; pending->ce_state = SLAP_CSN_PENDING; - LDAP_TAILQ_INSERT_TAIL( op->o_bd->be_pending_csn_list, + LDAP_TAILQ_INSERT_TAIL( be->be_pending_csn_list, pending, ce_csn_link ); - ldap_pvt_thread_mutex_unlock( op->o_bd->be_pcl_mutexp ); + ldap_pvt_thread_mutex_unlock( be->be_pcl_mutexp ); } int

1 0

(ITS#5487) syncprov_findbase must search the backend from the syncrepl search
by rein＠OpenLDAP.org 30 Apr '08

30 Apr '08

Full_Name: Rein Tollevik Version: CVS head OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (81.93.160.250) Submitted by: rein syncprov_findbase() must search the backend saved with the syncrepl operation, not the one from the operation passed as argument. The backend in the op argument can be a subordinate database, in which case the search for the base in the superior database will fail, and syncrepl consumers will be force to do a an unneccessary full refresh of the database. The patch at the end should fix this. Note that both fop.o_bd and fop.o_bd->bd_info can be changed by the overlay_op_walk() call, which is the reason for the long pointer traversal to find the correct bd_info to save and restore. Rein Tollevik Basefarm AS diff -u OpenLDAP/servers/slapd/overlays/syncprov.c:1.1.1.18 OpenLDAP/servers/slapd/overlays/syncprov.c:1.19 --- OpenLDAP/servers/slapd/overlays/syncprov.c:1.1.1.18 Wed Apr 30 13:17:58 2008 +++ OpenLDAP/servers/slapd/overlays/syncprov.c Wed Apr 30 19:34:00 2008 @@ -404,7 +404,7 @@ slap_callback cb = {0}; Operation fop; SlapReply frs = { REP_RESULT }; - BackendInfo *bi; + BackendInfo *bi = fc->fss->s_op->o_bd->bd_info; int rc; fc->fss->s_flags ^= PS_FIND_BASE; @@ -413,10 +413,8 @@ fop = *fc->fss->s_op; fop.o_hdr = op->o_hdr; - fop.o_bd = op->o_bd; fop.o_time = op->o_time; fop.o_tincr = op->o_tincr; - bi = op->o_bd->bd_info; cb.sc_response = findbase_cb; cb.sc_private = fc; @@ -435,7 +433,7 @@ fop.ors_filterstr = generic_filterstr; rc = overlay_op_walk( &fop, &frs, op_search, on->on_info, on ); - op->o_bd->bd_info = bi; + fc->fss->s_op->o_bd->bd_info = bi; } else { ldap_pvt_thread_mutex_unlock( &fc->fss->s_mutex ); fc->fbase = 1;

1 0

Re: (ITS#5470) Sporadic failures with RE24
by luca＠OpenLDAP.org 30 Apr '08

30 Apr '08

This is a multi-part message in MIME format. --------------080809000906010300090306 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Howard Chu wrote: > Thanks. Please try HEAD again. No way. new testrun directory in ftp://ftp.sys-net.it/luca_scamoni_its5470_20080430-new.tgz backtrace attached --------------080809000906010300090306 Content-Type: text/plain; name="bt.txt" Content-Transfer-Encoding: 8bit Content-Disposition: inline; filename="bt.txt" Program terminated with signal 11, Segmentation fault. #0 0x0807e6e4 in filter2bv_x (op=0x2a17dac, f=0x32383833, fstr=0x2a17948) at filter.c:588 588 undef = f->f_choice & SLAPD_FILTER_UNDEFINED; (gdb) thr apply all bt full Thread 5 (process 11932): #0 0x00110402 in __kernel_vsyscall () No symbol table info available. #1 0x0072f605 in pthread_join () from /lib/libpthread.so.0 No symbol table info available. #2 0x0011e907 in ldap_pvt_thread_join (thread=18434960, thread_return=0x0) at thr_posix.c:197 No locals. #3 0x080766b2 in slapd_daemon () at daemon.c:2644 listener_tid = 18434960 rc = 0 #4 0x0805badc in main (argc=8, argv=0xbfce4da4) at main.c:946 i = -1 no_detach = 1 rc = -12 urls = 0x9210018 "ldap://localhost:9012/" username = 0x0 groupname = 0x0 sandbox = 0x0 syslogUser = 160 g_argc = 8 g_argv = (char **) 0xbfce4da4 configfile = 0x0 configdir = 0x9210008 "./slapd.d" serverName = 0xbfce5306 "lt-slapd" serverMode = 1 scp = (struct sync_cookie *) 0x0 scp_entry = (struct sync_cookie *) 0x0 debug_unknowns = (char **) 0x0 syslog_unknowns = (char **) 0x0 serverNamePrefix = 0x812e057 "" l = 1347374360 slapd_pid_file_unlink = 0 slapd_args_file_unlink = 0 firstopt = 0 __PRETTY_FUNCTION__ = "main" Thread 4 (process 11947): #0 0x00110402 in __kernel_vsyscall () No symbol table info available. #1 0x00670346 in epoll_wait () from /lib/libc.so.6 No symbol table info available. #2 0x08075aa1 in slapd_daemon_task (ptr=0x0) at daemon.c:2281 ns = 1 at = 0 nfds = 7 revents = (struct epoll_event *) 0x9213d78 tvp = (struct timeval *) 0x11942fc cat = {tv_sec = 1209559064, tv_usec = 0} i = 0 nwriters = 0 now = 1209559054 tv = {tv_sec = 10, tv_usec = 0} tdelta = 1 rtask = (struct re_s *) 0x92895b0 l = 2 last_idle_check = 0 idle = {tv_sec = 0, tv_usec = 0} ebadf = 0 #3 0x0072e50b in start_thread () from /lib/libpthread.so.0 No symbol table info available. #4 0x0066fb2e in clone () from /lib/libc.so.6 No symbol table info available. Thread 3 (process 12114): #0 0x00110402 in __kernel_vsyscall () No symbol table info available. #1 0x007325d5 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/libpthread.so.0 No symbol table info available. #2 0x0011ea0c in ldap_pvt_thread_cond_wait (cond=0x9234cf4, mutex=0x9234cdc) at thr_posix.c:277 No locals. #3 0x0011d6bb in ldap_int_thread_pool_wrapper (xpool=0x9234cd8) at tpool.c:654 pool = (struct ldap_int_thread_pool_s *) 0x9234cd8 task = (ldap_int_thread_task_t *) 0x0 work_list = (ldap_int_tpool_plist_t *) 0x9234d58 ctx = {ltu_id = 22633360, ltu_key = {{ltk_key = 0x8079056, ltk_data = 0x926ab48, ltk_free = 0x8078e75 <conn_counter_destroy>}, {ltk_key = 0x80dc7a5, ltk_data = 0x9268408, ltk_free = 0x80dc5dc <slap_sl_mem_destroy>}, {ltk_key = 0x809116b, ltk_data = 0x926a890, ltk_free = 0x80910e8 <slap_op_q_destroy>}, { ltk_key = 0x9294ac0, ltk_data = 0xb7b821d4, ltk_free = 0xc0be2a}, {ltk_key = 0xbf9b33, ltk_data = 0xb6196008, ltk_free = 0xbf9b08}, {ltk_key = 0x0, ltk_data = 0x0, ltk_free = 0} <repeats 27 times>}} kctx = (ldap_int_thread_userctx_t *) 0x0 i = 32 keyslot = 165 hash = 5272741 __PRETTY_FUNCTION__ = "ldap_int_thread_pool_wrapper" #4 0x0072e50b in start_thread () from /lib/libpthread.so.0 No symbol table info available. #5 0x0066fb2e in clone () from /lib/libc.so.6 No symbol table info available. Thread 2 (process 12129): #0 0x00110402 in __kernel_vsyscall () No symbol table info available. #1 0x007325d5 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/libpthread.so.0 No symbol table info available. #2 0x0011ea0c in ldap_pvt_thread_cond_wait (cond=0x9234cf4, mutex=0x9234cdc) at thr_posix.c:277 No locals. #3 0x0011d6bb in ldap_int_thread_pool_wrapper (xpool=0x9234cd8) at tpool.c:654 pool = (struct ldap_int_thread_pool_s *) 0x9234cd8 task = (ldap_int_thread_task_t *) 0x0 work_list = (ldap_int_tpool_plist_t *) 0x9234d58 ctx = {ltu_id = 60083088, ltu_key = {{ltk_key = 0x80dc7a5, ltk_data = 0x9266bf8, ltk_free = 0x80dc5dc <slap_sl_mem_destroy>}, {ltk_key = 0x8079056, ltk_data = 0x927ba30, ltk_free = 0x8078e75 <conn_counter_destroy>}, {ltk_key = 0x809116b, ltk_data = 0x926a558, ltk_free = 0x80910e8 <slap_op_q_destroy>}, {ltk_key = 0x9294ac0, ltk_data = 0xb7b823b4, ltk_free = 0xc0be2a}, {ltk_key = 0xbf9b33, ltk_data = 0xb6997008, ltk_free = 0xbf9b08}, {ltk_key = 0x0, ltk_data = 0x0, ltk_free = 0} <repeats 27 times>}} kctx = (ldap_int_thread_userctx_t *) 0x0 i = 32 keyslot = 306 hash = 5400882 __PRETTY_FUNCTION__ = "ldap_int_thread_pool_wrapper" #4 0x0072e50b in start_thread () from /lib/libpthread.so.0 No symbol table info available. #5 0x0066fb2e in clone () from /lib/libc.so.6 No symbol table info available. Thread 1 (process 12939): #0 0x0807e6e4 in filter2bv_x (op=0x2a17dac, f=0x32383833, fstr=0x2a17948) at filter.c:588 i = 153708648 p = (Filter *) 0xb tmp = {bv_len = 0, bv_val = 0x9296868 "\b\220\231�\b\220\231�\b\220��\001"} value = {bv_len = 153577944, bv_val = 0x0} len = 44136616 choice = 134851750 undef = 153577944 sign = 0x0 ber_bvfalse = {bv_len = 9, bv_val = 0x8135aac "(?=false)"} ber_bvtrue = {bv_len = 8, bv_val = 0x8135aa3 "(?=true)"} ber_bvundefined = {bv_len = 13, bv_val = 0x8135a95 "(?=undefined)"} ber_bverror = {bv_len = 9, bv_val = 0x8135a8b "(?=error)"} ber_bvunknown = {bv_len = 11, bv_val = 0x8135a7f "(?=unknown)"} ber_bvnone = {bv_len = 8, bv_val = 0x8135a76 "(?=none)"} #1 0x0807ef20 in filter2bv_x (op=0x2a17dac, f=0x92dd360, fstr=0x2a17df0) at filter.c:742 i = 40 p = (Filter *) 0x32383833 tmp = {bv_len = 9, bv_val = 0x92769d8 "�]-\t"} value = {bv_len = 153998176, bv_val = 0x0} len = 94946797 choice = 160 undef = 0 sign = 0x0 ber_bvfalse = {bv_len = 9, bv_val = 0x8135aac "(?=false)"} ber_bvtrue = {bv_len = 8, bv_val = 0x8135aa3 "(?=true)"} ber_bvundefined = {bv_len = 13, bv_val = 0x8135a95 "(?=undefined)"} ber_bverror = {bv_len = 9, bv_val = 0x8135a8b "(?=error)"} ber_bvunknown = {bv_len = 11, bv_val = 0x8135a7f "(?=unknown)"} ber_bvnone = {bv_len = 8, bv_val = 0x8135a76 "(?=none)"} #2 0x080e97eb in syncrepl_del_nonpresent (op=0x2a17dac, si=0x9294348, uuids=0x0, sc=0x2a17c08, m=0) at syncrepl.c:2444 f = (Filter *) 0x92dd36c i = 1 cf = (Filter *) 0x92dd360 of = (Filter *) 0x92994e8 be = (Backend *) 0x92891f8 cb = {sc_next = 0x0, sc_response = 0x80eb85b <nonpresent_callback>, sc_cleanup = 0, sc_private = 0x9294348} rs_search = {sr_type = REP_RESULT, sr_tag = 0, sr_msgid = 0, sr_err = 0, sr_matched = 0x0, sr_text = 0x0, sr_ref = 0x0, sr_ctrls = 0x0, sr_un = {sru_sasl = { r_sasldata = 0x0}, sru_extended = {r_rspoid = 0x0, r_rspdata = 0x0}, sru_search = {r_entry = 0x0, r_attr_flags = 0, r_operational_attrs = 0x0, r_attrs = 0x0, r_nentries = 0, r_v2ref = 0x0}}, sr_flags = 0} rs_delete = {sr_type = REP_RESULT, sr_tag = 0, sr_msgid = 0, sr_err = 0, sr_matched = 0x0, sr_text = 0x0, sr_ref = 0x0, sr_ctrls = 0x0, sr_un = {sru_sasl = { r_sasldata = 0x0}, sru_extended = {r_rspoid = 0x0, r_rspdata = 0x0}, sru_search = {r_entry = 0x0, r_attr_flags = 0, r_operational_attrs = 0x0, r_attrs = 0x0, r_nentries = 0, r_v2ref = 0x0}}, sr_flags = 0} rs_modify = {sr_type = REP_RESULT, sr_tag = 0, sr_msgid = 0, sr_err = 0, sr_matched = 0x0, sr_text = 0x0, sr_ref = 0x0, sr_ctrls = 0x0, sr_un = {sru_sasl = { r_sasldata = 0x0}, sru_extended = {r_rspoid = 0x0, r_rspdata = 0x0}, sru_search = {r_entry = 0x0, r_attr_flags = 0, r_operational_attrs = 0x0, r_attrs = 0x0, r_nentries = 0, r_v2ref = 0x0}}, sr_flags = 0} np_list = (struct nonpresent_entry *) 0x92994e8 np_prev = (struct nonpresent_entry *) 0x0 rc = 44137248 an = {{an_name = {bv_len = 9, bv_val = 0x922ed58 "entryUUID"}, an_desc = 0x922edf8, an_oc_exclude = 0, an_oc = 0x0}, {an_name = {bv_len = 0, bv_val = 0x0}, an_desc = 0x0, an_oc_exclude = 0, an_oc = 0x0}} pdn = {bv_len = 0, bv_val = 0x0} csn = {bv_len = 4294967295, bv_val = 0x15a4b8 "P\223\004"} #3 0x080e4a27 in do_syncrep2 (op=0x2a17dac, si=0x9294348) at syncrepl.c:952 rctrls = (LDAPControl **) 0x92994e8 rctrlp = (LDAPControl *) 0x92ddf18 berbuf = { buffer = "\002\000\001\000\005\001", '\0' <repeats 14 times>, "X4'\t\2304'\t\2304'\t", '\0' <repeats 32 times>, "�|�\002\000\000\000\000\000\000\000\000�|�\002\000\000\000\000\000\000\000\000\001\000\000\000\000\000\000\000\021\000\000\000�h)\t\021\000\000\000\210�%\t�|�\002", '\0' <repeats 16 times>, "��\"\t8\226(\tpb)\t\001", '\0' <repeats 15 times>, "\n\000\000\0008�\"\t��\"\t\000\000\000\000��\025\000\000\000\000\000\000\000\000\000\000|�\002\000\000\000\000\001\000\000\000�D)\t\001\000\000\000��\025\000x}�\002\024\021\024\000\210\220(\t\001\000\000\000�}�\002\b9\016\b\001"..., ialign = 65538, lalign = 65538, falign = 9.18382988e-41, dalign = 5.5384093382201037e-312, palign = 0x10002 <Address 0x10002 out of bounds>} ber = (BerElement *) 0x2a17c44 msg = (LDAPMessage *) 0x92d6718 retoid = 0x9297730 "all alumni assoc staff" retdata = (struct berval *) 0x92734f8 entry = (Entry *) 0x92cbf2c syncstate = 1 syncUUID = {bv_len = 16, bv_val = 0x92d5dff "\t\020"} syncCookie = {ctxcsn = 0x92ddf30, octet_str = {bv_len = 60, bv_val = 0x92dcf08 "rid=004,sid=002,csn=20080430123714.430853Z#000000#001#000000"}, rid = 4, sid = 2, numcsns = 1, sids = 0x9277d68, sc_next = {stqe_next = 0x0}} syncCookie_req = {ctxcsn = 0x92734e0, octet_str = {bv_len = 60, bv_val = 0x92966e0 "rid=004,sid=002,csn=20080430123714.247229Z#000000#001#000000"}, rid = 4, sid = 2, numcsns = 1, sids = 0x9297bd8, sc_next = {stqe_next = 0x0}} cookie = {bv_len = 60, bv_val = 0x927345c "ames a jones 2,ou=alumni association,ou=people,dc=example,dc=com"} rc = 101 err = 0 len = 0 psub = (struct berval *) 0x9289190 modlist = (Modifications *) 0x92748b0 match = -1 m = 0 tout_p = (struct timeval *) 0x0 tout = {tv_sec = 0, tv_usec = 0} refreshDeletes = 0 syncUUIDs = (BerVarray) 0x9272478 si_tag = 163 #4 0x080e5c1f in do_syncrepl (ctx=0x2a1820c, arg=0x92895b0) at syncrepl.c:1276 rtask = (struct re_s *) 0x92895b0 si = (syncinfo_t *) 0x9294348 conn = {c_struct_state = 0, c_conn_state = 0, c_conn_idx = -1, c_sd = 0, c_close_reason = 0x0, c_mutex = {__data = {__lock = 0, __count = 0, __owner = 0, __kind = 0, __nusers = 0, {__spins = 0, __list = {__next = 0x0}}}, __size = '\0' <repeats 23 times>, __align = 0}, c_sb = 0x0, c_starttime = 0, c_activitytime = 0, c_connid = 4294967295, c_peer_domain = {bv_len = 0, bv_val = 0x812e3c4 ""}, c_peer_name = {bv_len = 0, bv_val = 0x812e3c4 ""}, c_listener = 0x8134fa0, c_sasl_bind_mech = { bv_len = 0, bv_val = 0x0}, c_sasl_dn = {bv_len = 0, bv_val = 0x0}, c_sasl_authz_dn = {bv_len = 0, bv_val = 0x0}, c_authz_backend = 0x0, c_authz_cookie = 0x0, c_authz = { sai_method = 0, sai_mech = {bv_len = 0, bv_val = 0x0}, sai_dn = {bv_len = 0, bv_val = 0x0}, sai_ndn = {bv_len = 0, bv_val = 0x0}, sai_ssf = 0, sai_transport_ssf = 0, sai_tls_ssf = 0, sai_sasl_ssf = 0}, c_protocol = 0, c_ops = {stqh_first = 0x0, stqh_last = 0x0}, c_pending_ops = {stqh_first = 0x0, stqh_last = 0x0}, c_write_mutex = { __data = {__lock = 0, __count = 0, __owner = 0, __kind = 0, __nusers = 0, {__spins = 0, __list = {__next = 0x0}}}, __size = '\0' <repeats 23 times>, __align = 0}, c_write_cv = {__data = {__lock = 0, __futex = 0, __total_seq = 0, __wakeup_seq = 0, __woken_seq = 0, __mutex = 0x0, __nwaiters = 0, __broadcast_seq = 0}, __size = '\0' <repeats 47 times>, __align = 0}, c_currentber = 0x0, c_sasl_bind_in_progress = 0 '\0', c_writewaiter = 0 '\0', c_is_tls = 0 '\0', c_needs_tls_accept = 0 '\0', c_sasl_layers = 0 '\0', c_sasl_done = 0 '\0', c_sasl_authctx = 0x0, c_sasl_sockctx = 0x0, c_sasl_extra = 0x0, c_sasl_bindop = 0x0, c_txn = 0, c_txn_backend = 0x0, c_txn_ops = { stqh_first = 0x0, stqh_last = 0x0}, c_pagedresults_state = {ps_be = 0x0, ps_size = 0, ps_count = 0, ps_cookie = 0, ps_cookieval = {bv_len = 0, bv_val = 0x0}}, c_n_ops_received = 0, c_n_ops_executing = 0, c_n_ops_pending = 0, c_n_ops_completed = 0, c_n_get = 0, c_n_read = 0, c_n_write = 0, c_extensions = 0x0, c_clientfunc = 0, c_clientarg = 0x0, c_send_ldap_result = 0x808d3c3 <slap_send_ldap_result>, c_send_search_entry = 0x808e0c3 <slap_send_search_entry>, c_send_search_reference = 0x808fe46 <slap_send_search_reference>, c_send_ldap_extended = 0, c_send_ldap_intermediate = 0} opbuf = {ob_op = {o_hdr = 0x2a17e84, o_tag = 99, o_time = 1209559044, o_tincr = 18, o_bd = 0x92891f8, o_req_dn = {bv_len = 17, bv_val = 0x92944e8 "dc=example,dc=com"}, o_req_ndn = {bv_len = 17, bv_val = 0x92944e8 "dc=example,dc=com"}, o_request = {oq_add = {rs_modlist = 0x2, rs_e = 0x0}, oq_bind = {rb_method = 2, rb_cred = {bv_len = 0, bv_val = 0xffffffff <Address 0xffffffff out of bounds>}, rb_edn = {bv_len = 4294967295, bv_val = 0x0}, rb_ssf = 0, rb_mech = {bv_len = 44136992, bv_val = 0x92dd360 "�"}}, oq_compare = {rs_ava = 0x2}, oq_modify = {rs_mods = {rs_modlist = 0x2, rs_no_opattrs = 0 '\0'}, rs_increment = -1}, oq_modrdn = {rs_mods = { rs_modlist = 0x2, rs_no_opattrs = 0 '\0'}, rs_deleteoldrdn = -1, rs_newrdn = {bv_len = 4294967295, bv_val = 0x0}, rs_nnewrdn = {bv_len = 0, bv_val = 0x2a17a20 "\t"}, rs_newSup = 0x92dd360, rs_nnewSup = 0x5a8c5ed}, oq_search = {rs_scope = 2, rs_deref = 0, rs_slimit = -1, rs_tlimit = -1, rs_limit = 0x0, rs_attrsonly = 0, rs_attrs = 0x2a17a20, rs_filter = 0x92dd360, rs_filterstr = {bv_len = 94946797, bv_val = 0xafb97008 "(&(?=error)(?=unknown)(?=error)(?=unknown)(?=unknown)(?=error)(?=error)(?=unknown)(?=unknown)(?=unknown)(?=error)(?=unknown)(?=error)(?=unknown)(?=error)(?=unknown)(?=unknown)(?=error)(?=error)(?=unkn"...}}, oq_abandon = {rs_msgid = 2}, oq_cancel = {rs_msgid = 2}, oq_extended = {rs_reqoid = {bv_len = 2, bv_val = 0x0}, rs_flags = -1, rs_reqdata = 0xffffffff}, oq_pwdexop = {rs_extended = {rs_reqoid = {bv_len = 2, bv_val = 0x0}, rs_flags = -1, rs_reqdata = 0xffffffff}, rs_old = { bv_len = 0, bv_val = 0x0}, rs_new = {bv_len = 44136992, bv_val = 0x92dd360 "�"}, rs_mods = 0x5a8c5ed, rs_modtail = 0xafb97008}}, o_abandon = 0, o_cancel = 0, o_groups = 0x0, o_do_not_cache = 0 '\0', o_is_auth_check = 0 '\0', o_acl_priv = ACL_NONE, o_nocaching = 0 '\0', o_delete_glue_parent = 0 '\0', o_no_schema_check = 1 '\001', o_no_subordinate_glue = 0 '\0', o_ctrlflag = '\0' <repeats 16 times>, "\002", '\0' <repeats 14 times>, o_controls = 0x2a17fb0, o_authz = {sai_method = 0, sai_mech = { bv_len = 0, bv_val = 0x0}, sai_dn = {bv_len = 28, bv_val = 0x9289570 "cn=Manager,dc=example,dc=com"}, sai_ndn = {bv_len = 28, bv_val = 0x92891c8 "cn=manager,dc=example,dc=com"}, sai_ssf = 0, sai_transport_ssf = 0, sai_tls_ssf = 0, sai_sasl_ssf = 0}, o_ber = 0x0, o_res_ber = 0x0, o_callback = 0x2a17afc, o_ctrls = 0x0, o_csn = {bv_len = 0, bv_val = 0x0}, o_private = 0x0, o_extra = {slh_first = 0x0}, o_next = {stqe_next = 0x0}}, ob_hdr = {oh_opid = 0, oh_connid = 4294967295, oh_conn = 0x2a18030, oh_msgid = 0, oh_protocol = 3, oh_tid = 44141456, oh_threadctx = 0x2a1820c, oh_tmpmemctx = 0x0, oh_tmpmfuncs = 0x817c834, oh_counters = 0x81c2900, oh_log_prefix = "conn=-1 op=0", '\0' <repeats 243 times>, oh_extensions = 0x0}, ob_controls = {0x0 <repeats 32 times>}} op = (Operation *) 0x2a17dac rc = 0 dostop = 0 do_setup = 0 s = 18 i = 44138952 defer = 1 fail = 0 be = (Backend *) 0x92891f8 #5 0x0011d72e in ldap_int_thread_pool_wrapper (xpool=0x9234cd8) at tpool.c:663 pool = (struct ldap_int_thread_pool_s *) 0x9234cd8 task = (ldap_int_thread_task_t *) 0x9266868 work_list = (ldap_int_tpool_plist_t *) 0x9234d58 ctx = {ltu_id = 44141456, ltu_key = {{ltk_key = 0x80dc7a5, ltk_data = 0x9296868, ltk_free = 0x80dc5dc <slap_sl_mem_destroy>}, {ltk_key = 0x9294ac0, ltk_data = 0xb7b822c4, ltk_free = 0xc0be2a}, {ltk_key = 0xbf9b33, ltk_data = 0xb7198008, ltk_free = 0xbf9b08}, {ltk_key = 0x8079056, ltk_data = 0x9288c68, ltk_free = 0x8078e75 <conn_counter_destroy>}, {ltk_key = 0x809116b, ltk_data = 0x9273cc0, ltk_free = 0x80910e8 <slap_op_q_destroy>}, {ltk_key = 0x0, ltk_data = 0x0, ltk_free = 0} <repeats 27 times>}} kctx = (ldap_int_thread_userctx_t *) 0x0 i = 32 keyslot = 606 hash = 5329502 __PRETTY_FUNCTION__ = "ldap_int_thread_pool_wrapper" #6 0x0072e50b in start_thread () from /lib/libpthread.so.0 No symbol table info available. #7 0x0066fb2e in clone () from /lib/libc.so.6 No symbol table info available. (gdb) --------------080809000906010300090306--

1 0

Re: (ITS#5470) Sporadic failures with RE24
by luca＠OpenLDAP.org 30 Apr '08

30 Apr '08

Here it is again. HEAD code checked out this morning. I'm able to reproduce the crash fairly often. testrun directory uploaded at ftp://ftp.sys-net.it/luca_scamoni_its5470_20080430.tgz the core file is in testrun/con

1 0

Re: (ITS#5486) openldap with syncprov intermittent core dump
by mark.cave-ayland＠siriusit.co.uk 29 Apr '08

29 Apr '08

Howard Chu wrote: >> Looking at the log snippet above, I can see in the "syncprov_sendresp" >> lines >> that the cookie appears to be empty. This does appear to be similar to >> ITS#5432, > > I don't see that in the snippet above. Seems unrelated. Okay. I was just querying whether it was related to the fact that the cookie= field appeared blank similar to the ITS#5432. > "info threads" would probably be a useful start. And "bt full". No problem. I've created a file containing the same snippet from the log file and the extra information requested above, and uploaded it to http://pastebin.siriusit.co.uk/openldap-its5486-detail.txt to help preserve formatting. Many thanks, Mark. -- Mark Cave-Ayland Sirius Corporation - The Open Source Experts http://www.siriusit.co.uk T: +44 870 608 0063

1 0

Re: (ITS#5486) openldap with syncprov intermittent core dump
by hyc＠symas.com 28 Apr '08

28 Apr '08

mark.cave-ayland(a)siriusit.co.uk wrote: > Full_Name: Mark Cave-Ayland > Version: 2.4.8cvs-RE24-2008-04-15 > OS: RHEL4, x86 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (217.207.197.142) > > > Hi there, > > In order to resolve issues experienced with syncrepl/glue on an existing > openldap-2.4.8 deployment (ITS#5430), we have been using a CVS checkout of > openldap RE24 branch taken from 2008-04-15 on one of our test systems. > > Unfortunately, we are still seeing random segfaults occurring roughly once a day > which appear to point towards the syncprov overlay once again. At the moment, we > are having difficulty reproducing the fault under test conditions, but if > openldap is left running long enough then it is possible to obtain a core dump. > > The issue is occurring with a server, pelican, which is configured using the > syncprov overlay to a number of subordinates for different parts of the tree. > The relevant log snippet follows: > > Apr 28 12:18:32 pelican slapd[7688]: do_syncrep2: > cookie=rid=142,csn=20080428111855.697316Z#000000#000#000000 > Apr 28 12:18:32 pelican slapd[7688]: syncrepl_entry: rid=142 > LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_MODIFY) > Apr 28 12:18:32 pelican slapd[7688]: syncrepl_entry: rid=142 be_search (0) > Apr 28 12:18:32 pelican slapd[7688]: syncrepl_entry: rid=142 > uid=richf,ou=V,ou=W,ou=X,dc=Y,dc=Z > Apr 28 12:18:32 pelican slapd[7688]: slap_queue_csn: queing 0x9ff7560 > 20080428111855.697316Z#000000#000#000000 > Apr 28 12:18:32 pelican slapd[7688]: syncprov_sendresp: > cookie=rid=146,csn=20080428111855.697316Z#000000#000#000000 > Apr 28 12:18:32 pelican slapd[7688]: syncprov_sendresp: > cookie=rid=134,csn=20080428111855.697316Z#000000#000#000000 > Apr 28 12:18:32 pelican slapd[7688]: slap_graduate_commit_csn: removing > 0xa12ee70 20080428111855.697316Z#000000#000#000000 > Apr 28 12:18:32 pelican slapd[7688]: syncrepl_entry: rid=142 be_modify (0) > Apr 28 12:18:32 pelican slapd[7688]: slap_queue_csn: queing 0x9ff7560 > 20080428111855.697316Z#000000#000#000000 > Looking at the log snippet above, I can see in the "syncprov_sendresp" lines > that the cookie appears to be empty. This does appear to be similar to ITS#5432, I don't see that in the snippet above. Seems unrelated. > although this claims to have been fixed by a commit on the 21st March (and hence > the fix would be included within our CVS checkout). Further information can be > provided on request. "info threads" would probably be a useful start. And "bt full". -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: (ITS#5470) Sporadic failures with RE24
by hyc＠symas.com 28 Apr '08

28 Apr '08

ando(a)sys-net.it wrote: > raphael.ouazana(a)linagora.com wrote: >> Hi, >> >> Le Lun 21 avril 2008 19:44, quanah(a)zimbra.com a écrit : >>> I updated RE24 this morning with a couple of fixes from Howard. >>> >>> See if you can still repo, thanks. >> It still seems to fail, after more than 100 runs: > > It appears from your logs that the entry > > "cn=ITD Staff,ou=Groups,dc=example,dc=com" > > is being added first, and then removed from server 3, probably related > to some issue in sync replication. Seems like the consumer has received a cookie from one provider, while receiving a newer entry from the other provider. During the nonpresent search the new entry is found and removed. So we need to restrict the filter in the nonpresent search to only return entries older than the cookie context. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs