openldap-bugs February 2012

openldap-bugs@openldap.org

33 participants
146 discussions

Re: ITS#6598
by masarati＠aero.polimi.it 18 Feb '12

18 Feb '12

> --On Thursday, September 09, 2010 6:45 PM +0000 masarati(a)aero.polimi.it > wrote: > >> Committed to HEAD; please test. Thanks, p. > > > Doesn't appear to work to me. > > This search returns 15 entries normally: > > ldapsearch -x -H ldapi:/// -D cn=config -w zimbra -b "" > '(objectClass=zimbraAccount)' zimbraId > > # numResponses: 16 > # numEntries: 15 > > > If you choose the control you get: > > zimbra@zre-ldap003:~$ ldapsearch -x -H ldapi:/// -D cn=config -w zimbra -b > "" -e '1.3.6.1.4.1.4203.666.5.18' '(objectClass=zimbraAccount)' zimbraId > # extended LDIF > # > # LDAPv3 > # base <> with scope subtree > # filter: (objectClass=zimbraAccount) > # requesting: zimbraId > # > > # search result > search: 2 > result: 0 Success > control: 1.3.6.1.4.1.4203.666.5.18 false MAkCAQACAQ8CAQA= I think it works as expected: $ echo -n 'MAkCAQACAQ8CAQA=' | base64 -d | od -x 0000000 0930 0102 0200 0f01 0102 0000 re-ordered: 0x30 ber sequence 0x09 length (9 bytes) 0x02 ber int 0x01 length (1 byte) 0x00 "0" (value of would be search result code) 0x02 ber int 0x01 length (1 byte) 0x0f "15" (number of would be returned entries) 0x02 ber int 0x01 length (1 byte) 0x00 "0" (number of would be returned search refs) p. > > # numResponses: 1 > > MAkCAQACAQ8CAQA= decodes to a 0 followed by several spaces. If you try to > make it critical, it fails: > > zimbra@zre-ldap003:~$ ldapsearch -x -H ldapi:/// -D cn=config -w zimbra -b > "" -e '!1.3.6.1.4.1.4203.666.5.18' '(objectClass=zimbraAccount)' zimbraId > # extended LDIF > # > # LDAPv3 > # base <> with scope subtree > # filter: (objectClass=zimbraAccount) > # requesting: zimbraId > # > > # search result > search: 2 > result: 12 Critical extension is unavailable > text: critical control unavailable in context > > # numResponses: 1 > > > --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

Re: ITS#6598
by quanah＠zimbra.com 18 Feb '12

18 Feb '12

--On Friday, February 17, 2012 11:48 PM +0000 quanah(a)zimbra.com wrote: > --On Thursday, September 09, 2010 6:45 PM +0000 masarati(a)aero.polimi.it > wrote: > >> Committed to HEAD; please test. Thanks, p. > > > Doesn't appear to work to me. > > This search returns 15 entries normally: > > ldapsearch -x -H ldapi:/// -D cn=config -w zimbra -b "" > '(objectClass=zimbraAccount)' zimbraId > ># numResponses: 16 ># numEntries: 15 > > > If you choose the control you get: > > zimbra@zre-ldap003:~$ ldapsearch -x -H ldapi:/// -D cn=config -w zimbra > -b "" -e '1.3.6.1.4.1.4203.666.5.18' '(objectClass=zimbraAccount)' Also, just to show it is definitely loaded: ldapsearch -x -H ldap://zre-ldap003.eng.vmware.com -s base -b "" + dn: structuralObjectClass: OpenLDAProotDSE configContext: cn=config monitorContext: cn=Monitor namingContexts: supportedControl: 1.3.6.1.4.1.4203.666.5.18 --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

Re: ITS#6598
by quanah＠zimbra.com 18 Feb '12

18 Feb '12

--On Thursday, September 09, 2010 6:45 PM +0000 masarati(a)aero.polimi.it wrote: > Committed to HEAD; please test. Thanks, p. Doesn't appear to work to me. This search returns 15 entries normally: ldapsearch -x -H ldapi:/// -D cn=config -w zimbra -b "" '(objectClass=zimbraAccount)' zimbraId # numResponses: 16 # numEntries: 15 If you choose the control you get: zimbra@zre-ldap003:~$ ldapsearch -x -H ldapi:/// -D cn=config -w zimbra -b "" -e '1.3.6.1.4.1.4203.666.5.18' '(objectClass=zimbraAccount)' zimbraId # extended LDIF # # LDAPv3 # base <> with scope subtree # filter: (objectClass=zimbraAccount) # requesting: zimbraId # # search result search: 2 result: 0 Success control: 1.3.6.1.4.1.4203.666.5.18 false MAkCAQACAQ8CAQA= # numResponses: 1 MAkCAQACAQ8CAQA= decodes to a 0 followed by several spaces. If you try to make it critical, it fails: zimbra@zre-ldap003:~$ ldapsearch -x -H ldapi:/// -D cn=config -w zimbra -b "" -e '!1.3.6.1.4.1.4203.666.5.18' '(objectClass=zimbraAccount)' zimbraId # extended LDIF # # LDAPv3 # base <> with scope subtree # filter: (objectClass=zimbraAccount) # requesting: zimbraId # # search result search: 2 result: 12 Critical extension is unavailable text: critical control unavailable in context # numResponses: 1 --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

Re: (ITS#7170) back-mdb indexing generation failure
by quanah＠zimbra.com 18 Feb '12

18 Feb '12

--On Friday, February 17, 2012 4:03 AM +0000 quanah(a)zimbra.com wrote: > > Further update -- If I reload the database with just "slapadd", searches > work. If I use quickmode "slapadd -q", the searches fail. So there is a > bug in index generation with quick mode slapadd. Oddly enough, it only occurs on a system that has two databases configured -- An accesslog DB for delta-syncrepl, and a DB for the primary data. --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

Re: (ITS#7172) SEGFAULT in openldap-2.4.28 & 2.4.29
by hyc＠symas.com 18 Feb '12

18 Feb '12

dcoutadeur(a)linagora.com wrote: > Full_Name: dcoutadeur > Version: 2.4.28 > OS: Red Hat Enterprise Linux Server release 5.7 (Tikanga) > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (109.197.176.10) > > > > Hello, > > > I had a segfault in the last git version of OpenLDAP, after 10 to 15 tests, each > interrupted by Ctrl+C. (see what's a test below) > The segfault is also reproduced in version 2.4.28. > > I think I won't be able to reproduce the bug with Valgrind. If you expect us to try to reproduce the bug, you'll have to provide more information. Since this crash is in syncprov there's obviously at least two servers involved; what are their configurations? What hardware are they running on (in particular, how many CPU cores per server)? Since you're using a custom client, can you provide the client source code? > > Thank you in advance for any help. > > D. > > > Note : A test is 100 times 100 threads, each doing a bind, an add, a modify, a > delete, and a logout. > > > > > > (gdb) bt full > #0 sp_avl_cmp (c1=0x8b4004c8, c2=0xa37cf28) at syncprov.c:366 > rc =<value optimized out> > #1 0x081afe3e in avl_delete (root=0xa255648, data=0x8b4004c8, > fcmp=0x81948a0<sp_avl_cmp>) at avl.c:197 > p =<value optimized out> > q =<value optimized out> > r =<value optimized out> > top =<value optimized out> > side =<value optimized out> > side_bf =<value optimized out> > shorter =<value optimized out> > nside =<value optimized out> > pptr = {0x89908, 0x0, 0x0, 0x0, 0xe8043c, 0x0, 0xfdc, > 0x8d994858, 0xe7b95c, 0xfdc, 0xa372570, 0x0, 0xa288350, > 0xe8043c, 0xa372570, 0x8d994878, 0xe7c324, 0xfdc, 0xa372570, > 0x0, 0xe7af2c, 0x8cb9136e, 0x81b3634, 0x0, 0xe8043c, > 0xe, 0xa3d3a40, 0x8d9948b8, 0xe7d081, 0xa3e3618, 0x8cb91358, > 0x823c27} > pdir = > "\000\000\000\000lI\231\215\064\066\033\bn>\000\000\244\345t\000\310\004@\213\b\346\067\n\310H\231\215" > depth = 0 > #2 0x08199f7f in syncprov_op_cleanup (op=0xa37e608, rs=0x8d995108) at > syncprov.c:1401 > cb = 0x8cb91258 > opc = 0x8cb91268 > si = 0xa255610 > sm = 0xa255688 > snext =<value optimized out> > mt = 0x8b4004c8 > #3 0x08089654 in slap_cleanup_play (op=0xa37e608, rs=0x8d995108) at > result.c:541 > sc_next = 0x8d994dec > sc = 0x8cb91258 > scp = 0x8d994928 > #4 0x0808a150 in send_ldap_response (op=0xa37e608, rs=0x8d995108) at > result.c:733 > berbuf = { > buffer = "\000\000\001\000\000\001\000\000\377\377\377\377", > '\000'<repeats 12 times>, > "f\023\271\214\064#\271\214\000\000\000\000f\023\271\214p%7\n\000\000\000\000\314I\231\215\001\000\000\000\000\000\000\000\314mK\236x\271\347\000\001\000\000\000`+@\213D`K\236\230\063\066\n\250<6\n\000\000\000\000\000\000\000\000\005\000\000\000P7@\213`\343\070\n\000\000\000\000\n\000\000\000(\234\200\330\000\000\000\000\000\000\000\000@4\"\000\000\000\000\000(\234\200\330\210J\231\215\270\214 > \000\230\063\066\n`+@\213\314mK\236\r\000\000\000\001\000\000\000\021\217;O(\234\200\330\000\000\000\000`&%\n`&%\n8J\231\215b\f\"\000\224mK\236\230\063\066\n(\234\200أ\347\022\b\a", > '\000'<repeats 31 times>, "D'%\n\224mK\236\000\000\000", > ialign = 65536, lalign = 65536, falign = 9.18354962e-41, > dalign = 5.4323095486619588e-312, > palign = 0x10000<Address 0x10000 out of bounds>} > ber =<value optimized out> > rc = 32768 > bytes = 14 > __PRETTY_FUNCTION__ = "send_ldap_response" > #5 0x0808af1f in slap_send_ldap_result (op=0xa37e608, rs=0x8d995108) at > result.c:860 > tmp = 0x0 > otext = 0x0 > oref = 0x0 > __PRETTY_FUNCTION__ = "slap_send_ldap_result" > #6 0x0812bde5 in bdb_add (op=0xa37e608, rs=0x8d995108) at add.c:511 > pdn = {bv_len = 23, bv_val = 0x8b40372f "ou=people,dc=afp,dc=com"} > p = 0x8fc4c0fc > oe = 0x8fc4c804 > ei = 0xa37d1c8 > textbuf = "\000\000\000\000\320O\"\n", '\000'<repeats 48 > times>, "\001", '\000'<repeats 198 times> > children = 0xa223b20 > entry = 0xa223980 > ltid = 0x0 > lt2 = 0x8b402bf0 > eid = 57976 > opinfo = {boi_oe = {oe_next = {sle_next = 0x8d99509c}, oe_key = > 0x0}, boi_txn = 0x8b402b60, boi_locks = 0x0, > boi_err = 0, boi_acl_cache = 0 '\000', boi_flag = 0 '\000'} > lock = {off = 133260, ndx = 772, gen = 2004, mode = DB_LOCK_READ} > num_retries = 0 > success = 0 > postread_ctrl = 0x0 > ctrls = {0x0, 0x0, 0x0, 0x0, 0x0, 0x0} > num_ctrls = 0 > #7 0x080e33a1 in overlay_op_walk (op=0xa37e608, rs=0x8d995108, > which=op_add, oi=0xa254ff0, on=0xa255508) at backover.c:671 > rc = 32768 > #8 0x080e3a0a in over_op_func (op=0xa37e608, rs=0x8d995108, > which=op_add) at backover.c:723 > oi = 0xa254ff0 > on = 0xa255508 > be = 0xa252560 > db = {bd_info = 0x821d41c, bd_self = 0xa252560, > be_ctrls = > "\000\001\001\001\000\001\000\000\001\000\000\001\001\000\001\001\000\000\000\000\001\000\001\000\000\000\000\000\000\000\000\000\001", > be_flags = 563464, 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 = > 0xa288350, be_nsuffix = 0xa288368, be_schemadn = { > bv_len = 0, bv_val = 0x0}, be_schemandn = {bv_len = 0, > bv_val = 0x0}, be_rootdn = {bv_len = 24, > bv_val = 0xa287648 "cn=Manager,dc=afp,dc=com"}, be_rootndn = > {bv_len = 24, > bv_val = 0xa2876d0 "cn=manager,dc=afp,dc=com"}, be_rootpw = > {bv_len = 38, > bv_val = 0xa2876f0 > "{SSHA}rEmMhg3MU5xkQX5Ng92tH4WzGMlA+nGU"}, be_max_deref_depth = 15, > be_def_limit = { > lms_t_soft = 3600, lms_t_hard = 0, lms_s_soft = 15000, > lms_s_hard = 0, lms_s_unchecked = -1, lms_s_pr = 0, > lms_s_pr_hide = 0, lms_s_pr_total = 0}, be_limits = > 0xa255748, be_acl = 0x0, 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 = 0xa363388, be_pcl_mutex = {__data = > {__lock = 0, __count = 0, __owner = 0, __kind = 0, > __nusers = 0, {__spins = 0, __list = {__next = 0x0}}}, > __size = '\000'<repeats 23 times>, __align = 0}, > be_syncinfo = 0xa28aec8, be_pb = 0x0, be_cf_ocs = 0x821f840, > be_private = 0xa252660, be_next = { > stqe_next = 0xa288538}} > cb = {sc_next = 0x0, sc_response = 0x80e30e0 > <over_back_response>, sc_cleanup = 0, sc_private = 0xa254ff0} > sc =<value optimized out> > rc =<value optimized out> > __PRETTY_FUNCTION__ = "over_op_func" > #9 0x08081129 in fe_op_add (op=0xa37e608, rs=0x8d995108) at add.c:334 > repl_user = 0 > rc =<value optimized out> > bd = 0x82234c0 > textbuf = > "\000\000\000\000\000\000\000\000\060[\231\215\000\000\000\000\035\000\000\000\020\070@\213\001\000\000\000xN\231\215\270\026@\213(I\"\n\002\000\000\000\250N\231\215\255\214\v\b\270\026@\213\224N\231\215\001\000\000\000\000\000\000\000x9@\213\000\000\000\000\n\000\000\000\001\000\000\000\340\067@\213\n\000\000\000\060\070@\213\320\026@\213(I\"\n\270\026@\213\370N\231\215oc\t\b\002\000\000\000X( > \n\370N\231\215\321_\t\bh\234!\n\240\066@\213'<\202\000\000\000\000\000\f\000\000\000W.@\213n>\000\000\244\345t\000\320O\"\n\320O\"\n\370N\231\215\035\205q\000 > .\"\b\314h\032\216\030O\231\215\245\063\b\b > .\"\b\240\066@\213\000\000\000\000\270\026@\213\244i\032\216\000\000\000\000HO\231\215\267\r\b\b\320O\"\n\320O\"\n\001\000\000\000HO\231\215\020\000\000\000\340h\032\216\377\377\377\377" > __PRETTY_FUNCTION__ = "fe_op_add" > #10 0x08081a13 in do_add (op=0xa37e608, rs=0x8d995108) at add.c:194 > ber =<value optimized out> > last = 0x8b402e71 "" > dn = {bv_len = 38, bv_val = 0x8b402d98 > "uid=dcoutadeur,ou=People,dc=afp,dc=com"} > len = 28 > tag =<value optimized out> > modlist = 0x8b4015f0 > modtail = 0x8b403694 > tmp = {sml_mod = {sm_desc = 0x80ce5ca, sm_values = 0x8b4036a0, > sm_nvalues = 0x0, sm_numvals = 2375635128, > sm_op = 0, sm_flags = 0, sm_type = {bv_len = 12, bv_val = > 0x8b402e57 "userPassword"}}, sml_next = 0x823c27} > textbuf = > "\025\000\000\000\310\031@\213\b\026@\213\006\340(\000\220[\231\215\000\000\000\000\000\000\000\000\020\000@\213\025\000\000\000\310\031@\213\310+@\213\005\070/\000\200O@\213T\245(\000\000\000\000\000\020\000@\213\364\237\067\000\220[\231\215\000\000\000\000\233\071@\213@:=\n\370O\231\215T\213\202\000b\213\202\000;\334\347\000\"\000\000\000\233\071@\213\b\000\000\000\201\354(\000\fP\231\215<\004\350\000\270P\231\215\312\315\347\000\370\326\070\n\233\071@\213\b\000\000\000\001\200\255\373\b\347\067\n@\000\000\000\243P\231\215@\000@\213\026\347\067\n@\000@\213\b\347\067\n@\261\067\000,\000\000\000\020\000@\213", > '\000'<repeats 20 times>, > "5\000\000\000@\000@\213\000\000\000\000\340\021@\213\000\000\000\000\000\000\000\000\260+@\213\000\000\000\000\001\000\000\000\004\000\020\000\350Q\231\215\310P\231\215" > rc =<value optimized out> > freevals =<value optimized out> > oex = {oe = {oe_next = {sle_next = 0x0}, oe_key = 0x8081330}, > oe_db = 0x0} > #11 0x0807988c in connection_operation (ctx=0x8d9951e8, arg_v=0xa37e608) > at connection.c:1150 > rc =<value optimized out> > cancel =<value optimized out> > rs = {sr_type = REP_RESULT, sr_tag = 105, sr_msgid = 2, 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} > tag = 104 > opidx = SLAP_OP_ADD > conn = 0xb7f3bc10 > memctx = 0xa372570 > memctx_null = 0x0 > __PRETTY_FUNCTION__ = "connection_operation" > #12 0x0807a0fd in connection_read_thread (ctx=0x8d9951e8, argv=0x22) at > connection.c:1286 > s =<value optimized out> > #13 0x00717a24 in ldap_int_thread_pool_wrapper (xpool=0xa2265c8) at > tpool.c:688 > task = 0xa382e10 > work_list =<value optimized out> > ctx = {ltu_id = 2375637904, ltu_key = {{ltk_key = 0x80ce400, > ltk_data = 0xa372570, > ltk_free = 0x80ce430<slap_sl_mem_destroy>}, {ltk_key = > 0xa363398, ltk_data = 0xa371a88, > ltk_free = 0x812e4c0<bdb_reader_free>}, {ltk_key = > 0x8078320, ltk_data = 0xa37de68, > ltk_free = 0x80783f0<conn_counter_destroy>}, {ltk_key = > 0x808dde0, ltk_data = 0x0, > ltk_free = 0x808dbf0<slap_op_q_destroy>}, {ltk_key = 0x0, > ltk_data = 0x0, ltk_free = 0}<repeats 28 times>}} > kctx =<value optimized out> > keyslot = 241 > hash = 5278961 > __PRETTY_FUNCTION__ = "ldap_int_thread_pool_wrapper" > #14 0x00821832 in start_thread () from /lib/libpthread.so.0 > No symbol table info available. > #15 0x002f746e in clone () from /lib/libc.so.6 > No symbol table info available. > > > > > -- -- 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#7172) SEGFAULT in openldap-2.4.28 & 2.4.29
by dcoutadeur＠linagora.com 18 Feb '12

18 Feb '12

Full_Name: dcoutadeur Version: 2.4.28 OS: Red Hat Enterprise Linux Server release 5.7 (Tikanga) URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (109.197.176.10) Hello, I had a segfault in the last git version of OpenLDAP, after 10 to 15 tests, each interrupted by Ctrl+C. (see what's a test below) The segfault is also reproduced in version 2.4.28. I think I won't be able to reproduce the bug with Valgrind. Thank you in advance for any help. D. Note : A test is 100 times 100 threads, each doing a bind, an add, a modify, a delete, and a logout. (gdb) bt full #0 sp_avl_cmp (c1=0x8b4004c8, c2=0xa37cf28) at syncprov.c:366 rc = <value optimized out> #1 0x081afe3e in avl_delete (root=0xa255648, data=0x8b4004c8, fcmp=0x81948a0 <sp_avl_cmp>) at avl.c:197 p = <value optimized out> q = <value optimized out> r = <value optimized out> top = <value optimized out> side = <value optimized out> side_bf = <value optimized out> shorter = <value optimized out> nside = <value optimized out> pptr = {0x89908, 0x0, 0x0, 0x0, 0xe8043c, 0x0, 0xfdc, 0x8d994858, 0xe7b95c, 0xfdc, 0xa372570, 0x0, 0xa288350, 0xe8043c, 0xa372570, 0x8d994878, 0xe7c324, 0xfdc, 0xa372570, 0x0, 0xe7af2c, 0x8cb9136e, 0x81b3634, 0x0, 0xe8043c, 0xe, 0xa3d3a40, 0x8d9948b8, 0xe7d081, 0xa3e3618, 0x8cb91358, 0x823c27} pdir = "\000\000\000\000lI\231\215\064\066\033\bn>\000\000\244\345t\000\310\004@\213\b\346\067\n\310H\231\215" depth = 0 #2 0x08199f7f in syncprov_op_cleanup (op=0xa37e608, rs=0x8d995108) at syncprov.c:1401 cb = 0x8cb91258 opc = 0x8cb91268 si = 0xa255610 sm = 0xa255688 snext = <value optimized out> mt = 0x8b4004c8 #3 0x08089654 in slap_cleanup_play (op=0xa37e608, rs=0x8d995108) at result.c:541 sc_next = 0x8d994dec sc = 0x8cb91258 scp = 0x8d994928 #4 0x0808a150 in send_ldap_response (op=0xa37e608, rs=0x8d995108) at result.c:733 berbuf = { buffer = "\000\000\001\000\000\001\000\000\377\377\377\377", '\000' <repeats 12 times>, "f\023\271\214\064#\271\214\000\000\000\000f\023\271\214p%7\n\000\000\000\000\314I\231\215\001\000\000\000\000\000\000\000\314mK\236x\271\347\000\001\000\000\000`+@\213D`K\236\230\063\066\n\250<6\n\000\000\000\000\000\000\000\000\005\000\000\000P7@\213`\343\070\n\000\000\000\000\n\000\000\000(\234\200\330\000\000\000\000\000\000\000\000@4\"\000\000\000\000\000(\234\200\330\210J\231\215\270\214 \000\230\063\066\n`+@\213\314mK\236\r\000\000\000\001\000\000\000\021\217;O(\234\200\330\000\000\000\000`&%\n`&%\n8J\231\215b\f\"\000\224mK\236\230\063\066\n(\234\200أ\347\022\b\a", '\000' <repeats 31 times>, "D'%\n\224mK\236\000\000\000", ialign = 65536, lalign = 65536, falign = 9.18354962e-41, dalign = 5.4323095486619588e-312, palign = 0x10000 <Address 0x10000 out of bounds>} ber = <value optimized out> rc = 32768 bytes = 14 __PRETTY_FUNCTION__ = "send_ldap_response" #5 0x0808af1f in slap_send_ldap_result (op=0xa37e608, rs=0x8d995108) at result.c:860 tmp = 0x0 otext = 0x0 oref = 0x0 __PRETTY_FUNCTION__ = "slap_send_ldap_result" #6 0x0812bde5 in bdb_add (op=0xa37e608, rs=0x8d995108) at add.c:511 pdn = {bv_len = 23, bv_val = 0x8b40372f "ou=people,dc=afp,dc=com"} p = 0x8fc4c0fc oe = 0x8fc4c804 ei = 0xa37d1c8 textbuf = "\000\000\000\000\320O\"\n", '\000' <repeats 48 times>, "\001", '\000' <repeats 198 times> children = 0xa223b20 entry = 0xa223980 ltid = 0x0 lt2 = 0x8b402bf0 eid = 57976 opinfo = {boi_oe = {oe_next = {sle_next = 0x8d99509c}, oe_key = 0x0}, boi_txn = 0x8b402b60, boi_locks = 0x0, boi_err = 0, boi_acl_cache = 0 '\000', boi_flag = 0 '\000'} lock = {off = 133260, ndx = 772, gen = 2004, mode = DB_LOCK_READ} num_retries = 0 success = 0 postread_ctrl = 0x0 ctrls = {0x0, 0x0, 0x0, 0x0, 0x0, 0x0} num_ctrls = 0 #7 0x080e33a1 in overlay_op_walk (op=0xa37e608, rs=0x8d995108, which=op_add, oi=0xa254ff0, on=0xa255508) at backover.c:671 rc = 32768 #8 0x080e3a0a in over_op_func (op=0xa37e608, rs=0x8d995108, which=op_add) at backover.c:723 oi = 0xa254ff0 on = 0xa255508 be = 0xa252560 db = {bd_info = 0x821d41c, bd_self = 0xa252560, be_ctrls = "\000\001\001\001\000\001\000\000\001\000\000\001\001\000\001\001\000\000\000\000\001\000\001\000\000\000\000\000\000\000\000\000\001", be_flags = 563464, 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 = 0xa288350, be_nsuffix = 0xa288368, be_schemadn = { bv_len = 0, bv_val = 0x0}, be_schemandn = {bv_len = 0, bv_val = 0x0}, be_rootdn = {bv_len = 24, bv_val = 0xa287648 "cn=Manager,dc=afp,dc=com"}, be_rootndn = {bv_len = 24, bv_val = 0xa2876d0 "cn=manager,dc=afp,dc=com"}, be_rootpw = {bv_len = 38, bv_val = 0xa2876f0 "{SSHA}rEmMhg3MU5xkQX5Ng92tH4WzGMlA+nGU"}, be_max_deref_depth = 15, be_def_limit = { lms_t_soft = 3600, lms_t_hard = 0, lms_s_soft = 15000, lms_s_hard = 0, lms_s_unchecked = -1, lms_s_pr = 0, lms_s_pr_hide = 0, lms_s_pr_total = 0}, be_limits = 0xa255748, be_acl = 0x0, 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 = 0xa363388, be_pcl_mutex = {__data = {__lock = 0, __count = 0, __owner = 0, __kind = 0, __nusers = 0, {__spins = 0, __list = {__next = 0x0}}}, __size = '\000' <repeats 23 times>, __align = 0}, be_syncinfo = 0xa28aec8, be_pb = 0x0, be_cf_ocs = 0x821f840, be_private = 0xa252660, be_next = { stqe_next = 0xa288538}} cb = {sc_next = 0x0, sc_response = 0x80e30e0 <over_back_response>, sc_cleanup = 0, sc_private = 0xa254ff0} sc = <value optimized out> rc = <value optimized out> __PRETTY_FUNCTION__ = "over_op_func" #9 0x08081129 in fe_op_add (op=0xa37e608, rs=0x8d995108) at add.c:334 repl_user = 0 rc = <value optimized out> bd = 0x82234c0 textbuf = "\000\000\000\000\000\000\000\000\060[\231\215\000\000\000\000\035\000\000\000\020\070@\213\001\000\000\000xN\231\215\270\026@\213(I\"\n\002\000\000\000\250N\231\215\255\214\v\b\270\026@\213\224N\231\215\001\000\000\000\000\000\000\000x9@\213\000\000\000\000\n\000\000\000\001\000\000\000\340\067@\213\n\000\000\000\060\070@\213\320\026@\213(I\"\n\270\026@\213\370N\231\215oc\t\b\002\000\000\000X( \n\370N\231\215\321_\t\bh\234!\n\240\066@\213'<\202\000\000\000\000\000\f\000\000\000W.@\213n>\000\000\244\345t\000\320O\"\n\320O\"\n\370N\231\215\035\205q\000 .\"\b\314h\032\216\030O\231\215\245\063\b\b .\"\b\240\066@\213\000\000\000\000\270\026@\213\244i\032\216\000\000\000\000HO\231\215\267\r\b\b\320O\"\n\320O\"\n\001\000\000\000HO\231\215\020\000\000\000\340h\032\216\377\377\377\377" __PRETTY_FUNCTION__ = "fe_op_add" #10 0x08081a13 in do_add (op=0xa37e608, rs=0x8d995108) at add.c:194 ber = <value optimized out> last = 0x8b402e71 "" dn = {bv_len = 38, bv_val = 0x8b402d98 "uid=dcoutadeur,ou=People,dc=afp,dc=com"} len = 28 tag = <value optimized out> modlist = 0x8b4015f0 modtail = 0x8b403694 tmp = {sml_mod = {sm_desc = 0x80ce5ca, sm_values = 0x8b4036a0, sm_nvalues = 0x0, sm_numvals = 2375635128, sm_op = 0, sm_flags = 0, sm_type = {bv_len = 12, bv_val = 0x8b402e57 "userPassword"}}, sml_next = 0x823c27} textbuf = "\025\000\000\000\310\031@\213\b\026@\213\006\340(\000\220[\231\215\000\000\000\000\000\000\000\000\020\000@\213\025\000\000\000\310\031@\213\310+@\213\005\070/\000\200O@\213T\245(\000\000\000\000\000\020\000@\213\364\237\067\000\220[\231\215\000\000\000\000\233\071@\213@:=\n\370O\231\215T\213\202\000b\213\202\000;\334\347\000\"\000\000\000\233\071@\213\b\000\000\000\201\354(\000\fP\231\215<\004\350\000\270P\231\215\312\315\347\000\370\326\070\n\233\071@\213\b\000\000\000\001\200\255\373\b\347\067\n@\000\000\000\243P\231\215@\000@\213\026\347\067\n@\000@\213\b\347\067\n@\261\067\000,\000\000\000\020\000@\213", '\000' <repeats 20 times>, "5\000\000\000@\000@\213\000\000\000\000\340\021@\213\000\000\000\000\000\000\000\000\260+@\213\000\000\000\000\001\000\000\000\004\000\020\000\350Q\231\215\310P\231\215" rc = <value optimized out> freevals = <value optimized out> oex = {oe = {oe_next = {sle_next = 0x0}, oe_key = 0x8081330}, oe_db = 0x0} #11 0x0807988c in connection_operation (ctx=0x8d9951e8, arg_v=0xa37e608) at connection.c:1150 rc = <value optimized out> cancel = <value optimized out> rs = {sr_type = REP_RESULT, sr_tag = 105, sr_msgid = 2, 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} tag = 104 opidx = SLAP_OP_ADD conn = 0xb7f3bc10 memctx = 0xa372570 memctx_null = 0x0 __PRETTY_FUNCTION__ = "connection_operation" #12 0x0807a0fd in connection_read_thread (ctx=0x8d9951e8, argv=0x22) at connection.c:1286 s = <value optimized out> #13 0x00717a24 in ldap_int_thread_pool_wrapper (xpool=0xa2265c8) at tpool.c:688 task = 0xa382e10 work_list = <value optimized out> ctx = {ltu_id = 2375637904, ltu_key = {{ltk_key = 0x80ce400, ltk_data = 0xa372570, ltk_free = 0x80ce430 <slap_sl_mem_destroy>}, {ltk_key = 0xa363398, ltk_data = 0xa371a88, ltk_free = 0x812e4c0 <bdb_reader_free>}, {ltk_key = 0x8078320, ltk_data = 0xa37de68, ltk_free = 0x80783f0 <conn_counter_destroy>}, {ltk_key = 0x808dde0, ltk_data = 0x0, ltk_free = 0x808dbf0 <slap_op_q_destroy>}, {ltk_key = 0x0, ltk_data = 0x0, ltk_free = 0} <repeats 28 times>}} kctx = <value optimized out> keyslot = 241 hash = 5278961 __PRETTY_FUNCTION__ = "ldap_int_thread_pool_wrapper" #14 0x00821832 in start_thread () from /lib/libpthread.so.0 No symbol table info available. #15 0x002f746e in clone () from /lib/libc.so.6 No symbol table info available.

1 0

Re: (ITS#7171) RefInt overlay: olcRefIntNothing doesn't kick in when deleting last member from group
by h.b.furuseth＠usit.uio.no 18 Feb '12

18 Feb '12

Looks like a duplicate of ITS#6663, which was fixed in OpenLDAP 2.4.24.

1 0

(ITS#7171) RefInt overlay: olcRefIntNothing doesn't kick in when deleting last member from group
by p.nijs＠xs4all.nl 17 Feb '12

17 Feb '12

Full_Name: Patrick Nijs Version: 2.4.23 OS: Debian Squeeze x86 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (2001:980:74b5:1:bcd8:7053:70b4:377d) I have a clean install of Debian Squeeze, and a clean install of OpenLDAP. Now I have enabled the REFINT overlay (it's the only overlay I am using): To enable it, I executed the following commands as root: echo " dn: cn=module{0},cn=config add: olcModuleLoad olcModuleLoad: refint " | ldapmodify -Y EXTERNAL -H ldapi:/// and: echo " dn: olcOverlay=refint,olcDatabase={1}hdb,cn=config changetype: add objectClass: olcRefintConfig objectClass: olcOverlayConfig objectClass: olcConfig objectClass: top olcOverlay: refint olcRefintAttribute: member olcRefintNothing: cn=admin,dc=domain,dc=local " | ldapmodify -Y EXTERNAL -H ldapi:/// The good thing is that if I rename the DN of a group member, all goes well. The only BAD thing is, that when I delete a user which is the ONLY MEMBER OF A GROUP, then the olcRefintNothing does NOT KICK IN. I expect that that when the last member of a group is deleted, then the member attribute of that group is replaced with the DN as specified in olcRefintNothing. This doesn't happen. Here is a snippet from my syslog (loglevel -1), where cn=test,dc=domein,dc=local is the GROUP (groupOfNames) with the member ATTRIBUTE. uid=peter1,dc=domein,dc=local is a User (account) and the only member left in the aforementioned group. When I delete this user this shows up in the log: Feb 17 13:27:27 vm03 slapd[25075]: refint_search_cb <cn=test,dc=domein,dc=local> Feb 17 13:27:27 vm03 slapd[25075]: refint_search_cb: member: uid=peter1,dc=domein,dc=local (#1) Feb 17 13:27:27 vm03 slapd[25075]: send_ldap_result: conn=-1 op=0 p=0 Feb 17 13:27:27 vm03 slapd[25075]: send_ldap_result: err=0 matched="" text="" Feb 17 13:27:27 vm03 slapd[25075]: refint_search_cb <NOTHING> Feb 17 13:27:27 vm03 slapd[25075]: hdb_modify: cn=test,dc=domein,dc=local Feb 17 13:27:27 vm03 slapd[25075]: slap_queue_csn: queing 0xb59c06b6 20120217122727.743313Z#000000#000#000000 Feb 17 13:27:27 vm03 slapd[25075]: bdb_dn2entry("cn=test,dc=domein,dc=local") Feb 17 13:27:27 vm03 slapd[25075]: bdb_modify_internal: 0x00000006: cn=test,dc=domein,dc=local Feb 17 13:27:27 vm03 slapd[25075]: <= acl_access_allowed: granted to database root Feb 17 13:27:27 vm03 slapd[25075]: bdb_modify_internal: delete member Feb 17 13:27:27 vm03 slapd[25075]: dnMatch 0#012#011"uid=peter1,dc=domein,dc=local"#012#011"uid=peter1,dc=domein,dc=local" Feb 17 13:27:27 vm03 slapd[25075]: bdb_modify_internal: replace modifiersName Feb 17 13:27:27 vm03 slapd[25075]: bdb_modify_internal: delete member Feb 17 13:27:27 vm03 slapd[25075]: bdb_modify_internal: 16 modify/delete: member: no such attribute Feb 17 13:27:27 vm03 slapd[25075]: hdb_modify: modify failed (16) Feb 17 13:27:27 vm03 slapd[25075]: send_ldap_result: conn=-1 op=0 p=0 Feb 17 13:27:27 vm03 slapd[25075]: send_ldap_result: err=16 matched="" text="modify/delete: member: no such attribute" Feb 17 13:27:27 vm03 slapd[25075]: slap_graduate_commit_csn: removing 0x938a7d0 20120217122727.743313Z#000000#000#000000 Feb 17 13:27:27 vm03 slapd[25075]: refint_repair: dependent modify failed: 16 Feb 17 13:27:27 vm03 slapd[25075]: daemon: activity on 1 descriptor I see that the REFINT overlay is kicking in, but it comes with the following error: bdb_modify_internal: 16 modify/delete: member: no such attribute That is strange, because this groupOfNames certainly has a member attribute. Is this a bug? Thanks in advance, Patrick

1 0

Re: (ITS#7170) back-mdb indexing generation failure
by quanah＠zimbra.com 17 Feb '12

17 Feb '12

--On February 17, 2012 3:22:47 AM +0000 quanah(a)zimbra.com wrote: > --On Friday, February 17, 2012 3:14 AM +0000 quanah(a)OpenLDAP.org wrote: > >> Full_Name: Quanah Gibson-Mount >> Version: 2.4.29 >> OS: Linux 2.6 >> URL: ftp://ftp.openldap.org/incoming/ >> Submission from: (NULL) (75.108.184.39) >> >> >> If one has a back-mdb database, some searches on the indexed attr of "cn" >> fail. I do not see this issue with an identically configured back-hdb >> install. > > In checking some other entries, it only appears to occur with the filters: > > "(cn=zimbra)" > > and > > "(cn=config)" > > All other cn=xxxx values I tested work correctly. Further update -- If I reload the database with just "slapadd", searches work. If I use quickmode "slapadd -q", the searches fail. So there is a bug in index generation with quick mode slapadd. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#7170) back-mdb indexing generation failure
by quanah＠zimbra.com 17 Feb '12

17 Feb '12

--On Friday, February 17, 2012 3:14 AM +0000 quanah(a)OpenLDAP.org wrote: > Full_Name: Quanah Gibson-Mount > Version: 2.4.29 > OS: Linux 2.6 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (75.108.184.39) > > > If one has a back-mdb database, some searches on the indexed attr of "cn" > fail. I do not see this issue with an identically configured back-hdb > install. In checking some other entries, it only appears to occur with the filters: "(cn=zimbra)" and "(cn=config)" All other cn=xxxx values I tested work correctly. --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

← Newer
1
2
3
4
5
6
7
8
...
15
Older →

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs February 2012