openldap-bugs

openldap-bugs@openldap.org

1 participants
20963 discussions

(ITS#7172) SEGFAULT in openldap-2.4.28 & 2.4.29
by dcoutadeur＠linagora.com 17 Feb '12

17 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 17 Feb '12

17 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 16 Feb '12

16 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 16 Feb '12

16 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

Re: (ITS#7166) MDB segfault
by quanah＠zimbra.com 16 Feb '12

16 Feb '12

--On Friday, February 17, 2012 1:52 AM +0000 hyc(a)symas.com wrote: > tomasz.rutkowski(a)tombas.pl wrote: >> --=-KyDwFvnw0ca1u3hWxz7q >> Content-Type: text/plain; charset="UTF-8" >> Content-Transfer-Encoding: quoted-printable >> >> Dnia 2012-02-15, =C5=9Bro o godzinie 10:11 -0800, Quanah Gibson-Mount >> pisze= : >>> --On Wednesday, February 15, 2012 1:00 PM +0000 >>> tomasz.rutkowski(a)tombas.p= >> l=20 >>> wrote: >>> =20 >>>> Full_Name: Tomasz Rutkowski >>>> Version: 2.4.28, 2.4.29 >>>> OS: PLD Linux (Th) x86_64 >>>> URL: >>>> Submission from: (NULL) (91.216.16.90) >>>> >>>> >>>> back_mdb crashes when it's accessed through back_relay >>>> (rwm-suffixmassa= >> ge >>>> rewrite) for authentication, works normal for search/write however. >>> =20 >>> =20 >>> Please provide a full backtrace from gdb, with debugging symbols. >>> =20 > > In addition, please provide the config of your mdb database as well. > There's more modules involved here than just rwm, relay, and mdb and the > entire combination is relevant. Also, have you verified that the same > combination using back-bdb/hdb works correctly? > > This looks more like an rwm bug to me than a backend bug. Could be related to <http://www.openldap.org/its/index.cgi/?findid=5941> and <http://www.openldap.org/its/index.cgi/?findid=6166> --Quanah -- Quanah Gibson-Mount Sr. Member of Technical Staff Zimbra, Inc A Division of VMware, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

(ITS#7170) back-mdb indexing generation failure
by quanah＠OpenLDAP.org 16 Feb '12

16 Feb '12

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. cn is explicitly indexed in my db: olcDbIndex: cn pres,eq,sub This works: zimbra@zre-ldap002:~$ ldapsearch -LLL -x -H ldapi:/// -D cn=config -w zimbra -b "cn=config,cn=zimbra" -s base createTimeStamp cn dn: cn=config,cn=zimbra cn: config createTimestamp: 20120217022019Z However, the following searches all fail: ldapsearch -LLL -x -H ldapi:/// -D cn=config -w zimbra -b "cn=zimbra" -s sub cn=config cn ldapsearch -LLL -x -H ldapi:/// -D cn=config -w zimbra -b "" -s sub cn=config cn ldapsearch -LLL -x -H ldapi:/// -D cn=config -w zimbra cn=config ldapsearch -LLL -x -H ldapi:/// -D cn=config -w zimbra cn=zimbra ldapsearch -LLL -x -H ldapi:/// -D cn=config -w zimbra "(cn=zimbra)" However, the following searches work: ldapsearch -LLL -x -H ldapi:/// -D cn=config -w zimbra "(cn=zre-ldap003.eng.vmware.com)" cn dn: cn=zre-ldap003.eng.vmware.com,cn=servers,cn=zimbra cn: zre-ldap003.eng.vmware.com zimbra@zre-ldap002:~/data/ldap/config/cn=config$ ldapsearch -LLL -x -H ldapi:/// -D cn=config -w zimbra -b "cn=zimbra" "(cn=zre-ldap003.eng.vmware.com)" cn dn: cn=zre-ldap003.eng.vmware.com,cn=servers,cn=zimbra cn: zre-ldap003.eng.vmware.com Running "slapindex" does not fix the issue. --Quanah

1 0

Re: (ITS#7166) MDB segfault
by hyc＠symas.com 16 Feb '12

16 Feb '12

tomasz.rutkowski(a)tombas.pl wrote: > --=-KyDwFvnw0ca1u3hWxz7q > Content-Type: text/plain; charset="UTF-8" > Content-Transfer-Encoding: quoted-printable > > Dnia 2012-02-15, =C5=9Bro o godzinie 10:11 -0800, Quanah Gibson-Mount pisze= > : >> --On Wednesday, February 15, 2012 1:00 PM +0000 tomasz.rutkowski(a)tombas.p= > l=20 >> wrote: >> =20 >>> Full_Name: Tomasz Rutkowski >>> Version: 2.4.28, 2.4.29 >>> OS: PLD Linux (Th) x86_64 >>> URL: >>> Submission from: (NULL) (91.216.16.90) >>> >>> >>> back_mdb crashes when it's accessed through back_relay (rwm-suffixmassa= > ge >>> rewrite) for authentication, works normal for search/write however. >> =20 >> =20 >> Please provide a full backtrace from gdb, with debugging symbols. >> =20 In addition, please provide the config of your mdb database as well. There's more modules involved here than just rwm, relay, and mdb and the entire combination is relevant. Also, have you verified that the same combination using back-bdb/hdb works correctly? This looks more like an rwm bug to me than a backend bug. -- -- 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#7166) MDB segfault
by quanah＠zimbra.com 16 Feb '12

16 Feb '12

--On Thursday, February 16, 2012 1:03 PM +0100 Tomasz Rutkowski <tomasz.rutkowski(a)tombas.pl> wrote: > Dnia 2012-02-15, śro o godzinie 10:11 -0800, Quanah Gibson-Mount pisze: >> --On Wednesday, February 15, 2012 1:00 PM +0000 >> tomasz.rutkowski(a)tombas.pl wrote: >> >> > Full_Name: Tomasz Rutkowski >> > Version: 2.4.28, 2.4.29 >> > OS: PLD Linux (Th) x86_64 >> > URL: >> > Submission from: (NULL) (91.216.16.90) >> > >> > >> > back_mdb crashes when it's accessed through back_relay >> > (rwm-suffixmassage rewrite) for authentication, works normal for >> > search/write however. >> >> >> Please provide a full backtrace from gdb, with debugging symbols. Unfortunately, you optimized your build, which makes backtraces fairly useless. Please rebuild with CFLAGS="-O0 -g" and obtain a new backtrace. Thanks! --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#7167) regression, ldap_result() returns -1
by hyc＠symas.com 16 Feb '12

16 Feb '12

jvcelak(a)redhat.com wrote: > Here is what I have tried. This is the processing of the failing ldap_result(): > > (gdb) c > Continuing. > > Breakpoint 3, ldap_is_read_ready (ld=0x7f48f3a170a0, sb=0x7f48f3a22580) at ../../../libraries/libldap/os-ip.c:1005 > 1005 sip = (struct selectinfo *)ld->ld_selectinfo; > (gdb) n > 1007 if (ber_sockbuf_ctrl( sb, LBER_SB_OPT_DATA_READY, NULL )) > (gdb) > 1010 ber_sockbuf_ctrl( sb, LBER_SB_OPT_GET_FD,&sd ); > (gdb) > 1016 for(i=0; i< sip->si_maxfd; i++) { > (gdb) > 1017 if( sip->si_fds[i].fd == sd ) { > (gdb) > 1018 return sip->si_fds[i].revents& POLL_READ; > (gdb) p sip->si_fds[0].revents > $14 = 4 > (gdb) bt full > #0 ldap_is_read_ready (ld=0x7f48f3a170a0, sb=0x7f48f3a22580) at ../../../libraries/libldap/os-ip.c:1018 > i = 0 > sip = 0x7f48f3a2f590 > sd = 17 > #1 0x00007f48f17ab743 in wait4msg (ld=0x7f48f3a170a0, msgid=-1, all=0, timeout=0x7fff16e75da0, result=0x7fff16e75d60) > at ../../../libraries/libldap/result.c:357 > lnext = 0x0 > serviced = 0 > lc_ready = 1 > rc = -2 > tv = {tv_sec = 0, tv_usec = 0} > tv0 = {tv_sec = 0, tv_usec = 0} > start_time_tv = {tv_sec = 1329407008, tv_usec = 270973} > tvp = 0x7fff16e75c70 > lc = 0x7f48f3a2db80 > __PRETTY_FUNCTION__ = "wait4msg" > #2 0x00007f48f17aaf0e in ldap_result (ld=0x7f48f3a170a0, msgid=-1, all=0, timeout=0x7fff16e75da0, result=0x7fff16e75d60) > at ../../../libraries/libldap/result.c:117 > rc = 32584 > __PRETTY_FUNCTION__ = "ldap_result" > #3 0x00007f48e6da897e in sdap_process_result (ev=0x7f48f39f94d0, pvt=0x7f48f3a38b70) at src/providers/ldap/sdap_async.c:179 > sh = 0x7f48f3a38b70 > no_timeout = {tv_sec = 0, tv_usec = 0} > te = 0x7f48f3a2cab0 > msg = 0x0 > ret = 101 > __FUNCTION__ = "sdap_process_result" > #4 0x00007f48e6da8594 in sdap_ldap_next_result (ev=0x7f48f39f94d0, te=0x7f48f3a2cab0, tv=..., pvt=0x7f48f3a38b70) > at src/providers/ldap/sdap_async.c:159 > No locals. > #5 0x00007f48f2f19310 in tevent_common_loop_timer_delay (ev=ev@entry=0x7f48f39f94d0) at ../tevent_timed.c:254 > current_time = {tv_sec = 0, tv_usec = 0} > te = 0x7f48f3a2cab0 > #6 0x00007f48f2f189ec in std_event_loop_once (ev=0x7f48f39f94d0, location=<optimized out>) at ../tevent_standard.c:558 > std_ev = 0x7f48f39f9590 > tval = {tv_sec = 0, tv_usec = 0} > #7 0x00007f48f2f15cb0 in _tevent_loop_once (ev=ev@entry=0x7f48f39f94d0, > location=location@entry=0x7f48f37e52e7 "src/util/server.c:572") at ../tevent.c:504 > ret =<optimized out> > nesting_stack_ptr = 0x0 > #8 0x00007f48f2f15e3b in tevent_common_loop_wait (ev=0x7f48f39f94d0, location=0x7f48f37e52e7 "src/util/server.c:572") > at ../tevent.c:605 > ret =<optimized out> > #9 0x00007f48f37b8a85 in server_loop (main_ctx=0x7f48f39fa640) at src/util/server.c:572 > No locals. > #10 0x00007f48f3779a88 in main (argc=5, argv=0x7fff16e763a8) at src/providers/data_provider_be.c:2003 > opt = -1 > pc = 0x7f48f39f8010 > be_domain = 0x7f48f39f8420 "foo" > srv_name = 0x7f48f39f80d0 "sssd[be[foo]]" > main_ctx = 0x7f48f39fa640 > confdb_path = 0x7f48f39f8140 "config/domain/foo" > ret = 0 > long_options = {{longName = 0x0, shortName = 0 '\000', argInfo = 4, arg = 0x7f48f2d06200, val = 0, > descrip = 0x7f48f37dcb7c "Help options:", argDescrip = 0x0}, {longName = 0x7f48f37dcb8a "debug-level", > shortName = 100 'd', argInfo = 2, arg = 0x7f48f39f4738, val = 0, descrip = 0x7f48f37dcb96 "Debug level", > argDescrip = 0x0}, {longName = 0x7f48f37dcba2 "debug-to-files", shortName = 102 'f', argInfo = 0, arg = 0x7f48f39f473c, > val = 0, descrip = 0x7f48f37dcbb8 "Send the debug output to files instead of stderr", argDescrip = 0x0}, { > longName = 0x7f48f37dcbe9 "debug-timestamps", shortName = 0 '\000', argInfo = 2, arg = 0x7f48f39f4598, val = 0, > descrip = 0x7f48f37dcbfa "Add debug timestamps", argDescrip = 0x0}, {longName = 0x7f48f37dcc0f "debug-microseconds", > shortName = 0 '\000', argInfo = 2, arg = 0x7f48f39f459c, val = 0, > descrip = 0x7f48f37dcc28 "Show timestamps with microseconds", argDescrip = 0x0}, {longName = 0x7f48f37dcc4a "domain", > shortName = 0 '\000', argInfo = 1, arg = 0x7fff16e76058, val = 0, > descrip = 0x7f48f37dcc58 "Domain of the information provider (mandatory)", argDescrip = 0x0}, {longName = 0x0, > shortName = 0 '\000', argInfo = 0, arg = 0x0, val = 0, descrip = 0x0, argDescrip = 0x0}} > __FUNCTION__ = "main" > (gdb) fin > Run till exit from #0 ldap_is_read_ready (ld=0x7f48f3a170a0, sb=0x7f48f3a22580) at ../../../libraries/libldap/os-ip.c:1028 > wait4msg (ld=0x7f48f3a170a0, msgid=-1, all=0, timeout=0x7fff16e75da0, result=0x7fff16e75d60) > at ../../../libraries/libldap/result.c:356 > 356 if ( lc->lconn_status == LDAP_CONNST_CONNECTED&& > Value returned is $15 = 0 > (gdb) c > Continuing. > > Breakpoint 2, wait4msg (ld=0x7f48f3a170a0, msgid=-1, all=0, timeout=0x7fff16e75da0, result=0x7fff16e75d60) > at ../../../libraries/libldap/result.c:378 > 378 rc = -1; > > As you may see, there is only a POLLOUT flag set: > >> (gdb) p sip->si_fds[0].revents >> $14 = 4 > > /usr/include/bits/poll.h: >> #define POLLOUT 0x004 /* Writing now will not block. */ > > So I believe, that there is some other problem, because lc_ready is 1. And > without the reverted patch, the operation would just keep looping with > LDAP_MSG_X_KEEP_LOOKING. (Or will timeout alternatively.) Your debug session indicates that the socket is writable but libldap doesn't have any record of being blocked for any writes, so it doesn't check for writable state. Frankly this sounds more like an sssd bug, since libldap is still working fine for just about everything else out there. Perhaps you should set libldap's debug level to 7 and see what actually got handled in the library up to the point of failure. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs