openldap-bugs

openldap-bugs@openldap.org

1 participants
21003 discussions

Re: (ITS#7531) Syncrepl push delete operation does not recover when slave is unavailable
by hans.moser＠ofd-z.niedersachsen.de 14 Mar '13

14 Mar '13

Hi, jsynacek(a)redhat.com schrieb (27.02.2013 12:25 Uhr): > 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. I think we had situations like this before... How about having a test for this? What is the test which is nearest to this situation where a test could be based on? Marc

1 0

Re: (ITS#7538) mdb_add: txn_commit failed : MDB_PAGE_FULL: Internal error - page has no more space
by hyc＠symas.com 12 Mar '13

12 Mar '13

quanah(a)OpenLDAP.org wrote: > 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) > > > 2.4.34 + d74330128ac0c5b1ba3a06a199238f9780f685fd This bug was caused by the above patch for ITS#7536. Since it is now resolved, I'm closing this ITS, it should not have been tracked separately. > > Seeing the following when writing to MDB under load: > > Mar 11 10:49:57 zqa-376 slapd[22478]: mdb_add: txn_commit failed : > MDB_PAGE_FULL: Internal error - page has no more space (-30786) > > I do not see this error in a build of RE24 that has everything in 2.4.34 except > 1f7b6c1199ccb986a240871a8b54f5dc9041136d > > -- -- 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#7538) mdb_add: txn_commit failed : MDB_PAGE_FULL: Internal error - page has no more space
by quanah＠zimbra.com 11 Mar '13

11 Mar '13

--On Monday, March 11, 2013 6:02 PM +0000 quanah(a)OpenLDAP.org wrote: Another side effect -- DB entries are being created out of order, meaning slapcat dumps are not loadable via ldapadd. --Quanah -- Quanah Gibson-Mount Sr. Member of Technical Staff Zimbra, Inc A Division of VMware, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

(ITS#7539) Bug in JLDAP LDAPAttributeSchema.java code
by maleks＠gmail.com 11 Mar '13

11 Mar '13

Full_Name: Aleksandar M. Version: JLDAP OS: Windows 8 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (78.73.228.218) Hello, This is not a bug in OpenLDAP but in the Java client library, JLDAP. The LDAPAttributeSchema.java file is not parsing attributes correctly. The issue is in the method: public LDAPAttributeSchema(String raw) It doesn't set the usage and collective fields when using that method. The fix is to add the following code: this.usage = parser.getUsage(); this.collective = parser.getCollective(); I have added it and uploaded the changed file to the incoming directory. The file is named AleksandarM-LDAPAttributeSchema-20130311.java

1 0

(ITS#7538) mdb_add: txn_commit failed : MDB_PAGE_FULL: Internal error - page has no more space
by quanah＠OpenLDAP.org 11 Mar '13

11 Mar '13

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) 2.4.34 + d74330128ac0c5b1ba3a06a199238f9780f685fd Seeing the following when writing to MDB under load: Mar 11 10:49:57 zqa-376 slapd[22478]: mdb_add: txn_commit failed : MDB_PAGE_FULL: Internal error - page has no more space (-30786) I do not see this error in a build of RE24 that has everything in 2.4.34 except 1f7b6c1199ccb986a240871a8b54f5dc9041136d

1 0

Re: (ITS#7531) Syncrepl push delete operation does not recover when slave is unavailable
by jsynacek＠redhat.com 11 Mar '13

11 Mar '13

On 03/02/2013 02:59 AM, hyc(a)symas.com wrote: > 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. > I'm sorry that I didn't notice this before sending the patch. New URL: ftp://ftp.openldap.org/incoming/jsynacek-20130311-syncrepl-retry.patch -- Jan Synacek Software Engineer, Red Hat

1 0

Re: (ITS#7536) mdb assert when cleaning up accesslog
by hyc＠symas.com 06 Mar '13

06 Mar '13

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--

1 0

Re: (ITS#7536) mdb assert when cleaning up accesslog
by quanah＠zimbra.com 06 Mar '13

06 Mar '13

--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

1 0

Re: (ITS#7537) ppolicy hangs slapd on 64bit version debian
by michael＠stroeder.com 06 Mar '13

06 Mar '13

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.

1 0

Re: (ITS#7537) ppolicy hangs slapd on 64bit version debian
by hyc＠symas.com 06 Mar '13

06 Mar '13

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/

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