openldap-bugs April 2012

openldap-bugs@openldap.org

36 participants
172 discussions

Re: (ITS#7222) Slapd hangs on high load
by hrvoje.habjanic＠zg.t-com.hr 04 Apr '12

04 Apr '12

On 03.04.2012 17:41, Howard Chu wrote: >> >> So, am i doing something wrong or openldap is...? > > > Looks like your glibc malloc is deadlocked. A Centos bug, not an > OpenLDAP bug. > > In the trace, you could confirm this in gdb with: > thread 13 > frame 3 > print *mutex > > most likely the "owner" field of this mutex will be 1502, which > corresponds to thread 17, which is waiting for a lock inside libc > malloc/free. > > You may be able to avoid this bug by using an alternate malloc > library, such as Google tcmalloc. > Hi. Thanx for inside info ... :-) And sorry that i was unable to provide more info - core dump alone is 16gb! Also, small sidenote - when this "hang" happens, it only affects existing connections - i'm attacking it with two procesess, each 4 connection. New searches using ldapsearch work fine ... And correction for typo - by "high load" i wrote (1-2 req/sec) - actually it should write 1-2k reg/sec ... What is interesting regarding this, that this "problem" goes back to db-4.7 and openldap-2.4.23 (provided with centos) ... I'll try alternate malloc and report back ... H.

1 0

Re: (ITS#7224) Core dump while trying to run slapd
by masarati＠aero.polimi.it 04 Apr '12

04 Apr '12

On 04/04/2012 02:39 AM, ashish(a)sendmail.com wrote: > Full_Name: Ashish Gawarikar > Version: 2.4.30 > OS: Redhat 5.8 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (108.80.56.188) > > > I got a core dump while trying to run slapd: > > This is the stack trace of the core: > > (gdb) where > #0 oc_delete_names (oc=0xeaa6080) at oc.c:403 > #1 0x0000000000461aa7 in oc_destroy () at oc.c:470 > #2 0x000000000045128e in schema_destroy () at schema_init.c:6846 > #3 0x00000000004050bf in main (argc=<value optimized out>, argv=0x7fff1b533918) > at main.c:1068 > > > A similar stack trace was produced while trying to do slapadd: > > #0 oc_delete_names (oc=0x171e86f0) at oc.c:403 > #1 0x0000000000461aa7 in oc_destroy () at oc.c:470 > #2 0x000000000045128e in schema_destroy () at schema_init.c:6846 > #3 0x0000000000486ecd in slap_tool_destroy () at slapcommon.c:942 > #4 0x0000000000485f73 in slapadd (argc=<value optimized out>, argv=<value > optimized out>) at slapadd.c:493 > #5 0x0000000000404f32 in main (argc=3, argv=0x7fffa4770db8) at main.c:410 > > > These are the configuration params: > --enable-accesslog --enable-auditlog --enable-collect --enable-constraint > --enable-dyngroup --enable-dynlist --enable-hdb --enable-memberof > --enable-ppolicy --enable-refint --enable-relay --enable-retcode --enable-rwm > --enable-seqmod --enable-translucent --enable-unique --enable-valsort > --enable-slapd --disable-mdb --enable-bdb --enable-proctitle --enable-ldap > --enable-meta --enable-rewrite --enable-monitor --enable-aci --enable-cleartext > --enable-crypt --enable-debug --enable-local --enable-lmpasswd > --enable-proxycache --with-threads --enable-static --disable-shared > --enable-local --enable-syslog --localstatedir=/var --sysconfdir=/etc/mail > --enable-ipv6 --with-cyrus-sasl --enable-spasswd --with-tls > > > Please let me know if you need more information. Con you provide: p oc p *oc p names p *names Thanks, p. -- Pierangelo Masarati Associate Professor Dipartimento di Ingegneria Aerospaziale Politecnico di Milano

1 0

(ITS#7224) Core dump while trying to run slapd
by ashish＠sendmail.com 03 Apr '12

03 Apr '12

Full_Name: Ashish Gawarikar Version: 2.4.30 OS: Redhat 5.8 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (108.80.56.188) I got a core dump while trying to run slapd: This is the stack trace of the core: (gdb) where #0 oc_delete_names (oc=0xeaa6080) at oc.c:403 #1 0x0000000000461aa7 in oc_destroy () at oc.c:470 #2 0x000000000045128e in schema_destroy () at schema_init.c:6846 #3 0x00000000004050bf in main (argc=<value optimized out>, argv=0x7fff1b533918) at main.c:1068 A similar stack trace was produced while trying to do slapadd: #0 oc_delete_names (oc=0x171e86f0) at oc.c:403 #1 0x0000000000461aa7 in oc_destroy () at oc.c:470 #2 0x000000000045128e in schema_destroy () at schema_init.c:6846 #3 0x0000000000486ecd in slap_tool_destroy () at slapcommon.c:942 #4 0x0000000000485f73 in slapadd (argc=<value optimized out>, argv=<value optimized out>) at slapadd.c:493 #5 0x0000000000404f32 in main (argc=3, argv=0x7fffa4770db8) at main.c:410 These are the configuration params: --enable-accesslog --enable-auditlog --enable-collect --enable-constraint --enable-dyngroup --enable-dynlist --enable-hdb --enable-memberof --enable-ppolicy --enable-refint --enable-relay --enable-retcode --enable-rwm --enable-seqmod --enable-translucent --enable-unique --enable-valsort --enable-slapd --disable-mdb --enable-bdb --enable-proctitle --enable-ldap --enable-meta --enable-rewrite --enable-monitor --enable-aci --enable-cleartext --enable-crypt --enable-debug --enable-local --enable-lmpasswd --enable-proxycache --with-threads --enable-static --disable-shared --enable-local --enable-syslog --localstatedir=/var --sysconfdir=/etc/mail --enable-ipv6 --with-cyrus-sasl --enable-spasswd --with-tls Please let me know if you need more information.

1 0

Re: (ITS#7219) back-mdb crash when used as accesslog
by quanah＠zimbra.com 03 Apr '12

03 Apr '12

--On Friday, March 30, 2012 11:37 PM +0000 quanah(a)OpenLDAP.org wrote: How to reproduce: What I do is run the add/del of 50k entries used in ITS#7210 5-6 times to > get a reasonably sized accesslog. Initially, I have the log purge set to > run once a day, deleting anything a week old (so nothing gets deleted). > > Then I change the logpurge to "00+00:10 00+00:05". > > After this, slapd dies from hitting the assert. -- 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#7223) back-mdb: accesslog segv on second cleanup run
by quanah＠OpenLDAP.org 03 Apr '12

03 Apr '12

Full_Name: Quanah Gibson-Mount Version: RE24 4/1/2012 OS: Linux 2.6 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (75.108.184.39) If you have an accesslog setup using back-mdb, it will segv in the following condition: Do a bunch of modifications, and then set up accesslog to clean them out periodically. In my test, I had it so that the accesslog DB was cleaned every 5 minutes, of any entries > 10 minutes old. Initially I had it set to clean up everything > 1 week old, running once a day, so I could gather data in the accesslog DB without triggering the purge. The first cleanup ran @ 5 minutes, and removed all entries from the accesslog DB, as they were all older than 10 minutes. The second run, with the now empty DB, triggered a SEGV: Program terminated with signal 11, Segmentation fault. #0 0x00007f38dfeb17b0 in mdb_page_alloc (mc=0xd3d8a80, num=1) at ./../../../libraries/libmdb/mdb.c:1317 1317 ./../../../libraries/libmdb/mdb.c: No such file or directory. in ./../../../libraries/libmdb/mdb.c #0 0x00007f38dfeb17b0 in mdb_page_alloc (mc=0xd3d8a80, num=1) at ./../../../libraries/libmdb/mdb.c:1317 txn = 0xd3ce000 np = 0x323d747261745371 pgno = 69385 mid = {mid = 139710414625424, mptr = 0x7f38dfeb5cdf} #1 0x00007f38dfeb18c6 in mdb_page_touch (mc=0xd3d8a80) at ./../../../libraries/libmdb/mdb.c:1349 np = 0xd3f2000 mp = 0x7f24f0114000 pgno = 69525 __PRETTY_FUNCTION__ = "mdb_page_touch" #2 0x00007f38dfeb7bc7 in mdb_cursor_touch (mc=0xd3d8a80) at ./../../../libraries/libmdb/mdb.c:4116 rc = 0 #3 0x00007f38dfeb93dd in mdb_cursor_del (mc=0xd3d8a80, flags=0) at ./../../../libraries/libmdb/mdb.c:4486 leaf = 0x0 rc = 0 #4 0x00007f38dfeaec65 in mdb_idl_delete_keys (cursor=0xd3d8a80, keys=0x3782c08, id=64) at idl.c:597 rc = 0 k = 0 key = {mv_size = 5, mv_data = 0x3782c30} data = {mv_size = 8, mv_data = 0x7f24f012c068} lo = 5 hi = 139706696817899 tmp = 40 i = 0x7f24f012c010 err = 0x7f38dfec37f4 "c_get" __PRETTY_FUNCTION__ = "mdb_idl_delete_keys" #5 0x00007f38dfea4faf in indexer (op=0x7f10dda2a440, txn=0xd3ce000, ai=0x12172c0, ad=0x11b87c0, atname=0x11e9028, vals=0x3782b48, id=64, opid=2, mask=4) at index.c:219 rc = 0 i = 26075136 keys = 0x3782c08 mc = 0xd3d8a80 keyfunc = 0x7f38dfeaea37 <mdb_idl_delete_keys> err = 0x7f38dfec27ea "c_open" __PRETTY_FUNCTION__ = "indexer" #6 0x00007f38dfea5363 in index_at_values (op=0x7f10dda2a440, txn=0xd3ce000, ad=0x11b87c0, type=0x11e8fc0, tags=0x11b87e0, vals=0x3782b48, id=64, opid=2) at index.c:337 rc = 0 mask = 4 ixop = 2 ai = 0x12172c0 #7 0x00007f38dfea54e7 in mdb_index_values (op=0x7f10dda2a440, txn=0xd3ce000, desc=0x11b87c0, vals=0x3782b48, id=64, opid=2) at index.c:386 rc = 0 #8 0x00007f38dfea59af in mdb_index_entry (op=0x7f10dda2a440, txn=0xd3ce000, opid=2, e=0x37823c8) at index.c:558 rc = 0 ap = 0x3782620 #9 0x00007f38dfe994ae in mdb_delete (op=0x7f10dda2a440, rs=0x7f10dda2a2b0) at delete.c:348 mdb = 0x18de000 pdn = {bv_len = 12, bv_val = 0xd5bec20 "cn=accesslog"} e = 0x37823c8 p = 0x3782158 manageDSAit = 0 children = 0x11b8ec0 entry = 0x11b8f00 txn = 0xd3ce000 mc = 0xd3d8a80 opinfo = {moi_oe = {oe_next = {sle_next = 0x0}, oe_key = 0x18de000}, moi_txn = 0xd3ce000, moi_ref = 1, moi_flag = 0 '\000'} moi = 0x7f10dda29ed0 preread_ctrl = 0x0 ctrls = {0x0, 0xfffffffffffffff9, 0x7f10dda29f10, 0x0, 0x0, 0x4} num_ctrls = 0 parent_is_glue = 0 parent_is_leaf = 0 __PRETTY_FUNCTION__ = "mdb_delete" #10 0x00000000004d4a48 in overlay_op_walk (op=0x7f10dda2a440, rs=0x7f10dda2a2b0, which=op_delete, oi=0x166d680, on=0x0) at backover.c:671 func = 0x7f38e00c7d18 rc = 32768 #11 0x00000000004d4c86 in over_op_func (op=0x7f10dda2a440, rs=0x7f10dda2a2b0, which=op_delete) at backover.c:723 oi = 0x166d680 on = 0x1706f00 be = 0x11ee9c0 db = {bd_info = 0x7f38e00c7cc0, bd_self = 0x11ee9c0, 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 = 0x1687840, be_nsuffix = 0x1687820, be_schemadn = {bv_len = 0, bv_val = 0x0}, be_schemandn = { bv_len = 0, bv_val = 0x0}, be_rootdn = {bv_len = 9, bv_val = 0x16766d0 "cn=config"}, be_rootndn = {bv_len = 9, bv_val = 0x16766b0 "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 = 0x16a0e00, 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 = 0x14bf900, 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 = 0x7f38e00c7ac0, be_private = 0x18de000, be_next = {stqe_next = 0x11ef6c0}} cb = {sc_next = 0x7f38dfa51c60, sc_response = 0x4d3780 <over_back_response>, sc_cleanup = 0, sc_private = 0x166d680} sc = 0x7f10dda2a578 rc = 32768 __PRETTY_FUNCTION__ = "over_op_func" #12 0x00000000004d4e6f in over_op_delete (op=0x7f10dda2a440, rs=0x7f10dda2a2b0) at backover.c:780 No locals. #13 0x00007f38df847f61 in accesslog_purge (ctx=0x7f10dda2ab50, arg=0x1298000) at accesslog.c:689 i = 62 rtask = 0x1298000 li = 0x17ea090 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 = 0x4f9d90 ""}, c_peer_name = {bv_len = 0, bv_val = 0x4f9d90 ""}, c_listener = 0x501ca0, 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 = 0x454a15 <slap_send_ldap_result>, c_send_search_entry = 0x45571d <slap_send_search_entry>, c_send_search_reference = 0x457c43 <slap_send_search_reference>, c_send_ldap_extended = 0x45527c <slap_send_ldap_extended>, c_send_ldap_intermediate = 0x4554fa <slap_send_ldap_intermediate>} opbuf = {ob_op = {o_hdr = 0x7f10dda2a5b0, o_tag = 74, o_time = 1333399445, o_tincr = 0, o_bd = 0x7f10dda2a0c0, o_req_dn = {bv_len = 44, bv_val = 0xd5bec30 "reqStart=20120402202935.000125Z,cn=accesslog"}, o_req_ndn = {bv_len = 44, bv_val = 0xd5bec00 "reqStart=20120402202935.000125Z,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 = 0x75cd60 "\003"}, rb_ssf = 3718423536, rb_mech = {bv_len = 27, bv_val = 0x3780008 "p\240\242\335\020\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 = 0x75cd60 "\003"}, rs_nnewrdn = {bv_len = 139710414627824, bv_val = 0x1b <Address 0x1b out of bounds>}, rs_newSup = 0x3780008, 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 = 0x75cd60, rs_filter = 0x7f10dda2a3f0, rs_filterstr = {bv_len = 27, bv_val = 0x3780008 "p\240\242\335\020\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 = 7720288, bv_val = 0x7f10dda2a3f0 "\246"}, rs_new = {bv_len = 27, bv_val = 0x3780008 "p\240\242\335\020\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 = 0x7f10dda2a6f8, o_authz = {sai_method = 0, sai_mech = {bv_len = 0, bv_val = 0x0}, sai_dn = {bv_len = 9, bv_val = 0x16766d0 "cn=config"}, sai_ndn = {bv_len = 9, bv_val = 0x16766b0 "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 = 0x37820b0, o_ctrls = 0x0, o_csn = {bv_len = 40, bv_val = 0x7f10dda2aac0 "20120402203319.698132Z#000000#000#000000\v\336C"}, o_private = 0x0, o_extra = {slh_first = 0x7f10dda29ed0}, o_next = {stqe_next = 0x0}}, ob_hdr = {oh_opid = 0, oh_connid = 18446744073709551615, oh_conn = 0x7f10dda2a800, oh_msgid = 0, oh_protocol = 0, oh_tid = 139710414632704, oh_threadctx = 0x7f10dda2ab50, oh_tmpmemctx = 0x1651a00, oh_tmpmfuncs = 0x75d320, oh_counters = 0x7607a0, oh_log_prefix = "conn=-1 op=0", '\000' <repeats 243 times>}, ob_controls = {0x0 <repeats 32 times>}} op = 0x7f10dda2a440 rs = {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_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 = 0x7f38df84787e <log_old_lookup>, sc_cleanup = 0, sc_private = 0x7f10dda2a360} f = {f_choice = 166, f_un = {f_un_result = -576543792, f_un_desc = 0x7f10dda2a3d0, f_un_ava = 0x7f10dda2a3d0, f_un_ssa = 0x7f10dda2a3d0, f_un_mra = 0x7f10dda2a3d0, f_un_complex = 0x7f10dda2a3d0}, f_next = 0x0} ava = {aa_desc = 0x1251240, aa_value = {bv_len = 15, bv_val = 0x7f10dda2ab00 "20120402203405Z"}} pd = {slots = 100000, used = 100000, dn = 0xe3b8000, ndn = 0xe588000, csn = {bv_len = 40, bv_val = 0x7f10dda2aac0 "20120402203319.698132Z#000000#000#000000\v\336C"}} timebuf = "20120402203405Z\000\241\210\001\000\000" csnbuf = "20120402203319.698132Z#000000#000#000000\v\336C\000\000\000\000\000\366\250\322\343\070\177\000\000\000\000\000\000\002\000\000" old = 1333398845 __PRETTY_FUNCTION__ = "accesslog_purge" #14 0x00007f38e51e9cc9 in ldap_int_thread_pool_wrapper (xpool=0x11d21c0) at tpool.c:688 pool = 0x11d21c0 task = 0x14ca440 work_list = 0x11d2258 ctx = {ltu_id = 139710414632704, ltu_key = {{ltk_key = 0x4b380b, ltk_data = 0x1651a00, ltk_free = 0x4b3630 <slap_sl_mem_destroy>}, {ltk_key = 0x317c000, ltk_data = 0x14cc000, ltk_free = 0x7f38dfeac523 <mdb_reader_free>}, {ltk_key = 0x347e000, ltk_data = 0x14cf400, ltk_free = 0x7f38dfeac523 <mdb_reader_free>}, {ltk_key = 0x7f38dfea23c4, ltk_data = 0x3e80000, ltk_free = 0x7f38dfea23a1 <search_stack_free>}, {ltk_key = 0x7f38dfe9fda9, ltk_data = 0x3880000, ltk_free = 0x7f38dfe9fd61 <scope_chunk_free>}, { ltk_key = 0x43d3cd, ltk_data = 0x167ae00, ltk_free = 0x43d211 <conn_counter_destroy>}, {ltk_key = 0x459151, ltk_data = 0x16fc800, ltk_free = 0x4590a4 <slap_op_q_destroy>}, { ltk_key = 0x0, ltk_data = 0xd5d1600, ltk_free = 0}, {ltk_key = 0x0, ltk_data = 0x0, ltk_free = 0} <repeats 24 times>}} kctx = 0x0 i = 32 keyslot = 965 hash = 2784641989 __PRETTY_FUNCTION__ = "ldap_int_thread_pool_wrapper" #15 0x00007f38e3d259ca in start_thread () from /lib/libpthread.so.0 No symbol table info available. #16 0x00007f38e3a8270d in clone () from /lib/libc.so.6 No symbol table info available. #17 0x0000000000000000 in ?? () No symbol table info available.

1 0

Re: (ITS#7222) Slapd hangs on high load
by hyc＠symas.com 03 Apr '12

03 Apr '12

hrvoje.habjanic(a)zg.t-com.hr wrote: > Full_Name: Hrvoje > Version: 2.4.30 > OS: Centos 6.2 x86_64 > URL: http://free-zg.t-com.hr/HrvojeHabjanic/hang2.log > Submission from: (NULL) (195.29.148.138) > > > > Hi. > > While testing openlap, with some of my data, slapd regularly hangs. I did manage > to "catch" it, but i need expert's interpretation of traces. > > I' using db-5.3.15 (latest), compiled with: > > ../dist/configure \ > --enable-shared --enable-static \ > --enable-tcl --with-tcl=/usr/lib64 \ > --enable-cxx --enable-sql \ > --enable-java \ > --enable-test \ > --with-tcl=/usr/lib64/tcl8.5 \ > --disable-rpath \ > --enable-debug \ > --prefix=/usr/local/db > > and openldap-2.4.30, compiled with: > > CFLAGS="-g -I/usr/local/db/include" CPPFLAGS="-g -I/usr/local/db/include" > LDFLAGS="-L/usr/local/db/lib -Wl,-R/usr/local/db/lib" ./configure \ > --prefix=/usr/local/openldap \ > --enable-local \ > --enable-rlookups \ > --with-tls=no \ > --with-cyrus-sasl \ > --enable-wrappers \ > --enable-passwd \ > --enable-cleartext \ > --enable-crypt \ > --enable-spasswd \ > --disable-lmpasswd \ > --enable-modules \ > --disable-sql \ > --enable-slapd \ > --enable-bdb \ > --enable-hdb \ > --enable-ldap \ > --enable-meta \ > --enable-monitor \ > --enable-null \ > --enable-shell \ > --disable-ndb \ > --enable-passwd \ > --enable-sock \ > --disable-perl \ > --enable-relay \ > --disable-shared \ > --disable-dynamic \ > --enable-overlays=mod \ > --enable-mdb \ > --enable-debug=yes > > Slapd is configured to use slapd.d directory (db). Inside, two databases are > configured - ie. ou=p,dc=pero,dc=com and ou=d,dc=pero,dc=com, including monitor > db. First database is using 10Gb on disk, and have around 10M unique dn's, while > second one is using around 3-4Gb, few mil. dn's. > > Server have 16G of ram, and 2xquad core CPU - total of 8 cpu's (and disks are > local). > > I'm using python scripts to generate load on openldap. First i fill in required > data (10Gb), and then do some transaction processing (read/update/write). > > Filling part goes without problems, but on transaction processing, slapd > regularly gets stuck. I'm only able to trigger this using more than one > connection - simulating couple of clients, and high load (1-2 req/sec). > Complete traces from gdb when this happens, are > http://free-zg.t-com.hr/HrvojeHabjanic/hang2.log . > > So, am i doing something wrong or openldap is...? Looks like your glibc malloc is deadlocked. A Centos bug, not an OpenLDAP bug. In the trace, you could confirm this in gdb with: thread 13 frame 3 print *mutex most likely the "owner" field of this mutex will be 1502, which corresponds to thread 17, which is waiting for a lock inside libc malloc/free. You may be able to avoid this bug by using an alternate malloc library, such as Google tcmalloc. -- -- 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#7222) Slapd hangs on high load
by hrvoje.habjanic＠zg.t-com.hr 03 Apr '12

03 Apr '12

Full_Name: Hrvoje Version: 2.4.30 OS: Centos 6.2 x86_64 URL: http://free-zg.t-com.hr/HrvojeHabjanic/hang2.log Submission from: (NULL) (195.29.148.138) Hi. While testing openlap, with some of my data, slapd regularly hangs. I did manage to "catch" it, but i need expert's interpretation of traces. I' using db-5.3.15 (latest), compiled with: ../dist/configure \ --enable-shared --enable-static \ --enable-tcl --with-tcl=/usr/lib64 \ --enable-cxx --enable-sql \ --enable-java \ --enable-test \ --with-tcl=/usr/lib64/tcl8.5 \ --disable-rpath \ --enable-debug \ --prefix=/usr/local/db and openldap-2.4.30, compiled with: CFLAGS="-g -I/usr/local/db/include" CPPFLAGS="-g -I/usr/local/db/include" LDFLAGS="-L/usr/local/db/lib -Wl,-R/usr/local/db/lib" ./configure \ --prefix=/usr/local/openldap \ --enable-local \ --enable-rlookups \ --with-tls=no \ --with-cyrus-sasl \ --enable-wrappers \ --enable-passwd \ --enable-cleartext \ --enable-crypt \ --enable-spasswd \ --disable-lmpasswd \ --enable-modules \ --disable-sql \ --enable-slapd \ --enable-bdb \ --enable-hdb \ --enable-ldap \ --enable-meta \ --enable-monitor \ --enable-null \ --enable-shell \ --disable-ndb \ --enable-passwd \ --enable-sock \ --disable-perl \ --enable-relay \ --disable-shared \ --disable-dynamic \ --enable-overlays=mod \ --enable-mdb \ --enable-debug=yes Slapd is configured to use slapd.d directory (db). Inside, two databases are configured - ie. ou=p,dc=pero,dc=com and ou=d,dc=pero,dc=com, including monitor db. First database is using 10Gb on disk, and have around 10M unique dn's, while second one is using around 3-4Gb, few mil. dn's. Server have 16G of ram, and 2xquad core CPU - total of 8 cpu's (and disks are local). I'm using python scripts to generate load on openldap. First i fill in required data (10Gb), and then do some transaction processing (read/update/write). Filling part goes without problems, but on transaction processing, slapd regularly gets stuck. I'm only able to trigger this using more than one connection - simulating couple of clients, and high load (1-2 req/sec). Complete traces from gdb when this happens, are http://free-zg.t-com.hr/HrvojeHabjanic/hang2.log . So, am i doing something wrong or openldap is...? H.

1 0

(ITS#7221) Support private keys in PKCS #8 in slapd when linked with gnutls
by komyagin＠altell.ru 03 Apr '12

03 Apr '12

Full_Name: Alexander Komyagin Version: 2.4.23 OS: Debian Squeeze URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (178.16.156.18) Hi! I found out that when slapd is linked with gnutls, it fails to parse private key on startup if the one is given in PKCS #8 form (TLS init def ctx failed: -207). The problem is in tlsg_ctx_init() (tls_g.c) function, which calls gnutls_x509_privkey_import() from gnutls. But gnutls_x509_privkey_import() is designed to support only RSA/DSA keys, while for PKCS#8 gnutls_x509_privkey_import_pkcs8() shall be used. I think that incorporating such enhancement for slapd would make it even better (for example, some popular commands like "openssl req" generate keys in PKCS #8) :) Especially when such enhancement can be done in a few lines of code (just like certtool does): if (!info.pkcs8) ret = gnutls_x509_privkey_import (key, &pem, info.incert_format); /* If we failed to import the certificate previously try PKCS #8 */ if (info.pkcs8 || ret == GNUTLS_E_BASE64_UNEXPECTED_HEADER_ERROR) { /* first try to import the key without asking any password */ ret = gnutls_x509_privkey_import_pkcs8 (key, &pem, info.incert_format, NULL, GNUTLS_PKCS_PLAIN); if (ret < 0) { if (info.pass) pass = info.pass; else pass = get_pass (); ret = gnutls_x509_privkey_import_pkcs8 (key, &pem, info.incert_format, pass, 0); } }

1 0

Re: RE : RE : (ITS#7149) Back-perl, Back-shell and Binary Data
by hyc＠symas.com 02 Apr '12

02 Apr '12

jiashun.qian(a)atos.net wrote: > After the tests, these patchs work but not work for what we expect. According to Howard Chu, "Since these backends communicate using LDIF, binary values should be base64 encoded according to the LDIF rules." These patchs send binary data to backends. Could you change this ? I probably mis-spoke. Only back-shell deals exclusively in LDIF, back-perl is obviously passing native perl variables around. > ________________________________________ > De : openldap-bugs-bounces(a)OpenLDAP.org [openldap-bugs-bounces(a)OpenLDAP.org] de la part de quanah(a)zimbra.com [quanah(a)zimbra.com] > Date d'envoi : jeudi 29 mars 2012 19:26 > À : openldap-its(a)openldap.org > Objet : Re: RE : (ITS#7149) Back-perl, Back-shell and Binary Data > > --On Thursday, March 29, 2012 1:59 PM +0000 Laurent.LeGrandois(a)atos.net > wrote: > >> This is a multi-part message in MIME format. >> --------------060203070300020608020002 >> Content-Type: text/plain; charset=ISO-8859-1; format=flowed >> Content-Transfer-Encoding: quoted-printable >> >> Le 29/03/2012 15:14, hyc(a)symas.com a =E9crit : >>> Laurent.LeGrandois(a)atos.net wrote: >>>> This is a multi-part message in MIME format. >>>> --------------070001090703090002060300 >>>> Content-Type: text/plain; charset=3DISO-8859-1; format=3Dflowed >>>> Content-Transfer-Encoding: quoted-printable >>>> >>>> Hi, >>>> >>>> any news concerning integration of this patch ? >>> An alternate patch is now in git master, please test. >> Ok, we will test it : any modifications to do for 2.4.28 version ? > > Please respond once you've tested. Since there were changes to back-perl > for 2.4.29, it may not apply cleanly to a 2.4.28 build. > > --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 > > > > ________________________________ > > > Ce message et les pièces jointes sont confidentiels et réservés à l'usage exclusif de ses destinataires. Il peut également être protégé par le secret professionnel. Si vous recevez ce message par erreur, merci d'en avertir immédiatement l'expéditeur et de le détruire. L'intégrité du message ne pouvant être assurée sur Internet, la responsabilité du groupe Atos ne pourra être engagée quant au contenu de ce message. Bien que les meilleurs efforts soient faits pour maintenir cette transmission exempte de tout virus, l'expéditeur ne donne aucune garantie à cet égard et sa responsabilité ne saurait être engagée pour tout dommage résultant d'un virus transmis. > > This e-mail and the documents attached are confidential and intended solely for the addressee; it may also be privileged. If you receive this e-mail in error, please notify the sender immediately and destroy it. As its integrity cannot be secured on the Internet, the Atos group liability cannot be triggered for the message content. Although the sender endeavors to maintain a computer virus-free network, the sender does not warrant that this transmission is virus-free and will not be liable for any damages resulting from any virus transmitted. > > > > -- -- 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#7220) Ldap_search_ext API blocked for around 20mints
by masarati＠aero.polimi.it 02 Apr '12

02 Apr '12

> Full_Name: Kona Jagan > Version: libldap-2.2.so.7.0.6 > OS: Linux 2.6.9-67.ELsmp #1 SMP Wed Nov 7 13:58:04 EST 2007 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (125.17.121.249) > > > Hi All, > > I have written a ldap client application in Linux which uses > ldap_search_ext() > API for querying details of a user. I am using two threads, one for > sending ldap > search queries and other for receiving response from Ldap server which > uses > ldap_result API. > > At production i am facing a issue which breaks down to ldap_search_ext() > API got > blocked which is causing all ldap request's to timeout. Can anyone help me > to > understand about the blocking behavior of ldap_search_ext() API. I mean > when > ldap_search_ext() API gets blocked.please provide me the user cases which > can > cause this behavior. As far as I know, asynchronous LDAP calls can only block when connect(2) blocks. There's a workaround for that (which only prevents blocking) but since blocking on connect(2) indicates a more serious issue (e.g. network misconfiguration), I'd address that issue first. In any case, there is nothing so far indicating a bug in OpenLDAP software, so I'd consider this ITS closed.

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 2012