openldap-bugs

openldap-bugs@openldap.org

1 participants
21518 discussions

Re: (ITS#5840) bdb_online_index and shutdown
by hyc＠symas.com 10 Apr '09

10 Apr '09

Hallvard B Furuseth wrote: > hyc(a)symas.com writes: > I suppose there could be a flag to _not_ start the indexing task when > you add an index via cn=config, so you always must slapindex. I'd rather not. >> I suppose we should save the last entryID that was indexed at shutdown time, >> so that the indexer task can resume at the next startup. We'd also need some >> coordination with slapindex, so that if you ran slapindex after shutdown, it >> would erase the saved status. Rather than add any fields to the DB index >> files, it would probably be OK to write the status in the cn=config tree. > > Or a status file in the database directory. > > A cn=config attribute would make it messy to swap database directories > around, since one must also modify cn=config when doing so. OK, a status file. It would record the old and new index masks for the attributes being reindexed, and the entryID where it stopped. If slapindex is run without a specific list of attributes, (reindex everything) it should remove and ignore the status file. If slapindex is run with a specific list of attributes, and those attributes are in the status file, it should use the saved status and remove the specified attributes from the status file. (Deleting the file if there are no other attributes remaining.) Otherwise, when slapd starts, it should read the status file and resume the indexing task. -- -- 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#6054) back-bdb indexing routines do not check for slap_sl_malloc() failure, leading to segfaults
by hyc＠symas.com 10 Apr '09

10 Apr '09

jwm(a)horde.net wrote: > Full_Name: John Morrissey > Version: 2.4.16 > OS: Linux > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (2001:4978:194:0:21f:5bff:fee9:da92) > > Looking back through the call chain, do_syncrepl() sets op->o_tmpmemctx to > NULL: > > /* use global malloc for now */ > op->o_tmpmemctx = NULL; > op->o_tmpmfuncs =&ch_mfuncs; This should be removed. > so generalizedTimeIndexer()'s call to slap_sl_malloc() falls back to > ber_memalloc_x() due to the null ctx. If malloc() fails there, NULL is > eventually returned to the original caller of slap_sl_malloc(), likely resulting > in a segfault. And slap_sl_malloc() should be changed in this case to assert() just like ch_malloc() does. > All of the indexing routines seem to ignore slap_sl_malloc()'s return value, > opening them up to this problem, too. Someone else will need to step in with a > proper fix since I don't know much about slapd internals, but it seems that if > these routines are being called with a deliberate null ctx, they should be > checking for malloc failure. A cursory glance around back-bdb indicates that > indexing function callers already handle failure return codes gracefully. -- -- 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#6054) back-bdb indexing routines do not check for slap_sl_malloc() failure, leading to segfaults
by jwm＠horde.net 10 Apr '09

10 Apr '09

Full_Name: John Morrissey Version: 2.4.16 OS: Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (2001:4978:194:0:21f:5bff:fee9:da92) Our gdb harness around slapd(8) recently caught a SIGSEGV: Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 0x5c6fcb90 (LWP 9059)] generalizedTimeIndexer (use=163, flags=4, syntax=0x8c73f58, mr=0x8c77f90, prefix=0x8cbed6c, values=0xbf5b6698, keysp=0x5c6fb2b4, ctx=0x0) at /tmp/buildd/openldap-2.4.16/servers/slapd/schema_init.c:5615 schema_init.c:5615: keys[j].bv_val = NULL; [...] Thread 11 (Thread 0x5c6fcb90 (LWP 9059)): #0 generalizedTimeIndexer (use=163, flags=4, syntax=0x8c73f58, mr=0x8c77f90, prefix=0x8cbed6c, values=0xbf5b6698, keysp=0x5c6fb2b4, ctx=0x0) at /tmp/buildd/openldap-2.4.16/servers/slapd/schema_init.c:5615 i = <value optimized out> j = 1 keys = (BerVarray) 0x0 tmp = "\000Iﬁ@" bvtmp = {bv_len = 5, bv_val = 0x5c6fb267 ""} tm = {tm_sec = 25, tm_min = 39, tm_hour = 18, tm_mday = 9, tm_mon = 3, tm_year = 109, tm_usec = 5, tm_usub = 147681736} tt = {tt_sec = 73, tt_gsec = 0, tt_usec = 5} __PRETTY_FUNCTION__ = "generalizedTimeIndexer" #1 0xb777f25e in indexer (op=0x5c6fbd50, txn=0xbf5b7130, ad=0x8cbedf0, atname=0x8cbed6c, vals=0xbf5b6698, id=786532, opid=1, mask=<value optimized out>) at /tmp/buildd/openldap-2.4.16/servers/slapd/back-bdb/index.c:205 rc = <value optimized out> db = (DB *) 0x8d7b168 keys = <value optimized out> __PRETTY_FUNCTION__ = "indexer" #2 0xb777f916 in index_at_values (op=0x5c6fbd50, txn=0xbf5b7130, ad=0xb7c7b160, type=0x8cbed30, tags=0x8cbee00, vals=0xbf5b6698, id=786532, opid=1) at /tmp/buildd/openldap-2.4.16/servers/slapd/back-bdb/index.c:337 rc = <value optimized out> mask = <value optimized out> ixop = 1 ai = <value optimized out> #3 0xb777faa7 in bdb_index_entry (op=0x5c6fbd50, txn=0xbf5b7130, opid=1, e=0xa3b1e154) at /tmp/buildd/openldap-2.4.16/servers/slapd/back-bdb/index.c:557 rc = 0 ap = (Attribute *) 0xa37a7a7c #4 0xb7773268 in bdb_add (op=0x5c6fbd50, rs=0x5c6fb774) at /tmp/buildd/openldap-2.4.16/servers/slapd/back-bdb/add.c:383 bdb = (struct bdb_info *) 0x8cd71c8 pdn = {bv_len = 6, bv_val = 0xbf5b8fc0 "cn=log"} p = (Entry *) 0x61a22034 oe = (Entry *) 0xa3b1e154 ei = (EntryInfo *) 0x8d735c8 textbuf = "\020\000P^\020w[øQ»∫∑∆\231∫∑HW\\ø\230\037\000\000Q»∫∑\004¥o\\Ï∆∫∑\020\000P^H\000P^8\000\000\000H\000P^\025\000\000\000-\000\000\000\005\000\000\000\000\000\000\000,¥o\\Hi[ø\001\000\000\000\000\000\000\000\220\003P^h[ø\004\000\000\000\020w[ø¥o\\\017s¿∑V\\øV\\ø@\000P^@\000P^@i[ø1Î∂∑\005\000\000\000@\000P^Ëh[øÙ\237«∑\000\000\000\000!\000\000\000ˇˇˇˇ\206Â∫∑\020\000P\017\000\000\000\000ˇˇˇ\017", '\0' <repeats 24 times>, "!\000\0000Á\221[ø∏¥o\\Ù\237"... children = (AttributeDescription *) 0x8c7dba0 entry = (AttributeDescription *) 0x8c7da08 ltid = (DB_TXN *) 0xbf5c3598 lt2 = (DB_TXN *) 0xbf5b7130 rtxn = <value optimized out> eid = 786532 opinfo = {boi_oe = {oe_next = {sle_next = 0x0}, oe_key = 0x8cd71c8}, boi_txn = 0xbf5c3598, boi_locks = 0x0, boi_err = 0, boi_acl_cache = 0 '\0', boi_flag = 0 '\0'} lock = {off = 193944, ndx = 386, gen = 3765, mode = DB_LOCK_READ} num_retries = 0 success = <value optimized out> postread_ctrl = <value optimized out> ctrls = {0x0, 0x80e2ed3, 0xbf5b91e7, 0x0, 0x10, 0xb7f6891c} num_ctrls = <value optimized out> #5 0x080d8be9 in syncrepl_entry (si=0x8cd8050, op=0x5c6fbd50, entry=0xa3b1e154, modlist=0x5c6fbce8, syncstate=1, syncUUID=0x5c6fbcb0, syncCSN=0xbf5b91f8) at /tmp/buildd/openldap-2.4.16/servers/slapd/syncrepl.c:2187 be = (Backend *) 0x8cd70c8 cb = {sc_next = 0x0, sc_response = 0x80d2260 <null_callback>, sc_cleanup = 0, sc_private = 0x8cd8050} syncuuid_inserted = 0 syncUUID_strrep = {bv_len = 36, bv_val = 0xbf5b9220 "7eef2b58-b981-102d-8a6a-27f91e6cbe6f"} rs_search = {sr_type = REP_RESULT, sr_tag = 101, sr_msgid = 0, sr_err = 0, sr_matched = 0x0, sr_text = 0x0, sr_ref = 0x0, sr_ctrls = 0x0, sr_un = {sru_sasl = {r_sasldata = 0x0}, sru_extended = {r_rspoid = 0x0, r_rspdata = 0x0}, sru_search = {r_entry = 0x0, r_attr_flags = 0, r_operational_attrs = 0x0, r_attrs = 0x0, r_nentries = 0, r_v2ref = 0x0}}, sr_flags = 0} rs_delete = {sr_type = REP_RESULT, sr_tag = 0, sr_msgid = 0, sr_err = 0, sr_matched = 0x0, sr_text = 0x0, sr_ref = 0x0, sr_ctrls = 0x0, sr_un = {sru_sasl = {r_sasldata = 0x0}, sru_extended = {r_rspoid = 0x0, r_rspdata = 0x0}, sru_search = {r_entry = 0x0, r_attr_flags = 0, r_operational_attrs = 0x0, r_attrs = 0x0, r_nentries = 0, r_v2ref = 0x0}}, sr_flags = 0} rs_add = {sr_type = REP_RESULT, sr_tag = 0, sr_msgid = 0, sr_err = 0, sr_matched = 0x0, sr_text = 0x0, sr_ref = 0x0, sr_ctrls = 0x0, sr_un = {sru_sasl = {r_sasldata = 0x0}, sru_extended = {r_rspoid = 0x0, r_rspdata = 0x0}, sru_search = {r_entry = 0x0, r_attr_flags = 0, r_operational_attrs = 0x0, r_attrs = 0x0, r_nentries = 0, r_v2ref = 0x0}}, sr_flags = 0} rs_modify = {sr_type = REP_RESULT, sr_tag = 0, sr_msgid = 0, sr_err = 0, sr_matched = 0x0, sr_text = 0x0, sr_ref = 0x0, sr_ctrls = 0x0, sr_un = {sru_sasl = {r_sasldata = 0x0}, sru_extended = {r_rspoid = 0x0, r_rspdata = 0x0}, sru_search = {r_entry = 0x0, r_attr_flags = 0, r_operational_attrs = 0x0, r_attrs = 0x0, r_nentries = 0, r_v2ref = 0x0}}, sr_flags = 0} f = {f_choice = 163, f_un = {f_un_result = 1550825600, f_un_desc = 0x5c6fb880, f_un_ava = 0x5c6fb880, f_un_ssa = 0x5c6fb880, f_un_mra = 0x5c6fb880, f_un_complex = 0x5c6fb880}, f_next = 0x0} ava = {aa_desc = 0x8c7a840, aa_value = {bv_len = 16, bv_val = 0xbf5b86d7 "~Ô+Xπ\201\020-\212j'˘\036læo"}} rc = 0 pdn = {bv_len = 0, bv_val = 0x0} dni = {new_entry = 0xa3b1e154, dn = {bv_len = 0, bv_val = 0x0}, ndn = {bv_len = 0, bv_val = 0x0}, nnewSup = {bv_len = 0, bv_val = 0x0}, renamed = 0, delOldRDN = 0, modlist = 0x5c6fbce8, mods = 0x0, oldNattr = 0x0, oldDesc = 0x0, newDesc = 0x0} retry = 1 freecsn = 1 nullattr = (AttributeDescription *) 0x0 __PRETTY_FUNCTION__ = "syncrepl_entry" opattrs = {0x81a6540, 0x81a6520, 0x81a6524, 0x8165a88} #6 0x080dafac in do_syncrep2 (op=0x5c6fbd50, si=0x8cd8050) at /tmp/buildd/openldap-2.4.16/servers/slapd/syncrepl.c:892 rctrlp = <value optimized out> rctrls = (LDAPControl **) 0xbf5b41c0 berbuf = {buffer = "\002\000\001", '\0' <repeats 17 times>, "\206[ø\025\207[ø\025\207[ø", '\0' <repeats 12 times>, "h\037fQ+\230\021\b\022", '\0' <repeats 11 times>, "\n\000\000\000øo\\ˇˇˇ\021", '\0' <repeats 18 times>, "@¿o\\∏Â∑∑\000\000\000\000,#\0000\n\000 uT¿o\\∏Â∑∑žˇˇˇ\020\000\000\000\000\000\000\000\000\000\000ž\037fQžˇˇˇ\001", '\0' <repeats 11 times>, "+m uxH>\200\000\000\000\000\000\000\000\000ˇˇˇˇ\006\000\000\000Ï≈∑§Ï≈∑\224\214∫∑ˇˇˇˇ&\000\000\000Ù\237«∑Oøo\\\214ªo\\\215\237∫"..., ialign = 65538, lalign = 65538, falign = 9.18382988e-41, dalign = 3.2380074297143616e-319, palign = 0x10002 ""} msg = (LDAPMessage *) 0xbf5b4ac8 retoid = 0x0 retdata = (struct berval *) 0x0 entry = (Entry *) 0xb7c7b160 syncstate = 1 syncUUID = {bv_len = 16, bv_val = 0xbf5b86d7 "~Ô+Xπ\201\020-\212j'˘\036læo"} syncCookie = {ctxcsn = 0xbf5b91f8, octet_str = {bv_len = 44, bv_val = 0xbf5b9198 "csn=20090409183925Z#000000#00#000000,rid=002"}, rid = 2, sid = -1, numcsns = 1, sids = 0xbf5b9210, sc_next = {stqe_next = 0x0}} syncCookie_req = {ctxcsn = 0xbf5b4a60, octet_str = {bv_len = 44, bv_val = 0xbf5b4188 "csn=20090409183916Z#000001#00#000000,rid=002"}, rid = 2, sid = -1, numcsns = 1, sids = 0xbf5b85c0, sc_next = {stqe_next = 0x0}} cookie = {bv_len = 44, bv_val = 0xbf5b86e9 "csn=20090409183925Z#000000#00#000000,rid=002"} rc = 0 err = 0 len = 44 psub = (struct berval *) 0x8cd7dc8 modlist = (Modifications *) 0xbf5ba250 match = <value optimized out> m = 148286664 tout_p = (struct timeval *) 0x5c6fbca0 tout = {tv_sec = 0, tv_usec = 0} refreshDeletes = 0 syncUUIDs = (BerVarray) 0x0 si_tag = 0 #7 0x080ddca4 in do_syncrepl (ctx=0x5c6fc248, arg=0x8cd7ea8) at /tmp/buildd/openldap-2.4.16/servers/slapd/syncrepl.c:1361 si = (syncinfo_t *) 0x8cd8050 conn = {c_struct_state = 0, c_conn_state = 0, c_conn_idx = -1, c_sd = 0, c_close_reason = 0x0, c_mutex = {__data = {__lock = 0, __count = 0, __owner = 0, __kind = 0, __nusers = 0, {__spins = 0, __list = {__next = 0x0}}}, __size = '\0' <repeats 23 times>, __align = 0}, c_sb = 0x0, c_starttime = 0, c_activitytime = 0, c_connid = 4294967295, c_peer_domain = {bv_len = 0, bv_val = 0x81172c9 ""}, c_peer_name = {bv_len = 0, bv_val = 0x81172c9 ""}, c_listener = 0x8119260, 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, __kind = 0, __nusers = 0, {__spins = 0, __list = {__next = 0x0}}}, __size = '\0' <repeats 23 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 = '\0' <repeats 47 times>, __align = 0}, c_write2_mutex = {__data = {__lock = 0, __count = 0, __owner = 0, __kind = 0, __nusers = 0, {__spins = 0, __list = {__next = 0x0}}}, __size = '\0' <repeats 23 times>, __align = 0}, c_write2_cv = {__data = {__lock = 0, __futex = 0, __total_seq = 0, __wakeup_seq = 0, __woken_seq = 0, __mutex = 0x0, __nwaiters = 0, __broadcast_seq = 0}, __size = '\0' <repeats 47 times>, __align = 0}, c_currentber = 0x0, c_writers = 0, c_sasl_bind_in_progress = 0 '\0', c_writewaiter = 0 '\0', c_is_tls = 0 '\0', c_needs_tls_accept = 0 '\0', c_sasl_layers = 0 '\0', c_sasl_done = 0 '\0', c_sasl_authctx = 0x0, c_sasl_sockctx = 0x0, c_sasl_extra = 0x0, c_sasl_bindop = 0x0, c_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 = 0x808aea0 <slap_send_ldap_result>, c_send_search_entry = 0x80885e0 <slap_send_search_entry>, c_send_search_reference = 0x8087da0 <slap_send_search_reference>, c_send_ldap_extended = 0, c_send_ldap_intermediate = 0} opbuf = {ob_op = {o_hdr = 0x5c6fbe28, o_tag = 104, o_time = 1239302589, o_tincr = 0, o_bd = 0x8cd70c8, o_req_dn = {bv_len = 38, bv_val = 0xbf5b8f70 "reqStart=20090409183925.000005Z,cn=log"}, o_req_ndn = {bv_len = 38, bv_val = 0xbf5b8fa0 "reqStart=20090409183925.000005Z,cn=log"}, o_request = {oq_add = {rs_modlist = 0x2, rs_e = 0xa3b1e154}, oq_bind = {rb_method = 2, rb_cred = {bv_len = 2746343764, bv_val = 0x1 <Address 0x1 out of bounds>}, rb_edn = {bv_len = 4294967295, bv_val = 0x0}, rb_ssf = 0, rb_mech = {bv_len = 135668576, bv_val = 0x5c6fb88c "£"}}, oq_compare = {rs_ava = 0x2}, oq_modify = {rs_mods = {rs_modlist = 0x2, rs_no_opattrs = 84 'T'}, rs_increment = 1}, oq_modrdn = {rs_mods = {rs_modlist = 0x2, rs_no_opattrs = 84 'T'}, rs_deleteoldrdn = 1, rs_newrdn = {bv_len = 4294967295, bv_val = 0x0}, rs_nnewrdn = {bv_len = 0, bv_val = 0x8162360 "\001"}, rs_newSup = 0x5c6fb88c, rs_nnewSup = 0x30}, oq_search = {rs_scope = 2, rs_deref = -1548623532, rs_slimit = 1, rs_tlimit = -1, rs_limit = 0x0, rs_attrsonly = 0, rs_attrs = 0x8162360, rs_filter = 0x5c6fb88c, rs_filterstr = {bv_len = 48, bv_val = 0xbf5ba2d0 "¢[øv\a\b4\020"}}, oq_abandon = {rs_msgid = 2}, oq_cancel = {rs_msgid = 2}, oq_extended = {rs_reqoid = {bv_len = 2, bv_val = 0xa3b1e154 "d"}, rs_flags = 1, rs_reqdata = 0xffffffff}, oq_pwdexop = {rs_extended = {rs_reqoid = {bv_len = 2, bv_val = 0xa3b1e154 "d"}, rs_flags = 1, rs_reqdata = 0xffffffff}, rs_old = {bv_len = 0, bv_val = 0x0}, rs_new = {bv_len = 135668576, bv_val = 0x5c6fb88c "£"}, rs_mods = 0x30, rs_modtail = 0xbf5ba2d0}}, o_abandon = 0, o_cancel = 0, o_groups = 0x0, o_do_not_cache = 0 '\0', o_is_auth_check = 0 '\0', o_dont_replicate = 0 '\0', o_acl_priv = ACL_NONE, o_nocaching = 0 '\0', o_delete_glue_parent = 0 '\0', o_no_schema_check = 1 '\001', o_no_subordinate_glue = 0 '\0', o_ctrlflag = '\0' <repeats 14 times>, "\002", '\0' <repeats 16 times>, o_controls = 0x5c6fbf54, o_authz = {sai_method = 0, sai_mech = {bv_len = 0, bv_val = 0x0}, sai_dn = {bv_len = 14, bv_val = 0x8cd70b0 "cn=root,cn=log"}, sai_ndn = {bv_len = 14, bv_val = 0x8cd7e90 "cn=root,cn=log"}, sai_ssf = 0, sai_transport_ssf = 0, sai_tls_ssf = 0, sai_sasl_ssf = 0}, o_ber = 0x0, o_res_ber = 0x0, o_callback = 0x5c6fb870, o_ctrls = 0x0, o_csn = {bv_len = 32, bv_val = 0xbf5b6948 "20090409183925Z#000000#00#000000"}, o_private = 0x0, o_extra = {slh_first = 0x5c6fb4e0}, o_next = {stqe_next = 0x0}}, ob_hdr = {oh_opid = 0, oh_connid = 4294967295, oh_conn = 0x5c6fbfd4, oh_msgid = 0, oh_protocol = 0, oh_tid = 1550830480, oh_threadctx = 0x5c6fc248, oh_tmpmemctx = 0x0, oh_tmpmfuncs = 0x8161214, oh_counters = 0x81a62c0, oh_log_prefix = "conn=-1 op=0", '\0' <repeats 243 times>, oh_extensions = 0x0}, ob_controls = {0x5c6fbc10, 0x0 <repeats 31 times>}} rc = 147681480 dostop = <value optimized out> s = <value optimized out> i = <value optimized out> defer = <value optimized out> fail = <value optimized out> be = (Backend *) 0x8cd70c8 #8 0x08077e6b in connection_read_thread (ctx=0x5c6fc248, argv=0x15) at /tmp/buildd/openldap-2.4.16/servers/slapd/connection.c:1225 No locals. #9 0xb7f7a5c8 in ldap_int_thread_pool_wrapper (xpool=0x8c80560) at /tmp/buildd/openldap-2.4.16/libraries/libldap_r/tpool.c:663 task = (ldap_int_thread_task_t *) 0x8e313c0 work_list = <value optimized out> ctx = {ltu_id = 1550830480, ltu_key = {{ltk_key = 0x8076090, ltk_data = 0x5b8025e8, ltk_free = 0x8076160 <conn_counter_destroy>}, {ltk_key = 0x80ced40, ltk_data = 0x5b8009c0, ltk_free = 0x80cec20 <slap_sl_mem_destroy>}, {ltk_key = 0x8d5edf8, ltk_data = 0x5b8026d8, ltk_free = 0xb7788ee0 <bdb_reader_free>}, {ltk_key = 0x808b890, ltk_data = 0x0, ltk_free = 0x808b680 <slap_op_q_destroy>}, {ltk_key = 0xb777b100, ltk_data = 0x58ff9008, ltk_free = 0xb777b1f0 <search_stack_free>}, {ltk_key = 0x8d5ca30, ltk_data = 0x56c81ce0, ltk_free = 0xb7788ee0 <bdb_reader_free>}, {ltk_key = 0x0, ltk_data = 0x54de7778, ltk_free = 0}, {ltk_key = 0x0, ltk_data = 0x0, ltk_free = 0} <repeats 25 times>}} kctx = <value optimized out> keyslot = 902 hash = <value optimized out> __PRETTY_FUNCTION__ = "ldap_int_thread_pool_wrapper" #10 0xb7c83f3b in start_thread (arg=0x5c6fcb90) at pthread_create.c:297 __res = <value optimized out> __ignore1 = <value optimized out> __ignore2 = <value optimized out> pd = (struct pthread *) 0x5c6fcb90 unwind_buf = {cancel_jmp_buf = {{jmp_buf = {-1211551756, 0, 4001536, 1550828744, -880287418, -2072111471}, mask_was_saved = 0}}, priv = {pad = {0x0, 0x0, 0x0, 0xb7c83e9b}, data = {prev = 0x0, cleanup = 0x0, canceltype = 0}}} not_first_call = <value optimized out> robust = <value optimized out> #11 0xb7c0abee in clone () from /usr/lib/debug/libc.so.6 fstab_state = {fs_fp = 0x0, fs_buffer = 0x0, fs_mntres = {mnt_fsname = 0x0, mnt_dir = 0x0, mnt_type = 0x0, mnt_opts = 0x0, mnt_freq = 0, mnt_passno = 0}, fs_ret = {fs_spec = 0x0, fs_file = 0x0, fs_vfstype = 0x0, fs_mntops = 0x0, fs_type = 0x0, fs_freq = 0, fs_passno = 0}} __elf_set___libc_subfreeres_element_fstab_free__ = (const void *) 0xb7c48820 generalizedTimeIndexer() segfaults since it assumes slap_sl_malloc() always succeeds: keys = slap_sl_malloc( sizeof( struct berval ) * (i+1), ctx ); [...] keys[j].bv_val = NULL; keys[j].bv_len = 0; Looking back through the call chain, do_syncrepl() sets op->o_tmpmemctx to NULL: /* use global malloc for now */ op->o_tmpmemctx = NULL; op->o_tmpmfuncs = &ch_mfuncs; so generalizedTimeIndexer()'s call to slap_sl_malloc() falls back to ber_memalloc_x() due to the null ctx. If malloc() fails there, NULL is eventually returned to the original caller of slap_sl_malloc(), likely resulting in a segfault. All of the indexing routines seem to ignore slap_sl_malloc()'s return value, opening them up to this problem, too. Someone else will need to step in with a proper fix since I don't know much about slapd internals, but it seems that if these routines are being called with a deliberate null ctx, they should be checking for malloc failure. A cursory glance around back-bdb indicates that indexing function callers already handle failure return codes gracefully.

1 0

(ITS#6053) gnutls doen't initialize gnutls_x509_privkey_t structure, leading to TLS init def ctx failed: -50
by jwm＠horde.net 10 Apr '09

10 Apr '09

Full_Name: John Morrissey Version: 2.4.16 OS: Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (2001:4978:194:0:21f:5bff:fee9:da92) tlsg_ctx_init() doesn't initialize the gnutls_x509_privkey_t structure before passing it to gnutls_x509_privkey_import. This yields: main: TLS init def ctx failed: -50 on slapd startup. gnutls error -50 is GNUTLS_E_INVALID_REQUEST. Initializing the structure with gnutls_x509_privkey_init() allows slapd startup to succeed. [jwm@coral.lab.isis:pts/1 ~> dpkg -l libgnutls26 [...] ii libgnutls26 2.6.4-2 the GNU TLS library - runtime library --- openldap-2.4.16.orig/libraries/libldap/tls_g.c +++ openldap-2.4.16/libraries/libldap/tls_g.c @@ -354,6 +354,9 @@ gnutls_x509_crt_t certs[VERIFY_DEPTH]; unsigned int max = VERIFY_DEPTH; + rc = gnutls_x509_privkey_init(&key); + if ( rc < 0 ) return -1; + /* OpenSSL builds the cert chain for us, but GnuTLS * expects it to be present in the certfile. If it's * not, we have to build it ourselves. So we have to

1 0

Re: (ITS#6043) slapd segfaults in bdb_rdn_cmp
by luca.scamoni＠sys-net.it 10 Apr '09

10 Apr '09

luca.scamoni(a)sys-net.it ha scritto: > luca.scamoni(a)sys-net.it ha scritto: New update The problem is still there. Same call in bdb_rdn_cmp. strncmp fails because one of the berval passed to the function has inconsistent values between bv_len and bv_val 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) Fax: +39 0382 476497 Email: luca.scamoni(a)sys-net.it -----------------------------------

1 0

(ITS#6052) Small typo in SASL chapter (15) in administration guide
by kkalev＠gmail.com 10 Apr '09

10 Apr '09

Full_Name: Kostas Kalevras Version: 2.4 OS: FreeBSD URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (147.102.247.75) In OpenLDAP 2.4 Administration Guide, chapter 15 (Using SASL) in 15.3.3.1. Notes on Proxy Authorization Rules the documentation states that the administrator can use regular expression matching like: authzTo: dn.regex=^uid=[^,]*,dc=example,dc=com$ I believe the correct form should be: authzTo: dn.regex:"^uid=[^,]*,dc=example,dc=com$" Notice the : instead of = and the quotes around the regular expression.

1 0

(ITS#6051) JLDAP SASL issue
by hendrik.saly＠gmx.de 10 Apr '09

10 Apr '09

Full_Name: Hendrik Saly Version: JLDAP 4.3 OS: Linux 2.6, Sun JDK 1.5 URL: http://svn.muleforge.org/mule-transport-ldap/trunk/src/main/java/com/novell… Submission from: (NULL) (78.43.136.21) While trying to use SASL with JLDAP i encounter a potential minor bug in $OpenLDAP: pkg/jldap/com/novell/ldap/LDAPConnection.java,v 1.154 2006/02/09 08:43:45 sunilk Exp $ Seems the bind method on line 1730 fails to release the bind semaphore properly under some circumstances. I tried to use more than the wit JLDAP provided SASL mechanisms DIGESTMD5 and EXTERNAL by wrapping the novell sasl client with a Java 1.5 sasl client. All works very well but CRAM login for example fails. I have a workaround http://svn.muleforge.org/mule-transport-ldap/trunk/src/main/java/com/novell… but i thinks there are some problems with the bind semaphore. The wrapping code is here http://svn.muleforge.org/mule-transport-ldap/trunk/src/main/java/org/mule/t… If neccessary i can provide a test suite for this. Thanks Hendrik

1 0

Re: (ITS#6021) slapo-pcache/back-ldap slapd crashes
by hyc＠symas.com 09 Apr '09

09 Apr '09

toby(a)inf.ed.ac.uk wrote: > OK, this is my first crash since moving to 2.4.16: > > Slightly different from the previous ones, but is coming through > pcache.c:remove_from_template and, according to slapd log, was > removing queries from cache when crash occurred: > > Apr 9 05:05:18 rockingham slapd[6662]: Lock CR index = 0x94e70f0 > Apr 9 05:05:18 rockingham slapd[6662]: TEMPLATE 0x94e70f0 QUERIES-- 5 > Apr 9 05:05:18 rockingham slapd[6662]: Unlock CR index = 0x94e70f0 > Apr 9 05:05:18 rockingham slapd[6662]: STALE QUERY REMOVED, SIZE=0 > Apr 9 05:05:18 rockingham slapd[6662]: STORED QUERIES = 26 > Apr 9 05:05:18 rockingham slapd[6662]: STALE QUERY REMOVED, CACHE =17 > entries > Apr 9 05:05:18 rockingham slapd[6662]: Lock CR index = 0x94e70f0 > Apr 9 05:05:18 rockingham slapd[6662]: TEMPLATE 0x94e70f0 QUERIES-- 4 > Apr 9 05:05:18 rockingham slapd[6662]: Unlock CR index = 0x94e70f0 > Apr 9 05:05:18 rockingham slapd[6662]: STALE QUERY REMOVED, SIZE=0 > Apr 9 05:05:18 rockingham slapd[6662]: STORED QUERIES = 25 > Apr 9 05:05:18 rockingham slapd[6662]: STALE QUERY REMOVED, CACHE =17 > entries > Apr 9 05:05:18 rockingham slapd[6662]: Lock CR index = 0x94e70f0 > Apr 9 05:05:18 rockingham slapd[6662]: TEMPLATE 0x94e70f0 QUERIES-- 3 > Apr 9 05:05:18 rockingham slapd[6662]: Unlock CR index = 0x94e70f0 > Apr 9 05:05:18 rockingham slapd[6662]: STALE QUERY REMOVED, SIZE=0 > Apr 9 05:05:18 rockingham slapd[6662]: STORED QUERIES = 24 > Apr 9 05:05:18 rockingham slapd[6662]: STALE QUERY REMOVED, CACHE =17 > entries > Apr 9 05:05:18 rockingham slapd[6662]: Lock CR index = 0x94e70f0 > Apr 9 05:05:18 rockingham slapd[6662]: TEMPLATE 0x94e70f0 QUERIES-- 2 > Apr 9 05:05:18 rockingham slapd[6662]: Unlock CR index = 0x94e70f0 > Apr 9 05:05:18 rockingham slapd[6662]: STALE QUERY REMOVED, SIZE=0 > Apr 9 05:05:18 rockingham slapd[6662]: STORED QUERIES = 23 > Apr 9 05:05:18 rockingham slapd[6662]: STALE QUERY REMOVED, CACHE =17 > entries > Apr 9 05:05:18 rockingham slapd[6662]: Lock CR index = 0x94e70f0 > Apr 9 05:05:18 rockingham slapd[6662]: TEMPLATE 0x94e70f0 QUERIES-- 1 > Apr 9 05:05:18 rockingham slapd[6662]: Unlock CR index = 0x94e70f0 > Apr 9 05:05:18 rockingham slapd[6662]: STALE QUERY REMOVED, SIZE=0 > Apr 9 05:05:18 rockingham slapd[6662]: STORED QUERIES = 22 > Apr 9 05:05:18 rockingham slapd[6662]: STALE QUERY REMOVED, CACHE =17 > entries > Apr 9 05:05:18 rockingham slapd[6662]: Lock CR index = 0x94e70f0 > Apr 9 05:05:18 rockingham slapd[6662]: TEMPLATE 0x94e70f0 QUERIES-- 0 > Apr 9 05:05:18 rockingham slapd[6662]: Unlock CR index = 0x94e70f0 > Apr 9 05:05:18 rockingham slapd[6662]: STALE QUERY REMOVED, SIZE=0 > Apr 9 05:05:18 rockingham slapd[6662]: STORED QUERIES = 21 > Apr 9 05:05:18 rockingham slapd[6662]: STALE QUERY REMOVED, CACHE =17 > entries > Apr 9 05:05:18 rockingham slapd[6662]: Lock CR index = 0x94e6eb0 > > > Here's the backtrace: > > Program terminated with signal 11, Segmentation fault. > #0 0x081764ed in pcache_query_cmp (v1=0xb1f0e900, v2=0x83e58955) > at pcache.c:694 > 694 return pcache_filter_cmp( q1->first, q2->first ); > (gdb) bt > #0 0x081764ed in pcache_query_cmp (v1=0xb1f0e900, v2=0x83e58955) > at pcache.c:694 > #1 0x08199b6d in tavl_delete (root=0x825d7d0, data=0xb1f0e900, > fcmp=0x81764d8<pcache_query_cmp>) at tavl.c:202 > #2 0x08177ab4 in remove_from_template (qc=0xb1f0e900, > template=0x94e6eb0) > at pcache.c:1302 > #3 0x0817b57d in consistency_check (ctx=0xb44201d0, arg=0x9537c50) > at pcache.c:2597 > #4 0x0819fd01 in ldap_int_thread_pool_wrapper (xpool=0x94a8fa0) at > tpool.c:663 > #5 0x009c546b in start_thread () from /lib/libpthread.so.0 > #6 0x0091cdbe in clone () from /lib/libc.so.6 > (gdb) > (gdb) p q1->first > $3 = (Filter *) 0xb1f0d4c0 > (gdb) p q2->first > Cannot access memory at address 0x83e58959 > > Let me know what else would be useful from this backtrace. Nothing obvious is jumping out here. Can you run a few of these slapds with libefence or valgrind? -- -- 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#6050) make install overwrites schema dir
by hyc＠symas.com 09 Apr '09

09 Apr '09

tmackey(a)zetta.net wrote: > Full_Name: Theral Mackey > Version: 2.4.16 > OS: Linux/Debian > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (216.200.8.2) > > > Running make install leaves an existing slapd.conf alone, but happily nukes and > replaces the existing schema directory, taking with it any additional or custom > schema, leaving you with only the ones installed by default (hooray for svn and > backups!). No, it doesn't. > For consistency, it should probably either nuke slapd.conf as well, or leave an > existing schema dir alone (I vote for option 2). > fix should be as simple as an 'if [ ! -d $base/schema ] ; then (mkdir, cp > schemas, etc) ; fi' around where it drops the schemas in place in the Makefile Since you're already looking in the Makefile, you should see this for the install-schema: rule... ### install-schema: FORCE @if test -d $(DESTDIR)$(schemadir) ; then \ echo "MOVING EXISTING SCHEMA DIR to $(DESTDIR)$(schemadir).$$$$" ; \ mv $(DESTDIR)$(schemadir) $(DESTDIR)$(schemadir).$$$$ ; \ fi $(MKDIR) $(DESTDIR)$(schemadir) ### The existing schema directory is simply renamed / moved out of the way. If you had any custom schema files stored there, they are still there. This ITS will be closed. -- -- 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#6050) make install overwrites schema dir
by tmackey＠zetta.net 09 Apr '09

09 Apr '09

Full_Name: Theral Mackey Version: 2.4.16 OS: Linux/Debian URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (216.200.8.2) Running make install leaves an existing slapd.conf alone, but happily nukes and replaces the existing schema directory, taking with it any additional or custom schema, leaving you with only the ones installed by default (hooray for svn and backups!). For consistency, it should probably either nuke slapd.conf as well, or leave an existing schema dir alone (I vote for option 2). fix should be as simple as an 'if [ ! -d $base/schema ] ; then (mkdir, cp schemas, etc) ; fi' around where it drops the schemas in place in the Makefile

1 0

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs