openldap-bugs April 2009

openldap-bugs@openldap.org

49 participants
141 discussions

Re: (ITS#6045) Use copy of db in syncprov_matchops
by hyc＠symas.com 03 Apr '09

03 Apr '09

rein(a)OpenLDAP.org wrote: > Full_Name: Rein Tollevik > Version: CVS HEAD/RE_24 > OS: Irrelevant > URL: > Submission from: (NULL) (81.93.160.250) > > > I had a couple of seg. faults when resync'ing my servers after upgrading to the > upcoming 2.4.16 release. Looks as if a copy of the backend must be used when > testing the filter in syncprov_matchops. See the gdb output at the end. Note, > some function names are incorrect due to optimization. A fix is coming. The fix makes no sense, or the problem has not yet been analyzed sufficiently. Nobody in that call chain should be zeroing out bd_info. And if someone *is*, then it will happen in *whatever* BackendDB structure is currently being used. Explain the real cause of the problem, and why the fix is correct. -- -- 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#6045) Use copy of db in syncprov_matchops
by rein＠OpenLDAP.org 03 Apr '09

03 Apr '09

Full_Name: Rein Tollevik Version: CVS HEAD/RE_24 OS: Irrelevant URL: Submission from: (NULL) (81.93.160.250) I had a couple of seg. faults when resync'ing my servers after upgrading to the upcoming 2.4.16 release. Looks as if a copy of the backend must be used when testing the filter in syncprov_matchops. See the gdb output at the end. Note, some function names are incorrect due to optimization. A fix is coming. Rein Tollevik Basefarm AS Program terminated with signal 11, Segmentation fault. #0 0x080989a1 in access_allowed_mask (op=0x8c98dc54, e=0x83f827c, desc=0x81f2008, val=0x0, access=ACL_SEARCH, state=0x0, maskp=0x0) at acl.c:454 454 if ( op->o_bd->bd_info->bi_access_allowed ) { (gdb) where #0 0x080989a1 in access_allowed_mask (op=0x8c98dc54, e=0x83f827c, desc=0x81f2008, val=0x0, access=ACL_SEARCH, state=0x0, maskp=0x0) at acl.c:454 #1 0x0809603b in test_filter (op=0x8c98dc54, e=0x83f827c, f=0x82ffb0ac) at filterentry.c:821 #2 0xb7a3d740 in syncprov_matchops (op=0x8c98edc8, opc=0x7ae2d620, saveit=0) at syncprov.c:1257 #3 0xb7a3e5cd in syncprov_op_response (op=0x8c98edc8, rs=0x8c98e890) at syncprov.c:1801 #4 0x08084e5d in slap_response_play (op=0x8c98edc8, rs=0x8c98e890) at result.c:350 #5 0x0808821c in send_ldap_response (op=0x8c98edc8, rs=0x8c98e890) at result.c:424 #6 0x080893b3 in slap_send_ldap_result (op=0x8c98edc8, rs=0x8c98e890) at result.c:693 #7 0x08109928 in bdb_add (op=0x8c98edc8, rs=0x8c98e890) at add.c:494 #8 0x080e13cf in overlay_op_walk (op=0x8c98edc8, rs=0x8c98e890, which=op_add, oi=0x829a000, on=0x829b2b0) at backover.c:669 #9 0x080e19b5 in over_op_func (op=0x8c98edc8, rs=0x8c98e890, which=op_add) at backover.c:721 #10 0x080e1a95 in over_op_add (op=0x8c98edc8, rs=0x8c98e890) at backover.c:767 #11 0x080df61f in glue_op_func (op=0x8c98edc8, rs=0x8c98e890) at backglue.c:238 #12 0x080e1379 in overlay_op_walk (op=0x8c98edc8, rs=0x8c98e890, which=op_add, oi=0x82a3098, on=0x82a3298) at backover.c:659 #13 0x080e19b5 in over_op_func (op=0x8c98edc8, rs=0x8c98e890, which=op_add) at backover.c:721 #14 0x080e1a95 in over_op_add (op=0x8c98edc8, rs=0x8c98e890) at backover.c:767 #15 0x080d962f in syncrepl_entry (si=0x829b140, op=0x8c98edc8, entry=0x83f827c, modlist=0x8c98ebf8, syncstate=1, syncUUID=0x8c98ec50, syncCSN=0x0) at syncrepl.c:2187 #16 0x080dca39 in do_syncrep2 (op=0x8c98edc8, si=0x829b140) at syncrepl.c:892 #17 0x080de907 in do_syncrepl (ctx=0x8c98f2b8, arg=0x829a760) at syncrepl.c:1361 #18 0x08075d59 in connection_read_thread (ctx=0x8c98f2b8, argv=0x4d) at connection.c:1225 #19 0xb7fb3a20 in ldap_int_thread_pool_wrapper (xpool=0x81f8cf0) at tpool.c:663 #20 0xb7c53371 in start_thread () from /lib/tls/libpthread.so.0 #21 0xb7beaffe in clone () from /lib/tls/libc.so.6 (gdb) print op->o_bd->bd_info $1 = (BackendInfo *) 0x0 (gdb) print op->o_bd $2 = (BackendDB *) 0x8a4c4814 (gdb) frame 2 #2 0xb7a3d740 in syncprov_matchops (op=0x8c98edc8, opc=0x7ae2d620, saveit=0) at syncprov.c:1257 1257 rc = test_filter( &op2, e, ss->s_op->ors_filter ); (gdb) print op2.o_bd $3 = (BackendDB *) 0x8a4c4814 (gdb) print *op2.o_bd $4 = {bd_info = 0x0, bd_self = 0x0, be_ctrls = "\000\000\000\000\214\221\030\b�\001�\204\210HL\212\201�\f\b ", '\0' <repeats 11 times>, be_flags = 0, be_restrictops = 0, be_requires = 0, be_ssf_set = {sss_ssf = 0, sss_transport = 0, sss_tls = 0, sss_sasl = 1, sss_update_ssf = 3086609409, sss_update_transport = 2142916662, sss_update_tls = 2320255160, sss_update_sasl = 1, sss_simple_bind = 0}, be_suffix = 0x0, be_nsuffix = 0x1, be_schemadn = {bv_len = 32, bv_val = 0xb7fa418c "\204�"}, be_schemandn = {bv_len = 0, bv_val = 0x8a4c4a0c "\002"}, be_rootdn = {bv_len = 2320255176, bv_val = 0xb7f9c44b "\203�,[^_]�U\211�\203�8\211]�\211u�\211}��w���\201�%}"}, be_rootndn = {bv_len = 2320255500, bv_val = 0x8a4c48b8 "\004\001�\204\214A��\fJL\212\fJL\212�HL\212?���\001"}, be_rootpw = {bv_len = 1, bv_val = 0x0}, be_max_deref_depth = 2229404096, be_def_limit = {lms_t_soft = 1, lms_t_hard = 0, lms_s_soft = -1208355505, lms_s_hard = 1, lms_s_unchecked = 24, lms_s_pr = -2065563388, lms_s_pr_hide = -1208335988, lms_s_pr_total = -1974711796}, be_limits = 0x8a4c4a0c, be_acl = 0x8a4c48f8, be_dfltaccess = -1208367041, be_update_ndn = {bv_len = 1, bv_val = 0x18 ""}, be_update_refs = 0x84e201c0, be_pending_csn_list = 0x818918c, be_pcl_mutex = {__m_reserved = 0, __m_count = 48, __m_owner = 0x7fba5030, __m_kind = -1208335988, __m_lock = {__status = -1, __spinlock = -1974711796}}, be_syncinfo = 0x8a4c4918, be_pb = 0xb7f9c961, be_cf_ocs = 0x8a4c4a0c, be_private = 0x81f24f8, be_next = {stqe_next = 0xf}}

1 0

Re: (ITS#6021) slapo-pcache/back-ldap slapd crashes
by toby＠inf.ed.ac.uk 03 Apr '09

03 Apr '09

Hi there, I've been collecting a bit more information on these crashes... Since we started running 2.4.15: 26 core files, of these, 15 have crashed in memory.c:152 It looks like the majority of these were removing stale entries from the cache when slapd crashed, which wasn't the case with the original ticket I submitted. Also, the last thing logged by slapd in quite a few of these cases was along this lines of ... Mar 30 20:50:16 albany slapd[14239]: DELETING ENTRY TEMPLATE=db78c810-0c2a-49de-96af-f5796bbe8ca3 Mar 30 20:50:17 albany last message repeated 14 times ... I don't know whether this is useful? Here's the details of the latest crash, slapd log and backtrace: Mar 30 20:50:16 albany slapd[14239]: Lock CR index = 0x83a5140 Mar 30 20:50:16 albany slapd[14239]: TEMPLATE 0x83a5140 QUERIES-- 0 Mar 30 20:50:16 albany slapd[14239]: Unlock CR index = 0x83a5140 Mar 30 20:50:16 albany slapd[14239]: DELETING ENTRY TEMPLATE=e7ccb20c-d263-4d6c-ba23-62afe55f0158 Mar 30 20:50:16 albany slapd[14239]: STALE QUERY REMOVED, SIZE=1 Mar 30 20:50:16 albany slapd[14239]: STORED QUERIES = 30 Mar 30 20:50:16 albany slapd[14239]: STALE QUERY REMOVED, CACHE =22 entries Mar 30 20:50:16 albany slapd[14239]: Lock CR index = 0x83a4e90 Mar 30 20:50:16 albany slapd[14239]: TEMPLATE 0x83a4e90 QUERIES-- 15 Mar 30 20:50:16 albany slapd[14239]: Unlock CR index = 0x83a4e90 Mar 30 20:50:16 albany slapd[14239]: STALE QUERY REMOVED, SIZE=0 Mar 30 20:50:16 albany slapd[14239]: STORED QUERIES = 29 Mar 30 20:50:16 albany slapd[14239]: STALE QUERY REMOVED, CACHE =22 entries Mar 30 20:50:16 albany slapd[14239]: Lock CR index = 0x83a4e90 Mar 30 20:50:16 albany slapd[14239]: TEMPLATE 0x83a4e90 QUERIES-- 14 Mar 30 20:50:16 albany slapd[14239]: Unlock CR index = 0x83a4e90 Mar 30 20:50:16 albany slapd[14239]: STALE QUERY REMOVED, SIZE=0 Mar 30 20:50:16 albany slapd[14239]: STORED QUERIES = 28 Mar 30 20:50:16 albany slapd[14239]: STALE QUERY REMOVED, CACHE =22 entries Mar 30 20:50:16 albany slapd[14239]: Lock CR index = 0x83a4e90 Mar 30 20:50:16 albany slapd[14239]: TEMPLATE 0x83a4e90 QUERIES-- 13 Mar 30 20:50:16 albany slapd[14239]: Unlock CR index = 0x83a4e90 Mar 30 20:50:16 albany slapd[14239]: STALE QUERY REMOVED, SIZE=0 Mar 30 20:50:16 albany slapd[14239]: STORED QUERIES = 27 Mar 30 20:50:16 albany slapd[14239]: STALE QUERY REMOVED, CACHE =22 entries Mar 30 20:50:16 albany slapd[14239]: Lock CR index = 0x83a4e90 Mar 30 20:50:16 albany slapd[14239]: TEMPLATE 0x83a4e90 QUERIES-- 12 Mar 30 20:50:16 albany slapd[14239]: Unlock CR index = 0x83a4e90 Mar 30 20:50:16 albany slapd[14239]: STALE QUERY REMOVED, SIZE=0 Mar 30 20:50:16 albany slapd[14239]: STORED QUERIES = 26 Mar 30 20:50:16 albany slapd[14239]: STALE QUERY REMOVED, CACHE =22 entries Mar 30 20:50:16 albany slapd[14239]: Lock CR index = 0x83a4e90 Mar 30 20:50:16 albany slapd[14239]: TEMPLATE 0x83a4e90 QUERIES-- 11 Mar 30 20:50:16 albany slapd[14239]: Unlock CR index = 0x83a4e90 Mar 30 20:50:16 albany slapd[14239]: STALE QUERY REMOVED, SIZE=0 Mar 30 20:50:16 albany slapd[14239]: STORED QUERIES = 25 Mar 30 20:50:16 albany slapd[14239]: STALE QUERY REMOVED, CACHE =22 entries Mar 30 20:50:16 albany slapd[14239]: Lock CR index = 0x83a4e90 Mar 30 20:50:16 albany slapd[14239]: TEMPLATE 0x83a4e90 QUERIES-- 10 Mar 30 20:50:16 albany slapd[14239]: Unlock CR index = 0x83a4e90 Mar 30 20:50:16 albany slapd[14239]: STALE QUERY REMOVED, SIZE=0 Mar 30 20:50:16 albany slapd[14239]: STORED QUERIES = 24 Mar 30 20:50:16 albany slapd[14239]: STALE QUERY REMOVED, CACHE =22 entries Mar 30 20:50:16 albany slapd[14239]: Lock CR index = 0x83a4e90 Mar 30 20:50:16 albany slapd[14239]: TEMPLATE 0x83a4e90 QUERIES-- 9 Mar 30 20:50:16 albany slapd[14239]: Unlock CR index = 0x83a4e90 Mar 30 20:50:16 albany slapd[14239]: STALE QUERY REMOVED, SIZE=0 Mar 30 20:50:16 albany slapd[14239]: STORED QUERIES = 23 Mar 30 20:50:16 albany slapd[14239]: STALE QUERY REMOVED, CACHE =22 entries Mar 30 20:50:16 albany slapd[14239]: Lock CR index = 0x83a4e90 Mar 30 20:50:16 albany slapd[14239]: TEMPLATE 0x83a4e90 QUERIES-- 8 Mar 30 20:50:16 albany slapd[14239]: Unlock CR index = 0x83a4e90 Mar 30 20:50:16 albany slapd[14239]: STALE QUERY REMOVED, SIZE=0 Mar 30 20:50:16 albany slapd[14239]: STORED QUERIES = 22 Mar 30 20:50:16 albany slapd[14239]: STALE QUERY REMOVED, CACHE =22 entries Mar 30 20:50:16 albany slapd[14239]: Lock CR index = 0x83a4e90 Mar 30 20:50:16 albany slapd[14239]: TEMPLATE 0x83a4e90 QUERIES-- 7 Mar 30 20:50:16 albany slapd[14239]: Unlock CR index = 0x83a4e90 Mar 30 20:50:16 albany slapd[14239]: STALE QUERY REMOVED, SIZE=0 Mar 30 20:50:16 albany slapd[14239]: STORED QUERIES = 21 Mar 30 20:50:16 albany slapd[14239]: STALE QUERY REMOVED, CACHE =22 entries Mar 30 20:50:16 albany slapd[14239]: Lock CR index = 0x83a4e90 Mar 30 20:50:16 albany slapd[14239]: TEMPLATE 0x83a4e90 QUERIES-- 6 Mar 30 20:50:16 albany slapd[14239]: Unlock CR index = 0x83a4e90 Mar 30 20:50:16 albany slapd[14239]: STALE QUERY REMOVED, SIZE=0 Mar 30 20:50:16 albany slapd[14239]: STORED QUERIES = 20 Mar 30 20:50:16 albany slapd[14239]: STALE QUERY REMOVED, CACHE =22 entries Mar 30 20:50:16 albany slapd[14239]: Lock CR index = 0x83a4e90 Mar 30 20:50:16 albany slapd[14239]: TEMPLATE 0x83a4e90 QUERIES-- 5 Mar 30 20:50:16 albany slapd[14239]: Unlock CR index = 0x83a4e90 Mar 30 20:50:16 albany slapd[14239]: STALE QUERY REMOVED, SIZE=0 Mar 30 20:50:16 albany slapd[14239]: STORED QUERIES = 19 Mar 30 20:50:16 albany slapd[14239]: STALE QUERY REMOVED, CACHE =22 entries Mar 30 20:50:16 albany slapd[14239]: Lock CR index = 0x83a4e90 Mar 30 20:50:16 albany slapd[14239]: TEMPLATE 0x83a4e90 QUERIES-- 4 Mar 30 20:50:16 albany slapd[14239]: Unlock CR index = 0x83a4e90 Mar 30 20:50:16 albany slapd[14239]: STALE QUERY REMOVED, SIZE=0 Mar 30 20:50:16 albany slapd[14239]: STORED QUERIES = 18 Mar 30 20:50:16 albany slapd[14239]: STALE QUERY REMOVED, CACHE =22 entries Mar 30 20:50:16 albany slapd[14239]: Lock CR index = 0x83a4e90 Mar 30 20:50:16 albany slapd[14239]: TEMPLATE 0x83a4e90 QUERIES-- 3 Mar 30 20:50:16 albany slapd[14239]: Unlock CR index = 0x83a4e90 Mar 30 20:50:16 albany slapd[14239]: STALE QUERY REMOVED, SIZE=0 Mar 30 20:50:16 albany slapd[14239]: STORED QUERIES = 17 Mar 30 20:50:16 albany slapd[14239]: STALE QUERY REMOVED, CACHE =22 entries Mar 30 20:50:16 albany slapd[14239]: Lock CR index = 0x83a4e90 Mar 30 20:50:16 albany slapd[14239]: TEMPLATE 0x83a4e90 QUERIES-- 2 Mar 30 20:50:16 albany slapd[14239]: Unlock CR index = 0x83a4e90 Mar 30 20:50:16 albany slapd[14239]: STALE QUERY REMOVED, SIZE=0 Mar 30 20:50:16 albany slapd[14239]: STORED QUERIES = 16 Mar 30 20:50:16 albany slapd[14239]: STALE QUERY REMOVED, CACHE =22 entries Mar 30 20:50:16 albany slapd[14239]: Lock CR index = 0x83a4e90 Mar 30 20:50:16 albany slapd[14239]: TEMPLATE 0x83a4e90 QUERIES-- 1 Mar 30 20:50:16 albany slapd[14239]: Unlock CR index = 0x83a4e90 Mar 30 20:50:16 albany slapd[14239]: STALE QUERY REMOVED, SIZE=0 Mar 30 20:50:16 albany slapd[14239]: STORED QUERIES = 15 Mar 30 20:50:16 albany slapd[14239]: STALE QUERY REMOVED, CACHE =22 entries Mar 30 20:50:16 albany slapd[14239]: Lock CR index = 0x83a4e90 Mar 30 20:50:16 albany slapd[14239]: TEMPLATE 0x83a4e90 QUERIES-- 0 Mar 30 20:50:16 albany slapd[14239]: Unlock CR index = 0x83a4e90 Mar 30 20:50:16 albany slapd[14239]: STALE QUERY REMOVED, SIZE=0 Mar 30 20:50:16 albany slapd[14239]: STORED QUERIES = 14 Mar 30 20:50:16 albany slapd[14239]: STALE QUERY REMOVED, CACHE =22 entries Mar 30 20:50:16 albany slapd[14239]: Lock CR index = 0x83a4e28 Mar 30 20:50:16 albany slapd[14239]: TEMPLATE 0x83a4e28 QUERIES-- 0 Mar 30 20:50:16 albany slapd[14239]: Unlock CR index = 0x83a4e28 Mar 30 20:50:16 albany slapd[14239]: DELETING ENTRY TEMPLATE=db78c810-0c2a-49de-96af-f5796bbe8ca3 Mar 30 20:50:17 albany last message repeated 14 times Program terminated with signal 6, Aborted. #0 0x00185402 in __kernel_vsyscall () (gdb) bt #0 0x00185402 in __kernel_vsyscall () #1 0x00476d20 in raise () from /lib/libc.so.6 #2 0x00478631 in abort () from /lib/libc.so.6 #3 0x004aee6b in __libc_message () from /lib/libc.so.6 #4 0x004b6b16 in _int_free () from /lib/libc.so.6 #5 0x004ba070 in free () from /lib/libc.so.6 #6 0x081d5746 in ber_memfree_x (p=0x841e688, ctx=0x0) at memory.c:152 #7 0x081d630c in ber_bvarray_free_x (a=0x843af58, ctx=0x0) at memory.c:731 #8 0x081d6343 in ber_bvarray_free (a=0x843af58) at memory.c:741 #9 0x0807979c in attr_clean (a=0xb62934ec) at attr.c:146 #10 0x0807983b in attrs_free (a=0xb62934ec) at attr.c:196 #11 0x0807c059 in entry_clean (e=0xb6727584) at entry.c:504 #12 0x0807c080 in entry_free (e=0xb6727584) at entry.c:514 #13 0x08140030 in bdb_entry_return (e=0xb6727584) at id2entry.c:229 #14 0x08134c0c in bdb_cache_delete_cleanup (cache=0x838956c, ei=0xb332a060) at cache.c:1316 #15 0x0813a824 in bdb_delete (op=0xb32fed5c, rs=0xb32febec) at delete.c:575 #16 0x08177be1 in remove_query_data (op=0xb32fed5c, rs=0xb32fecf8, query_uuid=0x83ff288) at pcache.c:1460 #17 0x0817af8f in consistency_check (ctx=0xb32ff1d0, arg=0x83f57e8) at pcache.c:2611 #18 0x0819ecad in ldap_int_thread_pool_wrapper (xpool=0x8366f90) at tpool.c:663 #19 0x005c746b in start_thread () from /lib/libpthread.so.0 #20 0x0051edbe in clone () from /lib/libc.so.6 (gdb) Also, I'll include details of another type of crash that I've seen 3 times since running 2.4.15 in the lab, at the risk of overloading information into this ticket. I'm including it here as the slapd behaviour at time of crash was similar to that noted above, i.e. removing stale entries from the cache: Mar 13 04:37:48 pemberton slapd[6767]: Lock CR index = 0x9ac9188 Mar 13 04:37:48 pemberton slapd[6767]: TEMPLATE 0x9ac9188 QUERIES-- 2 Mar 13 04:37:48 pemberton slapd[6767]: Unlock CR index = 0x9ac9188 Mar 13 04:37:48 pemberton slapd[6767]: DELETING ENTRY TEMPLATE=febcaede-1a2f-42ef-af2e-9206f0a4f678 Mar 13 04:37:48 pemberton slapd[6767]: STALE QUERY REMOVED, SIZE=1 Mar 13 04:37:48 pemberton slapd[6767]: STORED QUERIES = 32 Mar 13 04:37:48 pemberton slapd[6767]: STALE QUERY REMOVED, CACHE =19 entries Mar 13 04:37:48 pemberton slapd[6767]: Lock CR index = 0x9ac8eb0 Mar 13 04:37:48 pemberton slapd[6767]: TEMPLATE 0x9ac8eb0 QUERIES-- 15 Mar 13 04:37:48 pemberton slapd[6767]: Unlock CR index = 0x9ac8eb0 Mar 13 04:37:48 pemberton slapd[6767]: STALE QUERY REMOVED, SIZE=0 Mar 13 04:37:48 pemberton slapd[6767]: STORED QUERIES = 31 Mar 13 04:37:48 pemberton slapd[6767]: STALE QUERY REMOVED, CACHE =19 entries Mar 13 04:37:48 pemberton slapd[6767]: Lock CR index = 0x9ac8eb0 Mar 13 04:37:48 pemberton slapd[6767]: TEMPLATE 0x9ac8eb0 QUERIES-- 14 Mar 13 04:37:48 pemberton slapd[6767]: Unlock CR index = 0x9ac8eb0 Mar 13 04:37:48 pemberton slapd[6767]: STALE QUERY REMOVED, SIZE=0 Mar 13 04:37:48 pemberton slapd[6767]: STORED QUERIES = 30 Mar 13 04:37:48 pemberton slapd[6767]: STALE QUERY REMOVED, CACHE =19 entries Mar 13 04:37:48 pemberton slapd[6767]: Lock CR index = 0x9ac8eb0 Mar 13 04:37:48 pemberton slapd[6767]: TEMPLATE 0x9ac8eb0 QUERIES-- 13 Mar 13 04:37:48 pemberton slapd[6767]: Unlock CR index = 0x9ac8eb0 Mar 13 04:37:48 pemberton slapd[6767]: STALE QUERY REMOVED, SIZE=0 Mar 13 04:37:48 pemberton slapd[6767]: STORED QUERIES = 29 Mar 13 04:37:48 pemberton slapd[6767]: STALE QUERY REMOVED, CACHE =19 entries Mar 13 04:37:48 pemberton slapd[6767]: Lock CR index = 0x9ac8eb0 Mar 13 04:37:48 pemberton slapd[6767]: TEMPLATE 0x9ac8eb0 QUERIES-- 12 Mar 13 04:37:48 pemberton slapd[6767]: Unlock CR index = 0x9ac8eb0 Mar 13 04:37:48 pemberton slapd[6767]: STALE QUERY REMOVED, SIZE=0 Mar 13 04:37:48 pemberton slapd[6767]: STORED QUERIES = 28 Mar 13 04:37:48 pemberton slapd[6767]: STALE QUERY REMOVED, CACHE =19 entries Mar 13 04:37:48 pemberton slapd[6767]: Lock CR index = 0x9ac8eb0 Mar 13 04:37:48 pemberton slapd[6767]: TEMPLATE 0x9ac8eb0 QUERIES-- 11 Mar 13 04:37:48 pemberton slapd[6767]: Unlock CR index = 0x9ac8eb0 Mar 13 04:37:48 pemberton slapd[6767]: STALE QUERY REMOVED, SIZE=0 Mar 13 04:37:48 pemberton slapd[6767]: STORED QUERIES = 27 Mar 13 04:37:48 pemberton slapd[6767]: STALE QUERY REMOVED, CACHE =19 entries Mar 13 04:37:48 pemberton slapd[6767]: Lock CR index = 0x9ac8eb0 Mar 13 04:37:48 pemberton slapd[6767]: TEMPLATE 0x9ac8eb0 QUERIES-- 10 Mar 13 04:37:48 pemberton slapd[6767]: Unlock CR index = 0x9ac8eb0 Mar 13 04:37:48 pemberton slapd[6767]: STALE QUERY REMOVED, SIZE=0 Mar 13 04:37:48 pemberton slapd[6767]: STORED QUERIES = 26 Mar 13 04:37:48 pemberton slapd[6767]: STALE QUERY REMOVED, CACHE =19 entries Mar 13 04:37:48 pemberton slapd[6767]: Lock CR index = 0x9ac8e48 Mar 13 04:37:48 pemberton slapd[6767]: TEMPLATE 0x9ac8e48 QUERIES-- 1 Mar 13 04:37:48 pemberton slapd[6767]: Unlock CR index = 0x9ac8e48 Mar 13 04:37:48 pemberton slapd[6767]: DELETING ENTRY TEMPLATE=3eff8b71-4ca6-4918-b760-c32023dbe215 Mar 13 04:37:48 pemberton last message repeated 12 times Mar 13 04:37:48 pemberton slapd[6767]: REMOVING TEMP ATTR : TEMPLATE=3eff8b71-4ca6-4918-b760-c32023dbe215 Mar 13 04:37:48 pemberton last message repeated 2 times Mar 13 04:37:48 pemberton slapd[6767]: STALE QUERY REMOVED, SIZE=13 Mar 13 04:37:48 pemberton slapd[6767]: STORED QUERIES = 25 Mar 13 04:37:48 pemberton slapd[6767]: STALE QUERY REMOVED, CACHE =6 entries Mar 13 04:37:48 pemberton slapd[6767]: Lock CR index = 0x9ac8da8 Program terminated with signal 11, Segmentation fault. #0 0x081772d2 in remove_from_template (qc=0xaef209a8, template=0x9ac8da8) at pcache.c:1297 1297 qc->prev->next = qc->next; (gdb) bt #0 0x081772d2 in remove_from_template (qc=0xaef209a8, template=0x9ac8da8) at pcache.c:1297 #1 0x0817adc8 in consistency_check (ctx=0xaeeff1d0, arg=0x9b19860) at pcache.c:2594 #2 0x0819ecad in ldap_int_thread_pool_wrapper (xpool=0x9a8afa0) at tpool.c:663 #3 0x00bb046b in start_thread () from /lib/libpthread.so.0 #4 0x00b07dbe in clone () from /lib/libc.so.6 (gdb) (gdb) p qc->prev->next Cannot access memory at address 0x54 (gdb) p qc->prev $2 = (struct cached_query_s *) 0x30 (gdb) p *qc->prev Cannot access memory at address 0x30 (gdb) As always, if there's any more information that would be useful, let me know... Cheers Toby -- The University of Edinburgh is a charitable body, registered in Scotland, with registration number SC005336.

1 0

Re: (ITS#6043) slapd segfaults in bdb_rdn_cmp
by hyc＠symas.com 02 Apr '09

02 Apr '09

Luca Scamoni wrote: > (gdb) thread apply all bt full > > Thread 4 (process 29343): > #0 0x006487a2 in _dl_sysinfo_int80 () from /lib/ld-linux.so.2 > No symbol table info available. > #1 0x001271d7 in pthread_join () from /lib/tls/libpthread.so.0 > No symbol table info available. > #2 0x008f8926 in ldap_pvt_thread_join (thread=4294967292, > thread_return=0xfffffffc) > at ../../../libraries/libldap_r/thr_posix.c:197 > No locals. > #3 0x080704d7 in slapd_daemon () > No symbol table info available. > #4 0x0805858e in main () > No symbol table info available. > > Thread 3 (process 29344): > #0 0x006487a2 in _dl_sysinfo_int80 () from /lib/ld-linux.so.2 > No symbol table info available. > #1 0x007372be in epoll_wait () from /lib/tls/libc.so.6 > No symbol table info available. > #2 0x0806f3fb in slapd_daemon_destroy () This trace is bogus, there's no call from slapd_daemon_destroy() to epoll_wait() in the code. And you wouldn't have gotten to slapd_daemon_destroy() unless you were shutting down. > No symbol table info available. > #3 0x001263cc in start_thread () from /lib/tls/libpthread.so.0 > No symbol table info available. > #4 0x00736c3e in clone () from /lib/tls/libc.so.6 > No symbol table info available. > > Thread 2 (process 29345): > #0 0x006487a2 in _dl_sysinfo_int80 () from /lib/ld-linux.so.2 > No symbol table info available. > #1 0x00128c26 in pthread_cond_wait@@GLIBC_2.3.2 () from > /lib/tls/libpthread.so.0 > No symbol table info available. > #2 0x008f8a2b in ldap_pvt_thread_cond_wait (cond=0xfffffffc, > mutex=0xfffffffc) > at ../../../libraries/libldap_r/thr_posix.c:277 > No locals. > #3 0x008f7d5a in ldap_int_thread_pool_wrapper (xpool=0x96eeb98) > at ../../../libraries/libldap_r/tpool.c:654 > task = (ldap_int_thread_task_t *) 0x0 > work_list = Variable "work_list" is not available. > > Thread 1 (process 29346): > #0 0x006d7860 in strncmp () from /lib/tls/libc.so.6 > No symbol table info available. > #1 0x0019085e in bdb_rdn_cmp (v_e1=0x17d7270, v_e2=0x9837d58) at > cache.c:301 > rc = 5 > #2 0x080fc1f5 in avl_find () > No symbol table info available. > #3 0x00190abd in hdb_cache_find_ndn (op=0x17d7460, txn=0x9837aa8, > ndn=0x17d73ec, res=0x17d7318) > at cache.c:433 > bdb = (struct bdb_info *) 0x97bf5d8 > ei = {bei_parent = 0x97bf624, bei_id = 0, bei_lockpad = 0, > bei_state = 0, > bei_finders = 0, bei_nrdn = {bv_len = 23, > bv_val = 0xffffffe9<Address 0xffffffe9 out of bounds>}, bei_rdn = > {bv_len = 0, > bv_val = 0x0}, bei_modrdns = 0, bei_ckids = 0, bei_dkids = 0, bei_e > = 0x0, > bei_kids = 0xb7f43994, bei_kids_mutex = {__m_reserved = 0, __m_count = > 0, __m_owner = 0x0, > __m_kind = 0, __m_lock = {__status = 0, __spinlock = 135208867}}, > bei_lrunext = 0x55313c, > bei_lruprev = 0x542022fc} > eip = (EntryInfo *) 0x97bf624 > ei2 = (EntryInfo *) 0x0 > rc = 0 > ptr = Variable "ptr" is not available. This is also bogus; is this an optimized compile? It's always hard to tell how much to trust the debugger here; if there are no further stack frames then possibly the stack was overwritten. But if you compiled with any type of optimization, and didn't use -fno-omit-frame-pointer, then that may be all that's happening here. -- -- 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#6043) slapd segfaults in bdb_rdn_cmp
by luca.scamoni＠sys-net.it 02 Apr '09

02 Apr '09

Howard Chu ha scritto: > Do you still have the data that caused this crash? Will it continue to > re-occur each time you restart a down server? (Can you continue to > reproduce the event...) I still have the data but the behaviour doesn't seem to be reproducible. It happened only on first run. After that we had to switch back to the old instance (it wasn't a real test, more an attempt to push it into production). I started slapd listening on another port after that and it didn't crash anymore (but it's also not receiving modifications). > > Please print *op and *eip as well. Also, what's in frame 4 or higher, > what function called hdb_cache_find_ndn(), does the stack trace stop > there or is there more? > (gdb) thread apply all bt full Thread 4 (process 29343): #0 0x006487a2 in _dl_sysinfo_int80 () from /lib/ld-linux.so.2 No symbol table info available. #1 0x001271d7 in pthread_join () from /lib/tls/libpthread.so.0 No symbol table info available. #2 0x008f8926 in ldap_pvt_thread_join (thread=4294967292, thread_return=0xfffffffc) at ../../../libraries/libldap_r/thr_posix.c:197 No locals. #3 0x080704d7 in slapd_daemon () No symbol table info available. #4 0x0805858e in main () No symbol table info available. Thread 3 (process 29344): #0 0x006487a2 in _dl_sysinfo_int80 () from /lib/ld-linux.so.2 No symbol table info available. #1 0x007372be in epoll_wait () from /lib/tls/libc.so.6 No symbol table info available. #2 0x0806f3fb in slapd_daemon_destroy () No symbol table info available. #3 0x001263cc in start_thread () from /lib/tls/libpthread.so.0 No symbol table info available. #4 0x00736c3e in clone () from /lib/tls/libc.so.6 No symbol table info available. Thread 2 (process 29345): #0 0x006487a2 in _dl_sysinfo_int80 () from /lib/ld-linux.so.2 No symbol table info available. #1 0x00128c26 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/tls/libpthread.so.0 No symbol table info available. #2 0x008f8a2b in ldap_pvt_thread_cond_wait (cond=0xfffffffc, mutex=0xfffffffc) at ../../../libraries/libldap_r/thr_posix.c:277 No locals. #3 0x008f7d5a in ldap_int_thread_pool_wrapper (xpool=0x96eeb98) at ../../../libraries/libldap_r/tpool.c:654 task = (ldap_int_thread_task_t *) 0x0 work_list = Variable "work_list" is not available. Thread 1 (process 29346): #0 0x006d7860 in strncmp () from /lib/tls/libc.so.6 No symbol table info available. #1 0x0019085e in bdb_rdn_cmp (v_e1=0x17d7270, v_e2=0x9837d58) at cache.c:301 rc = 5 #2 0x080fc1f5 in avl_find () No symbol table info available. #3 0x00190abd in hdb_cache_find_ndn (op=0x17d7460, txn=0x9837aa8, ndn=0x17d73ec, res=0x17d7318) at cache.c:433 bdb = (struct bdb_info *) 0x97bf5d8 ei = {bei_parent = 0x97bf624, bei_id = 0, bei_lockpad = 0, bei_state = 0, bei_finders = 0, bei_nrdn = {bv_len = 23, bv_val = 0xffffffe9 <Address 0xffffffe9 out of bounds>}, bei_rdn = {bv_len = 0, bv_val = 0x0}, bei_modrdns = 0, bei_ckids = 0, bei_dkids = 0, bei_e = 0x0, bei_kids = 0xb7f43994, bei_kids_mutex = {__m_reserved = 0, __m_count = 0, __m_owner = 0x0, __m_kind = 0, __m_lock = {__status = 0, __spinlock = 135208867}}, bei_lrunext = 0x55313c, bei_lruprev = 0x542022fc} eip = (EntryInfo *) 0x97bf624 ei2 = (EntryInfo *) 0x0 rc = 0 ptr = Variable "ptr" is not available. Nothing else... variables contents follow in a private mail... Ing. Luca Scamoni Responsabile Ricerca e Sviluppo SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ----------------------------------- Office: +39 0382 573859 (137) Mobile: +39 347 1014425 Fax: +39 0382 476497 Email: luca.scamoni(a)sys-net.it -----------------------------------

1 0

(ITS#6044) AnonCVS not working
by evaristojosec＠yahoo.es 02 Apr '09

02 Apr '09

Full_Name: Evaristo Camarero Version: Not relevant OS: Fedora Core 10 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (194.237.142.7) I am trying to access to the OpenLDAP repository but it is not possible doing it cvs -d :pserver:anonymous@cvs.OpenLDAP.org:/repo/OpenLDAP login Logging in to :pserver:anonymous@cvs.openldap.org:2401/repo/OpenLDAP CVS password: cvs [login aborted]: end of file from server (consult above messages if any) Checking with wireshark (old ethereal), I have checked that my cvs client is able to send the authentication request, but the openLDAP cvs server request the end of the TCP connection BEGIN VERIFICATION REQUEST /repo/OpenLDAP anonymous A#:d=*.9} END VERIFICATION REQUEST I have also checked that the same client is working fine with other CVS servers and I had no problem at all cvs -d :pserver:anonymous@cvs.fedoraproject.org:/cvs/pkgs login Logging in to :pserver:anonymous@cvs.fedoraproject.org:2401/cvs/pkgs CVS password:

1 0

Re: (ITS#6043) slapd segfaults in bdb_rdn_cmp
by hyc＠symas.com 02 Apr '09

02 Apr '09

luca(a)OpenLDAP.org wrote: > Full_Name: Luca Scamoni > Version: RELENG > OS: Linux > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (82.63.140.131) > > > Testing releng got this segfaults in a master-slave setup on both machines. Both > traces show the same: > > (gdb) bt full > #0 0x006d7860 in strncmp () from /lib/tls/libc.so.6 > No symbol table info available. > #1 0x0019085e in bdb_rdn_cmp (v_e1=0x17d7270, v_e2=0x9837d58) at cache.c:301 > rc = 5 > #2 0x080fc1f5 in avl_find () > No symbol table info available. > #3 0x00190abd in hdb_cache_find_ndn (op=0x17d7460, txn=0x9837aa8, > ndn=0x17d73ec, res=0x17d7318) at cache.c:433 > bdb = (struct bdb_info *) 0x97bf5d8 > ei = {bei_parent = 0x97bf624, bei_id = 0, bei_lockpad = 0, bei_state = > 0, bei_finders = 0, bei_nrdn = {bv_len = 23, > bv_val = 0xffffffe9<Address 0xffffffe9 out of bounds>}, bei_rdn = {bv_len = > 0, bv_val = 0x0}, bei_modrdns = 0, bei_ckids = 0, bei_dkids = 0, > bei_e = 0x0, bei_kids = 0xb7f43994, bei_kids_mutex = {__m_reserved = 0, > __m_count = 0, __m_owner = 0x0, __m_kind = 0, __m_lock = {__status = 0, > __spinlock = 135208867}}, bei_lrunext = 0x55313c, bei_lruprev = > 0x542022fc} > eip = (EntryInfo *) 0x97bf624 > ei2 = (EntryInfo *) 0x0 > rc = 0 > ptr = Variable "ptr" is not available. > > The core happened on master shortly after starting the slave, then on slave > shortly after staring the master again. > Using HDB and syncrepl (two databases per instance, different suffixes) > > I have access to the core(s) for any further information needed > > Do you still have the data that caused this crash? Will it continue to re-occur each time you restart a down server? (Can you continue to reproduce the event...) Please print *op and *eip as well. Also, what's in frame 4 or higher, what function called hdb_cache_find_ndn(), does the stack trace stop there or is there more? -- -- 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#6043) slapd segfaults in bdb_rdn_cmp
by luca＠OpenLDAP.org 02 Apr '09

02 Apr '09

Full_Name: Luca Scamoni Version: RELENG OS: Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (82.63.140.131) Testing releng got this segfaults in a master-slave setup on both machines. Both traces show the same: (gdb) bt full #0 0x006d7860 in strncmp () from /lib/tls/libc.so.6 No symbol table info available. #1 0x0019085e in bdb_rdn_cmp (v_e1=0x17d7270, v_e2=0x9837d58) at cache.c:301 rc = 5 #2 0x080fc1f5 in avl_find () No symbol table info available. #3 0x00190abd in hdb_cache_find_ndn (op=0x17d7460, txn=0x9837aa8, ndn=0x17d73ec, res=0x17d7318) at cache.c:433 bdb = (struct bdb_info *) 0x97bf5d8 ei = {bei_parent = 0x97bf624, bei_id = 0, bei_lockpad = 0, bei_state = 0, bei_finders = 0, bei_nrdn = {bv_len = 23, bv_val = 0xffffffe9 <Address 0xffffffe9 out of bounds>}, bei_rdn = {bv_len = 0, bv_val = 0x0}, bei_modrdns = 0, bei_ckids = 0, bei_dkids = 0, bei_e = 0x0, bei_kids = 0xb7f43994, bei_kids_mutex = {__m_reserved = 0, __m_count = 0, __m_owner = 0x0, __m_kind = 0, __m_lock = {__status = 0, __spinlock = 135208867}}, bei_lrunext = 0x55313c, bei_lruprev = 0x542022fc} eip = (EntryInfo *) 0x97bf624 ei2 = (EntryInfo *) 0x0 rc = 0 ptr = Variable "ptr" is not available. The core happened on master shortly after starting the slave, then on slave shortly after staring the master again. Using HDB and syncrepl (two databases per instance, different suffixes) I have access to the core(s) for any further information needed

1 0

Access to pseudoattribute "entry" and rewrite overlay
by Konovalov Andrey 01 Apr '09

01 Apr '09

Hi4All! :) I notice that active RWM/Remap overlay affects ACL-subsystem when ACL checks access to pseudoatribute "entry" and this strange situation occurs even if i not use any rules for rewrite/remap. Нerewith without the loaded overlay RWM all works correctly... In debug mode slapd with active RWM (no rewrite rules!) deny all access to attribute entry except for "root" user => access_allowed: search access to "uid=akkerman,cn=Directory Server Admins,ou=Groups,dc=r2,dc=money,dc=ge,dc=com" "objectClass" requested <= test_filter 5 => acl_get: [13] attr entry => slap_access_allowed: result not in cache (entry) => acl_mask: access to entry "uid=akkerman,cn=Directory Server Admins,ou=Groups,dc=r2,dc=money,dc=ge,dc=com", attr "entry" requested => acl_mask: to all values by "", (none(=0)) <= check a_dn_pat: * <= acl_mask: [1] applying none(=0) (stop) <= acl_mask: [1] mask: none(=0) => slap_access_allowed: read access denied by none(=0) This problem may be solved by adding radically liberate rule to the beginning of olcAccess sequence in cn=config: olcAccess: {1}to * attrs=entry by * read Is it a bug?

2 1

Re: (ITS#6042) Microsoft compatibility patch
by ghenry＠suretecsystems.com 01 Apr '09

01 Apr '09

----- hyc(a)OpenLDAP.org wrote: > Full_Name: Howard Chu > Version: HEAD > OS: Linux > URL: ftp://ftp.openldap.org/incoming/hyc-mscompat.txt > Submission from: (NULL) (76.91.220.157) > > > This patch adds a new olcMsCompat config keyword which enables > ActiveDirectory emulation mode in slapd. It's still experimental, any > feedback > is appreciated. Can we fast track this patch in, as we really need this feature to get more breakfix requests. Stock slapd never goes down enough! -- Kind Regards, Gavin Henry. Managing Director. T +44 (0) 1224 279484 M +44 (0) 7930 323266 F +44 (0) 1224 824887 E ghenry(a)suretecsystems.com Open Source. Open Solutions(tm). http://www.suretecsystems.com/ Suretec Systems is a limited company registered in Scotland. Registered number: SC258005. Registered office: 13 Whiteley Well Place, Inverurie, Aberdeenshire, AB51 4FP. Subject to disclaimer at http://www.suretecgroup.com/disclaimer.html

1 0

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs April 2009