Re: (ITS#7536) mdb assert when cleaning up accesslog
by hyc＠symas.com
This is a multi-part message in MIME format.
--------------080809050807080004080107
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Fixed in the attached patch, please test.
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
--------------080809050807080004080107
Content-Type: text/x-patch;
name="0001-ITS-7536-fix-mdb_rebalance.patch"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
filename="0001-ITS-7536-fix-mdb_rebalance.patch"
>From aee706272c660e052c991fea82ce6269c605be1d Mon Sep 17 00:00:00 2001
From: Howard Chu <hyc(a)openldap.org>
Date: Wed, 6 Mar 2013 12:30:37 -0800
Subject: [PATCH] ITS#7536 fix mdb_rebalance
A page must always have at least 2 keys (unless it's a root page)
---
libraries/liblmdb/mdb.c | 7 ++++---
1 files changed, 4 insertions(+), 3 deletions(-)
diff --git a/libraries/liblmdb/mdb.c b/libraries/liblmdb/mdb.c
index 4d8bfa3..058c68b 100644
--- a/libraries/liblmdb/mdb.c
+++ b/libraries/liblmdb/mdb.c
@@ -6368,12 +6368,13 @@ mdb_rebalance(MDB_cursor *mc)
DPRINTF("found neighbor page %zu (%u keys, %.1f%% full)",
mn.mc_pg[mn.mc_top]->mp_pgno, NUMKEYS(mn.mc_pg[mn.mc_top]), (float)PAGEFILL(mc->mc_txn->mt_env, mn.mc_pg[mn.mc_top]) / 10);
- /* If the neighbor page is above threshold and has at least two
- * keys, move one key from it.
+ /* If the neighbor page is above threshold and has at least three
+ * keys, move one key from it. (A page must never have fewer than
+ * 2 keys.)
*
* Otherwise we should try to merge them.
*/
- if (PAGEFILL(mc->mc_txn->mt_env, mn.mc_pg[mn.mc_top]) >= FILL_THRESHOLD && NUMKEYS(mn.mc_pg[mn.mc_top]) >= 2)
+ if (PAGEFILL(mc->mc_txn->mt_env, mn.mc_pg[mn.mc_top]) >= FILL_THRESHOLD && NUMKEYS(mn.mc_pg[mn.mc_top]) > 2)
return mdb_node_move(&mn, mc);
else {
if (mc->mc_ki[ptop] == 0)
--
1.7.2.5
--------------080809050807080004080107--
8 years, 6 months
Re: (ITS#7536) mdb assert when cleaning up accesslog
by quanah＠zimbra.com
--On Wednesday, March 06, 2013 2:11 AM +0000 quanah(a)OpenLDAP.org wrote:
Thread 7 (Thread 0x7fd7f09c9700 (LWP 1927)):
#0 0x000000341dc0b3dc in pthread_cond_wait@@GLIBC_2.3.2 () from
/lib64/libpthread.so.0
No symbol table info available.
#1 0x00007ffff7daed7f in ldap_pvt_thread_cond_wait (cond=0x7d9fd0,
mutex=0x7d9fa8) at thr_posix.c:277
No locals.
#2 0x00007ffff7dad70b in ldap_int_thread_pool_wrapper (xpool=0x7d9fa0) at
tpool.c:675
pool = 0x7d9fa0
task = 0x0
work_list = 0x7da038
ctx = {ltu_id = 140565431490304, ltu_key = {{ltk_key = 0x4ad88b,
ltk_data = 0x7fd7d80008c0, ltk_free = 0x4ad6b0 <slap_sl_mem_destroy>},
{ltk_key = 0x0, ltk_data = 0x0,
ltk_free = 0} <repeats 28 times>, {ltk_key = 0x0, ltk_data =
0x0, ltk_free = 0x80}, {ltk_key = 0x0, ltk_data = 0x0, ltk_free = 0},
{ltk_key = 0x0, ltk_data = 0x0,
ltk_free = 0}}}
kctx = 0x0
i = 32
keyslot = 985
hash = 2179612633
__PRETTY_FUNCTION__ = "ldap_int_thread_pool_wrapper"
#3 0x000000341dc077f1 in start_thread () from /lib64/libpthread.so.0
No symbol table info available.
#4 0x000000341d8e570d in clone () from /lib64/libc.so.6
No symbol table info available.
Thread 6 (Thread 0x7fd7f11ca700 (LWP 1926)):
#0 0x000000341d832885 in raise () from /lib64/libc.so.6
No symbol table info available.
#1 0x000000341d834065 in abort () from /lib64/libc.so.6
No symbol table info available.
#2 0x000000341d82b9fe in __assert_fail_base () from /lib64/libc.so.6
No symbol table info available.
#3 0x000000341d82bac0 in __assert_fail () from /lib64/libc.so.6
No symbol table info available.
#4 0x00007ffff4317bfa in mdb_page_search_root (mc=0x7fd7e81023f8, key=0x0,
modify=0) at ./../../../libraries/liblmdb/mdb.c:4017
node = 0x7febf6dceff8
i = 0
mp = 0x7febf6dd2000
rc = 0
__PRETTY_FUNCTION__ = "mdb_page_search_root"
#5 0x00007ffff431813a in mdb_page_search (mc=0x7fd7e81023f8, key=0x0,
flags=0) at ./../../../libraries/liblmdb/mdb.c:4153
rc = 0
root = 14843
__PRETTY_FUNCTION__ = "mdb_page_search"
#6 0x00007ffff43196c5 in mdb_cursor_first (mc=0x7fd7e81023f8,
key=0x7fd7f11c8df0, data=0x0) at ./../../../libraries/liblmdb/mdb.c:4599
rc = 32727
leaf = 0x7ffff431749f
__PRETTY_FUNCTION__ = "mdb_cursor_first"
#7 0x00007ffff43194f5 in mdb_cursor_set (mc=0x7fd7e8102270,
key=0x7fd7f11c8e00, data=0x7fd7f11c8df0, op=MDB_SET, exactp=0x7fd7f11c8d80)
at ./../../../libraries/liblmdb/mdb.c:4552
rc = 0
mp = 0x7febf6dcc000
leaf = 0x7febf6dccf54
__PRETTY_FUNCTION__ = "mdb_cursor_set"
#8 0x00007ffff4319ec6 in mdb_cursor_get (mc=0x7fd7e8102270,
key=0x7fd7f11c8e00, data=0x7fd7f11c8df0, op=MDB_SET) at
./../../../libraries/liblmdb/mdb.c:4735
rc = 0
exact = 1
__PRETTY_FUNCTION__ = "mdb_cursor_get"
key = {mv_size = 8, mv_data = 0x7fd7f11c8e30}
data = {mv_size = 0, mv_data = 0x7fd7e8000df8}
subs = 140737290221723
nid = 1
ptr = 0x7febf6da0f0a ""
rc = 0
#10 0x00007ffff42f9754 in mdb_delete (op=0x7fd7f11c9480, rs=0x7fd7f11c9410)
at delete.c:335
mdb = 0x8d09c0
pdn = {bv_len = 12, bv_val = 0x7fd7e810347f "cn=accesslog"}
e = 0x7fd7e8000df8
p = 0x7fd7e80009b0
manageDSAit = 0
children = 0x7d56a0
entry = 0x7d5400
txn = 0x7fd7e82fd3b0
mc = 0x7fd7e8102270
opinfo = {moi_oe = {oe_next = {sle_next = 0x0}, oe_key = 0x8d09c0},
moi_txn = 0x7fd7e82fd3b0, moi_ref = 1, moi_flag = 0 '\000'}
moi = 0x7fd7f11c8f30
preread_ctrl = 0x0
ctrls = {0x0, 0x7fd7f11c933e, 0x7fd7e8000908, 0x7fd7f11c9341,
0x7fd7f11c933e, 0x100000001}
num_ctrls = 0
parent_is_glue = 0
parent_is_leaf = 0
__PRETTY_FUNCTION__ = "mdb_delete"
#11 0x00000000004cd715 in overlay_op_walk (op=0x7fd7f11c9480,
rs=0x7fd7f11c9410, which=op_delete, oi=0x8cf4f0, on=0x0) at backover.c:671
func = 0x7ffff452c258
rc = 32768
#12 0x00000000004cd92c in over_op_func (op=0x7fd7f11c9480,
rs=0x7fd7f11c9410, which=op_delete) at backover.c:723
oi = 0x8cf4f0
on = 0x8a8330
be = 0x8c2720
db = {bd_info = 0x7ffff452c200, bd_self = 0x8c2720, be_ctrls =
"\000\001\001\001\000\001\000\000\001\000\000\001\001\000\001\000\000\001",
'\000' <repeats 14 times>, "\001",
be_flags = 2312, be_restrictops = 0, be_requires = 0, be_ssf_set
= {sss_ssf = 0, sss_transport = 0, sss_tls = 0, sss_sasl = 0,
sss_update_ssf = 0, sss_update_transport = 0,
sss_update_tls = 0, sss_update_sasl = 0, sss_simple_bind = 0},
be_suffix = 0x8ce9c0, be_nsuffix = 0x8c4760, be_schemadn = {bv_len = 0,
bv_val = 0x0}, be_schemandn = {
bv_len = 0, bv_val = 0x0}, be_rootdn = {bv_len = 9, bv_val =
0x8bea90 "cn=config"}, be_rootndn = {bv_len = 9, bv_val = 0x8ce0d0
"cn=config"}, be_rootpw = {bv_len = 0,
bv_val = 0x0}, be_max_deref_depth = 15, be_def_limit =
{lms_t_soft = -1, lms_t_hard = 0, lms_s_soft = -1, lms_s_hard = 0,
lms_s_unchecked = -1, lms_s_pr = 0,
lms_s_pr_hide = 0, lms_s_pr_total = 0}, be_limits = 0x0, be_acl
= 0x8c4840, be_dfltaccess = ACL_READ, be_extra_anlist = 0x0, be_update_ndn
= {bv_len = 0, bv_val = 0x0},
be_update_refs = 0x0, be_pending_csn_list = 0xe1ef70,
be_pcl_mutex = {__data = {__lock = 0, __count = 0, __owner = 0, __nusers =
0, __kind = 0, __spins = 0, __list = {
__prev = 0x0, __next = 0x0}}, __size = '\000' <repeats 39
times>, __align = 0}, be_syncinfo = 0x0, be_pb = 0x0, be_cf_ocs =
0x7ffff452bf80, be_private = 0x8d09c0,
be_next = {stqe_next = 0x99fd90}}
cb = {sc_next = 0x7ffff3eb2fe0, sc_response = 0x4cc6f2
<over_back_response>, sc_cleanup = 0, sc_private = 0x8cf4f0}
sc = 0x7fd7f11c9414
rc = 32768
__PRETTY_FUNCTION__ = "over_op_func"
#13 0x00000000004cdae6 in over_op_delete (op=0x7fd7f11c9480,
rs=0x7fd7f11c9410) at backover.c:780
No locals.
#14 0x00007ffff3ca9bc6 in accesslog_purge (ctx=0x7fd7f11c9b60,
arg=0x8cb090) at accesslog.c:700
i = 0
rtask = 0x8cb090
li = 0x8a7f70
conn = {c_struct_state = SLAP_C_UNINITIALIZED, c_conn_state =
SLAP_C_INVALID, c_conn_idx = -1, c_sd = 0, c_close_reason = 0x0, c_mutex =
{__data = {__lock = 0, __count = 0,
__owner = 0, __nusers = 0, __kind = 0, __spins = 0, __list =
{__prev = 0x0, __next = 0x0}}, __size = '\000' <repeats 39 times>, __align
= 0}, c_sb = 0x0, c_starttime = 0,
c_activitytime = 0, c_connid = 18446744073709551615,
c_peer_domain = {bv_len = 0, bv_val = 0x4f1c90 ""}, c_peer_name = {bv_len =
0, bv_val = 0x4f1c90 ""}, c_listener = 0x4f9bc0,
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_write1_mutex = {
__data = {__lock = 0, __count = 0, __owner = 0, __nusers = 0,
__kind = 0, __spins = 0, __list = {__prev = 0x0, __next = 0x0}}, __size =
'\000' <repeats 39 times>,
__align = 0}, c_write1_cv = {__data = {__lock = 0, __futex = 0,
__total_seq = 0, __wakeup_seq = 0, __woken_seq = 0, __mutex = 0x0,
__nwaiters = 0, __broadcast_seq = 0},
__size = '\000' <repeats 47 times>, __align = 0},
c_write2_mutex = {__data = {__lock = 0, __count = 0, __owner = 0, __nusers
= 0, __kind = 0, __spins = 0, __list = {
__prev = 0x0, __next = 0x0}}, __size = '\000' <repeats 39
times>, __align = 0}, c_write2_cv = {__data = {__lock = 0, __futex = 0,
__total_seq = 0, __wakeup_seq = 0,
__woken_seq = 0, __mutex = 0x0, __nwaiters = 0,
__broadcast_seq = 0}, __size = '\000' <repeats 47 times>, __align = 0},
c_currentber = 0x0, c_writers = 0,
c_writing = 0 '\000', c_sasl_bind_in_progress = 0 '\000',
c_writewaiter = 0 '\000', c_is_tls = 0 '\000', c_needs_tls_accept = 0
'\000', c_sasl_layers = 0 '\000',
c_sasl_done = 0 '\000', c_sasl_authctx = 0x0, c_sasl_sockctx =
0x0, c_sasl_extra = 0x0, c_sasl_bindop = 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 = 0x45118c <slap_send_ldap_result>,
c_send_search_entry = 0x451e94 <slap_send_search_entry>,
c_send_search_reference = 0x453f44 <slap_send_search_reference>,
c_send_ldap_extended = 0x4519f3 <slap_send_ldap_extended>,
c_send_ldap_intermediate = 0x451c71 <slap_send_ldap_intermediate>}
opbuf = {ob_op = {o_hdr = 0x7fd7f11c95f0, o_tag = 74, o_time =
1362595264, o_tincr = 5, o_bd = 0x7fd7f11c90a0, o_req_dn = {bv_len = 44,
bv_val = 0x7fd7e8103420
"reqStart=20130227005207.000010Z,cn=accesslog"}, o_req_ndn = {bv_len = 43,
bv_val = 0x7fd7e8103460 "reqStart=20130227005207.00001Z,cn=accesslog"},
o_request = {oq_add = {rs_modlist = 0x1, rs_e =
0xffffffffffffffff}, oq_bind = {rb_method = 1, rb_cred = {bv_len =
18446744073709551615, bv_val = 0x0}, rb_edn = {bv_len = 1,
bv_val = 0x755cc0 "\003"}, rb_ssf = 4045181904, rb_mech =
{bv_len = 27, bv_val = 0x7fd7e8000908 "\200\220\034\361\327\177"}},
oq_compare = {rs_ava = 0x1}, oq_modify = {
rs_mods = {rs_modlist = 0x1, rs_no_opattrs = -1 '\377'},
rs_increment = 0}, oq_modrdn = {rs_mods = {rs_modlist = 0x1, rs_no_opattrs
= -1 '\377'}, rs_deleteoldrdn = 0,
rs_newrdn = {bv_len = 1, bv_val = 0x755cc0 "\003"},
rs_nnewrdn = {bv_len = 140565439878096, bv_val = 0x1b <Address 0x1b out of
bounds>}, rs_newSup = 0x7fd7e8000908,
rs_nnewSup = 0x0}, oq_search = {rs_scope = 1, rs_deref = 0,
rs_slimit = -1, rs_tlimit = -1, rs_limit = 0x0, rs_attrsonly = 1, rs_attrs
= 0x755cc0,
rs_filter = 0x7fd7f11c93d0, rs_filterstr = {bv_len = 27,
bv_val = 0x7fd7e8000908 "\200\220\034\361\327\177"}}, oq_abandon =
{rs_msgid = 1}, oq_cancel = {rs_msgid = 1},
oq_extended = {rs_reqoid = {bv_len = 1, bv_val =
0xffffffffffffffff <Address 0xffffffffffffffff out of bounds>}, rs_flags =
0, rs_reqdata = 0x1}, oq_pwdexop = {
rs_extended = {rs_reqoid = {bv_len = 1, bv_val =
0xffffffffffffffff <Address 0xffffffffffffffff out of bounds>}, rs_flags =
0, rs_reqdata = 0x1}, rs_old = {
bv_len = 7691456, bv_val = 0x7fd7f11c93d0 "\246"}, rs_new
= {bv_len = 27, bv_val = 0x7fd7e8000908 "\200\220\034\361\327\177"},
rs_mods = 0x0, rs_modtail = 0x0}},
o_abandon = 0, o_cancel = 0, o_groups = 0x0, o_do_not_cache = 0
'\000', o_is_auth_check = 0 '\000', o_dont_replicate = 1 '\001', o_acl_priv
= ACL_NONE, o_nocaching = 0 '\000',
o_delete_glue_parent = 0 '\000', o_no_schema_check = 0 '\000',
o_no_subordinate_glue = 0 '\000', o_ctrlflag = '\000' <repeats 31 times>,
o_controls = 0x7fd7f11c9738,
o_authz = {sai_method = 0, sai_mech = {bv_len = 0, bv_val =
0x0}, sai_dn = {bv_len = 9, bv_val = 0x8bea90 "cn=config"}, sai_ndn =
{bv_len = 9, bv_val = 0x8ce0d0 "cn=config"},
sai_ssf = 0, sai_transport_ssf = 0, sai_tls_ssf = 0,
sai_sasl_ssf = 0}, o_ber = 0x0, o_res_ber = 0x0, o_callback =
0x7fd7e8000908, o_ctrls = 0x0, o_csn = {bv_len = 40,
bv_val = 0x7fd7f11c9320
"20130228042415.556142Z#000000#001#000000"}, o_private = 0x0, o_extra =
{slh_first = 0x7fd7f11c8f30}, o_next = {stqe_next = 0x0}}, ob_hdr = {
oh_opid = 0, oh_connid = 18446744073709551615, oh_conn =
0x7fd7f11c9840, oh_msgid = 0, oh_protocol = 0, oh_tid = 140565439883008,
oh_threadctx = 0x7fd7f11c9b60,
oh_tmpmemctx = 0x7fd7e80008c0, oh_tmpmfuncs = 0x756280,
oh_counters = 0x7597c0, oh_log_prefix = "conn=-1 op=0", '\000' <repeats 243
times>}, ob_controls = {
0x0 <repeats 32 times>}}
op = 0x7fd7f11c9480
rs = {sr_type = REP_RESULT, sr_tag = 0, sr_msgid = 0, sr_err =
-30798, sr_matched = 0x0, sr_text = 0x0, sr_ref = 0x0, sr_ctrls = 0x0,
sr_un = {sru_search = {r_entry = 0x0,
r_attr_flags = 0, r_operational_attrs = 0x0, r_attrs = 0x0,
r_nentries = 0, r_v2ref = 0x0}, sru_sasl = {r_sasldata = 0x0}, sru_extended
= {r_rspoid = 0x0, r_rspdata = 0x0}},
sr_flags = 0}
cb = {sc_next = 0x0, sc_response = 0x7ffff3ca9570 <log_old_lookup>,
sc_cleanup = 0, sc_private = 0x7fd7f11c9380}
f = {f_choice = 166, f_un = {f_un_result = -249785424, f_un_desc =
0x7fd7f11c93b0, f_un_ava = 0x7fd7f11c93b0, f_un_ssa = 0x7fd7f11c93b0,
f_un_mra = 0x7fd7f11c93b0,
f_un_complex = 0x7fd7f11c93b0}, f_next = 0x0}
ava = {aa_desc = 0x82b4a0, aa_value = {bv_len = 15, bv_val =
0x7fd7f11c9360 "20130305184104Z"}}
pd = {slots = 18200, used = 18152, dn = 0x7fd7e837aed0, ndn =
0x7fd7e83c2060, csn = {bv_len = 40, bv_val = 0x7fd7f11c9320
"20130228042415.556142Z#000000#001#000000"}}
timebuf = "20130305184104Z\000\000\000\000\000\000"
csnbuf = "20130228042415.556142Z#000000#001#000000", '\000'
<repeats 23 times>
old = 1362508864
__PRETTY_FUNCTION__ = "accesslog_purge"
#15 0x00007ffff7dad7b2 in ldap_int_thread_pool_wrapper (xpool=0x7d9fa0) at
tpool.c:688
pool = 0x7d9fa0
task = 0x7fd7ec000a00
work_list = 0x7da038
ctx = {ltu_id = 140565439883008, ltu_key = {{ltk_key = 0x4ad88b,
ltk_data = 0x7fd7e80008c0, ltk_free = 0x4ad6b0 <slap_sl_mem_destroy>},
{ltk_key = 0x7ffff33d2010,
ltk_data = 0x7fd7e8100910, ltk_free = 0x7ffff430d65e
<mdb_reader_free>}, {ltk_key = 0x7ffff4302b9c, ltk_data = 0x7fd7e2cfe010,
ltk_free = 0x7ffff4302b79 <search_stack_free>}, {ltk_key =
0x7ffff42fff19, ltk_data = 0x7fd7e3cff010, ltk_free = 0x7ffff42ffed1
<scope_chunk_free>}, {ltk_key = 0x0,
ltk_data = 0x0, ltk_free = 0} <repeats 25 times>, {ltk_key =
0x0, ltk_data = 0x0, ltk_free = 0x80}, {ltk_key = 0x0, ltk_data = 0x0,
ltk_free = 0}, {ltk_key = 0x0,
ltk_data = 0x0, ltk_free = 0}}}
kctx = 0x0
i = 32
keyslot = 42
hash = 2079142954
__PRETTY_FUNCTION__ = "ldap_int_thread_pool_wrapper"
#16 0x000000341dc077f1 in start_thread () from /lib64/libpthread.so.0
No symbol table info available.
#17 0x000000341d8e570d in clone () from /lib64/libc.so.6
No symbol table info available.
Thread 5 (Thread 0x7fd7f19cb700 (LWP 1925)):
#0 0x000000341dc0b3dc in pthread_cond_wait@@GLIBC_2.3.2 () from
/lib64/libpthread.so.0
No symbol table info available.
#1 0x00007ffff7daed7f in ldap_pvt_thread_cond_wait (cond=0x7d9fd0,
mutex=0x7d9fa8) at thr_posix.c:277
No locals.
#2 0x00007ffff7dad70b in ldap_int_thread_pool_wrapper (xpool=0x7d9fa0) at
tpool.c:675
pool = 0x7d9fa0
task = 0x0
work_list = 0x7da038
ctx = {ltu_id = 140565448275712, ltu_key = {{ltk_key = 0x4ad88b,
ltk_data = 0x7fd7d40008c0, ltk_free = 0x4ad6b0 <slap_sl_mem_destroy>},
{ltk_key = 0x0, ltk_data = 0x0,
ltk_free = 0} <repeats 28 times>, {ltk_key = 0x0, ltk_data =
0x0, ltk_free = 0x80}, {ltk_key = 0x0, ltk_data = 0x0, ltk_free = 0},
{ltk_key = 0x0, ltk_data = 0x0,
ltk_free = 0}}}
kctx = 0x0
i = 32
keyslot = 954
hash = 553430970
__PRETTY_FUNCTION__ = "ldap_int_thread_pool_wrapper"
#3 0x000000341dc077f1 in start_thread () from /lib64/libpthread.so.0
No symbol table info available.
#4 0x000000341d8e570d in clone () from /lib64/libc.so.6
No symbol table info available.
Thread 4 (Thread 0x7fd7f21cc700 (LWP 1924)):
#0 0x000000341dc0b3dc in pthread_cond_wait@@GLIBC_2.3.2 () from
/lib64/libpthread.so.0
No symbol table info available.
#1 0x00007ffff7daed7f in ldap_pvt_thread_cond_wait (cond=0x7d9fd0,
mutex=0x7d9fa8) at thr_posix.c:277
No locals.
#2 0x00007ffff7dad70b in ldap_int_thread_pool_wrapper (xpool=0x7d9fa0) at
tpool.c:675
pool = 0x7d9fa0
task = 0x0
work_list = 0x7da038
ctx = {ltu_id = 140565456668416, ltu_key = {{ltk_key = 0x4ad88b,
ltk_data = 0x7fd7dc0008c0, ltk_free = 0x4ad6b0 <slap_sl_mem_destroy>},
{ltk_key = 0x7febf31d1010,
ltk_data = 0x7fd7dc101670, ltk_free = 0x7ffff430d65e
<mdb_reader_free>}, {ltk_key = 0x0, ltk_data = 0x0, ltk_free = 0} <repeats
27 times>, {ltk_key = 0x0, ltk_data = 0x0,
ltk_free = 0x80}, {ltk_key = 0x0, ltk_data = 0x0, ltk_free =
0}, {ltk_key = 0x0, ltk_data = 0x0, ltk_free = 0}}}
kctx = 0x0
i = 32
keyslot = 395
hash = 457840011
__PRETTY_FUNCTION__ = "ldap_int_thread_pool_wrapper"
#3 0x000000341dc077f1 in start_thread () from /lib64/libpthread.so.0
No symbol table info available.
#4 0x000000341d8e570d in clone () from /lib64/libc.so.6
No symbol table info available.
Thread 3 (Thread 0x7fd7f29cd700 (LWP 1923)):
#0 0x000000341dc0b3dc in pthread_cond_wait@@GLIBC_2.3.2 () from
/lib64/libpthread.so.0
No symbol table info available.
#1 0x00007ffff7daed7f in ldap_pvt_thread_cond_wait (cond=0x7d9fd0,
mutex=0x7d9fa8) at thr_posix.c:277
No locals.
#2 0x00007ffff7dad70b in ldap_int_thread_pool_wrapper (xpool=0x7d9fa0) at
tpool.c:675
pool = 0x7d9fa0
task = 0x0
work_list = 0x7da038
ctx = {ltu_id = 140565465061120, ltu_key = {{ltk_key = 0x4ad88b,
ltk_data = 0x7fd7e40008c0, ltk_free = 0x4ad6b0 <slap_sl_mem_destroy>},
{ltk_key = 0x7ffff33d2010,
ltk_data = 0x7fd7e4100910, ltk_free = 0x7ffff430d65e
<mdb_reader_free>}, {ltk_key = 0x7febf31d1010, ltk_data = 0x7fd7e410fa50,
ltk_free = 0x7ffff430d65e <mdb_reader_free>}, {
ltk_key = 0x7ffff4302b9c, ltk_data = 0x7fd7e17f6010, ltk_free
= 0x7ffff4302b79 <search_stack_free>}, {ltk_key = 0x7ffff42fff19, ltk_data
= 0x7fd7e27f7010,
ltk_free = 0x7ffff42ffed1 <scope_chunk_free>}, {ltk_key =
0x0, ltk_data = 0x0, ltk_free = 0} <repeats 24 times>, {ltk_key = 0x0,
ltk_data = 0x0, ltk_free = 0x80}, {
ltk_key = 0x0, ltk_data = 0x0, ltk_free = 0}, {ltk_key = 0x0,
ltk_data = 0x0, ltk_free = 0}}}
kctx = 0x0
i = 32
keyslot = 283
hash = 3227095323
__PRETTY_FUNCTION__ = "ldap_int_thread_pool_wrapper"
#3 0x000000341dc077f1 in start_thread () from /lib64/libpthread.so.0
No symbol table info available.
#4 0x000000341d8e570d in clone () from /lib64/libc.so.6
No symbol table info available.
Thread 2 (Thread 0x7fd7f31ce700 (LWP 1922)):
#0 0x000000341d8e5d03 in epoll_wait () from /lib64/libc.so.6
No symbol table info available.
#1 0x00000000004362dc in slapd_daemon_task (ptr=0x8cb050) at daemon.c:2542
ns = 1
at = 0
nfds = 3
revents = 0x7b0c90
tvp = 0x7fd7f31cdda0
cat = {tv_sec = 1362595564, tv_usec = 0}
i = 1
nwriters = 0
now = 1362595266
tv = {tv_sec = 298, tv_usec = 0}
tdelta = 1
rtask = 0x8b29b0
l = 1
last_idle_check = 1362595264
ebadf = 0
tid = 0
#2 0x000000341dc077f1 in start_thread () from /lib64/libpthread.so.0
No symbol table info available.
#3 0x000000341d8e570d in clone () from /lib64/libc.so.6
No symbol table info available.
Thread 1 (Thread 0x7ffff7117700 (LWP 1919)):
#0 0x000000341dc0804d in pthread_join () from /lib64/libpthread.so.0
No symbol table info available.
#1 0x00007ffff7daecc0 in ldap_pvt_thread_join (thread=140565473453824,
thread_return=0x0) at thr_posix.c:197
No locals.
#2 0x0000000000437437 in slapd_daemon () at daemon.c:2935
i = 0
rc = 0
#3 0x00000000004149eb in main (argc=9, argv=0x7fffffffe498) at main.c:1012
i = 9
no_detach = 1
rc = 0
urls = 0x7aa090 "ldapi:///"
username = 0x7aa0b0 "root"
groupname = 0x0
sandbox = 0x0
syslogUser = 160
pid = 501312480
waitfds = {0, 0}
g_argc = 9
g_argv = 0x7fffffffe498
configfile = 0x0
configdir = 0x7aa0d0 "/opt/zimbra/data/ldap/config"
serverName = 0x7fffffffe759 "slapd"
serverMode = 1
scp = 0x0
scp_entry = 0x0
debug_unknowns = 0x0
syslog_unknowns = 0x0
serverNamePrefix = 0x4f1728 ""
l = 5181968
slapd_pid_file_unlink = 1
slapd_args_file_unlink = 1
firstopt = 0
__PRETTY_FUNCTION__ = "main"
--
Quanah Gibson-Mount
Sr. Member of Technical Staff
Zimbra, Inc
A Division of VMware, Inc.
--------------------
Zimbra :: the leader in open source messaging and collaboration
8 years, 6 months
Re: (ITS#7537) ppolicy hangs slapd on 64bit version debian
by michael＠stroeder.com
On Wed, 6 Mar 2013 10:11:53 GMT hyc(a)symas.com wrote
> marek.platta(a)blstream.com wrote:
> > Full_Name: Marek Platta
> > Version: 2.4.23-7.2
> > OS: Debian6
> > URL: ldap.zumbai.pl
> > Submission from: (NULL) (83.168.110.42)
>
> 2.4.23 is quite old, plus yours has been patched by Debian so we don't know
> what it contains. You will have to get support from Debian. If you can
> reproduce the issue on our current release (2.4.34) then we will investigate
> it.
To add:
I tried that with our own build of OpenLDAP 2.4.34 on Debian Squeeze
2.6.32-5-amd64 and I can't reproduce the lockup.
Ciao, Michael.
8 years, 6 months
Re: (ITS#7537) ppolicy hangs slapd on 64bit version debian
by hyc＠symas.com
marek.platta(a)blstream.com wrote:
> Full_Name: Marek Platta
> Version: 2.4.23-7.2
> OS: Debian6
> URL: ldap.zumbai.pl
> Submission from: (NULL) (83.168.110.42)
>
>
> Hi!,
2.4.23 is quite old, plus yours has been patched by Debian so we don't know
what it contains. You will have to get support from Debian. If you can
reproduce the issue on our current release (2.4.34) then we will investigate it.
> I got problem implementing ppolicy on slapd 64bit version
>
> Tested on
> debian6 2.6.32-5-xen-amd64 with slapd 2.4.23-7.2
>
> debian6 2.6.32-5-amd64 with slapd 2.4.23-7.2
>
> and
>
> debian7 3.2.0-4-amd64 with slapd 2.4.31-1
>
>
> Problem occours when i try to change parameters of ppolicy (using phpldapadmin,
> luma, etc.) for example:
>
> pwdMaxFailure: 6 to 5
>
> Slapd process hangs and you can only stop it by "kill -9"
>
>
> On Debian 32bit works fine
>
>
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
8 years, 6 months
(ITS#7537) ppolicy hangs slapd on 64bit version debian
by marek.platta＠blstream.com
Full_Name: Marek Platta
Version: 2.4.23-7.2
OS: Debian6
URL: ldap.zumbai.pl
Submission from: (NULL) (83.168.110.42)
Hi!,
I got problem implementing ppolicy on slapd 64bit version
Tested on
debian6 2.6.32-5-xen-amd64 with slapd 2.4.23-7.2
debian6 2.6.32-5-amd64 with slapd 2.4.23-7.2
and
debian7 3.2.0-4-amd64 with slapd 2.4.31-1
Problem occours when i try to change parameters of ppolicy (using phpldapadmin,
luma, etc.) for example:
pwdMaxFailure: 6 to 5
Slapd process hangs and you can only stop it by "kill -9"
On Debian 32bit works fine
8 years, 6 months
(ITS#7536) mdb assert when cleaning up accesslog
by quanah＠OpenLDAP.org
Full_Name: Quanah Gibson-Mount
Version: 2.4.34
OS: Linux 2.6
URL: ftp://ftp.openldap.org/incoming/
Submission from: (NULL) (74.196.25.250)
When deleting entries from the accesslog, slapd dies after hitting an assert:
5136a59f => access_allowed: delete access to "cn=accesslog" "children"
requested
5136a59f <= root access granted
5136a59f => access_allowed: delete access granted by manage(=mwrscxd)
5136a59f => access_allowed: delete access to
"reqStart=20130227005207.000010Z,cn=accesslog" "entry" requested
5136a59f <= root access granted
5136a59f => access_allowed: delete access granted by manage(=mwrscxd)
5136a59f => mdb_dn2id_delete 0x5bd1e
slapd: ./../../../libraries/liblmdb/mdb.c:4017: mdb_page_search_root: Assertion
`(((mp)->mp_pb.pb.pb_lower - ((unsigned) __builtin_offsetof (MDB_page,
mp_ptrs))) >> 1) > 1' failed.
8 years, 6 months
Re: (ITS#7531) Syncrepl push delete operation does not recover when slave is unavailable
by hyc＠symas.com
jsynacek(a)redhat.com wrote:
> On 02/27/2013 02:48 PM, jsynacek(a)redhat.com wrote:
>> On 02/27/2013 12:25 PM, jsynacek(a)redhat.com wrote:
>>> Full_Name: Jan Synacek
>>> Version: RE24 (7b03a58)
>>> OS: Linux - Fedora 18
>>> URL: ftp://ftp.openldap.org/incoming/jsynacek-reproducer.tar.gz
>>> Submission from: (NULL) (209.132.186.34)
>>>
>>>
>>> The setup is a master with an ldap backend and a slave consumer. If the master
>>> is running and slave is not, delete operation results in the master being
>>> stuck.
>>>
>>> Steps to reproduce:
>>> 1. Start master.
>>> 2. Add the example ldif.
>>> 3. Delete one of the test org units.
>>> 4. Observe the error.
>>>
>>> I would expect the master to honor the retry setting.
>>>
>>
>> During the reproduction, it may be necessary to first have both master and slave
>> running, delete a testing test org unit (so the first replication is
>> successful), stop the slave and then continue to step 3.
>>
>
> URL:
> ftp://ftp.openldap.org/incoming/jsynacek-20130103-syncrepl-retry.patch
This patch is clearly unacceptable. Your goto obviously skips over two _free()
invocations, thus introducing a memory leak.
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
8 years, 6 months
Re: (ITS#7535) MDB_PREV on a cursor which was at EOF
by hyc＠symas.com
claude(a)renegat.net wrote:
> Full_Name: Claude Brisson
> Version: 2.4.33
> OS: debian
> URL:
> Submission from: (NULL) (86.76.238.166)
>
>
> When calling mdb_cursor_get with operation MDB_PREV on a cursor which was at
> EOF, the last key is fetched as expected, but the cursor state is left
> uninitialized.
>
> It looks like there is a missing "mc->mc_flags |= C_INITIALIZED" somewhere in
> this case.
This was fixed in git rev 5c1ee7f7ba9580d5ff29e74cbb02eee335c33d94 2012-10-22.
The fix will be in 2.4.34.
Bug reports should only be reported against latest source.
Closing this ITS.
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
8 years, 6 months
Re: (ITS#7531) Syncrepl push delete operation does not recover when slave is unavailable
by jsynacek＠redhat.com
On 02/27/2013 02:48 PM, jsynacek(a)redhat.com wrote:
> On 02/27/2013 12:25 PM, jsynacek(a)redhat.com wrote:
>> Full_Name: Jan Synacek
>> Version: RE24 (7b03a58)
>> OS: Linux - Fedora 18
>> URL: ftp://ftp.openldap.org/incoming/jsynacek-reproducer.tar.gz
>> Submission from: (NULL) (209.132.186.34)
>>
>>
>> The setup is a master with an ldap backend and a slave consumer. If the master
>> is running and slave is not, delete operation results in the master being
>> stuck.
>>
>> Steps to reproduce:
>> 1. Start master.
>> 2. Add the example ldif.
>> 3. Delete one of the test org units.
>> 4. Observe the error.
>>
>> I would expect the master to honor the retry setting.
>>
>
> During the reproduction, it may be necessary to first have both master and slave
> running, delete a testing test org unit (so the first replication is
> successful), stop the slave and then continue to step 3.
>
URL:
ftp://ftp.openldap.org/incoming/jsynacek-20130103-syncrepl-retry.patch
The attached file is derived from OpenLDAP Software. All of the modifications
to
OpenLDAP Software represented in the following patch(es) were developed by Red
Hat. Red Hat has not assigned rights and/or interest in this work to any party.
I, Jan Synacek am authorized by Red Hat, my employer, to release this work
under the following terms.
Red Hat hereby place the following modifications to OpenLDAP Software (and only
these modifications) into the public domain. Hence, these modifications may be
freely used and/or redistributed for any purpose with or without attribution
and/or other notice.
--
Jan Synacek
Software Engineer, BaseOS team Brno, Red Hat
8 years, 6 months
(ITS#7535) MDB_PREV on a cursor which was at EOF
by claude＠renegat.net
Full_Name: Claude Brisson
Version: 2.4.33
OS: debian
URL:
Submission from: (NULL) (86.76.238.166)
When calling mdb_cursor_get with operation MDB_PREV on a cursor which was at
EOF, the last key is fetched as expected, but the cursor state is left
uninitialized.
It looks like there is a missing "mc->mc_flags |= C_INITIALIZED" somewhere in
this case.
8 years, 6 months
