- openldap-bugs - openldap.org

(ITS#7989) wrong search results "scope one" with mdb backend
by dab1818＠gmail.com 01 Dec '14

01 Dec '14

Full_Name: Dmitry Bakshaev Version: 2.4.38, 2.4.40 OS: gentoo linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (87.249.250.7) slapd.conf: include /etc/openldap/schema/core.schema pidfile /tmp/openldap-data-test/slapd.pid argsfile /tmp/openldap-data-test/slapd.args database mdb directory /tmp/openldap-data-test suffix "c=ru" index objectClass eq test.ldif: dn: c=ru objectClass: country c: ru dn: o=org,c=ru objectClass: organization o: org dn: ou=unit,o=org,c=ru objectClass: organizationalUnit ou: unit dn: ou=subunit,ou=unit,o=org,c=ru objectClass: organizationalUnit ou: subunit dn: cn=pers,ou=unit,o=org,c=ru objectClass: person cn: pers sn: pers load test.ldif: slapadd -f slapd.conf -l test.ldif -q run slapd: /usr/lib/openldap/slapd -f slapd.conf -d 127 -h "ldap:///" execute query: ldapsearch -H ldaps://localhost -b ou%ununit,o=org,c=ru -s one "(objectclass=organizationalUnit)" result contains wrong data (expects only ou=subunit,ou=unit,o=org,c=ru): # unit, org, ru dn: ou=unit,o=org,c=ru objectClass: organizationalUnit ou: unit # subunit, unit, org, ru dn: ou=subunit,ou=unit,o=org,c=ru objectClass: organizationalUnit ou: subunit # search result search: 2 result: 0 Success # numResponses: 3 # numEntries: 2 worked as expected: 1. on openldap-2.4.35 (with mdb 0.9.6) or below; or 2. with "database bdb"; or 3. without "index objectClass eq".

1 0

Re: (ITS#7832) Proposing ppolicy extended module for OpenLDAP
by dcoutadeur＠linagora.com 01 Dec '14

01 Dec '14

Hi, I am considering solutions to give the password policy module its configuration in cn=config, and not in a flat configuration file. However, If I create a ppm.la overlay to register a ppm configuration schema, I won't be able to read it in the ppm.so which is loaded dynamically by the ppolicy overlay. Indeed, ppolicy is dynamically including the ppm.so code through libtool, so there is no link at all between ppm.so and ppm.la. Does anybody have an idea on how a module called by the ppolicy could read some configuration in cn=config ? Thanks in advance ! David Le 12/11/2014 10:41, David Coutadeur a écrit : > > Hi, > > The ppm module is still alive, and is evolving. > Last version is 1.2, and source code is now available on Github : > > https://github.com/davidcoutadeur/ppm > > There are also plans to package it. > If anybody is interrested, I am always glad to hear about comments, > ideas, improvements,... > > Sincerely, > > David

1 0

Re: (ITS#7987) SIGSEGV in LMDB while adding ldap-entries
by leo＠yuriev.ru 30 Nov '14

30 Nov '14

Previously noted (2) and (3) was caused by following patch. It is a trial from Howard Chu for workout on ITS#7968 ;) Under a heavy load of add/delete it may induce "DN index delete failed" in the mdb backend. > Message-ID: <5440D299.60208(a)symas.com> > Date: Fri, 17 Oct 2014 09:26:01 +0100 > From: Howard Chu <hyc(a)symas.com> > > Can you try this patch and followup again? > >> diff --git a/servers/slapd/overlays/syncprov.c >> b/servers/slapd/overlays/syncprov.c >> index e15020e..b54c83f 100644 >> --- a/servers/slapd/overlays/syncprov.c >> +++ b/servers/slapd/overlays/syncprov.c >> @@ -1306,11 +1306,12 @@ syncprov_matchops( Operation *op, opcookie >> *opc, int saveit ) >> op2.o_hdr = &oh; >> op2.o_extra = op->o_extra; >> op2.o_callback = NULL; >> - if (ss->s_flags & PS_FIX_FILTER) { >> + if ((ss->s_flags & PS_FIX_FILTER) >> + && op2.ors_filter->f_choice == >> LDAP_FILTER_AND) { >> /* Skip the AND/GE clause that we >> stuck on in front. We >> would lose deletes/mods that >> happen during the refresh >> phase otherwise (ITS#6555) */ >> - op2.ors_filter = >> ss->s_op->ors_filter->f_and->f_next; >> + op2.ors_filter = >> op2.ors_filter->f_and->f_next; >> } >> ldap_pvt_thread_mutex_unlock( &ss->s_mutex ); >> rc = test_filter( &op2, e, op2.ors_filter );

1 0

Re: (ITS#7968) SIGSEGV shortly after reconnection performed by syncrepl due to synchronization conflicts
by leo＠yuriev.ru 29 Nov '14

29 Nov '14

This is a multi-part message in MIME format. --------------010409020705090508090802 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Some of Valgrind's DRD output, seems be enough to crash around connect/disconnect and walking on overlays. --------------010409020705090508090802 Content-Type: application/gzip; name="valgrind-drd.log.gz" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="valgrind-drd.log.gz" H4sICJ8XelQAA3ZhbGdyaW5kLWRyZC5sb2cA7V3bcuO4EX3PV/At3lRkgSB4U2pqQ922tmqS naq9VB5SxaJJ2GZGIrUk5bHz9WmQ1IUayNY6HluSjx9kXdgkgO7TOH0kgB8+uMz1P3wwkiL5 qxEZ1W0ho8SQRZEXRiIrGVd58acPq6NG+eKhSG9uK+Ni9J3BGXN6nJkWWWaJ8cM/fzV++PTx z3SiqwdjGBWV8VuUGUFZxrfycnOSX8s0u6GPZjdFmiU969Jkl6w+w8f06rfJv/5mFLJYZsaX tLo1erfGNTUlXl84za7z7QbN52Q5MPq3+Vz2Zw/9T0X+H2p12f/4j/GwV8myiqNSXt6kVV+9 6N1FSTrv38pC9spZtEj6s/RK3su4X78yejPj40+j4KNt9BKDGb1SPQjVjFkSLQb9PjWWX7JL c2DSH+//e/0+d+nt+gNm+bxv9K6f1agkqqJ+licy5H1Ztc26jPPsetPrT1Ehs8r49ON4YDi+ zzafbJ790nhSDLYHK7uepXGlhr8kv0rlp9bjwogqg90zh8vYkrFRpv+VhtjY0l99gDCnLHAG hmpWOEvLSmayMC6SSM7z7DIemJ7wvuuY0TVqM2/CdszC9toba848X2c9sb0xNwf1WIdpVrWW 4SLPZ+GXIlosVCMq9ZLO4njaJows0w2GA+P77783LtLM6C/LQnm/f9eGYv/uZlHIWU4nJjj0 onniiN4szZb3l2WuOaPNh4wFgnpVUbCve7NoGxfTYyWpPRbTdcq2R8wTo4ERz/JMGhf1v8uf VVxtHR0kSSFLisL7lWfSUnkiv74uZWUIYVwX+Xz1ccwujWA2y+OoSvOMUJNV8r4aaNw44uPp mBwyj9ThLzQeLDDJ/wPjinw7l82pw3vjgp7nxYPyL9d6xppMxwENxG24as76KRnZQhtQk0BY bUDlC5lpg9H2mM6Wm97UbGypa/XRFFVptW3quNpIZAFvho0G7EI90rGu2PbYTxXh2CjlzVxh tA4NCs0mNvh3OldYYjqm5qziZr4kp4XLjHr/+WUcIzgLht5Oh6uo/LwNPXFGqOn6QNLU8pgH 1Dkn3Gr7WD6UMYUeZen5Yqaa8vPAM/WDyqbTJwbVtpwzHdTDAtsy2W5gv2BYm1NKHE+FtWWd qQeeCuvXSSyM8ac8YJ9PYvmKX7l7+JVq9ha9clf0yvKkbbGGXnmaVGQyPqRGlA9ZvCjyu/D3 ZjRXr9XMxJh2QgRHIhLUDm+HI7E1RWo+PZgiWYyNKH3FL02RphuKFGs4kqdNWNaUuHnNkWIN RzL1MUHeHBFZv4riz5QtwuSqpTntG4pc+doJisLQplaqsiO9CW8Ur0rpklfNGzW14lxrGDgj vjak4Q9pqEpq7MrQsrXdM8eW5Q6MJiga4+t0JrcMXV87C5vOyJ52DLebKbiljXOicfZol8b5 /MDZznqjbDvmPqe+zsmP1KjiISxktSyoB2nC6zdqyqHtMJk6oms6k1SDdm19Lef1iPPSNJvf yWIWPXTtw/yuCSf1qRpwSxuInjkcW01aK+Ri1pyjSWvqdR32rta/rWWSh+3BvGNGgaq/oOWr iWljNuua2Za2q9xmE7cO34zqdUoQYe3LVdravK/OwX1tKL/fRLyfn+xDzLflh95w6K5qxN+X cinDuCS0xNU9/Vce1KcUd+RzthWsy0VCYzPK88+p7ESR5Tra4HOnTCWzR2JW63PE7OvH7Lcm dBThNLabKXjLS7tTsW9qp2JOM+a4497GsONX29WLJFMxEfvFOk7Nh1gHIgoiCiL6hybWie1O VGdriC/uuhAvl1dz5dsVwi2hc5DNhiPH3a50CTqLnUrX18m3tmmORt6W5Tyq4tt8UXaNLS0T tU0eTPiWcb4I1YXzrJRde18/21rW0GsVj7VhuCBebFzQy+WsUrHM9DK3YBOfTBUC6pHbXHhj ugd0IvBaxTrs2JPVlrXnaENz5E0mXkP+o4SSHj3UVF0LHC8Qwt6wfRqfL9Hsc4fkO3uoemAP WWOpzK6XWdwxc7m2bx5zV5LH3tpAz7NaywNrgz/OTr+5ejYa2jTHRVVVhG0uVc+VI7UBxMc2 c9vj57K4kevjhWtriajgPnVhnifp9YPyvUqCS0lIobfK+msOrScD1/SDJmBaW5rHZZFFs9qS 3qhttY0M3MnY2bbdMnH2RMBrhxwx/OGBDF+Px5Nh+Ec4e6j8zZyn87epC2nk73ebv48GRW8u bBB3ClRX0ixuzk3ZuRP8rqsj0yuzRymXrSVroFyA7OtB9mUVGM/31mO0Bf6vxsrT1ilKwHEm Bwo4LgQcCDgQcCDgQMCBgAM2AQEHAg4EHAg4yN/I38eEIgg4oFyA7CkJOGP7IAFHW4FCwIGA AwEHAg4EHAg4YBMQcCDgHEHIQcCBgIP8fWL5+2hQBAEHlAuQfRUBp10WZR24j5B1uKgzUes6 63GL4piK9pqAfZFJZ/gsrt3BRYihS4PQNSRMqLXyUaw6JGy9IR8O6bJq16WQEE9hFUtVXlZK EWn+r1bDelzr8O0z6A1NLRIUglfLCh+ddLWJAwh+rwiGpAVJ61UlrR0N/NVqcXM85WK1l0wN +LXQ7ekLXSXM208L83pXQphfw/ZNtwZ4q3Cj4BHu08GjVXUQPG8YPMhWCDhkK2SrYw2er2pn 57AtRZyDtxSxAodI4bUMo+W92vy0qNm++mpgQ31NX2iDwWJ1FlqR5r3W+hxm2fa4U9CVMiqI qrfFz7qiMxnTl7HMdfytMlad4ysJzPP1uvOO7e9N+bpl6Au9+rVrqNlTz9SqBe83iFF1oup8 Dz+kwFdhUOXwVRi+CgNkAVk9ZDFpAQHvGwGYtDBpAbInBdmXFZxojETw2BiZ2qG1rMCzD9Cp tItuoFNBp4JOBZ0KOhUoP/gDKD8oPyALyEKnAgKAAExamLQA2XOA7IvrVK54VKfS/yQKOhV0 KuhUm8kDOhV0KlB+8Ifj5w+g/KD8gOxJQRaTFhDwvhGASQuTFiB7UpDdPGvX9HmHrenzDpWu KBc4rNagaNCiqyhLqPC/aJ/UkayVrjgXbNjJIGvbTvZw9eIVWY+9jnk8y0vVj665p9+Fh4vR cPJV/tpNXEIL/T3G+5Kfp3Ui9CToSdCTzllPwkbHYBmnxzKw0TE2Ol6Ny7vZ6PhlCfEz1xxQ B1znUR6tJ6Pg0eDR4NHg0eDR4NHg0eDR4NHg0efCo5/zm0jwaPBo8GjwaPBo8GjwaPBo8Gjw 6JPl0e1vNvhhv9ngK2rNZWxJbz+1NqdTx1ltAd9siB02S2E2u2ML7RKak+d47dB0OJ7YkDz1 cXw4yePj6ZgpJvDCJM/bkDwNx9PHqTWZjoOa4801HM/W3+R7EgirnaLyhcx0u6ybtqevWUxv au4EUUMQN6aOq8UGEahm2LYJlDj0xgn2G2V+zxra7iOJwBFYOnbgzQj2uNCeWJONCwl4CU0q afX3v7wYBfbGLj/YFfr5+QxcATydgROBp6NxxdM39qnPappfndX7/27e8k1/Gi+4JTz/yVu3 CL0GhFu3HEs8ijfK78obpnO4N7RxdAbe2AayzhfUImdsj9s+lg+l0mh7lZwvZqopO0liCyps ZO9HGNUQWowAYUDYuXkDCDs/nwJhx+QNIOwcfPoMFTluVGShgR9nzOVPqMh7vug9ydHbVZHj HRVZQEWGigzVC6rXu1S9gKeTdCLwdDSugIoMFfl44xEV+PEkalTg5+FTIOyYvAGEnZ9PgbBj 8gYQdn4+BcKOyRtA2Dn4dPPsl+b0zmELAA6+34jFzSDYLO2Lb2X8Wa1Mqoq0rsjLzi1AmNAG hTCH7mi10vYqVZGnHusVGPqluaZte7VU1zmaM/0OkcLlVkc3WN+iZHf5BJ0XAYRFrVjU2hi+ o0WtWI3XfguC1XjHsWH5MyR6IAlIApLOBkm4Jwe2OuhY4p4cuCcHIAvIauSdF7p37HP2G7a4 qXYNO1gC0noWEhAkIEhAkIBQuKJwReF64oUrkAQkAUmQgFBPnlg9+frAhAQEyAKyxyQBPWer fEhAkIAgAUECggSEwhWFKwpXIAlIApIgAaGePLl68vWBCQkIkAVkj0YCEubQs/UyjH7jNcgw kGEgw0CGQfGI4hHFI5AEJAFJ54ckyDCo6SDDQIYBZAHZI16MJUxCyx71RjuoUG+g3kC9gXqD mhM1J2pOIAlIApLOD0lQb1AKQr2BegPIArJHvI4K6g3UG6g3UG9Qc6LmRM154jUnkAQkAUlQ b1AKnlgp+PrAhHoDyAKyfxyy/wMt47cXvE0BAA== --------------010409020705090508090802--

1 0

Re: (ITS#7968) SIGSEGV shortly after reconnection performed by syncrepl due to synchronization conflicts
by leo＠yuriev.ru 29 Nov '14

29 Nov '14

Program terminated with signal 11, Segmentation fault. #0 0x00007ffda90d607b in ?? () from /lib/x86_64-linux-gnu/libc.so.6 (gdb) bt #0 0x00007ffda90d607b in ?? () from /lib/x86_64-linux-gnu/libc.so.6 #1 0x000000000047fb7c in do_syncrep2 (op=0x7ffd68cf5740, si=0x1681d00) at syncrepl.c:893 #2 0x0000000000483903 in do_syncrepl (ctx=<optimised out>, arg=0x1682090) at syncrepl.c:1551 #3 0x00000000004250e8 in connection_input (cri=<optimised out>, conn=<optimised out>) at connection.c:1732 #4 connection_read (cri=<optimised out>, s=<optimised out>) at connection.c:1460 #5 connection_read_thread (ctx=0x7ffd68cf5bd0, argv=0x25) at connection.c:1284 #6 0x00007ffda9777d22 in ldap_int_thread_pool_wrapper (xpool=0x1635090) at tpool.c:688 #7 0x00007ffda93420a5 in start_thread () from /lib/x86_64-linux-gnu/libpthread.so.0 #8 0x00007ffda906f84d in clone () from /lib/x86_64-linux-gnu/libc.so.6 (gdb) frame 1 #1 0x000000000047fb7c in do_syncrep2 (op=0x7ffd68cf5740, si=0x1681d00) at syncrepl.c:893 893 Debug( LDAP_DEBUG_ANY, "do_syncrep2: %s malformed message (%s)\n", (gdb) info locals syncUUID = {{bv_len = 16, bv_val = 0x7ffd543a98b7 "\177]\201N\f'\020\064\235\255Չ\v\247\331", <incomplete sequence \351>}, {bv_len = 128849018894, bv_val = 0x7ffd68cf4ec4 "\375\177"}} cookie = {bv_len = 60, bv_val = 0x7ffd543a98c9 "rid=002,sid=002,csn=20141129152404.971057Z#000000#001#000000"} rctrls = 0x7ffd543f7130 bdn = {bv_len = 33, bv_val = 0x7ffd543706f7 "cn=modem,uid=4711,dc=ngdr,dc=ldap"} si_tag = 1 syncstate = 3 retdata = 0x7ffd68cf57c0 retoid = 0xb <Address 0xb out of bounds> syncUUIDs = 0x7ffd68cf57c0 len = 60 berbuf = { buffer = "\002\000\001", '\000' <repeats 29 times>, "\260\230:T\375\177\000\000\005\231:T\375\177\000\000\005\231:T\375\177", '\000' <repeats 34 times>, "i\215\064\251\375\177\000\000\000\000\000\000\000\000\000\000x\021V\251\375\177\000\000\340\022h\001", '\000' <repeats 36 times>, "\060S\317h\375\177\000\000Q\020", '\000' <repeats 14 times>, "X", '\000' <repeats 15 times>, "\300U\317h\375\177\000\000"..., ialign = 65538, lalign = 65538, falign = 9.18382988e-41, dalign = 3.2380074297143616e-319, palign = 0x10002 <Address 0x10002 out of bounds>} msg = 0x7ffd543f3c50 syncCookie = {ctxcsn = 0x7ffd543f3f10, sids = 0x7ffd542eb890, numcsns = 1, rid = 2, octet_str = {bv_len = 60, bv_val = 0x7ffd5440f6d0 "rid=002,sid=002,csn=20141129152404.971057Z#000000#001#000000"}, sid = 2, sc_next = {stqe_next = 0x0}} syncCookie_req = {ctxcsn = 0x7ffd5440f380, sids = 0x7ffd542ebae0, numcsns = 5, rid = 2, octet_str = {bv_len = 224, bv_val = 0x7ffd543714e0 "rid=002,sid=004,csn=20141129152404.970764Z#000000#001#000000;20141129151341.491595Z#000000#002#000000;20141129151341.507685Z#000000#003#000000;20141129151341.523508Z#000000#004#000000;20141129151341.5"...}, sid = 4, sc_next = {stqe_next = 0x0}} rc = 100 err = 0 modlist = 0x0 m = 32765 tout = {tv_sec = 0, tv_usec = 0} refreshDeletes = 0 empty = "empty" (gdb) p *si $1 = {si_next = 0x1682200, si_be = 0x1680940, si_wbe = 0x1680940, si_re = 0x1682090, si_rid = 2, si_ridtxt = "rid=002", si_bindconf = {sb_uri = {bv_len = 22, bv_val = 0x16816b0 "ldap://10.2.0.1:11113/"}, sb_version = 3, sb_tls = 0, sb_method = 128, sb_timeout_api = 10, sb_timeout_net = 0, sb_binddn = {bv_len = 19, bv_val = 0x1681690 "uid=replica,dc=ldap"}, sb_cred = {bv_len = 3, bv_val = 0x1682110 "xyz"}, sb_saslmech = {bv_len = 0, bv_val = 0x0}, sb_secprops = 0x0, sb_realm = {bv_len = 0, bv_val = 0x0}, sb_authcId = {bv_len = 0, bv_val = 0x0}, sb_authzId = {bv_len = 0, bv_val = 0x0}, sb_keepalive = {sk_idle = 1, sk_probes = 1, sk_interval = 1}, sb_tls_ctx = 0x0, sb_tls_cert = 0x0, sb_tls_key = 0x0, sb_tls_cacert = 0x0, sb_tls_cacertdir = 0x0, sb_tls_reqcert = 0x0, sb_tls_cipher_suite = 0x0, sb_tls_protocol_min = 0x0, sb_tls_crlcheck = 0x0, sb_tls_do_init = 0}, si_base = {bv_len = 15, bv_val = 0x1682030 "dc=ngdr,dc=ldap"}, si_logbase = { bv_len = 0, bv_val = 0x0}, si_filterstr = {bv_len = 15, bv_val = 0x1681200 "(objectclass=*)"}, si_filter = 0x1682010, si_logfilterstr = {bv_len = 0, bv_val = 0x0}, si_contextdn = {bv_len = 7, bv_val = 0x16811e0 "dc=ldap"}, si_scope = 2, si_attrsonly = 0, si_anfile = 0x0, si_anlist = 0x1682130, si_exanlist = 0x1681fc0, si_attrs = 0x169f0f0, si_exattrs = 0x0, si_allattrs = 1, si_allopattrs = 1, si_schemachecking = 0, si_type = 3, si_ctype = 3, si_interval = 60, si_retryinterval = 0x1681ff0, si_retrynum_init = 0x1682070, si_retrynum = 0x1682050, si_syncCookie = { ctxcsn = 0x7ffd7c1d87d0, sids = 0x7ffd54411150, numcsns = 5, rid = 2, octet_str = {bv_len = 224, bv_val = 0x7ffd543f57f0 "rid=002,sid=004,csn=20141129152404.970905Z#000000#001#000000;20141129151341.491595Z#000000#002#000000;20141129151341.507685Z#000000#003#000000;20141129151341.523508Z#000000#004#000000;20141129151341.5"...}, sid = 4, sc_next = {stqe_next = 0x0}}, si_cookieState = 0x1681c70, si_cookieAge = 1539004, si_manageDSAit = 0, si_slimit = 0, si_tlimit = 0, si_refreshDelete = 0, si_refreshPresent = 1, si_refreshDone = 1, si_syncdata = 0, si_logstate = 0, si_got = 269715, si_strict_refresh = 0, si_too_old = 0, si_msgid = 2, si_presentlist = 0x7ffd7c58e050, si_ld = 0x7ffd7c718210, si_conn = 0x7ffda9a365d0, si_nonpresentlist = {lh_first = 0x0}, si_rewrite = 0x0, si_suffixm = {bv_len = 0, bv_val = 0x0}, si_mutex = {__data = {__lock = 1, __count = 0, __owner = 13107, __nusers = 1, __kind = 0, __spins = 0, __elision = 0, __list = {__prev = 0x0, __next = 0x0}}, __size = "\001\000\000\000\000\000\000\000\063\063\000\000\001", '\000' <repeats 26 times>, __align = 1}} (gdb) p si->si_ridtxt $2 = "rid=002" (gdb) p (void*)si->si_ridtxt $3 = (void *) 0x1681d24

1 0

Re: (ITS#7968) SIGSEGV shortly after reconnection performed by syncrepl due to synchronization conflicts
by leo＠yuriev.ru 29 Nov '14

29 Nov '14

Program terminated with signal 11, Segmentation fault. #0 0x000000000047fb64 in do_syncrep2 (op=0x7f8c494e7740, si=0x19967e0) at syncrepl.c:892 892 bdn.bv_val[bdn.bv_len] = '\0'; (gdb) bt #0 0x000000000047fb64 in do_syncrep2 (op=0x7f8c494e7740, si=0x19967e0) at syncrepl.c:892 #1 0x0000000000483903 in do_syncrepl (ctx=<optimised out>, arg=0x1996410) at syncrepl.c:1551 #2 0x00000000004250e8 in connection_input (cri=<optimised out>, conn=<optimised out>) at connection.c:1732 #3 connection_read (cri=<optimised out>, s=<optimised out>) at connection.c:1460 #4 connection_read_thread (ctx=0x7f8c494e7bd0, argv=0x21) at connection.c:1284 #5 0x00007f8c6bb5bd22 in ldap_int_thread_pool_wrapper (xpool=0x194a090) at tpool.c:688 #6 0x00007f8c6b7260a5 in start_thread () from /lib/x86_64-linux-gnu/libpthread.so.0 #7 0x00007f8c6b45384d in clone () from /lib/x86_64-linux-gnu/libc.so.6 (gdb) info locals syncUUID = {{bv_len = 16, bv_val = 0x7f8c40106ad7 "\023Z,P\f!\020\064\223e\177\031\357Ζ:"}, {bv_len = 0, bv_val = 0x0}} cookie = {bv_len = 60, bv_val = 0x7f8c40106ae9 "rid=001,sid=001,csn=20141129143806.208485Z#000000#001#000000"} rctrls = 0x7f8c40104ad0 bdn = {bv_len = 34, bv_val = 0x7f8c40105209 "cn=tablet,uid=1756,dc=ngdr,dc=ldap"} si_tag = 1 syncstate = 1 retdata = 0x19eb878 retoid = 0x0 syncUUIDs = 0x0 len = 60 berbuf = { buffer = "\002\000\001", '\000' <repeats 29 times>, "\320j\020@\214\177\000\000%k\020@\214\177\000\000%k\020@\214\177", '\000' <repeats 34 times>, "i\315rk\214\177\000\000\000\000\000\000\000\000\000\000xQ\224k\214\177\000\000\340b\231\001", '\000' <repeats 36 times>, "\a\000\000\000\000\000\000\000\020c\231\001\000\000\000\000\a\000\000\000\000\000\000\000@b\231\001\000\000\000\000\006\000\000\000\000\000\000\000\300b\231\001\000\000\000\000"..., ialign = 65538, lalign = 65538, falign = 9.18382988e-41, dalign = 3.2380074297143616e-319, palign = 0x10002 <Address 0x10002 out of bounds>} msg = 0x7f8c40102be0 syncCookie = {ctxcsn = 0x7f8c401038f0, sids = 0x7f8c40105890, numcsns = 1, rid = 1, octet_str = {bv_len = 60, bv_val = 0x7f8c40104e10 "rid=001,sid=001,csn=20141129143806.208485Z#000000#001#000000"}, sid = 1, sc_next = {stqe_next = 0x0}} syncCookie_req = {ctxcsn = 0x7f8c40105e80, sids = 0x7f8c40105020, numcsns = 1, rid = 1, octet_str = {bv_len = 60, bv_val = 0x7f8c40105760 "rid=001,sid=001,csn=20141129143806.208232Z#000000#001#000000"}, sid = 1, sc_next = {stqe_next = 0x0}} rc = 100 err = 0 modlist = 0x7f8c40106a70 m = 32652 tout = {tv_sec = 0, tv_usec = 0} refreshDeletes = 0 empty = "empty" (gdb)

1 0

Re: (ITS#7968) SIGSEGV shortly after reconnection performed by syncrepl due to synchronization conflicts
by leo＠yuriev.ru 29 Nov '14

29 Nov '14

This is a multi-part message in MIME format. --------------050709090905040108060403 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit A simple testcase is attached. All activity (add/delete/read) come via first node of 4x cluster. Unfortunately a lot of time may be required to reproduce a bug (coredump), from 10 minutes up to 2-3 hours. Leonid. --------------050709090905040108060403 Content-Type: application/gzip; name="testcase-its7968-1.tar.gz" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="testcase-its7968-1.tar.gz" H4sIAFrZeVQAA+1abXPbNhLOV/FXbGm7phKREiXLvipVL6mtXj3n2h7LuZuOz+OhSEhizRcV oGK7sf/77QKkSEqy7OSS9DojZGIRwGKxWDz7ApB+5CdW4PnDF1+uNLDs7u7Qr73XbhR/Zdlt N1/YzZ2m3bbtdsN+0bAbbbvxAhpfUKZZmYrE4QAvgrvVdE/1/0WLF3XAc7uB50y0ePAbc5P9 wBGiAzEfOZH/h5P4cVTuSeI5Us89kVXNczugOHXgnWD8wEmcMzaJhZ/E/E7TaLKp73UdL/Sj WjYttnRANj0xj+O68TRKcj6cTQLfdWpLF5BRr+Yp/HASsD5zp9xP7tJ1SIlS5toUF3KKtDcx x9bbuz/U/DhnNPL48rlLytv4CO0Ry0e092X2P4w9Zrlx9Gfav72zQ/bfarfabfxd2/9XLBoC 7T3jhwfw5vDgjaaFPucxJ1TA+dm7nhZjZ+DcgbiL3AmP32vZg+mOmXs9if0oAbvRADvv4SyI HW9MPZLHn73GdXm8pF7ui7qAp+y/tdeexf/W3h7av91c2//XKdJqCQTAMaBKH1AhI/Y9xrtv 3h4cnGFDcjdhGGyHnInx28g7ZVz4ItEqnCX8rqu34ZUOiR+yeJp07QZcMzZxAv896+p2B//p WkUwh7vjgSOwbS5yYq+TJFx09Ze1V1gZ+JEXsmQce10VnFWTF3X1JTEfB6D4HosS3wlEl8Jz hUQJ/NBPutNI/jIPJfD/WGj8s5X/f1D4NAqZ6Sdi77vdv5m2Jcaffw6y8T208eX2j8G+uSvj /26rTX/I/vca7bX9f42y8U0drauOljnWtJ97Z73upjG58araj4fHB4dn3c0P1PhQHzPOTBE4 E087eHv+dqHLw2RV2z961z/vYY8h2O9gQ7uqbWRttrbRP3p7enXQ+/HdP7r2butvO1qhoaFp 134QOEEA5u8gJ4KQhTLJMJ3Q290xAz+a3sK332IvOhhMOHgI5hBeWt5ghH+T2wTcmDNNS5hI wLwFqx5PWERewhTxlLusTlHOH005g/9olft7MEY+DgriiAE+dep1/GtlgyzM4mccLKKcY0dM KiiP6y30YKtkTeKjV4ST097x0QGu9qx3dNU7/sdV82onG06E6FkZymyOHY7MuD/CPXlqTMj4 iOEYNw5DEk6NCr2BFToiYRzMEPSXL1/CL5KQszBOmJlwx732oxEMuBO5Y9heGLcNmLnFS0XW q6ni2C3OuPn3XNebHxRgHuqC8EQb6HgemM7yjVBZp5B0Xt0K/EH6DLQrSxSK02Y6DZgTEVfc e9NLO6zC1prmBGOVf9udyYRNLHIGAcL0LnLcIK/TFHktTXYFtni+kE3oHRLfLTMIZUNGMfAG hdoYa0qk0Llm4DFchwdZNfv1I+QbBI9qc1FhqCHucJ8Jegpws2jDrki6lIfka+4/Z+j8rOG1 5yNaJriJqW0/kKRkXnxYaKy/nB9phHTEhnsYYVguDkciMfViUP1mAkk4GQo4e/tLgWph+cOY Q4TKQZrUbTy8Bi/WKscnBz3lcmayRHhEudqMMAnJxEyJSEzSc76oWcd7h9cx4M03ke8qtrHE haJYmL14oIv7dO77nPR+9FrcK5Ddz9B2P9Lhe8i8o0S1TK/hh7lJin2l+fwhXMCmcYMwu4Hv v/8e9FwhaILmCI9ccPkakjFDBVRIbXyZ2iopJw7fdGEzKgypVCi16+qEE3R7dsPa5FbDsjub hmFTgVc4rFqt65I4VQClh/ebXK5a5Yb3m/RTXnHxSAE/PHPROMnQx78e+mJtbsKozH92ZfF8 5shaqxweH57Pgpaf3XtqlfpUcBkEKW9EU0YnMIgFPsWALszcNChtRatnuZOrmpuRDDiPub3h CsHMADtJGPRLfdoW3OTmDyunoghXXM/RYf/8CjX/qms8JWIV8+F4io6+IBBmzA7mv5ZUNv15 /Ym2R/GhBKJoAUQRgggyiuYe9mcUjdZ3jYxCV3Y8RAGG8cr1kDmSZ/GHyuNDEHdQh7PJIWIJ xrFraLbbVuE/TCc4lLnjWAVFSvsS5NnRQcaPj3C4y9yHyVYj6cl1kS/M0YRzsluWwoYQc3Sy //aoTQFv80OeNiGCBDTA3AFzTE6C9uNBXw2/5g83Mb9ejbVvFcQQXk/KjfjK8jEJJ1VpatpT ypjc4RkvWs5bKkQRAMVEF0kKh5TJnaapnex+7qI/bghlsK+Cco4yshQJMq1CA9UxGMyfYZO4 Yag/Ojo6yC7gwRzkjzcgGNppQjtMGoL9OErYbbLfP1aK/mIK0Ix0QxuvIcvJJX5ep5l3O29f lqJXET5SODMC/d8OuixSKWapeJanC3HLsqTN3VAX/qqFgAm0LP0TPdEKtLlO8tFOHMc86cTT vTVnoaToouUWaTkQFJiVs5HJEu5uHHniebagnf56/vPJ8VW/t39yfNDHA5bkgUb/UWwwUXPx MIJOZLuzTetrYsuEkn5EmfcKKwO3mgoNacHEoTz5p+6QTEVM8QxPmKcpSw2potbOQP/JDxiI O5Q/BDxlTaaJ0KmjpJSVwaRS+TyeX8nkzkx0ERwyCZGoIPd9sGIrTRPnIfd78eby4XlbhqnA aoZ1j72vR9MgSFlT8vB89guIKC2hBlnagz0FSRAoKXJOe2f7vWNMvgzFaQ5R8FK+QaiDMd/x am6qqp5KpFoX+JaIP4GtcltMQW5TgQUPLeeHJx1UXHk1D1unyFtF44O8sf+fSP8LXSwuja6f eY7V9/92c7e1k93/tfbazRfYtLO+//86xQ8nMU/UW/v0mSJoDT0wHhI8PxrVMMMejeQDdyIv DtHeE471jB4dcA1ioWkbzyraBvwzim8iOSekF0EUTLIX7jJRQl9yoVUu9DzPoiTL1mtwjD70 sqZtLHQ2V3W2VnXu5J2Xz12FNuon8QTF/MkJBNNC5/aUx0MMSCR6G3GtYSUotBUp6pgg43g8 hGHHhwdN5YV9F0MRNsj7xv7+yWnvqv/ux/OzXk8LYvcae2abYh1hg1HVNJc+IoD+dCBS5ob6 uKDa0SpeRNwr21603QH58uRD46E2//qlRmfvbTxUC6S6qBh64esE1MuFXvyYwQno5U8cYYc+ mT2hIugHZ1CfMuiXVckVi0Gtkg3OXWp3I9lslxpFoREusfmBjnsDu7gQN+rSFUBY++QVYTD0 XZZJvkQoyX9OhuacDAnd9yVfUAg1QUEKrfJGbrd6O4b7y4agjvKGYMGwBlcoDP6l+Wn/K6Mg HjgBSKTWQAEOuVQITZbj/j71OUMQyWsiGktWqKhotCLjLGAYHyQZvfCbckrMFNUFDbpEvdja AjW20N0Er0k4C/6+inRSNOxJ+J2cQSKUZLe8SNUvlMouL2ziW0aPhXln6CQGzVq9lAKlvC2c 6UoYNBz357JEWIOcqxQrA5Scl54XGVHrUlaqY45Zs8CsuZRZ8zFmzTKzObU20VeRYqX7tSib NXTkyTBb2xLbkMSwhQnvFjy2cNJ/VXJmty6bKDdv0cmzR195gCOAcZ7utZqEUYeh/+SgK/Fo Bsrr5GyIjS08ijLXmeK5ipqemloGCgM5VqvVdHXSY57zKVsGZvyPgP8cYJZSYA6e5IiuAi7Y KCn4G9Rw9SOR3vhEpK/CnFr247B7GmhFDsuwpjjMW9vC6KV7mY5lARRVsQSZ9ILpfYbNIY/D r4BOJfpKgD5qy09D9HmpwIZGjnjEkiuVH8mtNwhYKWSlnrUKd5Hxsbzf9un1nAQTZgVpBc8q WuVmTEdaAi53OwrLqlvmD/Qo9cEdH5fYk2rDqGzoxzHICyU88EUYZbANhvE0kh59y5M8nCSO hEUqoZo0FOL8Snlvzkg6tQALT0EYmgwpd2pR2I8uWU0uKZmrpUaComqoK6DUBBmqHMUCTBT8 2MOELgjuZJ+Am3GMqzs4PFfwULOlKaBUomIhdYdzNmg6effVhSVfjRSUJbdNClewRDLDhV0h mswmKxsZrjw2mI4MvS/TMHo5WgCUvK5CHJEgM9BWUvOxVOaGtqO6C4lc9TVRpdCebVUR1Y/D Or0nXAXrXJwyhil7t+Q9nZHuJv34UWLYjRrYzUYVs0/EmtWo0qZROMn37IyNpoHD76hZ1JVx CRBxyGCi0svHdk7ykRu3ZFdobI6umTy1Yk5MOi2ksVaa2NDQ1LFeSBlw7QGLUmzC5WddhKL9 rMtIQ9ozlkEC0JFBzl72rD9hM6ESLTldgXKsxRMG7T3dy0nmiJlblG/ESLoSVedT1Twn0uwo M0xlk5e36TJSL1T0gWnYTl0hfVOdGnVqzJP0C2tqVRffuqYW5NPtnq+OiyL3iWHmjujSzY9k RlEZxyJBDrK7cVkIv3OGfs7vSGa0NPq0DDC57HywH958aOZJJolYg0ysGhBrZfhBdkSjuz3f Cfw/mJG9FiimqYURFqo0id04uKLDLrmBlMW/emf9w5PjlqIS6K1i5dFl78np+dVx7/zfJ2f/ vDo//KV38u68Bi2yXEUuP4+7oiXMiatidnnH+lPXZUIMp+SPaYxyNSgx+SRcfknwGhBHJX6q bZL5fwrWUtelKctubXH++fC8UY7PhLXQ8aMFoOVoRTfpu/vyTaERsPcs6GY98gVaDdSc3e0t wxEuOc+q/Z0A2FLUdG1cVfUQleeMWFVs44kCbWYY0qhfza3QRLvc+rmz9Utnq7+Ncs7gT3e+ ZNAlr9zG6ga9JjDIA1dUyLNLh/tz+WQkDsf4JYMt0VQz4ubziKVXXM1YkmSkq9mWSFvPJ915 FmnqeVdLmxLl5KslXiBfLfUC+WrJZ+SzLbTkK2Uj36a8QW3FXH2+vzVX38nrmXoWWpoLLa2F lpwPAg+Ofu2AAwHGNXTy8mWZLxAz8vjklT1uHkJ2G/ASmk11Wipg2U6zw1hYEycZWwhrkQhD p+/wdHW0KlnsglMiQm8aTr7RU055JjdALV6/lolgKQrPMZxzctg3wape3JffYnIR+bZk9XRX StW53la5ujOrznZkrqE539Cab8h5zAf5yBdj5qHoyqf9hd4irMu6rMu6rMu6rMu6rMu6rMu6 rMu6rMu6rMu6rMu6rMu6rMv/U/kvfCGhtABQAAA= --------------050709090905040108060403--

1 0

Re: (ITS#7968) SIGSEGV shortly after reconnection performed by syncrepl due to synchronization conflicts
by leo＠yuriev.ru 29 Nov '14

29 Nov '14

current OPENLDAP_REL_ENG_2_4 (6b26910 Silence compiler warning...) with merge-in current mdb.master (9a72292 ITS#7961,#7987 Re-fix txn init) - cluster of 4 node, but on single machine. - only localback network, no any failures. - multi-master by config, but all writes come only to first node. Testcase will be available shortly (config + script). Core was generated by `/opt/openldap.devel/libexec/slapd -l LOCAL5 -d 0 -s 0 -4 -h ldap://10.4.0.1:1114'. Program terminated with signal 11, Segmentation fault. #0 0x00007ff68564d07b in ?? () from /lib/x86_64-linux-gnu/libc.so.6 (gdb) bt #0 0x00007ff68564d07b in ?? () from /lib/x86_64-linux-gnu/libc.so.6 #1 0x000000000047fb3c in do_syncrep2 (op=0x7ff62f7fd740, si=0x1c74190) at syncrepl.c:934 #2 0x00000000004838c3 in do_syncrepl (ctx=<optimised out>, arg=0x1c746d0) at syncrepl.c:1539 #3 0x00000000004250a8 in connection_read_thread (ctx=0x7ff62f7fdbd0, argv=0x35) at connection.c:1293 #4 0x00007ff685ceecf2 in ldap_int_thread_pool_wrapper (xpool=0x1c27090) at tpool.c:688 #5 0x00007ff6858b90a5 in start_thread () from /lib/x86_64-linux-gnu/libpthread.so.0 #6 0x00007ff6855e684d in clone () from /lib/x86_64-linux-gnu/libc.so.6 > if ( !BER_BVISNULL( &syncCookie.octet_str ) ) > { > slap_parse_sync_cookie( &syncCookie, NULL ); > if ( syncCookie.ctxcsn ) { > int i, sid = slap_parse_csn_sid( syncCookie.ctxcsn ); > check_syncprov( op, si ); > for ( i =0; i<si->si_cookieState->cs_num; i++ ) { > /* new SID */ > if ( sid < si->si_cookieState->cs_sids[i] ) > break; > if ( si->si_cookieState->cs_sids[i] == sid ) { syncrepl.c:934 > if ( ber_bvcmp( syncCookie.ctxcsn, &si->si_cookieState->cs_vals[i] ) <= 0 ) { > bdn.bv_val[bdn.bv_len] = '\0'; > Debug( LDAP_DEBUG_SYNC, "do_syncrep2: %s CSN too old, ignoring %s (%s)\n", > si->si_ridtxt, syncCookie.ctxcsn->bv_val, bdn.bv_val ); > ldap_controls_free( rctrls ); > rc = 0; > si->si_too_old = 1; > goto done; > } > si->si_too_old = 0; > break; > } > }

1 0

Re: (ITS#7987) SIGSEGV in LMDB while adding ldap-entries
by leo＠yuriev.ru 28 Nov '14

28 Nov '14

(1) ITS#7968 not fixed - still crash in a few 'favorite' locations - last time SIGSEGV in do_syncrep2() at "if ( ber_bvcmp( syncCookie.ctxcsn, &si->si_cookieState->cs_vals[i] ) <= 0 )" (2) mdb.master seems to be have another bug(s), that also was fixed in the 'mdb/fixes' branch on git://git.uio.no/u/hbf/openldap.git - just a cherry-pick of ead57604 fixes this SIGSEGV, but I got a 'implementation specific' error in heavy add/delete test (same as in the attached testcase). - but merge 'mdb/fixes' passed my test. (3) OPENLDAP_REL_ENG_2_4 without merge current mdb.master and after revert all 4d02c741-related changes (single write txn) also passed my test. Leonid. 2014-11-28 22:06 GMT+03:00 Howard Chu <hyc(a)symas.com>: > leo(a)yuriev.ru wrote: >> >> Sure this bug is introduced by the 4d02c741 (Use a single write txn). >> >> Could be fixed by: >> cherry-pick ead57604 (ITS#7961 Re-fix txn init) from >> git://git.uio.no/u/hbf/openldap.git >> or >> revert: d72b2f5d (ITS#7961 fix txn init), 62e4eeb7 (ITS#7943 reinit >> txn flags), 891e6627 (Plug leak in 4d02c741...) and 4d02c741 (Use a >> single write txn). > > > Totally fixed? Or are you still seeing the ITS#7968 crash now? So far I've > run your testcase on the patched source (with ead57604) and gotten no > crashes. > > -- > -- 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#7987) SIGSEGV in LMDB while adding ldap-entries
by hyc＠symas.com 28 Nov '14

28 Nov '14

leo(a)yuriev.ru wrote: > Sure this bug is introduced by the 4d02c741 (Use a single write txn). > > Could be fixed by: > cherry-pick ead57604 (ITS#7961 Re-fix txn init) from > git://git.uio.no/u/hbf/openldap.git > or > revert: d72b2f5d (ITS#7961 fix txn init), 62e4eeb7 (ITS#7943 reinit > txn flags), 891e6627 (Plug leak in 4d02c741...) and 4d02c741 (Use a > single write txn). Totally fixed? Or are you still seeing the ITS#7968 crash now? So far I've run your testcase on the patched source (with ead57604) and gotten no crashes. -- -- 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#7987) SIGSEGV in LMDB while adding ldap-entries
by leo＠yuriev.ru 28 Nov '14

28 Nov '14

Sure this bug is introduced by the 4d02c741 (Use a single write txn). Could be fixed by: cherry-pick ead57604 (ITS#7961 Re-fix txn init) from git://git.uio.no/u/hbf/openldap.git or revert: d72b2f5d (ITS#7961 fix txn init), 62e4eeb7 (ITS#7943 reinit txn flags), 891e6627 (Plug leak in 4d02c741...) and 4d02c741 (Use a single write txn). Leonid.

1 0

Re: (ITS#7987) SIGSEGV in LMDB while adding ldap-entries
by leo＠yuriev.ru 27 Nov '14

27 Nov '14

confirm - this bug seems to be fixed (just merge with 'mdb/fixes' from git://git.uio.no/u/hbf/openldap.git). but now is another, like http://www.openldap.org/its/index.cgi/Incoming?id=7968 #3 0x00007f5061836c82 in __assert_fail () from /lib/x86_64-linux-gnu/libc.so.6 #4 0x00007f5061df4553 in ber_int_sb_write (sb=sb@entry=0x7f5024105870, buf=0x7f4ff80019d0, len=len@entry=152) at sockbuf.c:441 #5 0x00007f5061df0b8b in ber_flush2 (sb=0x7f5024105870, ber=ber@entry=0x7f500cffb330, freeit=freeit@entry=0) at io.c:246 #6 0x0000000000433dce in send_ldap_ber (op=0x7f500cffb7c0, ber=0x7f500cffb330) at result.c:339 #7 0x00000000004367a6 in slap_send_search_entry (op=0x7f500cffb7c0, rs=0x7f500cffb5c0) at result.c:1430 #8 0x000000000051077a in syncprov_sendresp (mode=<optimised out>, so=<optimised out>, opc=<optimised out>, op=<optimised out>) at syncprov.c:895 #9 syncprov_qplay (so=<optimised out>, op=<optimised out>) at syncprov.c:944 #10 syncprov_qtask (ctx=0x7f4ff81086c8, arg=0x7f4ff8108670) at syncprov.c:1010 #11 0x00007f5062009d12 in ldap_int_thread_pool_wrapper (xpool=0xd3b070) at tpool.c:688 #12 0x00007f5061bd40a5 in start_thread () from /lib/x86_64-linux-gnu/libpthread.so.0 #13 0x00007f506190184d in clone () from /lib/x86_64-linux-gnu/libc.so.6 (gdb) frame 4 #4 0x00007f5061df4553 in ber_int_sb_write (sb=sb@entry=0x7f5024105870, buf=0x7f4ff80019d0, len=len@entry=152) at sockbuf.c:441 441 assert( sb->sb_iod != NULL ); (gdb) info local ret = <optimised out> __PRETTY_FUNCTION__ = "ber_int_sb_write" (gdb) p *sb $1 = {sb_opts = {lbo_valid = 3, lbo_options = 0, lbo_debug = 16384}, sb_iod = 0x0, sb_fd = 75, sb_max_incoming = 262143, sb_trans_needs_read = 0, sb_trans_needs_write = 0} tail xxx.log 54775e18 syncrepl_entry: rid=001 cn=tablet,uid=1040,dc=ngdr,dc=ldap 54775e18 slap_queue_csn: queueing 0x7f5020107890 20141127172334.589180Z#000000#001#000000 54775e18 syncprov_matchops: skipping original sid 001 54775e18 slap_graduate_commit_csn: removing 0x7f502012d740 20141127172334.589180Z#000000#001#000000 54775e18 syncrepl_entry: rid=001 be_delete cn=tablet,uid=1040,dc=ngdr,dc=ldap (0) 54775e18 slap_queue_csn: queueing 0x7f5020107890 20141127172334.589180Z#000000#001#000000 54775e18 slap_graduate_commit_csn: removing 0x7f5020108020 20141127172334.589180Z#000000#001#000000 54775e18 do_syncrep2: rid=001 cookie=rid=001,sid=001,csn=20141127172334.589328Z#000000#001#000000 54775e18 syncrepl_message_to_entry: rid=001 DN: cn=tablet,uid=1793,dc=ngdr,dc=ldap, UUID: dc4d5d30-0aa5-1034-8ff5-a9ee5a485f53 slapd: sockbuf.c:441: ber_int_sb_write: Assertion `sb->sb_iod != ((void *)0)' failed. 2014-11-27 13:07 GMT+03:00 Hallvard Breien Furuseth <h.b.furuseth(a)usit.uio.no>: > On 11/27/2014 10:26 AM, leo(a)yuriev.ru wrote: >> >> # possible first bad commit: >> [4d02c741b120786df1b87ee9ed49c1d3f9bc7522] Use a single write txn > > > Partly fixed in mdb.master, but I think branch "mdb/fixes" > in <git://git.uio.no/u/hbf/openldap.git> is needed too. > That is, the "[Untested] ITS#7961 Re-fix txn init." commit. > Both branches have some remaining problems, however. > > -- > Hallvard

1 0

Re: (ITS#7987) SIGSEGV in LMDB while adding ldap-entries
by h.b.furuseth＠usit.uio.no 27 Nov '14

27 Nov '14

On 11/27/2014 10:26 AM, leo(a)yuriev.ru wrote: > # possible first bad commit: > [4d02c741b120786df1b87ee9ed49c1d3f9bc7522] Use a single write txn Partly fixed in mdb.master, but I think branch "mdb/fixes" in <git://git.uio.no/u/hbf/openldap.git> is needed too. That is, the "[Untested] ITS#7961 Re-fix txn init." commit. Both branches have some remaining problems, however. -- Hallvard

1 0

Re: (ITS#7987) SIGSEGV in LMDB while adding ldap-entries
by leo＠yuriev.ru 27 Nov '14

27 Nov '14

--f46d043c06bcb68d180508d3bcbe Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Two runs gave the same result, bisect-testcase attached. sudo will be called for ramfs-mount and ifconfig for ip-aliases (for cluste= r). mkdir xxx cd xxx tar xaf its7987-gitbisect-testcase.tar.gz git clone git://git.openldap.org/openldap.git openldap-source cd openldap-source git checkout OPENLDAP_REL_ENG_2_4 git bisect start 'OPENLDAP_REL_ENG_2_4' 'OPENLDAP_REL_ENG_2_4_39' git bisect run ../git-bisect-probe.sh git bisect log # bad: [6b26910c5acbf141ff322d043b3301d0976a7913] Silence compiler warning by adding explicit return 0 to ppolicy_db_destroy # good: [6bfa8256161618e62e56d139243aa234b3ece875] Prep for release git bisect start 'OPENLDAP_REL_ENG_2_4' 'OPENLDAP_REL_ENG_2_4_39' # good: [0e104da454c0f59c6d3195add38c935179de2cb3] Merge remote-tracking branch 'origin/mdb.master' into OPENLDAP_REL_ENG_2_4 git bisect good 0e104da454c0f59c6d3195add38c935179de2cb3 # good: [5e4cc6d1c515ace1e0c151ca8986bf805f203834] ITS#7895, ITS#7915 git bisect good 5e4cc6d1c515ace1e0c151ca8986bf805f203834 # good: [d871d328544124573bdbf63e360c4bb47e6c0d38] ITS#7702 git bisect good d871d328544124573bdbf63e360c4bb47e6c0d38 # good: [e4c848e24ff36139eb235efe7f426d89e01056ae] ITS#7915 fix memory leaks in previous patch git bisect good e4c848e24ff36139eb235efe7f426d89e01056ae # bad: [0659ef45d486b5daaafc020cb67b561a8029036d] ITS#7941 fix for repeated= tags git bisect bad 0659ef45d486b5daaafc020cb67b561a8029036d # bad: [5ebeec95535786ce7a0e80173209e33f64ab9013] Merge remote-tracking branch 'origin/mdb.master' into OPENLDAP_REL_ENG_2_4 git bisect bad 5ebeec95535786ce7a0e80173209e33f64ab9013 # skip: [29fd241fadc3dd49b3486f0e3556b029b716bcbf] Remember oldest reader t= xnid git bisect skip 29fd241fadc3dd49b3486f0e3556b029b716bcbf # skip: [3646ba966c75137b01e38fc5baea6d5864189c8e] More for me_pgoldest git bisect skip 3646ba966c75137b01e38fc5baea6d5864189c8e # skip: [4d02c741b120786df1b87ee9ed49c1d3f9bc7522] Use a single write txn git bisect skip 4d02c741b120786df1b87ee9ed49c1d3f9bc7522 # skip: [5ee99f1125a775f28ed69b06d991a43c60d894a9] Change retry to num times 60. Testing shows that on a known dataset, this has the same growth behavior as 2.4.39, while num times 20 resulted in significant growth. git bisect skip 5ee99f1125a775f28ed69b06d991a43c60d894a9 # only skipped commits left to test # possible first bad commit: [5ebeec95535786ce7a0e80173209e33f64ab9013] Merge remote-tracking branch 'origin/mdb.master' into OPENLDAP_REL_ENG_2_4 # possible first bad commit: [5ee99f1125a775f28ed69b06d991a43c60d894a9] Change retry to num times 60. Testing shows that on a known dataset, this has the same growth behavior as 2.4.39, while num times 20 resulted in significant growth. # possible first bad commit: [3646ba966c75137b01e38fc5baea6d5864189c8e] More for me_pgoldest # possible first bad commit: [29fd241fadc3dd49b3486f0e3556b029b716bcbf] Remember oldest reader txnid # possible first bad commit: [4d02c741b120786df1b87ee9ed49c1d3f9bc7522] Use a single write txn 2014-11-26 22:11 GMT+03:00 =D0=9B=D0=B5=D0=BE=D0=BD=D0=B8=D0=B4 =D0=AE=D1= =80=D1=8C=D0=B5=D0=B2 <leo(a)yuriev.ru>: > Just run a 'runme.sh' from attached tarball. > Problem (coredump) usually is reproduced for 10-20 min. > I will try 'git bisect'. > > Leonid. --f46d043c06bcb68d180508d3bcbe Content-Type: application/x-gzip; name="its7987-gitbisect-testcase.tar.gz" Content-Disposition: attachment; filename="its7987-gitbisect-testcase.tar.gz" Content-Transfer-Encoding: base64 X-Attachment-Id: f_i2zwyqwk1 H4sIAIHtdlQAA+07XVPjSJL9av2KbGEGuduSLYOh2z2eaxrcM8QwQGD69iZYgpClsq1BHx6VzMc0 PNze6/6Y3Y3d23u4299A/6PLrJJsyTYGehtmNoLqNlZlZWVlZWVlZmXJPTfWOy5ndqwPorDDDN5/ 9qVLFctavU7f5lq9mv2mUjNX156ZtZXler26srq6/KyKldrKM6h+cU5mlCGPrQjgmXcxH++29n/R svC80nGDSsfifUX5duvgeHNrv1nUImY5nhucgN6FojY4c0olpd3afp80O24UWD6DCcQqYu3tt95v /Uez+DFFv6r0WcR07lkDR1G6w8CO3TCAztD1HK0EH5WC7UAxGRouL4GduzGYtbpS6OGD7TErIOr6 OehOvt3twiE8p0ajYodB1+0NIwZHbyDus2CE9wa6rlLIYuio66zrniOXkt0rBLHA6nhMdy4Cy/bG dc+xBuNaeMoiz7rgCHFcLkCoP7Fr5wn4ApBidJxOptbHWm4WvnXCwGEDFjjw1VcgqvpPK6NnN8Ah PC/X6SojSbFvx5JM5U79I5+EY4c4Z6wZlWgY+Ex3Y772+tUabvU8I8zuh6C+eLACqliymPGYVo0J xuRiKYXx6LD7PSIWIsaHXtwMT5Axj7Mcxvv1re0MTtcSCLTMjzAHlL1QXkWxw2EQs6hZVTzXd+Pm mnLWdz2GSllMmkD3YiiKVtJLJ8Q1SjoVNW2E9RJM3DqZCUaoDlZiksfEwm5CC+cumpItUJRygOdN UMMTNd0BKKAO7s8TIRknDJjyCNLhHmMDMKuKMuarmfKlCGUr/pvya5u9p5IUN3Bjw3Pc7gOOQU5+ dXXlJv9fXa3XyP/XzLpp1qsm+v9q3aw++f/HKE7QAMdukpdTws5PGAdueBbnDQijnhW4v1jkYvIt cTiB6ti7oqo4dgMkpQZ84CzatGJrnw1C7sZhdKEoNNjQdZqW47tBOR0WIQ0QoFvGsWxhCMd00Ep6 rm2VZ04gxZ5Pk7v+wGNtZg8jN75I5iE4SogrQ5zIHuKehRFCzy9+kePjmEHPiWaPnRPewj2kRyRv kN7DrL8fOsygyOhhyIty2/43V1Zk/I8nAPx+2v+PWBRUNIxptzbh7dbmW0Xx3SgKI9IKONj/0FKS gBf4RWBjyHGqpA+63Wf2ySB0A4weq1Uwxy0R80LL6VOLoPFrz/Gp3FwSK/egJuC2/b+8Vh/5/+W1 Ndz/Zu1p/z9OEbuWlAAidKjCBtDR4tR18Ijydn1zcx8B8cWAobPtYjjfXw+cPRZxl8cKHr/i6KKp 1uGlCrHrs3AYN80qnOAJwPLcU9ZUzQb+w9MKZ1Zk9zsWR9iE58RWK44j3lRflF9ipeMGjs/ifug0 pXOWICdoqjN8PnZA9h0WxC4eApvkngvEijyQDQPxzRzkwP1lCvhrC/83UCYzAg8xxvz8Hzp7uf/R +6+u1tfI/5v11drT/n+Mksv/fdfabzVluk95t7Ujcn0fCZjL4W2uH6xPNTkYrCob2x/aBy1KEHL2 M5hQLynKiet5lL3SfwbRHXzmi9BBt3xndUX33GB4TtmpJHGgyJzVC8Pp9PBvfB6LNJGiiLSRfg5G JRywgPa+zsNhZLNMYu/3SuHyEjSZNwwDBvjUqFTwr5F2MjA2H1EwCHOCHBEpID+2M9WCUEGa2Edb B7t7rZ3tzfW94/3W9nFr59vj2vFKKWEizXSM+C5+lCK9qnCSOAnDchzQrdmTknEZF3hOxfDcTvJM OTttBnM4bMqfTJmei6ypkzTckP9MeHrk/KdkaVbicyLpeaM0pwWGEoqsyGWcnjzf6VTwc0zcJTRk YnXjLl1nj+rgGibKf5VMgZQ16mbglReTff0Tx41AH0x31nw6oMIl9NCpZZuxOx86Ich2PYbYH3Q5 7K//kMGaEk03jCBAwSFOshGvZMZxZ3ezJTfsiMsAA/zjYoAuPJ1AgkQToDUYMz1qOLUiSiBPgmjn Z2EstiHLFvp+B1R+mYx9OUa97L3hl1IBL0eaeNlT4WtIbYvQeBGcwjcTg2TbcuPJlKh2hip4Bl9/ /TWoY4GoJdB7eGDJpEhJbNEssRXS5CrlVYtBpkuhQIFRUyUdQvNiVo1iZFQNs1HUNJMKvMRupVJF FciJACi4uixGYtYysros0ld+xtmAHL6546RxEEp+F0SSd2LAIE9/dOC/O3EkrRS2drYORiZ/lDVU CpUhj4QLoagLtzkaiE7I8SkENG96UaOgT14WpUtc0ouBMOw3mcTuHMZ0DxuJGbRZbVoWXOTaN3OH Ik+Snc9CD3f4TWOzcxQdi8GKevzunJypomd0X1a2t9oHx6gEL5vabdIqYWAbDu1+liMMfS0MZA2x 7vTnzWeaAfJiOX0OpvQ5QH2GFKO2hu0pRnX5dTXFUKVJ6SID3XDufMgykJFzu9IxgRc2cDlHg0PA Yt/iJ1Cr143MB4YDJXtVQvFbjDTVubp4KztkTcc6gX6AnbNkuUHvkw0hGV2ptOzbuxvr23VyCObq 8qsV0DlUQV+Zry61b87C6GS+anwlNQK14VZ+UR3SiEmsvqzUFOU2IQwu8GwVzKYtBCER0E2S17MR aXQ8GFwoyRVS80sX9Wa9zevmPM0bKwUpNgqqgUDqKI+foH8HRaKGAcT29vZmmvgGvTN+PAPOcFvF tKgkIdgIg5idxxvtnewd2gMIQNHSu7M3kEbNQn/eJLFxfQyfFUSXUH0Ec3oA6u8stDAkUjukMzQl og3DUMm3n1ETfsuJgA40LfUzDcccbbOt+N7mH/vcanSTtdVHTihrUcUSje85E2VuiImLMAtXNwwc fre9oOz9ePDd7s5xu7Wxu7PZxoONoIH24F5kMMSzhyKAXGos0fxqCBlYPEY5ceclVjp2KWEakoIh R37wz10hEcTo/A4W8GjGXfxoI8kXCO4RdM8KE3XWTcPdpcUlHEiKk4H6nu7N+QWKxAc8Wg2GMSeX mpfzXHdSKDwQe/bIAEyr3vhqvb29vrc5R1F0HYck43749ujqbgqBccF8ghWHnVaCoeclpCmSuDv5 KX3LTaEMaUiELRlOUA0Tvdxr7W+0djAo1CSlCX2FF+JeoALaZMPLiaFKasKRhE7RzSF/BllpFJlU 6KLUGzxMHWztNlBw+dlcLe4h7eLHHCtXi+3fY3yhLMhz4PiNGgok73N0122ZzBDWqvpbyD+OTevD jXFL/r9WX66N7/+qq3T/t7r2lP97lLIA7zbfwTvLPqEsTJoiEhfX0EWbrCxAmzEYq4lWL4m4wmGx 5XocEC/fKxzQFzew50Hf5YIK8H449BzY2T2ADgMMhLFCrw5SRggxhzbZX31gxX204rKmKG5ge0OH FQpyy4pQIN1rFY7xj29VaDsZ8vmO+NwN7tnD85gdu6f36hW4/D7oyFMcRr0Bmg0M1O7RcZTJvEcf 5yLoReFw1EcZuA6tUqGQRA9pqqciKGOrQqdhgTITg1oVL+xNE0GgRMEHRYn7tOZcOhxzVYnD0NNT 4AraV9SqLooCfkCdHFgROvoYJaJ0pHoWCui9FdINCgNEZcG3zulmp2BW15bXVsxXtRUlBRXqy6uv 1qqvzZqywILTrmf1eOEscjHEwEAfPxbdfSnTTUEoGmZ0ki3guV0Mb0PLY9xmEIY+heXIPW0hOQNF 4cNu1z0vFNTRRVUUhrETTEIGZwiRRw70MI4boa6F0UVOiul2cBgSzLw8AuxnHDW9dwc+YLbbdW0Q mG7QA0oqQIhBXcTB4rjjfh7iAE5J0kJ+4+iC4hqkk4F8+LC1SSBlIXPHL8prUfDIOdVSq6MlR5c2 1QCvzNe1WQ1VOqwuCFvS/nFnY7+1t43V6/+7/htc//36T9d//vRf13/99MdPf0DAp/+8/gcC/3r9 p09/+PRHWf0HtvzFACcAje4FbYeXc+8W0R1jCa7/Atd/Rmp/Ryoa9vtfg4b4n+v/vv5bSb61yZGE wc4tO77hghGA1ClzbQjisjMDUBYc1GEfDy84yQhWavj/t+Dc71BmnPG/+Bjz/T+987c6ev9/zazS +/+15bUn//8YxfUHYRTLt/aSZ1LuMkizjEakDGi7e+IhsgIn9PFkEEdYT/Hx1FaGkOMuuFPBTf59 EJ4FYkxIYmU61KYv3ImEDZ46DpWFwqE6TviIbI9ahh08bh2Vlak2c9w23bE2r3F5XuPKuPHorlNU eu04HOAc3os309Ej7UUheUeaF1lKBSteBpbFqKBhxP4Wntaa8PFKkcmrto1uHAHCm7Y3dvdax+0P 7w72Wy30vPYJtoxWzNhGgFZSFFs4ifawwxPimnQepYZSQLuJ1AtLTrDUAGH4PlavypPvZpTpamHJ Dx2OWIcFTc14H5TLoZp909Hy9kT8gg3qYPSEgqAvHEG+56gelQRVLBpBBRkcOwe3AwE2c0CeAcIR gq8ohdwxsxOxgybdcPjlz54Rnqldm6Wcz2BK0J/goTbBQ0yBbfyATMgBMlwohbdiueWrM7i+DI+p 4npA48zrluEYmcG/ND6tf6HnhR3LA6GpZZAKh1QKpE2GZYtIAZVI3IJRX9qiEot6S7SIeQydh0Cj t4GGEWWPJNYhdTpCuZjKFDZCKDSJykKdeXRaQjzBGrZgBCJGEBpKvBtOIOuHUmRHhybRzWuPgYGE b8UajVo6EgwltA0c6Zhr1B3X5yiHWIYxVcFWqlBiXHqeJkTQmaRkwwSxWoZYbSax2k3EanliE2LF qFYsg7DNBuXHNBVpMgeWFvkSxCEschUW4aaJk/xLgjI7t9lA+gCD0uMtegWU4kUWRclay0EYNWjq ezz44TCxuOGTo6FuLHI82tnWkDMBum1o4UU0pFgqlZLZCYt5EA3ZLGXGDyr8l1BmwQWG8vFYo0uA E9ZyAn6OEi7dU9Orn6np83ROTvtmtbtd0bIUZumapDC526Z6z1zLpC/zICuKGZoZMT88TXWzG4X+ I2inZH2ugt64l29X0buFAgsKGeIei49l8CSWXiPFSlRWyFkpRDYS3hHX9y791EsoE0YFScXEkKEg f1xGihvZDanLslnED/Qo5BFZLk6xJcSGXllTd0IQt152GARM/mawGw4DYdEXHUHDiillQyKhmtgo 4ndp0nrjmRR5kBMw7H6IrkkTfCc7CtvRJMvBBSazlWSTIKsKHfPIMkVJiGLAPusNPSu6IDCvyHXi wEOf0a8ZRcZI6IgcMgkShSQFHSG/sTTEutDo1HfMKH3haVMzy9nwiljORERG4iOpa7JHDwUPKAqP Bck0gUzwl5uExP2i00is4x2mQQxQ9ClGz2/S9wimtAEqRTIDuUezwSptBTqzC+KoQOfIX48Rdzms xueKeYKlUVTcTXgTl5XJNBKFzm6nxAMku4p+u4OSHGdcCoPklzwEHWVdxIQoxUMTEl3H28tPNZuu gdxAOKdCP+QxUhDN1aOMJU+Zd1hn2NPUg+iCeEZbRK8wA8YpjY/m1duPtXG8QiyWIWWrDERamhsv jfbptsm1PPcXpqXX4NmIJ9PDQJHGoR16x3Sooo2ekPj31n57a3dnWWJxNEcyTSsEb+zuHRzvtA5+ t7v//fHB1g+t3Q8HZVg2qglR+Rr2MU1hgl1p/vMr1h7aNuO8O/S8CzFtaYyRYzLaOP0c42UgipL9 RNrE8z9l94Wsc0PmDf/0+JOWfiFv6knXfMsNphRtrK0di7v2hkiEax47ZV4zbdlsvfvwbRnkmM2l Rc3iNh2xS+ZrDrAoselOsyTrPgrP6rESX8LgFPdM16deP+qLvo77cvG7xuIPjcX2Uol+SZyoP91C 0oaWr74b4m0BrY7VBbpo0qq0TMJ2mblj4oF40mIrQv+ELQKllKDW7o66fHfUlTuhJvZxPrcJ0hh9 PsdT6PO5nkKfz/kIPRW0IV5L0kbSnKgvT9RXxvV08lOQ2hRkeQoyppM3amMrvVqlG1QZ2ma0xUxc ecgNuoUxUHF4zPG4GUZobhtT4c/UtidEZ+gPnqsJpZE7kz9CfyPeRMj5uQmCE2YE2wZYVTMy/Smk PTgSaa66nK+ujKojeU4AapOA5UnAmMakmwxc3mcOsiatwr9IrvepPJWn8lSeylN5Kk/lqTyV/wdD 8uEBAFAAAA== --f46d043c06bcb68d180508d3bcbe--

1 0

Re: (ITS#7988) Reflected XSS vulnerability in www.openldap.org
by hyc＠symas.com 26 Nov '14

26 Nov '14

yann.cam(a)gmail.com wrote: > Full_Name: Yann CAM > Version: > OS: > URL: http://www.openldap.org/its/ > Submission from: (NULL) (2a01:e34:edbf:a5d0:845:664b:ce80:cf7b) > > > I'm contacting you to inform you about the presence of a Reflected XSS > vulnerability on the www.openldap.org main domain. Thanks for the report, this is now fixed. > > Through this vulnerability, an attacker could tamper with page rendering, > redirect victims to fake OpenLdap pages, or capture users data. > > This reflected XSS is on GET "id" variable of the current "JitterBug" tracker, > and is not properly sanitized before being used to his page. > > The JitterBug tracker project seems to be suspended > (https://www.samba.org/cgi-bin/jitterbug/), this vulnerability isn't specific to > your bug tracker. I just open a ticket to report this vulnerability to the > samba-jitterbug maintainers (https://bugzilla.samba.org/show_bug.cgi?id=10967). > > Proof of Concept, tested with Firefox 33.1.1 (screenshot in attachment): > > http://www.openldap.org/its/index.cgi/Documentation?id=1337</TITLE><img > src=x onerror="alert(/Reflected XSS - Yann CAM @ASAfety/)" > /><TITLE>;selectid=1337 > > Screenshots available : > > http://www.asafety.fr/data/20141126-RXSS_openldap.org_synetis_001.png > http://www.asafety.fr/data/20141126-RXSS_openldap.org_synetis_002.png > > Feel free to contact me for more information, > > Best regards, > > Yann CAM - Security Consultant @ASafety - Synetis - www.synetis.com > > -- -- 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#7988) Reflected XSS vulnerability in www.openldap.org
by yann.cam＠gmail.com 26 Nov '14

26 Nov '14

Full_Name: Yann CAM Version: OS: URL: http://www.openldap.org/its/ Submission from: (NULL) (2a01:e34:edbf:a5d0:845:664b:ce80:cf7b) I'm contacting you to inform you about the presence of a Reflected XSS vulnerability on the www.openldap.org main domain. Through this vulnerability, an attacker could tamper with page rendering, redirect victims to fake OpenLdap pages, or capture users data. This reflected XSS is on GET "id" variable of the current "JitterBug" tracker, and is not properly sanitized before being used to his page. The JitterBug tracker project seems to be suspended (https://www.samba.org/cgi-bin/jitterbug/), this vulnerability isn't specific to your bug tracker. I just open a ticket to report this vulnerability to the samba-jitterbug maintainers (https://bugzilla.samba.org/show_bug.cgi?id=10967). Proof of Concept, tested with Firefox 33.1.1 (screenshot in attachment): http://www.openldap.org/its/index.cgi/Documentation?id=1337</TITLE><img src=x onerror="alert(/Reflected XSS - Yann CAM @ASAfety/)" /><TITLE>;selectid=1337 Screenshots available : http://www.asafety.fr/data/20141126-RXSS_openldap.org_synetis_001.png http://www.asafety.fr/data/20141126-RXSS_openldap.org_synetis_002.png Feel free to contact me for more information, Best regards, Yann CAM - Security Consultant @ASafety - Synetis - www.synetis.com

1 0

Re: (ITS#7987) SIGSEGV in LMDB while adding ldap-entries
by leo＠yuriev.ru 26 Nov '14

26 Nov '14

--e89a8f8389d1c4af560508c7cb28 Content-Type: text/plain; charset=UTF-8 Just run a 'runme.sh' from attached tarball. Problem (coredump) usually is reproduced for 10-20 min. I will try 'git bisect'. Leonid. --e89a8f8389d1c4af560508c7cb28 Content-Type: application/x-gzip; name="its7987-testcase.tar.gz" Content-Disposition: attachment; filename="its7987-testcase.tar.gz" Content-Transfer-Encoding: base64 X-Attachment-Id: f_i2z2cx130 H4sIADIkdlQAA+0723LbyLF+Bb6iF5JWoE2CN1Gy6eUe2xI3q4pWUolyUluKSgUCQxIRLtwZUBLX 0kOS13xMkkpOzkOSb5D/KN0zAAleREmO7c3W4eyKwPT09PT09G1mYC/0Yst3vc6TT1dKWDY3N+hZ 3qqVsk9ZNmuVJ+XKRqVcK5drpfKTUrlUK5eeQOkT8jQqAxHbHOCJP1yMd1/7z7S4YR1cp+G7dl+P 2r9lTrzt20LUIeJdO/R+tGMvCidb4mgK1XUOZFV3nTooSnV4KxjfsWP7iPUj4cURH+o6DTbw3Ibt Bl6YT4dFSB0k6J5xbMeJBmE8psNZ3/ccOz93Ain2YprCC/o+azFnwL14mMxDcpQQ1wc4kUPEvYw4 Qq+GP6rxccyw6/L5Y08Ib+UR0iOSd0jv06x/ELnMcqLwp7T/8sYG2X+1Vq3V8Lm0/89YdFS0C8Z3 d+DV7s4rXQ88ziNOWgHHR2+beoSNvj0EMQydPo8u9PSl4PSYc96PvDCGcqkE5XELZ35kuz1qkTR+ 6jkuy90l8XKf1AXcZ//Vrdoo/le3ttD+y5Wl/X+eIq2WlAA4BlTpAzQyYs9lvPHq9c7OEQLiYZ9h sO1wJnqvQ/eQceGJWNc4i/mwYdTgmQGxF7BoEDfKJThnrG/73gVrGOU6/mfommA2d3ptWyBsKnJi qx3HXDSMp/lnWGl7oRuwuBe5DRWcFcgNG8acmI8dkH2XhbFn+6JB4VkjVnwv8OLGIJRP5iIH3o8z wJ9a+P8FhQ/CgBW8WGy9eL5lid6nGINsfKtWu8P+MdiXkvhPLmCzSvZfq24u7f9zlJUvimhdRbTM nq5/2zxqNlbN/qWb09/s7u/sHjVW3xHwpthjnBWEb/ddfef18euZJheTVX17723ruIktpmA/QBk2 crp+7vm+7ftQ+AFkdwhYIFOHgh24mxsF3wsHV/Dll9iKbgPTCB5AoQNPLbfdxd/4KgYn4kzXYyZi KFyBVYz6LCTbL4howB1WpNjldQecwW907foazK6HnfwoZIBv9WIRf620k4W5+YiCRZhT5IiIhvw4 7kwLQiVpYh99HRwcNvf3dl4fnh01986a+784q5xt5BIm2BVirv7PmO/Vd0qkN0VBEidh2K4LxO+c oZBIOprP7JAIoFQKbtJgZSZdKPTRN3tXjdEICGKh3fZxWYah7fjjOg0xriXJnUCI6wkJQmuIPWeS QCABKUbbbWdqPawplgL7nIHLcB4upNX06YVI1/fvlM3smvpem9vcY4Le/MBtF/HvjLhLaEi6he2H dJ0/qosrkqjyTTIFUj3eycCLT6f7Bueux6HQn+1sBrTdhGvoYojKNmN3MXAjUO2FGOKg3xFw9Pq7 DNaMaDoRhxAFhziJWd28BDfStf2DnaYyvxGXIabrZ6shBuR0AgkSTYDWYMz0qOHC5kV0/tMgsuMs jMUOZNnCSO6CIa6Tsa/HqNfdl+JaKeD1SBOvuwZ8BamnkA5Apprw9dQg2baJ8bwOnMCqeYkqeAlf ffUVGGOBGDkodHH7AacvIe4xFIBGYuPzxKYllDh80YDVMNNF0yjNaRikQ+gsyiVrlVslq1xfNc0y FXiG3XK5oiGREwFQqnS9yuWsVZ50vUqPyRln02v4+oGTxkE6Hv666MH0qQHDSfqj7fvDiSNpXdvd 3z0eOXAvPQPUteJAcBkQKIdCM0cH0Y4EvkWAzqqwalIKhx6Bjd1ZrrAaSjd9h4MrdBYwVvCxkZhB n9WiZcFFrny9cCiKC9n5rHTRwu8am12h6FgMNu+Kh3Nyacie/LGs7O22js9QCZ41zPuklcM0NRo4 vSxHmMjamJZact3p5+UHugGKSRP6HM7oc4j6DClGZQvbU4xS9UUpxTCUS+kgA51o4XzIM5CT8zoq MIEf1XE5R4NDyOLAFudQqdWszB8M+tiVOb0IjKdPnwJlYzHSrBsLlfFefsidjpUCAwG7Ysl6Q6FH ToSEdGPQuu8dbL/eq1FEKG9Wn29AQUAJChuL9aXy9WXEzxfrxpdKJVAd7uUX9SFNgOTyq0pF1+8T Qn+IW6VwPm0pCIWAcZLCnoNIo2y/P9R1JfnGxy7G3Yo7qZyLVG+sFaTZiVJQR7WbhMK3sErUMIPY 29vbSc+xodAev16CYGhXMS0qSQi2ozBmV/F2a18J+pMJQDeTBS29hDQJlvrzMkl1a2P4vJw4h+oj mSuEYPzaRhdDInUi2hLTubJlWQYF90tqwqeaCBSApmV8oOdYoG2OHT/a/2Ofe71usraFURTKulS5 RPpYEZQy1+XEZZ6FqxuFrniYLeiH3x9/e7B/1mpuH+zvtHCfImmgP3gUGczxnIHMINfr6zS/CkL6 tohRTsJ9hpW2k0uYhqRgzjE5+IeukMxiCuIBHnCc4cwxJJCbiEdk3fPyxALrpPnu+to6DqTEycD4 xvMZiCGKJADcKfUHsaCYOinnhfFE0z4Re87IAcyqnsyOpM619l4f7ixQlEIBhyTnfvLq9OZhCoGJ wWKCRZddFMOB7yekKZV4OPkZfZuYQh7SnAhbMpygGiZ6edg82m7uY1ZoKkpT+gpP5TF/EczphmdT Q+WMhCMFnaE7gfwBZJVTZEqhV5Xe4G7qePegjoKbnM3N2iHSXn03wcrNWus3oZHuAzvyfEE6FEwk Z5VOXZAI5bWKFmqeSPMIRx1N/NRnOP9JGfviTzfGPef/lVq1Mr7/K23S/d/mVmV5/vc5ygq82XkD b2znnM5t0kMleXENHXTi+gq0GIOxmpi1nExEXBbbni8A8SZ7RX16CAt7Hvc8IamA6EUD34X9g2No M8DMGSu423HpDAkxBw457ELfjnvo9lVN173Q8Qcu0zRl4zJ3SK2zKDBhCuwiGaCl3h+IL7zwkT18 nzmxd/GoXqEnHoOOPMUR7/bR0WBm94iOo5PMR/Rxh2GXR4NRH73vubRKmpakG+nhUFFSxlad9s8S ZS4Gtep+1J0lgkCFgi/ocHu05kJFqPKmHkeRX0iBGzpqjMs6KAr4DnWyb3PMDGKUiN5W6qlpGO51 0g3KG2RlJbCv6GZHK5e2qlsb5eeVDT0FabXq5vOt0otyRV9h4UXHt7tCu+Qe5iS4M8A/m+6+9Nmm MJINczqpFvC9DubDke0z4TCIooDyeOSeTEjNQNfFoNPxrjTNGF1U8SiK3XAa0r9EiNqjYEhyPY66 FvHhhBRTc3AZEsx8PALsBxw1vXcH0WeO1/EckJhe2AU6hoAIs0AuwBZocT8McAA3p2ghvzEfUiKE dDKQt293dwikr2Tu+GV5IQvuUWdaKjX05FCabYDn5ReVeQ0l2t2uSF/S+n5/+6h5uIfV23/e/g1u /377p9s/v//D7V/f//H97xHw/ne3/0LgX2//9P737/+oqv/Clr9Y4IZg0r2g44r8xLdFdMeYg9u/ wO2fkdrfkYqJ/f5h0RD/d/u/t3/L6fIeUCAJi13ZTnzHBSMAqVPm2hDkZWcGoK+4qMMB7nZwkhw2 Kvj/zyQrmHMo8NHHWBz/6Zu/zeT+D8HVGsb/SmVjaxn/P0fxgn7EY/XVXvJOyp0H5ZbRieQBfXdX vnA7dKMAtxIxx3qKj9u8PEQCreBBBY38l2F0GcoxIcmuaRecfnAnT3hwm3Kir2gnxviESB4PGXnY x/3ZaV6faSuP22Y7VhY1Vhc1bowbTx86Rb3biqM+zuEb2xeMItIhjyg60rzIU+pY8TOwLEYRHSP2 t3F714B3N7o67Wo5GMYRIKNpa/vgsHnWevvm+KjZxMjrnGPLaMWsPQSYOV13ZJBoDdoiIW6q4JGr 6xr6TaSurbvheh2k43tXuslPf5uRp8uI9SByBWKdaKaRiT4olxMj+6Wj7R/K/AUbjP7oDQVBDxxB fedonOYkVSwmQSUZHHsC7oQSXJ4AigwQThF8Q4fO7XJ2Ik7YoDuRIP/BM8JNuOewlPM5TEn6UzxU pniIKbGNPyETaoAMF7r2Si63+nQG15fhxlZeKJiC+Z08nCEz+Evj0/prXT9q2z5ITc2DUjikopE2 WbYjMwVUInlvRn3JRBUW9VZonPkMg4dEo6+BBpyOmxTWCXU6RbmU9RlshFBqwvNSnQW/yCGeZA1b MAORI0gNJd4tN1T1EyWy05My0Z3UHgsTicCOTRo1dyoZSmhbONKZMKk7rs/pBGIexlQlW6lCyXHp fZYQQeeSUg1TxCoZYpW5xCp3EatMEpsSK2a1chmkb7boQM00kCZzYX1NrEMcwZowYA3umjjJPycp syuH9VUMsOg8vUmfgFK+yDhP1loNwqjBNL7BjR8OE8s7QTUa6saawK2dYw8Ek6D7hpZRxESKuVwu mZ30mMd8wOYpM/6hwn8MZZZcYCofjzU6Bzhhc0LAX6CEc4/U9NIHavoinVPTvlvt7le0LIV5uqYo TFvbTO+5a5n0ZT5kRTFHMzkLootUNzs8Cj6DdirWFyronbZ8v4o+LBVY0ckRd1l8ppInufQmKVai slLOusYdJLwvL/xxS8GVMmFWkFTKmDJolz06SiHF5U5d6bJqlvkDvUp5cNvDKTal2DAqm8Z+BPKa zInCkE4y6GgnGoTSo6+5koYd05ENiYRq0lCI8jPlvXFPijyoCVhOL8LQZEq+E4vCdnTJanCJyRw9 MRJkVadtHnkmnqQoFhyx7sC3+ZDAoqjWSYCIAgZ9lakoHVFDJkmilKSkI+U3loZcFxqd+o4ZpQfu Ns1yPpteEcuZjMhKYiR1TWz0RPKAovBZmEwTyAV/vEko3I86jcQ7PmAaxABln3L0SSP9BsF0bIBK kcxA2Wg2WSVToD27JI4KdIX8dRlxN4FV/1AxT7E0yoo7CW/ydjOZRqLQWXNKIkBiVfRvd1CS4xMX rZ/8Sx6Cjk5d5IToiIcmJLuOzStINZvujbxQBietF4kYKcjm0mnGk6fMu6w96JrGMR8Sz+iL6BNm wDyl/q588+pdZZyvEIt5SNnKA5FW7sZPs326nvJs3/uRmem9eTbjyfSwUKRx5ET+GW2qyNATEr9q HrV2D/arCkugO1LHtFLw1sHh8dl+8/jXB0e/PDve/a558PY4D1WrlBBVn2Gf0RSm2FXuf3LFWgPH YUJ0Br4/lNNWzhg5JqeN059gPA9EUbGfSJt4/o/8vpT1xJCTjn92/GlPvzLp6knXAtsLZxRtrK1t W3jOtjwIN312wfxG2rLTfPP2F3lQYzbW10xbOLTFzpVfCIA1hU2XoDlVD1B4dpflxDomp2gznYB6 fV9YCwpol2vf1te+q6+11pHPkfrTtSUZtPr03ZKfF5g1rK7QPbpZomWSvqs8sU08lm9mbHOMT9gi UXIJauXhqNWHo248CDXxj4u5TZDG6Is5nkFfzPUM+mLOR+ipoC35IZM5kuZUvTpV3xjX08nPQCoz kOoMZExn0qmNvfRmCZ5CtSQddEZbykkoj4RFtzAWKo6IBW43I47utj6T/syYPSG6g6D/hZFQGoUz rY2yOn8pP12YiHNTBKfcCLb1sWpkZPrbiGxwJNKJanWyujGqjuQ5BahMA6rTgDGN6TAZeqLHXGRN eYWfyVnvsizLsizLsizLsizLsizLsizLsizLsizLsvz/K/8GiErmgABQAAA= --e89a8f8389d1c4af560508c7cb28--

1 0

(ITS#7987) SIGSEGV in LMDB while adding ldap-entries
by leo＠yuriev.ru 26 Nov '14

26 Nov '14

Full_Name: Leonid Yuriev Version: 2.4 git head (OPENLDAP_REL_ENG_2_4 branch) OS: Ubuntu 14.10 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (31.130.36.33) Multi-master cluster of 4 nodes. Testcase will be available shortly (config + script). Program terminated with signal 11, Segmentation fault. #0 0x00000000004a2e25 in mdb_cursor_put (mc=0x7f81f915c370, key=0x7f82177fd120, data=0x7f82177fd130, flags=32) at ./../../../libraries/liblmdb/mdb.c:6358 6358 nsize = IS_LEAF2(mc->mc_pg[mc->mc_top]) ? key->mv_size : mdb_leaf_size(env, key, rdata); (gdb) bt #0 0x00000000004a2e25 in mdb_cursor_put (mc=0x7f81f915c370, key=0x7f82177fd120, data=0x7f82177fd130, flags=32) at ./../../../libraries/liblmdb/mdb.c:6358 #1 0x00000000004a2b52 in mdb_cursor_put (mc=mc@entry=0x7f81f915c370, key=key@entry=0x7f82177fd120, data=data@entry=0x7f82177fd130, flags=flags@entry2%2) at ./../../../libraries/liblmdb/mdb.c:6471 #2 0x00000000004d3e58 in mdb_idl_insert_keys (be=<optimised out>, cursor=0x7f81f915c370, keys=<optimised out>, id=997543) at idl.c:534 #3 0x00000000004d5143 in indexer (op=0x7f81ed1356e0, txn=0x0, atname=0%0, vals=0x7f81f81026d0, id=997543, opid=1, mask=4, ad=<optimised out>, ai=<optimised out>, ai=<optimised out>) at index.c:219 #4 0x00000000004d5445 in index_at_values (op=0x7f81ed1356e0, txn=0x1b55110, type=0x194a270, tags=0x1943830, vals=0x7f81f81026d0, id=997543, opid=1, ad=<optimised out>) at index.c:337 #5 0x00000000004d59f9 in mdb_index_values (opid=<optimised out>, id=<optimised out>, vals=<optimised out>, desc=<optimised out>, txn=<optimised out>, op=<optimised out>) at index.c:386 #6 mdb_index_entry (op=0x0, txn=0x2C o opid=394252592, e=0x8) at index.c:558 #7 0x00000000004c9159 in mdb_add (op=0x7f81ed1356e0, rs=0x7f82177fda80) at add.c:359 #8 0x000000000048a346 in overlay_op_walk (op=op@entry=0x7f81ed1356e0, rs=0x7f82177fda80, which=op_add, oi=0x19a3730, on=0x0)t t backover.c:671 #9 0x000000000048a4b1 in over_op_func (op=0x7f81ed1356e0, rs=<optimised out>, which=<optimised out>) at backover.c:723 #10 0x000000000042a9b0 in fe_op_add (op=0x7f81ed1356e0, rs=0x7f82177fda80) at add.c:334 #11 0x000000000042b59f in do_add (op=0x7f81ed1356e0, rs=0x7f82177fda80) at add.c:194 #12 0x0000000000424624 in connection_operation (ctx=0x7f82177fdbd0, arg_v=0x7f81ed1356e0) at connection.c:1155 #13 0x0000000000424d3c in connection_read_thread (ctx=0x7f82177fdbd0, argv=0x13) at connection.c:1291 #14 0x00007f824def1cf2 in ldap_int_thread_pool_wrapper (xpool=0x1956090) at tpool.c:688 #15 0x00007f824dabc0a5 in start_thread () from /lib/x86_64-linux-gnu/libpthread.so.0 #16 0x00007f824d7e984d in clone () from /lib/x86_64-linux-gnu/libc.so.6 (gdb) p * mc $1 = {mc_next = 0x0, mc_backup = 0x0, mc_xcursor = 0x7f81f915c4f8, mc_txn = 0x1b55110, mc_dbi = 5, mc_db = 0x1b55288, mc_dbx = 0x1b52660, mc_dbflag = 0x1b57015 "\v\n\n", mc_snum = 0, mc_top = 0, mc_flags % 6 64, mc_pg = {0x0, 0x7f822f03f000, 0x7f822f287000, 0x308f, 0x2fb0, 0x2e37, 0x2d75, 0x2bbc, 0x2b76, 0x28eb, 0x25f4, 0x2582, 0x2439, 0x225f, 0x21d0, 0x1fdd, 0x1c89, 0x1b68, 0x1b00, 0x19db, 0x1323, 0xf00, 0x895, 0x223, 0x12b, 0x3cb, 0x32b, 0xe5, 0x0, 0x7f81f9006e63, 0x941, 0x7f81f80005b8}, mc_ki = {0, 0, 0, 0, 50336, 63765, 32641, 0, 50336, 63765, 32641, 0, 3, 0, 12849, 14641, 21032, 437, 0, 0, 9728, 437, 0, 0, 28691, 437, 0, 0, 3, 2, 65, 0}} (gdb) p mc->mc_top $2 = 0 (gdb) p mc->mc_pg $3 = {0x0, 0f8f822f03f000, 0x7f822f287000, 0x308f, 0x2fb0, 0x2e37, 0x2d75, 0x2bbc, 0x2b76, 0x28eb, 0x25f4, 0x2582, 0x2439, 0x225f, 0x21d0, 0x1fdd, 0x1c89, 0x1b68, 0x1b00, 0x19db, 0x1323, 0xf00, 0x895, 0x223, 0x12b, 0x3cb, 0x32b, 0xe5, 0x0, 0x7f81f9006e63, 0x941, 0x7f81f80005b8} (gdb) p mc->mc_pg[mc->mc_top] $4 = (MDB_page *) 0x0 git show commit 6b26910c5acbf141ff322d043b3301d0976a7913 Author: Quanah Gibson-Mount <quanah(a)openldap.org> Date: 2014-10-03 15:35:39 -0500 Silence compiler warning by adding explicit return 0 to ppolicy_db_destroy

1 0

(ITS#7986) -y option issue during read the password from a file
by shifeng.hu＠ericsson.com 21 Nov '14

21 Nov '14

Full_Name: Shifeng Hu Version: openldap2-2.4.26-0.26.1 OS: SUSE 11 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (195.235.15.200) Dear There Our server is using LDAP, but I found there was an issue when I use -y file option to set the password of LDAP User. the User password was defined in server system as 7 characters without any "\0" when I try to use ldapsearch or ldapmodify with the option -y to give the password I am for sure the password in file is exactly same with I set. And I did a capture for LDAP, I saw there is a \0 in the suffix of password, this means the tool adds an additional '\0' in the last. then I got the error output li%0 below ldap_bind: Invalid credentials (49) As I check the src in the file "libraries\liblutil\passfile.c" passwd->bv_len = nread; passwd->bv_val[nread] = '\0'; is this necessary for a \0 BR//shifeng Thanks!

1 0

Re: (ITS#7985) Recursive values
by andrew.findlay＠skills-1st.co.uk 19 Nov '14

19 Nov '14

On Tue, Nov 18, 2014 at 07:48:28PM +0000, michael(a)stroeder.com wrote: > > Same problems (recursion) with slapcat - > > In this case I rather suspect something's wrong with your LDAP management > client application. I'd check the slapd logs covering the period the entries > were created. Good point. The critical thing to note in the slapcat output is that the entryUUID values are all different. I had missed that first time around but it clearly indicates that those entries actually exist. Andrew -- ----------------------------------------------------------------------- | From Andrew Findlay, Skills 1st Ltd | | Consultant in large-scale systems, networks, and directory services | | http://www.skills-1st.co.uk/ +44 1628 782565 | -----------------------------------------------------------------------

1 0

Re: (ITS#7985) Recursive values
by michael＠stroeder.com 18 Nov '14

18 Nov '14

belykh.o(a)gmail.com wrote: > Same problems (recursion) with slapcat - In this case I rather suspect something's wrong with your LDAP management client application. I'd check the slapd logs covering the period the entries were created. Ciao, Michael.

1 0

Re: (ITS#7985) Recursive values
by belykh.o＠gmail.com 18 Nov '14

18 Nov '14

--f46d04428fb47234e2050826ed02 Content-Type: text/plain; charset=UTF-8 Database reindexing: no effect. Overlays: overlay syncprov Same problems (recursion) with slapcat - dn: telephoneNumber=1000,telephoneNumber=1000,telephoneNumber=2020,ou=phones ,ou=accounts,dc=... telephoneNumber: 1000 telephoneNumberAccessCode: 8864 objectClass: telephoneNumberAccount userPassword:: ... structuralObjectClass: telephoneNumberAccount entryUUID: bc8a4014-0355-1034-8cad-1351d00c5bbd creatorsName: cn=ldroot,dc=... createTimestamp: 20141118100223Z entryCSN: 20141118100223.423286Z#000000#000#000000 modifiersName: cn=ldroot,dc=... modifyTimestamp: 20141118100223Z dn: telephoneNumber=1000,telephoneNumber=1000,telephoneNumber=1000,telephone Number=2020,ou=phones,ou=accounts,dc=... telephoneNumber: 1000 telephoneNumberAccessCode: 8864 objectClass: telephoneNumberAccount userPassword:: ... structuralObjectClass: telephoneNumberAccount entryUUID: bc8d2860-0355-1034-8cae-1351d00c5bbd creatorsName: cn=ldroot,dc=... createTimestamp: 20141118100223Z entryCSN: 20141118100223.442503Z#000000#000#000000 modifiersName: cn=ldroot,dc=... modifyTimestamp: 20141118100223Z dn: telephoneNumber=1000,telephoneNumber=1000,telephoneNumber=1000,telephone Number=1000,telephoneNumber=2020,ou=phones,ou=accounts,dc=... telephoneNumber: 1000 telephoneNumberAccessCode: 8864 objectClass: telephoneNumberAccount userPassword:: ... structuralObjectClass: telephoneNumberAccount entryUUID: bc914c06-0355-1034-8caf-1351d00c5bbd creatorsName: cn=ldroot,dc=... createTimestamp: 20141118100223Z entryCSN: 20141118100223.469632Z#000000#000#000000 modifiersName: cn=ldroot,dc=... modifyTimestamp: 20141118100223Z dn: telephoneNumber=1000,telephoneNumber=1000,telephoneNumber=1000,telephone Number=1000,telephoneNumber=1000,telephoneNumber=2020,ou=phones,ou=accounts ,dc=... telephoneNumber: 1000 telephoneNumberAccessCode: 8864 objectClass: telephoneNumberAccount userPassword:: ... structuralObjectClass: telephoneNumberAccount entryUUID: bc9429a8-0355-1034-8cb0-1351d00c5bbd creatorsName: cn=ldroot,dc=... createTimestamp: 20141118100223Z On 18 November 2014 17:47, <openldap-its(a)openldap.org> wrote: > > *** THIS IS AN AUTOMATICALLY GENERATED REPLY *** > > Thanks for your report to the OpenLDAP Issue Tracking System. Your > report has been assigned the tracking number ITS#7985. > > One of our support engineers will look at your report in due course. > Note that this may take some time because our support engineers > are volunteers. They only work on OpenLDAP when they have spare > time. > > If you need to provide additional information in regards to your > issue report, you may do so by replying to this message. Note that > any mail sent to openldap-its(a)openldap.org with (ITS#7985) > in the subject will automatically be attached to the issue report. > > mailto:openldap-its@openldap.org?subject=(ITS#7985) > > You may follow the progress of this report by loading the following > URL in a web browser: > http://www.OpenLDAP.org/its/index.cgi?findid=7985 > > Please remember to retain your issue tracking number (ITS#7985) > on any further messages you send to us regarding this report. If > you don't then you'll just waste our time and yours because we > won't be able to properly track the report. > > Please note that the Issue Tracking System is not intended to > be used to seek help in the proper use of OpenLDAP Software. > Such requests will be closed. > > OpenLDAP Software is user supported. > http://www.OpenLDAP.org/support/ > > -------------- > Copyright 1998-2007 The OpenLDAP Foundation, All Rights Reserved. > > --f46d04428fb47234e2050826ed02 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr"><div>Database reindexing: no effect.</div><div><br></div><= div>Overlays:</div><div>overlay syncprov</div><div><br></div><div>Same prob= lems (recursion) with slapcat -=C2=A0</div><div><br style=3D"color:rgb(0,0,= 0);font-family:Helvetica;font-size:medium;text-align:-webkit-auto"><div sty= le=3D"color:rgb(0,0,0);font-family:Helvetica;font-size:medium;text-align:-w= ebkit-auto"><div>dn: telephoneNumber=3D1000,telephoneNumber=3D1000,telephon= eNumber=3D2020,ou=3Dphones</div><div>=C2=A0,ou=3Daccounts,dc=3D...</div><di= v>telephoneNumber: 1000</div><div>telephoneNumberAccessCode: 8864</div><div= >objectClass: telephoneNumberAccount</div><div>userPassword:: ...</div><div= >structuralObjectClass: telephoneNumberAccount</div><div>entryUUID: bc8a401= 4-0355-1034-8cad-1351d00c5bbd</div><div>creatorsName: cn=3Dldroot,dc=3D...<= /div><div>createTimestamp: 20141118100223Z</div><div>entryCSN: 201411181002= 23.423286Z#000000#000#000000</div><div>modifiersName: cn=3Dldroot,dc=3D...<= /div><div>modifyTimestamp: 20141118100223Z</div><div><br></div><div>dn: tel= ephoneNumber=3D1000,telephoneNumber=3D1000,telephoneNumber=3D1000,telephone= </div><div>=C2=A0Number=3D2020,ou=3Dphones,ou=3Daccounts,dc=3D...</div><div= >telephoneNumber: 1000</div><div>telephoneNumberAccessCode: 8864</div><div>= objectClass: telephoneNumberAccount</div><div>userPassword:: ...</div><div>= structuralObjectClass: telephoneNumberAccount</div><div>entryUUID: bc8d2860= -0355-1034-8cae-1351d00c5bbd</div><div>creatorsName: cn=3Dldroot,dc=3D...</= div><div>createTimestamp: 20141118100223Z</div><div>entryCSN: 2014111810022= 3.442503Z#000000#000#000000</div><div>modifiersName: cn=3Dldroot,dc=3D...</= div><div>modifyTimestamp: 20141118100223Z</div><div><br></div><div>dn: tele= phoneNumber=3D1000,telephoneNumber=3D1000,telephoneNumber=3D1000,telephone<= /div><div>=C2=A0Number=3D1000,telephoneNumber=3D2020,ou=3Dphones,ou=3Daccou= nts,dc=3D...</div><div>telephoneNumber: 1000</div><div>telephoneNumberAcces= sCode: 8864</div><div>objectClass: telephoneNumberAccount</div><div>userPas= sword:: ...</div><div>structuralObjectClass: telephoneNumberAccount</div><d= iv>entryUUID: bc914c06-0355-1034-8caf-1351d00c5bbd</div><div>creatorsName: = cn=3Dldroot,dc=3D...</div><div>createTimestamp: 20141118100223Z</div><div>e= ntryCSN: 20141118100223.469632Z#000000#000#000000</div><div>modifiersName: = cn=3Dldroot,dc=3D...</div><div>modifyTimestamp: 20141118100223Z</div><div><= br></div><div>dn: telephoneNumber=3D1000,telephoneNumber=3D1000,telephoneNu= mber=3D1000,telephone</div><div>=C2=A0Number=3D1000,telephoneNumber=3D1000,= telephoneNumber=3D2020,ou=3Dphones,ou=3Daccounts</div><div>=C2=A0,dc=3D...<= /div><div>telephoneNumber: 1000</div><div>telephoneNumberAccessCode: 8864</= div><div>objectClass: telephoneNumberAccount</div><div>userPassword:: ...</= div><div>structuralObjectClass: telephoneNumberAccount</div><div>entryUUID:= bc9429a8-0355-1034-8cb0-1351d00c5bbd</div><div>creatorsName: cn=3Dldroot,d= c=3D...</div><div>createTimestamp: 20141118100223Z</div><div><br></div></di= v></div></div><div class=3D"gmail_extra"><br><div class=3D"gmail_quote">On = 18 November 2014 17:47, <span dir=3D"ltr"><<a href=3D"mailto:openldap-i= ts(a)openldap.org" target=3D"_blank">openldap-its(a)openldap.org</a>></span>= wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;bor= der-left:1px #ccc solid;padding-left:1ex"><br> *** THIS IS AN AUTOMATICALLY GENERATED REPLY ***<br> <br> Thanks for your report to the OpenLDAP Issue Tracking System.=C2=A0 Your<br= > report has been assigned the tracking number ITS#7985.<br> <br> One of our support engineers will look at your report in due course.<br> Note that this may take some time because our support engineers<br> are volunteers.=C2=A0 They only work on OpenLDAP when they have spare<br> time.<br> <br> If you need to provide additional information in regards to your<br> issue report, you may do so by replying to this message.=C2=A0 Note that<br= > any mail sent to <a href=3D"mailto:openldap-its@openldap.org">openldap-its@= openldap.org</a> with (ITS#7985)<br> in the subject will automatically be attached to the issue report.<br> <br> =C2=A0 =C2=A0 =C2=A0 =C2=A0 mailto:<a href=3D"mailto:openldap-its@openldap.= org">openldap-its(a)openldap.org</a>?subject=3D(ITS#7985)<br> <br> You may follow the progress of this report by loading the following<br> URL in a web browser:<br> =C2=A0 =C2=A0 <a href=3D"http://www.OpenLDAP.org/its/index.cgi?findid=3D798= 5" target=3D"_blank">http://www.OpenLDAP.org/its/index.cgi?findid=3D7985</a= ><br> <br> Please remember to retain your issue tracking number (ITS#7985)<br> on any further messages you send to us regarding this report.=C2=A0 If<br> you don't then you'll just waste our time and yours because we<br> won't be able to properly track the report.<br> <br> Please note that the Issue Tracking System is not intended to<br> be used to seek help in the proper use of OpenLDAP Software.<br> Such requests will be closed.<br> <br> OpenLDAP Software is user supported.<br> =C2=A0 =C2=A0 =C2=A0 =C2=A0 <a href=3D"http://www.OpenLDAP.org/support/" ta= rget=3D"_blank">http://www.OpenLDAP.org/support/</a><br> <br> --------------<br> Copyright 1998-2007 The OpenLDAP Foundation, All Rights Reserved.<br> <br> </blockquote></div><br></div> --f46d04428fb47234e2050826ed02--

1 0

Re: (ITS#7985) Recursive values
by michael＠stroeder.com 18 Nov '14

18 Nov '14

belykh.o(a)gmail.com wrote: > Error details: request returns recursive values on some leaves. What does the slapcat output look like? Also which overlays are configured? slapo-rwm? Ciao, Michael.

1 0

Re: (ITS#7985) Recursive values
by andrew.findlay＠skills-1st.co.uk 18 Nov '14

18 Nov '14

On Tue, Nov 18, 2014 at 11:47:10AM +0000, belykh.o(a)gmail.com wrote: > Error details: request returns recursive values on some leaves. Some sensitive > values replaced with '…' Please check: That is certainly an odd one. You are going to have to supply a lot more information before the developers will consider this a usable bug report, but before getting into that I suggest you stop the server and use slapindex to re-build all the indexes. If you have been modifying the configuration after loading data it is possible that the index data is inconsistent. Andrew -- ----------------------------------------------------------------------- | From Andrew Findlay, Skills 1st Ltd | | Consultant in large-scale systems, networks, and directory services | | http://www.skills-1st.co.uk/ +44 1628 782565 | -----------------------------------------------------------------------

1 0

(ITS#7985) Recursive values
by belykh.o＠gmail.com 18 Nov '14

18 Nov '14

Full_Name: Oleg Belykh Version: 2.4.40 OS: FreeBSD URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (37.99.40.12) We are testing latest OpenLDAP 2.4.40 with mdb (FreeBSD 10) with our custom schema and structure. Error details: request returns recursive values on some leaves. Some sensitive values replaced with 'âŠ' Please check: custom schema: # Telephone Attributes attributetype ( 1.3.6.1.4.1.4203.666.6273.2.1 NAME 'telephoneNumberAccessCode' DESC 'Access code for telephoneNumber services' EQUALITY caseIgnoreIA5Match SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 ) attributetype ( 1.3.6.1.4.1.4203.666.6273.2.2 NAME 'faxDeliveryMailbox' EQUALITY caseIgnoreIA5Match SUBSTR caseIgnoreIA5SubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.26{256} ) attributetype ( 1.3.6.1.4.1.4203.666.6273.2.3 NAME 'voiceDeliveryMailbox' DESC 'Voice Mailbox' EQUALITY caseIgnoreIA5Match SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 ) attributetype ( 1.3.6.1.4.1.4203.666.6273.2.4 NAME 'phoneGroupName' DESC 'Telephone Group Name'D0D EQUALITY caseIgnoreIA5Match SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 ) objectclass ( 1.3.6.1.4.1.4203.666.6273.2.100 NAME 'telephoneNumberAccount' DESC 'Telephone account' SUP top STRUCTURAL MUST ( telephoneNumber ) MAY ( userPassword $ telephoneNumberAccessCode $ macAddress $ faxDeliveryMailbox ) ) ldapsearch results: root@sw:/lib/ldap # ldapsearch -H 'ldapi://%2fvar%2frun%2fopenldap%2fldapi/' -W -b 'dc=âŠ' -D 'cn=ldroot,dc=âŠ' Enter LDAP Password: # extended LDIF # # LDAPv3 # base <dc=âŠ> with scope subtree # filter: (objectclass=*) # requesting: ALL # # âŠ dn: dc=âŠ objectClass: dcObject objectClass: organization objectClass: top dc: ... o: ... # accounts, âŠ dn: ou=accounts,dc=âŠ objectClass: top objectClass: organizationalUnit ou: accounts # persons, accounts, âŠ dn: ou=persons,ou=accounts,dc=âŠ objectClass: organizationalUnit ou: persons # kerberos, accounts, âŠ dn: ou=kerberos,ou=accounts,dc=âŠ objectClass: organizaonalalUnit ou: kerberos # mails, accounts, âŠ dn: ou=mails,ou=accounts,dc=âŠ objectClass: organizationalUnit ou: mails # phones, accounts, âŠ dn: ou=phones,ou=accounts,dc=âŠ objectClass: organizationalUnit ou: phones # groups, âŠ dn: ou=groups,dc=âŠ objectClass: top objectClass: organizationalUnit ou: groups # userGroups, groups, âŠ dn: ou=userGroups,ou=groups,dc=âŠ objectClass: organizationalUnit ou: usergroups # phoneGroups, groups, âŠ dn: ou=phoneGroups,ou=groups,dc>2E2Š objectClass: organizationalUnit ou: phonegroups # computers, âŠ dn: ou=computers,dc=âŠ objectClass: top objectClass: organizationalUnit ou: computers # services, âŠ dn: ou=services,dc=âŠ objectClass: top objectClass: organizationalUnit ou: services # manager, accounts, âŠ dn: uid=manager,ou=accounts,dc=âŠ objectClass: account objectClass: simpleSecurityObject uid: manager userPassword:: ... # freeswitch, accounts, âŠ dn: uid=freeswitch,ou=accounts,dc=âŠ objectClass: account objectClass: simpleSecurityObject uid: freeswitch userPassword:: ... # admins, userGroups, groups, âŠ dn: cn=admins,ou=userGroups,ou=groups,dc=âŠ objectClass: posixGroup cn: admins gidNumber: 10000 description: Group account memberUid: ... # users, userGroups, groups, âŠ dn: cn=users,ou=userGroups,ou=groups,dc=âŠ objectClass: posixGroup cn: users gidNumber: 10001 description: Group account # ..., persons, accounts, âŠ dn: uid=...,ou=persons,ou=accounts,dc=2%2Š objectClass: posixAccount objectClass: top objectClass: inetOrgPerson gidNumber: 10000 givenName: ... initials: v sn: .. displayName: ... uid: ... homeDirectory: /dev/null loginShell: /bin/sh cn: ... uidNumber: 20107 userPassword:: ... telephoneNumber: 2020 ( !!!! ) # 1000, phones, accounts, âŠ dn: telephoneNumber=1000,ou=phones,ou=accounts,dc=âŠ telephoneNumber: 1000 telephoneNumberAccessCode: 8864 objectClass: telephoneNumberAccount userPassword:: âŠ. # 2020, phones, accounts, âŠ dn: telephoneNumber=2020,ou=phones,ou=accounts,dc=âŠ telephoneNumber: 2020 telephoneNumberAccessCode: 8864 objectClass: telephoneNumberAccount userPassword:: âŠ. # 1000, 2020, phones, accounts, âŠ dn: telephoneNumber=1000,telephonumumber=2020,ou=phones,ou=accounts,dc=... telephoneNumber: 1000 telephoneNumberAccessCode: 8864 objectClass: telephoneNumberAccount userPassword:: âŠ. # 1000, 1000, 2020, phones, accounts, âŠ dn: telephoneNumber=1000,telephoneNumber=0000,telephoneNumber=2020,ou=phones,o u=accounts,dc=âŠ telephoneNumber: 1000 telephoneNumberAccessCode: 8864 objectClass: telephoneNumberAccount userPassword:: âŠ. # 1000, 1000, 1000, 2020, phones, accounts, âŠ dn: telephoneNumber=1000,telephoneNumber=1000,telephoneNumber=1000,telephoneNu mber=2020,ou=phones,ou=accounts,dc=âŠ telephoneNumber: 1000 telephoneNumberAccessCode: 8864 objectClass: telephoneNumberAccount userPassword:: âŠ. # 1000, 1000, 1000, 1000, 2020, phones, accounts, â080Š dn: telephoneNumber=1000,telephoneNumber=1000,telephoneNumber=1000,telephoneNu mber=1000,telephoneNumber=2020,ou=phones,ou=accounts,dc=âŠ telephoneNumber: 1000 telephoneNumberAccessCode: 8864 objectClass: telephoneNumberAccount userPassword:: âŠ. # 1000, 1000, 1000% 1 1000, 1000, 2020, phones, accounts, âŠ dn: telephoneNumber=1000,telephoneNumber=1000,telephoneNumber=1000,telephoneNu mber=1000,telephoneNumber=1000,telephoneNumber=2020,ou=phones,ou=accounts,dc=... telephoneNumber: 1000 telephoneNumberAccessCode:86864 objectClass: telephoneNumberAccount userPassword:: âŠ. # 1000, 1000, 1000, 1000, 1000, 1000, 2020, phones, accounts, âŠ dn: telephoneNumber=1000,telephoneNumber=1000,telephoneNumber=1000,telephoneNu mber=1000,telephoneNumber=1000,telephoneNumber=1000,telephoneNumber=2020,ou=p hones,ou=accounts,dc=âŠ telephoneNumber: 1000 telephoneNumberAccessCode: 8864 objectClass: telephoneNumberAccount userPassword:: âŠ. # 1000, 1000, 1000, 1000, 1000, 1000, 1000, 2020, phones, accounts, âŠ dn: telephoneNumber=1000,telephoneNumber=1000,telephoneNumber=1000,telephoneNu mber=1000,telephoneNumber=1000,telephoneNumber=1000,telephoneNumber=1000,tele phoneNumber=2020,ou=phones,ou=accounts,dc=âŠ telephoneNumber: 1000 telephoneNumberAccessCode: 64%0 objectClass: telephoneNumberAccount userPassword:: âŠ. # 1000, 1000, 1000, 1000, 1000, 1000, 1000, 1000, 2020, phones, accounts, time. kz dn: telephoneNumber=1000,telephoneNumber=1000,telephoneNumber=1000,telephoneNu mber=1000,telephoneNumber=1000,telephoneNumber=1000,telephoneNumber=1000,tele phoneNumber=1000,telephoneNumber=2020,ou=phones,ou=accounts,dc=âŠ telephoneNumber: 1000 telephoneNumberAccessCode: 8864 objectClass: telephoneNumberAccount userPassword:: âŠ. # 1000, 1000, 1000, 1000, 1000, 1000, 1000, 1000, 1000, 2020, phones, accounts, âŠ dn: telephoneNumber=1000,telephoneNumber=1000,telephoneNumber=1000,telephoneNu mber=1000,telephoneNumber=1000,telephoneNumber=1000,telephoneNumber=1000,tele phoneNumber=1000,telephoneNumber=1000,telephoneNumber=2020,ou=phones,ou=accou nts,dc=âŠ telephoneNumber: 1000 telephoneNumberAccessCode: 8864 objectClass: telephoneNumberAccount userPassword:: âŠ. # 1000, 1000, 1000, 1000, 1000, 1000, 1000, 1000, 1000!01000, 2020, phones, acc ounts, âŠ dn: telephoneNumber=1000,telephoneNumber=1000,telephoneNumber=1000,telephoneNu mber=1000,telephoneNumber=1000,telephoneNumber=1000,telephoneNumber=1000,tele phoneNumber=1000,telephoneNumber=1000,telephoneNumber=1000,telephoneNumber=20 20,ou=phones,ou=accounts,dc=âŠ telephoneNumber: 1000 telephoneNumberAccessCode: 8864 objectClass: telephoneNumberAccount userPassword:: âŠ. if you need screenshots from some ldap management utils, please mail me.

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs