- openldap-bugs - openldap.org

Re: (ITS#6945) nssov does not build on older Linux distributions (RHEL3, RHEL4)
by h.b.furuseth＠usit.uio.no 19 Feb '12

19 Feb '12

smbk5pwd is the strangest failure, since there are no #includes preceding portable.h and slap.h to interfere. My guess is RHEL[34] need a compilation flag like -pthread to enable threading. If you can still test this, check against which options OpenLDAP uses when compiling an overlay in slapd/overlays/. If that's not it, run the gcc compile command but replace '-c (-o foo.o)' with '-E -dD -o foo.i' This puts the preprocessor output plus macro definitions in foo.i, which should ease comparing with the /usr/include/ files and see why the pthread_rwlock_t def is excluded. -- Hallvard

1 0

Re: (ITS#6883) Improved Makefiles for contrib modules
by h.b.furuseth＠usit.uio.no 19 Feb '12

19 Feb '12

On Thu, 16 Feb 2012 11:38:13 GMT, bgmilne(a)staff.telkomsa.net wrote: > Please let me know how we can get this patch merged. OpenLDAP needs more active developers... Anyway: It should remove GNU Make dependencies, not introduce them: Only use '$<' in inference rules, not explicit target rules (like ITS#7160). Drop '%.x: %.y' rules. I've scribbled a draft for that at repo <http://folk.uio.no/hbf/OpenLDAP/openldap.git>, branch its6883. (Not tested, and I need to install a non-Gnu Make to test with too.) I'll work at it later, but don't quite know when. Unless you beat me to it. Also I suppose '+=' should go away. Which I would mean move what is added to a new variable so the user can easily say things like make CPPFLAGS='-Dwhatever $(DEFS)'. Or maybe use LT_CPPFLAGS= ..whatever $(CPPFLAGS) ... like e.g. slapd/overlays/Makefile ends up doing. THat one has an awful number of Make variables and is fairly unreadable to me, probably to satisfy autoconf & co. But a few more vars seems useful. -- Hallvard

1 0

Re: (ITS#7173) Patch: Fixing prototype of function in manpage to match prototype in C header.
by hyc＠symas.com 19 Feb '12

19 Feb '12

syzdek(a)bindlebinaries.com wrote: > Full_Name: David M. Syzdek > Version: MIGRATION_CVS2GIT-630-g463c1fa > OS: OS X 10.7 > URL: http://bindlebinaries.com/patches/openldap/0001-Fixing-prototype-of-functio… > Submission from: (NULL) (209.193.42.108) > > > The prototype for ldap_modify_ext() in the C header file declares msgidp as "int > *", however the current manpage declares msgidp as "int **". This patch updates > the manpage to accurately reflect the C header. > > The attached patch file is derived from OpenLDAP Software. All of the > modifications to OpenLDAP Software represented in the following patch(es) were > developed by David M. Syzdek syzdek(a)bindlebinaries.com. I have not assigned > rights and/or interest in this work to any party. Thanks, applied to git master. > > I, David M. Syzdek, hereby place the following modifications to OpenLDAP > Software (and only these modifications) into the public domain. Hence, these > modifications may be freely used and/or redistributed for any purpose with or > without attribution and/or other notice. > > SHA1 (./0001-Fixing-prototype-of-function-in-manpage-to-match-pro.patch) = > 4d088491dd02bbc1c2884d08ae90b415d4aa5d87 > MD5 (./0001-Fixing-prototype-of-function-in-manpage-to-match-pro.patch) = > e0f1ddc73c937d15629e11183f409028 > > -- -- 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#7160) MDB-back is not buildable on HP-UX 11.31
by h.b.furuseth＠usit.uio.no 18 Feb '12

18 Feb '12

Fixed in Git master. Please test: http://www.openldap.org/devel/gitweb.cgi?p=openldap.git;h=465942e74ddbd8c5 Also fixed contrib/ldaptcl which had the same bug. POSIX 'make' does not specify '$<' for target rules (rules that name an explicit target), only for inference rules: http://pubs.opengroup.org/onlinepubs/009695399/utilities/make.html Maybe because $< would be ambiguous in target rules with several dependencies. GNU 'make' defines it as the 1st dependency. -- Hallvard

1 0

(ITS#7173) Patch: Fixing prototype of function in manpage to match prototype in C header.
by syzdek＠bindlebinaries.com 18 Feb '12

18 Feb '12

Full_Name: David M. Syzdek Version: MIGRATION_CVS2GIT-630-g463c1fa OS: OS X 10.7 URL: http://bindlebinaries.com/patches/openldap/0001-Fixing-prototype-of-functio… Submission from: (NULL) (209.193.42.108) The prototype for ldap_modify_ext() in the C header file declares msgidp as "int *", however the current manpage declares msgidp as "int **". This patch updates the manpage to accurately reflect the C header. The attached patch file is derived from OpenLDAP Software. All of the modifications to OpenLDAP Software represented in the following patch(es) were developed by David M. Syzdek syzdek(a)bindlebinaries.com. I have not assigned rights and/or interest in this work to any party. I, David M. Syzdek, hereby place the following modifications to OpenLDAP Software (and only these modifications) into the public domain. Hence, these modifications may be freely used and/or redistributed for any purpose with or without attribution and/or other notice. SHA1 (./0001-Fixing-prototype-of-function-in-manpage-to-match-pro.patch) = 4d088491dd02bbc1c2884d08ae90b415d4aa5d87 MD5 (./0001-Fixing-prototype-of-function-in-manpage-to-match-pro.patch) = e0f1ddc73c937d15629e11183f409028

1 0

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

18 Feb '12

--On Saturday, February 18, 2012 12:41 AM +0000 quanah(a)zimbra.com wrote: > --On Saturday, February 18, 2012 1:32 AM +0100 masarati(a)aero.polimi.it > wrote: > ah, ok thanks. :) Any particularly reason why the control can't be made critical? 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#6598
by quanah＠zimbra.com 18 Feb '12

18 Feb '12

--On Saturday, February 18, 2012 1:32 AM +0100 masarati(a)aero.polimi.it 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)' >> 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) ah, ok 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#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 17 Feb '12

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

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

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

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

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

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

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

17 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

Re: (ITS#7169) When using protocol address, port parameter is ignored on connect
by h.b.furuseth＠usit.uio.no 16 Feb '12

16 Feb '12

To clarify a bit: When you use ldap_connect(URI, port), php ignores the port parameter and uses ldap_initialize() - which does not take a port parameter. Maybe php should refuse to accept a port parameter to in this case. OTOH ldap_connect(host, port) calls ldap_init(host, port), where port is used unless the host paramter has the form "host:actual port". -- Hallvard

1 0

Re: (ITS#7169) When using protocol address, port parameter is ignored on connect
by quanah＠zimbra.com 16 Feb '12

16 Feb '12

--On Thursday, February 16, 2012 5:02 PM +0000 marcel.esser(a)gmail.com wrote: > Full_Name: Marcel Esser > Version: 2.4 > OS: Ubuntu Lucid > URL: http://pastebin.com/TzNGmUCL > Submission from: (NULL) (98.169.136.204) > > > When passing a protocol address (i.e. "ldap://127.0.0.1" instead of a > plain hostname/IP address, i.e. "127.0.0.1" to libldap, connect seems to > ignore the port number parameter and always use 389/636 instead. > > Issue with libldap 2.4 on Ubuntu Lucid. Note that in the example below, > the PHP wrapper for libldap passes the strings on to the library > unmodified. Detail system information is at the bottom. Linked against > /usr/lib/libldap-2.4.so.2 I don't see a bug here. You are using two different methods: 1) The first method is using a URI. A URI includes the port, or defaults to 389/636, depending on the URI protocol. For example, ldap://127.0.0.1 is treated as ldap://127.0.0.1:389. If you want to use a URI with a different port, then include the port as part of the URI. 2) The second method is composed of a hostname/IP address, and a port. Since it is not a URI, these two separate pieces are required to be passed in. Essentially, if you are going to use a URI, then use it correctly and pass in the port as a part of the URI string. Passing in a URI with a separate port parameter that is not part of the URI is not valid. --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#7169) When using protocol address, port parameter is ignored on connect
by marcel.esser＠gmail.com 16 Feb '12

16 Feb '12

Full_Name: Marcel Esser Version: 2.4 OS: Ubuntu Lucid URL: http://pastebin.com/TzNGmUCL Submission from: (NULL) (98.169.136.204) When passing a protocol address (i.e. "ldap://127.0.0.1" instead of a plain hostname/IP address, i.e. "127.0.0.1" to libldap, connect seems to ignore the port number parameter and always use 389/636 instead. Issue with libldap 2.4 on Ubuntu Lucid. Note that in the example below, the PHP wrapper for libldap passes the strings on to the library unmodified. Detail system information is at the bottom. Linked against /usr/lib/libldap-2.4.so.2 Use case illustrated in attached URL.

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs