- openldap-bugs - openldap.org

Re: (ITS#7726) how to config kerberos with openldap via clear passwords?
by quanah＠zimbra.com 18 Oct '13

18 Oct '13

--On Friday, October 18, 2013 9:14 PM +0000 mostafa.basu(a)gmail.com wrote: > Full_Name: Mostafa Moeini > Version: 2.4.23 > OS: CentOS 5 X86 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (199.201.121.184) > > > I want to use kerberos with openldap backend. > but the problem is kerberos encrypt passwords before save into ldap > database . how can I config kerberos to use clear mode for saving (and > reading) passwords? The ITS system is for reporting bugs. It is *not* for asking "how do I" questions. Please use the appropriate resource (the openldap-technical(a)openldap.org mailing list). This ITS will be closed. I would also strongly advise you to upgrade to a current openldap release. 2.4.23 is years old. --Quanah -- Quanah Gibson-Mount Architect - Server Zimbra, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

(ITS#7726) how to config kerberos with openldap via clear passwords?
by mostafa.basu＠gmail.com 18 Oct '13

18 Oct '13

Full_Name: Mostafa Moeini Version: 2.4.23 OS: CentOS 5 X86 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (199.201.121.184) I want to use kerberos with openldap backend. but the problem is kerberos encrypt passwords before save into ldap database . how can I config kerberos to use clear mode for saving (and reading) passwords?

1 0

Re: (ITS#7705) mdb back-end segfaults sporadically with paged searches
by quanah＠zimbra.com 18 Oct '13

18 Oct '13

--On Tuesday, September 24, 2013 5:58 PM +0000 openldap(a)semyon.org wrote: > On 13-09-23 10:16 PM, Howard Chu wrote: > >> If you backup the DB with slapcat and reload it on another server with >> slapadd, can you still reproduce the fault on the copy? > > Unfortunately, yes. It breaks trying to retrieve the same record as > before, on the same instruction in back_mdb: > > yesterday: > [126393.233615] slapd[19244]: segfault at 7f499f38d000 ip > 00007f4da0e9b6a1 sp 00007f499f1fa540 error 6 in > back_mdb-2.4.so.2.9.2[7f4da0e80000+34000] > > today: > [517860.953779] slapd[24871]: segfault at 7fdeb50a0000 ip > 00007fe2b63ad6a1 sp 00007fdeb4f0d540 error 6 in > back_mdb-2.4.so.2.9.2[7fe2b6392000+34000] Please provide a useful bug report. I.e., get a stack trace from gdb, as noted in: <http://www.openldap.org/faq/data/cache/59.html> Sample data/testcase/configs always welcome as well. --Quanah -- Quanah Gibson-Mount Architect - Server Zimbra, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#7713) Segmentation fault if the pagesize of the Operating system is not equal to 4096.
by hyc＠symas.com 16 Oct '13

16 Oct '13

sumanth wrote: > As per ur suggestions,tried changing > > 1. MDB_PAGESIZE to 65536 > 2. changing pb_lower and pb_upper to uint32_t. > As of now it is running fine for the existing testcases in openldap-2.4.36. > However there were problems in 2.4.35. Also saw the comments in > openldap-devel. So whether this will make to openldap 2.4.36? The current plan is to fix this in OpenLDAP 2.5, and we are now halting new development in 2.4. -- -- 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#7713) Segmentation fault if the pagesize of the Operating system is not equal to 4096.
by sumantk2＠linux.vnet.ibm.com 16 Oct '13

16 Oct '13

This is a multi-part message in MIME format. --------------050805010104090604050102 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit As per ur suggestions,tried changing 1. MDB_PAGESIZE to 65536 2. changing pb_lower and pb_upper to uint32_t. As of now it is running fine for the existing testcases in openldap-2.4.36. However there were problems in 2.4.35. Also saw the comments in openldap-devel. So whether this will make to openldap 2.4.36? Thank you, Sumanth K --------------050805010104090604050102 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit <html> <head> <meta content="text/html; charset=UTF-8" http-equiv="Content-Type"> </head> <body bgcolor="#FFFFFF" text="#000000"> As per ur suggestions,tried changing 1. MDB_PAGESIZE to 65536 2. changing pb_lower and pb_upper to uint32_t. As of now it is running fine for the existing testcases in openldap-2.4.36. However there were problems in 2.4.35. Also saw the comments in openldap-devel. So whether this will make to openldap 2.4.36? Thank you, Sumanth K <span style="color: rgb(0, 0, 0); font-family: 'Times New Roman'; font-size: medium; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; background-color: rgb(255, 255, 255); display: inline !important; float: none;"> </body> </html> --------------050805010104090604050102--

1 0

RE: (ITS#7717) Sudden memory increase leading to Master LDAP crash
by quanah＠zimbra.com 15 Oct '13

15 Oct '13

--On Tuesday, October 15, 2013 11:47 PM +0200 Bruno Marcon <marcon.bruno(a)free.fr> wrote: > I have found the origin of the memory increase. The problem occur with a > huge group and the RefreshAndPersist mode replication without using DELTA > Sync. So each slaves pull from the master the entire entry. > > The LDAP contains about 100.000 users. All of them are member of a group > name "XXX". The group XXX is a group with 100.000 attributes "member", > one for each user. > > So when I assign 20 users per seconds to the XXX group, the master LDAP > push (or the slaves pull ?) the group XXX 20 times per seconds for each > slaves (there is 5 slaves). > > 5x20x100.000 = 10.000.000 attributes per seconds... The master LDAP handle > this rate for several seconds, perhaps one minute, then suddenly increase > in memory and is killed by the OS at 2Go of memory. > > To avoid this, i have set the DELTA sync replication to only send the > modification : for each assignition of a user in the group, only the > attribute member for the user is replicate. > > A question is why the LDAP is increasing in memory ? it should be slowed > rather than store something in memory after having reach a limit ? > > Our main problem now is : we have two masters in mirror mode, and 4 > replicas. For the replicas, I can use the DELTA sync mode. For the > recovery master (for fail over), I can't use DELTA sync because this mode > is not supported in Mirror mode. > So we have configure the masters replication in RefreshOnly mode with a > polling period of 5 seconds, to avoid this memory increase in > RefreshAndPersist mode without DELTA sync. > Doing this, the recovery master have 5s of delay before replicate the > primary master, so if the primary master crash for any reason, the > recovery master may have missed up to 5s of modifications (users creation > for example). BUT replicas are up to date with the old primary master are > more up to date than the recovery master and may have more users, because > there replication is immediate (RefreshAndPersist mode). > > If we can restart the "old" primary master, the recovery master get the > missing users thanks to replication. If we can't restart the primary > master because it is KO, we have a recovery master with less users than > slave, so we have some onconsistency between replicas and the recovery > master. > > Do you have any solution to this problem ? It occures with big LDAP > database and hight rate of modifications on the master because we work on > a huge project with thousands of users (and perhaps in the future > millions of users). > > Regards, > Bruno Marcon. > > > -----Message d'origine----- > De : MARCON Bruno [mailto:Bruno.MARCON@thalesgroup.com] > Envoyé : mercredi 9 octobre 2013 14:04 > À : Bruno Marcon > Objet : RE: (ITS#7717) Sudden memory increase leading to Master LDAP > crash > > > > Bruno Marcon > ThereSIS Innovation lab, ICT Security Unit > - IT Security Expert > - Software Architect > > Thales Research & Technology > Campus Polytechnique > 1, avenue Augustin Fresnel > 91767 Palaiseau cedex > France > Office: +33 (0)1 69 41 60 96 > Fax: +33 (0)1 69 41 55 63 > > > -----Message d'origine----- > De : Bruno Marcon [mailto:marcon.bruno@free.fr] Envoyé : mardi 8 > octobre 2013 18:05 À : MARCON Bruno Objet : TR: (ITS#7717) Sudden > memory increase leading to Master LDAP crash > > > > -----Message d'origine----- > De : Quanah Gibson-Mount [mailto:quanah@zimbra.com] > Envoyé : lundi 7 octobre 2013 16:56 > À : marcon.bruno(a)free.fr; openldap-its(a)openldap.org > Objet : Re: (ITS#7717) Sudden memory increase leading to Master LDAP > crash > > --On Thursday, October 03, 2013 1:14 PM +0000 marcon.bruno(a)free.fr wrote: > >> The problem is very easy to replay : one master and one slave are >> sufficient. Then run 9 windows with a script adding an entry and >> modifying an entry. > > Please provide full configuration details. > > --Quanah > > > -- > > Quanah Gibson-Mount > Architect - Server > Zimbra Software, LLC > -------------------- > Zimbra :: the leader in open source messaging and collaboration > > -- Quanah Gibson-Mount Architect - Server Zimbra, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#7723) slapd crashes on multi core machines if a search request is *immediately* followed by an unbind
by hyc＠symas.com 15 Oct '13

15 Oct '13

michael.vishchers(a)7p-group.com wrote: > --_004_96779DE2D69B3E4DB46CA3AEAA8C409D8B0DCCRTGMX02intranetlo_ > Content-Type: multipart/alternative; > boundary="_000_96779DE2D69B3E4DB46CA3AEAA8C409D8B0DCCRTGMX02intranetlo_" > > --_000_96779DE2D69B3E4DB46CA3AEAA8C409D8B0DCCRTGMX02intranetlo_ > Content-Type: text/plain; charset="iso-8859-1" > Content-Transfer-Encoding: quoted-printable > > It is not the client loop that is multithreading but the ldap server. Thanks for clarifying. > > And it is not a misuse of the API but a problem that may be raised by day t= > o day network problems. > > I've boiled down the problem to a few simple configurations that work (or b= > etter, fail ;-) with both 2.4.23 and 2.4.36. A tgz file containing a setup = > with start script and testclient is attached. It should be sufficient to re= > produce the fault. > > The problem occurs only if we use session variable substitution in the rwm = > overlay, and only if a search is *immediately* (e.g. caused by network loss= > and client timeout) followed by an unbind. Yes, your test config shows that the problem is that rwm_conn_destroy frees the session context while rwm_op_search is using it. Seems like the rwm overlay is not doing reference counting properly. -- -- 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#7723) slapd crashes on multi core machines if a search request is *immediately* followed by an unbind
by michael.vishchers＠7p-group.com 15 Oct '13

15 Oct '13

--_004_96779DE2D69B3E4DB46CA3AEAA8C409D8B0DCCRTGMX02intranetlo_ Content-Type: multipart/alternative; boundary="_000_96779DE2D69B3E4DB46CA3AEAA8C409D8B0DCCRTGMX02intranetlo_" --_000_96779DE2D69B3E4DB46CA3AEAA8C409D8B0DCCRTGMX02intranetlo_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable It is not the client loop that is multithreading but the ldap server. And it is not a misuse of the API but a problem that may be raised by day t= o day network problems. I've boiled down the problem to a few simple configurations that work (or b= etter, fail ;-) with both 2.4.23 and 2.4.36. A tgz file containing a setup = with start script and testclient is attached. It should be sufficient to re= produce the fault. The problem occurs only if we use session variable substitution in the rwm = overlay, and only if a search is *immediately* (e.g. caused by network loss= and client timeout) followed by an unbind. Mit freundlichen Gr=FC=DFen / Kind regards Michael Vishchers Senior System Engineer 7P Solutions & Consulting AG Calor-Emag-Stra=DFe 1 40878 Ratingen Phone : +49-2102-5354-356 Fax : +49-2102-5354-111 Email : michael.vishchers(a)7p-group.com<mailto://michael.vishchers@7P-Grou= p.com> Home : www.7p-group.com<http://www.7P-Group.com> Sitz der Gesellschaft: K=F6ln Registriergericht: Amtsgericht K=F6ln Handelsregister: HRB 32361 Aufsichtsratsvorsitzender: Dr. Kai H=F6hmann Vorstand: Jens Harig (Vorsitzender), Dr. Joachim Philippi USt-ID-Nr.: DE197820124 Steuer-Nr.: 215/5917/1764 Eine Bitte: Denken Sie an Ihre Umwelt, bevor Sie diese E-Mail ausdrucken! P Please consider the environment before printing this e-mail Der Inhalt dieser e-Mail ist ausschlie=DFlich f=FCr den bezeichneten Adress= aten bestimmt. Wenn Sie nicht der vorgesehene Adressat dieser e-Mail oder d= essen Vertreter sein sollten, beachten Sie bitte, dass jede Form der Ver=F6= ffentlichung, Vervielf=E4ltigung oder Weitergabe des Inhalts dieser e-Mail = unzul=E4ssig ist. Wir bitten Sie sofort den Absender zu informieren und die= E-mail zu l=F6schen. The information contained in this e-mail is intended solely for the address= ee. Access to this e-mail by anyone else is unauthorized. If you are not th= e intended recipient, any form of disclosure, reproduction, distribution or= any action taken or refrained from in reliance on it, is prohibited and ma= y be unlawful. Please notify the sender immediately and destroy this e-mail= . --_000_96779DE2D69B3E4DB46CA3AEAA8C409D8B0DCCRTGMX02intranetlo_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable <html dir=3D"ltr"> <head> <meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Diso-8859-= 1"> <style id=3D"owaParaStyle" type=3D"text/css">P {margin-top:0;margin-bottom:= 0;}</style> </head> <body ocsi=3D"0" fpstyle=3D"1"> <div style=3D"direction: ltr;font-family: Tahoma;color: #000000;font-size: = 10pt;">It is not the client loop that is multithreading but the ldap server= . And it is not a misuse of the API but a problem that may be raised by day t= o day network problems. I've boiled down the problem to a few simple configurations that work (or b= etter, fail ;-) with both 2.4.23 and 2.4.36. A tgz file containing a setup = with start script and testclient is attached. It should be sufficient to re= produce the fault. The problem occurs only if we use session variable substitution in the rwm = overlay, and only if a search is *immediately* (e.g. caused by network loss= and client timeout) followed by an unbind. <div> <div style=3D"font-family: Tahoma; font-size: 13px;"> <div style=3D"font-family: Arial; font-size: 13px;">Mit freundlichen Gr=FC= =DFen / Kind regards Michael Vishchers Senior System Engineer 7P Solutions & Consulting AG Calor-Emag-Stra=DFe 1 40878 Ratingen Phone  : +49-2102-5354-356 Fax      : +49-2102-5354-111 Email   : <a href=3D"mailto://michael.vishchers@7P-Group.com" tab= index=3D"0">michael.vishchers(a)7p-group.com</a> Home   : <a href=3D"http://www.7P-Group.com" tabindex=3D"0">www.7= p-group.com</a> Sitz der Gesellschaft: K=F6ln Registriergericht: Amtsgericht K=F6ln Handelsregister: HRB 32361 Aufsichtsratsvorsitzender: Dr. Kai H=F6hmann Vorstand: Jens Harig (Vorsitzender), Dr. Joachim Philippi USt-ID-Nr.: DE197820124 Steuer-Nr.: 215/5917/1764</= b> Eine Bitte: Denken Sie an Ihre Umwelt, bevor Sie= diese E-Mail ausdrucken! P<= /b> Please consider the envir= onment before printing this e-mail Der Inhalt dieser e-Mail ist ausschlie=DFlich f=FCr den bezeichneten Ad= ressaten bestimmt. Wenn Sie nicht der vorgesehene Adressat dieser e-Mail oder dessen Vertreter sein sollten, beachten Sie bitte, dass jede F= orm der Ver=F6ffentlichung, Vervielf=E4ltigung oder Weitergabe des Inhalts = dieser e-Mail unzul=E4ssig ist. Wir bitten Sie sofort den Absender zu infor= mieren und die E-mail zu l=F6schen. The information contained in this e-mail is intended solely for the address= ee. Access to this e-mail by anyone else is unauthorized. If you are not th= e intended recipient, any form of disclosure, reproduction, distribution or= any action taken or refrained from in reliance on it, is prohibited and may be unlawful. Please notify the se= nder immediately and destroy this e-mail.   </div> </div> </div> </div> </body> </html> --_000_96779DE2D69B3E4DB46CA3AEAA8C409D8B0DCCRTGMX02intranetlo_-- --_004_96779DE2D69B3E4DB46CA3AEAA8C409D8B0DCCRTGMX02intranetlo_ Content-Type: application/x-compressed-tar; name="test_scenario.tgz" Content-Description: test_scenario.tgz Content-Disposition: attachment; filename="test_scenario.tgz"; size=2305; creation-date="Tue, 15 Oct 2013 11:09:38 GMT"; modification-date="Tue, 15 Oct 2013 11:09:38 GMT" Content-Transfer-Encoding: base64 H4sIAFX9XFIAA+1a3XPbuBG33UxnjM70vS+dPVqXyIk+SOrrKltu0sTpeTrn3FzSt8y5EAlZbEiA BcjIas4zfeu/3QVI6stO3On5lLaHnz22uAR3F4vFYnepjKnsQgWMUxmJ9s5PAhcx6PXMf8Tmf/PZ 831/4A363U53x/X8rt/fgd5Po846cpVRCbAjhcg+Ne6u+/+jyNbWX8U0Df1WIPjkHmXoBe53ux9d /x7eK9e/O/A7uP7dbr+7A+496vBR/MzXP+JBnIcM2iwL2iJlPA5p2lbBlCW0HQjJWsVnEovLmL1n MaC9MgVccEayqWQ0VNDxCQlpRsdUMUhYRonKJ5PoChwx0g7mkJBNaB5nTbT1JcuKp0MeUOTdzLIY wkjRccxCgjekRBkiJZKNIx42qWrmisn9OVNERRy1aKJ/ctDXeKOZsSQVksr5ksxZNhPyXTOLEiby DDxCchntO3puw3bb8wctF3+8od/56ndtkY9oo1IUpc5klLFTfhlxBoJXhOeCZ+wqg3ImFfm7PGbg 1FtPDn/fWGFUcwCcmueAM3TI517jT2F9/3sX2uQtSWf3KeOu/e92F/Hf73V8vf/9vm/3/zbg/nZv d/cvv9nb/cWDXwd8pGdZuvA/HvyfTtliBev7PwtS3PutNL5XGXfkf34X9/xi/w86xf4f2P2/DRx8 0c6VbGPYb6dMxtCc6UMVD2AZBdkRwYN8DPqQR7eADwQQyRzqtQmnCTuEETy9ODLUWAQ0hlq7uNKJ BNTPzhvOcTHUOTyqHq5Jlo2Oz85PCkoQC5R3dl5c4b1ccjPmiFwTo8vZq+HwtQjeaRI5+Bjg+dfP zv94Cl+ffndKiJYTpSPHqDUVeLIfGRpmCtkID/2jYog+7XAS1QTrzvIA1BrrIYpRGUzXBvkXBbEa ZsZh8sNDwXFgSoN3UH/0/KtHDbK/r2flXnXchnvl9pcE19cET//pLKk9d0H1G8YgFfucl7pW3AcV 94p5b3G9xhsONKUD0QQqFSOdvmWAtg2rR7rmEVdLUyxmQQav37x49ec3R1D7AYV6hRZPlVkGVfpF EDPK83TpF085my2GaNoEE0jM8cyyK6hXzx/iI/tcZ1Oo1Rc6pcJcK8QhR2QfKfUl6bimTszopauY UfpSM8CP12Q/zdV0VXjDDNJjrs3fSu7ohoKpjHgGCp0Eg8ByeteF0RPFglETJz+bRpjm1Q3hyRM4 Bk8HLq1Y6cPGECsscRIOfOn2wrfSaZjHtGmrHVDIQbuiOivuPRyenZ++gTrZ/5Yx+SwMMS6NTrQj NwrSt+i9BUn7sSZKkQlNeISRWzvEm3nK9PXrV8//dPH6zXenz75B6iFsgOwLiTk3Zq7nAjC5fs8k rlWODobugfKGRkBhgLfcKVUvzLxi42pTLi1ZTc3srPJO6VB1ZM8mDVj/57Z66OPopCpmLIUpjdFP 8RHM5cNbGRdbr1HtiB8tA5e6kOC85S8jHqkpC82UP3dk3g5uqf+9Ldf/Ht6szv+eq8dh/d/r2/N/ G/i3639yYAIuYGUNMcbm4gzhjIUYpjHOg9/qtjp9kogQS+KUZlMwmUUcjfvdBefydixoCHKWtGJk fFtnYbW1oHsDcSxmoPf7BeWmJv9bHkkGNM+mweJK319pRBh5i7o/wsI/mbeKMOLc2lzY6FkQgWEx pnOtKCH4p3mzN7AkVv0BzfbF+eod0yJAON/X1yusw5oDTu3Dw4d4mNbp4fWX3moLQXcQhk+dTU76 6HNaj/FJ/D146pDblFg0KTa0MI0KI9WIqn14/BhlXy8k6m7FbfyKoHvKMznHuX1un7W4P2zEf4yF 9x/l7qj/PN/zFv3fzmCA8b/T81wb/7cBrP907aem5F0UxxhnweQAJHkXRhKaaXHptnRUvUncoHg3 KD5SCPnD2fnIHAYKZZEDczkVCWuP8ygO26ZIKz9GY3bFAlLDMUU2As0uNCeVRJ2ZQPPlQgFoTqHs 6rqmp+uani7mek2858FJORDPGPBPHnrwkBRJYA/PHXyOhgWLqkzUihsGzRewHqyxMgZ9CcfHp69e wkk7ZO/bPEeDab4k5EMoBhIx/ivmokFMlUKavKQ8+jvNIjwuxBDMCIIcyEfm6K/P0V/Oce0E25ih vzrD2xl764y9W41303beKmeSKmiyCfwAl5KVS6wzA82lLJQ3rflpYzbHldU+90b4mWI9/mO9+OKb 0/uWcVf+P/D6y/e/rs7/Ox0b/7cDsxur9R8SMqFRrGAWYfquE3q/A5SHVW5Plnl+A+Yix1L6PYNM QCCShPGiOBATyKaampZ1QsRXAxAm6EwFMkp1RESBTTBJxxAKouYmcw76JOIsYEpROS9bFEoPXp4D QxhTDIWoXtnBEBxM20IH8GqoVw6dSJ3KooqpFFfzBmDgV1Bm/Cgy5AqTZixSwohfakam2xbyio1f skmiMMQ8umQiGZ51GOsV6BIELbnBpOSPsrBGGs8rJcLieeS96LcXB4OmX0qaoAEprkqU5DFFurFn +U4TxgyNHolc4uPLbuVQ3wdTVqH9jfKJtt0lw2Gr/cr1gWXMroYSlD+OWQLrS7Sutu4bKaCTDC2u sG6TNIZ6Qq9Q2wToWL9v7bqHQDP9YhYtgtadog+h1Wglr7QWMdOMFDyO0H3CCOcazx9jMamrvcJi lEPZ+azjx5UGpjDK0fiwRcgZ183ZGN1tgn43xbsJVm1TmuoudFS447pkuGSoWayPKPTOFfM2zEUQ R9pVFM5ZkRW5eissNGqYSz08iZR+Mb0pI9JugTyy1tKwirHEmGSMUgRHD89wotrnZwlU9WZTK811 Yw75otj3uDf123HNUTdtSyUlVVOYCf4oK+fa+g8O0fX4v+op9xdj7nz/i7XBxvvfvm/f/24F7pO9 3b3g4YNflmnY7h7Z3dkzv7u7O//81Uoyu5XlsNgubun/utv+/lfH7yzq//6gb7//tUX8qO9/3UeX dhyOb3Reta1DDs560VjQ06JyJEXmJTA5dFrtlSbFf/fXrSwsLCwsLCwsLCwsLCwsLCwsLCwsLCws LCwsLCwsLCwsLCwsLO4N/wJ4ZNBaAFAAAA== --_004_96779DE2D69B3E4DB46CA3AEAA8C409D8B0DCCRTGMX02intranetlo_--

1 0

Antwort: Re: Antwort: Re: (ITS#7653) Test Build Version 2.4.36 hangs
by howard.allison＠pensionsversicherung.at 13 Oct '13

13 Oct '13

--0__=4EBBF697DF89C4868f9e8a93df938690918c4EBBF697DF89C486 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: quoted-printable Howard Chu <hyc(a)symas.com> wrote on 13.10.2013 00:54:04: > Von: Howard Chu <hyc(a)symas.com> > An: howard.allison(a)pensionsversicherung.at, openldap-its(a)openldap.org= , > Datum: 13.10.2013 00:54 > Betreff: Re: Antwort: Re: (ITS#7653) Test Build Version 2.4.36 hangs > > howard.allison(a)pensionsversicherung.at wrote: > > --0__=3D4EBBF156DFB715BF8f9e8a93df938690918c4EBBF156DFB715BF > > Content-type: multipart/alternative; > > Boundary=3D"1__=3D4EBBF156DFB715BF8f9e8a93df938690918c4EBBF156DF= B715BF" > > > > --1__=3D4EBBF156DFB715BF8f9e8a93df938690918c4EBBF156DFB715BF > > Content-type: text/plain; charset=3DISO-8859-1 > > Content-transfer-encoding: quoted-printable > > > > > > Hi! > > Sorry - here's the stack trace: > > Which backend were you testing, it's not shown in any of your output.= Your > trace is strange because it shows overlays being used, but test005 > doesn't use > any overlays. Seems like you may have a slapd left over from some oth= er test. > > > > > SLAPD: > > (dbx) thread info > > thread state-k wchan state-u k-tid mode held scope functi=3D > > on > > $t1 wait 0xf1000f0a1000ee40 blocked 15597767 k no= sy=3D > > s > > > > general: > > pthread addr =3D3D 0x3009f56c size =3D3D = 0x290 > > vp addr =3D3D 0x300a15b0 size =3D3D = 0x2e0 > > thread errno =3D3D 0 > > start pc =3D3D 0x10000420 > > joinable =3D3D yes > > pthread_t =3D3D 1 > > scheduler: > > kernel =3D3D > > user =3D3D 1 (other) > > nice =3D3D 60 > > event : > > event =3D3D 0x0 > > cancel =3D3D enabled, deferred, not pending > > stack storage: > > base =3D3D 0x20000000 size =3D3D 0xff22190=3D > > > > limit =3D3D 0x2ff22190 > > sp =3D3D 0x2ff21e90 > > thread state-k wchan state-u k-tid mode held scope functi=3D > > on > >> $t2 run running 36372639 k no sys > > __fd_select > > > > general: > > pthread addr =3D3D 0x308e5cf0 size =3D3D = 0x290 > > vp addr =3D3D 0x303d3780 size =3D3D = 0x2e0 > > thread errno =3D3D 4 > > start pc =3D3D 0x3001f600 > > joinable =3D3D yes > > pthread_t =3D3D 102 > > scheduler: > > kernel =3D3D > > user =3D3D 1 (other) > > nice =3D3D 60 > > event : > > event =3D3D 0x0 > > cancel =3D3D enabled, deferred, not pending > > stack storage: > > base =3D3D 0x304e5000 size =3D3D = 0x400000 > > limit =3D3D 0x308e5b90 > > sp =3D3D 0x308e4530 > > thread state-k wchan state-u k-tid mode held scope functi=3D > > on > > $t3 run running 30015693 u no sys > > base_candidate > > > > general: > > pthread addr =3D3D 0x30ce9cf0 size =3D3D = 0x290 > > vp addr =3D3D 0x303d5790 size =3D3D = 0x2e0 > > thread errno =3D3D 11 > > start pc =3D3D 0xf0391ec0 > > joinable =3D3D no > > pthread_t =3D3D 203 > > scheduler: > > kernel =3D3D > > user =3D3D 1 (other) > > nice =3D3D 60 > > event : > > event =3D3D 0x0 > > cancel =3D3D enabled, deferred, not pending > > stack storage: > > base =3D3D 0x308e9000 size =3D3D = 0x400000 > > limit =3D3D 0x30ce9b90 > > sp =3D3D 0x30c286f0 > > thread state-k wchan state-u k-tid mode held scope functi=3D > > on > > $t4 run running 21561505 u no sys > > base_candidate > > > > general: > > pthread addr =3D3D 0x319eecf0 size =3D3D = 0x290 > > vp addr =3D3D 0x303e4b60 size =3D3D = 0x2e0 > > thread errno =3D3D 11 > > start pc =3D3D 0xf0391ec0 > > joinable =3D3D no > > pthread_t =3D3D 304 > > scheduler: > > kernel =3D3D > > user =3D3D 1 (other) > > nice =3D3D 60 > > event : > > event =3D3D 0x0 > > cancel =3D3D enabled, deferred, not pending > > stack storage: > > base =3D3D 0x315ed000 size =3D3D = 0x400000 > > limit =3D3D 0x319eeb90 > > sp =3D3D 0x3192d6f0 > > > > (dbx) thread current -1 > > warning: Thread is in kernel mode, not all registers can be accesse= d. > > (dbx) where > > .() at 0x11c501d40 > > _event_wait(??, ??) at 0xd0502be4 > > _cond_wait_local(??, ??, ??) at 0xd0510f40 > > _cond_wait(??, ??, ??) at 0xd0511510 > > pthread_join(??, ??) at 0xd04f91b0 > > ldap_pvt_thread_join(thread =3D3D 8, thread_return =3D3D 0x00000008= ), line =3D > > 197 in > > "thr_posix.c" > > slapd_daemon(), line 2929 in "daemon.c" > > main(argc =3D3D 0, argv =3D3D (nil)), line 1012 in "main.c" > > > > (dbx) thread current -2 > > (dbx) where > > __fd_select(??, ??, ??, ??, ??) at 0xd0262f2c > > daemon.select(__fds =3D3D 0, __readlist =3D3D (nil), __writelist =3D= 3D (nil),=3D > > > > __exceptlist =3D3D (nil), __timeout =3D3D (nil)), line 234 in "time= .h" > > unnamed block in slapd_daemon_task(ptr =3D3D (nil)), line 2536 in "daemon=3D > > .c" > > unnamed block in slapd_daemon_task(ptr =3D3D (nil)), line 2536 in "daemon=3D > > .c" > > slapd_daemon_task(ptr =3D3D (nil)), line 2536 in "daemon.c" > > > > (dbx) thread current -3 > > (dbx) where > > search.base_candidate(be =3D3D (nil), e =3D3D (nil), ids =3D3D (nil= )), line 3=3D > > 71 in > > "search.c" > > glue_sub_search(op =3D3D 0xf061b148, rs =3D3D 0xf061b108, b0 =3D3D 0x00000002=3D > > , on =3D3D > > 0xf0240744), line 380 in "backglue.c" > > glue_op_search(op =3D3D 0x301185f8, rs =3D3D 0x303d5a78), line 537 = in "back=3D > > glue.c" > > overlay_op_walk(op =3D3D (nil), rs =3D3D (nil), which =3D3D op_bind= , oi =3D3D (=3D > > nil), on =3D3D > > 0x01000000), line 661 in "backover.c" > > over_op_func(op =3D3D (nil), rs =3D3D 0x102c9510, which =3D3D op_bi= nd), line =3D > > 723 in > > "backover.c" > > fe_op_search(op =3D3D 0x00004105, rs =3D3D 0x00000100), line 402 in= "search=3D > > .c" > > do_search(op =3D3D 0x000003e8, rs =3D3D (nil)), line 247 in "search= .c" > > unnamed block in connection_operation(ctx =3D3D 0x00000114, arg_v =3D= 3D > > 0x00000045), line 1155 in "connection.c" > > connection_operation(ctx =3D3D 0x00000114, arg_v =3D3D 0x00000045),= line 11=3D > > 55 in > > "connection.c" > > connection_read_thread(ctx =3D3D (nil), argv =3D3D (nil)), line 129= 1 in > > "connection.c" > > ldap_int_thread_pool_wrapper(xpool =3D3D (nil)), line 688 in "tpool= .c" > > > > (dbx) thread current -4 > > (dbx) where > > search.base_candidate(be =3D3D (nil), e =3D3D (nil), ids =3D3D (nil= )), line 3=3D > > 71 in > > "search.c" > > glue_sub_search(op =3D3D 0xf061b148, rs =3D3D 0xf061b108, b0 =3D3D 0x00000002=3D > > , on =3D3D > > 0xf0240744), line 380 in "backglue.c" > > glue_op_search(op =3D3D 0x301185f8, rs =3D3D 0x303e4ee8), line 537 = in "back=3D > > glue.c" > > overlay_op_walk(op =3D3D (nil), rs =3D3D (nil), which =3D3D op_bind= , oi =3D3D (=3D > > nil), on =3D3D > > 0x01000000), line 661 in "backover.c" > > over_op_func(op =3D3D (nil), rs =3D3D 0x102c9510, which =3D3D op_bi= nd), line =3D > > 723 in > > "backover.c" > > fe_op_search(op =3D3D 0x00004105, rs =3D3D 0x00000100), line 402 in= "search=3D > > .c" > > do_search(op =3D3D 0x000003e9, rs =3D3D (nil)), line 247 in "search= .c" > > unnamed block in connection_operation(ctx =3D3D 0x0000019c, arg_v =3D= 3D > > 0x00000067), line 1155 in "connection.c" > > connection_operation(ctx =3D3D 0x0000019c, arg_v =3D3D 0x00000067),= line 11=3D > > 55 in > > "connection.c" > > connection_read_thread(ctx =3D3D (nil), argv =3D3D (nil)), line 129= 1 in > > "connection.c" > > ldap_int_thread_pool_wrapper(xpool =3D3D (nil)), line 688 in "tpool= .c" > > > > > > LDAPSEARCH: > > Waiting to attach to process 11272394 ... > > Successfully attached to ldapsearch. > > warning: Directory containing ldapsearch could not be determined. > > Apply 'use' command to initialize source path. > > > > Type 'help' for help. > > reading symbolic information ... > > stopped in __fd_poll at 0xd0262734 ($t1) > > 0xd0262734 (__fd_poll+0xb4) 80410014 lwz r2,0x14(r1) > > (dbx) where > > __fd_poll(??, ??, ??) at 0xd0262734 > > os-ip.poll(__listptr =3D3D 0x00000001, __nfds =3D3D 4294967294, __t= imeout =3D3D=3D > > > > 1000000), line 107 in "poll.h" > > ldap_int_select(ld =3D3D (nil), timeout =3D3D 0x3002a9c8), line 113= 9 in "os=3D > > -ip.c" > > wait4msg(ld =3D3D 0xd0f6bb50, msgid =3D3D 804398239, all =3D3D 8043= 89024, tim=3D > > eout =3D3D > > (nil), result =3D3D 0x2ff200e0), line 312 in "result.c" > > ldap_result(ld =3D3D (nil), msgid =3D3D 805309096, all =3D3D 804389= 216, timeo=3D > > ut =3D3D > > 0x28224243, result =3D3D 0x1000866c), line 117 in "result.c" > > dosearch(ld =3D3D 0x30009c18, base =3D3D "file:///%s/", scope =3D3D= 268504837=3D > > , filtpatt > > =3D3D (nil), value =3D3D (nil), attrs =3D3D (nil), attrsonly =3D3D = -261995236, =3D > > sctrls =3D3D > > 0x10010f08, cctrls =3D3D (nil), timeout =3D3D (nil), sizelimit =3D3= D -1), lin=3D > > e 1447 in > > "ldapsearch.c" > > main(argc =3D3D 0, argv =3D3D (nil)), line 1222 in "ldapsearch.c" > > > > (dbx) thread > > thread state-k wchan state-u k-tid mode held scope functi=3D > > on > >> $t1 run running 35192885 k no sys __fd_=3D > > poll > > > -- > -- Howard Chu > CTO, Symas Corp. http://www.symas.com > Director, Highland Sun http://highlandsun.com/hyc/ > Chief Architect, OpenLDAP http://www.openldap.org/project/ This happens on the first backend that isn't MDB - I've tried disabling= BDB and HDB separately and it hangs on both.The slapd is the test5 slapd(it= 's been a while, but I seem to recall checking the start time of the daemo= n) Howard -----------------------------------------------------------------------= --------------------------------- VERTRAULICHKEIT: Diese Nachricht ist ausschlie=DFlich f=FCr denjenigen bestimmt, an den sie adressiert ist und kann vertrauliche Informationen= enthalten. Falls Sie nicht der Empf=E4nger dieser Nachricht sind, weise= n wir Sie darauf hin, dass die unberechtigte Weitergabe oder Verwendung sowie= das unberechtigte Verteilen oder Kopieren dieser Nachricht strikt untersagt= sind. Falls Sie diese Nachricht irrt=FCmlich erhalten haben, vernichten= Sie sie bitte sofort. CONFIDENTIALITY: This message is intended only for the use of the individuality or entity to which it is addressed and may contain information that is privileged, confidential and exempt from disclosure= . If you are not the intended recipient you are notified that any disseminat= ion, distribution, use or copying of this communication is strictly prohibit= ed. If you received this message in error, please immediately destroy this message. -----------------------------------------------------------------------= --------------------------------- = --0__=4EBBF697DF89C4868f9e8a93df938690918c4EBBF697DF89C486 Content-type: text/html; charset=ISO-8859-1 Content-Disposition: inline Content-transfer-encoding: quoted-printable <html><body> <tt>Howard Chu <hyc(a)symas.com> wrote on 13.10= .2013 00:54:04: > Von: Howard Chu <hyc(a)symas.com></tt> <tt>> An: howard.allison(a)pensionsversicherung.at, o= penldap-its(a)openldap.org, </tt> <tt>> Datum: 13.10.2013 00:54</tt> <tt>> Betreff: Re: Antwort: Re: (ITS#7653) Test Bui= ld Version 2.4.36 hangs</tt> <tt>> > howard.allison(a)pensionsversicherung.at wrote: > > --0__=3D4EBBF156DFB715BF8f9e8a93df938690918c4EBBF156DFB715BF<= br> > > Content-type: multipart/alternative; > >    Boundary=3D"1__=3D4EBBF156DFB715BF8f9e8a93d= f938690918c4EBBF156DFB715BF" > > > > --1__=3D4EBBF156DFB715BF8f9e8a93df938690918c4EBBF156DFB715BF<= br> > > Content-type: text/plain; charset=3DISO-8859-1 > > Content-transfer-encoding: quoted-printable > > > > > > Hi! > > Sorry - here's the stack trace: > > Which backend were you testing, it's not shown in any of your outp= ut. Your > trace is strange because it shows overlays being used, but test005= > doesn't use > any overlays. Seems like you may have a slapd left over from some = other test. > > > > > SLAPD: > > (dbx) thread info > >   thread  state-k     wchan    = state-u    k-tid   mode held scope functi=3D > > on > >   $t1     wait      0xf1000f0a1= 000ee40 blocked  15597767     k   no   sy=3D<b= r> > > s > > > >        general: > >           pthread addr =3D3D 0x3009f= 56c         size         =3D3D = 0x290 > >           vp addr     &nbs= p;=3D3D 0x300a15b0         size     &nbsp= ;   =3D3D 0x2e0 > >           thread errno =3D3D 0 > >           start pc     =3D= 3D 0x10000420 > >           joinable     =3D= 3D yes > >           pthread_t    =3D= 3D 1 > >        scheduler: > >           kernel     &nbsp= ; =3D3D > >           user       =   =3D3D 1 (other) > >           nice       =   =3D3D 60 > >        event : > >           event      =  =3D3D 0x0 > >           cancel     &nbsp= ; =3D3D enabled, deferred, not pending > >        stack storage: > >           base       =   =3D3D 0x20000000         size     =     =3D3D 0xff22190=3D > > > >           limit      =  =3D3D 0x2ff22190 > >           sp       &n= bsp;   =3D3D 0x2ff21e90 > >   thread  state-k     wchan    = state-u    k-tid   mode held scope functi=3D > > on > >> $t2     run           =        running  36372639     k &nbsp= ; no   sys > > __fd_select > > > >        general: > >           pthread addr =3D3D 0x308e5= cf0         size         =3D3D = 0x290 > >           vp addr     &nbs= p;=3D3D 0x303d3780         size     &nbsp= ;   =3D3D 0x2e0 > >           thread errno =3D3D 4 > >           start pc     =3D= 3D 0x3001f600 > >           joinable     =3D= 3D yes > >           pthread_t    =3D= 3D 102 > >        scheduler: > >           kernel     &nbsp= ; =3D3D > >           user       =   =3D3D 1 (other) > >           nice       =   =3D3D 60 > >        event : > >           event      =  =3D3D 0x0 > >           cancel     &nbsp= ; =3D3D enabled, deferred, not pending > >        stack storage: > >           base       =   =3D3D 0x304e5000         size     =     =3D3D 0x400000 > >           limit      =  =3D3D 0x308e5b90 > >           sp       &n= bsp;   =3D3D 0x308e4530 > >   thread  state-k     wchan    = state-u    k-tid   mode held scope functi=3D > > on > >   $t3     run         &nbs= p;        running  30015693     u &n= bsp; no   sys > > base_candidate > > > >        general: > >           pthread addr =3D3D 0x30ce9= cf0         size         =3D3D = 0x290 > >           vp addr     &nbs= p;=3D3D 0x303d5790         size     &nbsp= ;   =3D3D 0x2e0 > >           thread errno =3D3D 11 > >           start pc     =3D= 3D 0xf0391ec0 > >           joinable     =3D= 3D no > >           pthread_t    =3D= 3D 203 > >        scheduler: > >           kernel     &nbsp= ; =3D3D > >           user       =   =3D3D 1 (other) > >           nice       =   =3D3D 60 > >        event : > >           event      =  =3D3D 0x0 > >           cancel     &nbsp= ; =3D3D enabled, deferred, not pending > >        stack storage: > >           base       =   =3D3D 0x308e9000         size     =     =3D3D 0x400000 > >           limit      =  =3D3D 0x30ce9b90 > >           sp       &n= bsp;   =3D3D 0x30c286f0 > >   thread  state-k     wchan    = state-u    k-tid   mode held scope functi=3D > > on > >   $t4     run         &nbs= p;        running  21561505     u &n= bsp; no   sys > > base_candidate > > > >        general: > >           pthread addr =3D3D 0x319ee= cf0         size         =3D3D = 0x290 > >           vp addr     &nbs= p;=3D3D 0x303e4b60         size     &nbsp= ;   =3D3D 0x2e0 > >           thread errno =3D3D 11 > >           start pc     =3D= 3D 0xf0391ec0 > >           joinable     =3D= 3D no > >           pthread_t    =3D= 3D 304 > >        scheduler: > >           kernel     &nbsp= ; =3D3D > >           user       =   =3D3D 1 (other) > >           nice       =   =3D3D 60 > >        event : > >           event      =  =3D3D 0x0 > >           cancel     &nbsp= ; =3D3D enabled, deferred, not pending > >        stack storage: > >           base       =   =3D3D 0x315ed000         size     =     =3D3D 0x400000 > >           limit      =  =3D3D 0x319eeb90 > >           sp       &n= bsp;   =3D3D 0x3192d6f0 > > > > (dbx) thread current -1 > > warning: Thread is in kernel mode, not all registers can be a= ccessed. > > (dbx) where > > .() at 0x11c501d40 > > _event_wait(??, ??) at 0xd0502be4 > > _cond_wait_local(??, ??, ??) at 0xd0510f40 > > _cond_wait(??, ??, ??) at 0xd0511510 > > pthread_join(??, ??) at 0xd04f91b0 > > ldap_pvt_thread_join(thread =3D3D 8, thread_return =3D3D 0x00= 000008), line =3D > > 197 in > > "thr_posix.c" > > slapd_daemon(), line 2929 in "daemon.c" > > main(argc =3D3D 0, argv =3D3D (nil)), line 1012 in "main= .c" > > > > (dbx) thread current -2 > > (dbx) where > > __fd_select(??, ??, ??, ??, ??) at 0xd0262f2c > > daemon.select(__fds =3D3D 0, __readlist =3D3D (nil), __writel= ist =3D3D (nil),=3D > > > > __exceptlist =3D3D (nil), __timeout =3D3D (nil)), line 234 in= "time.h" > > unnamed block in slapd_daemon_task(ptr =3D3D (nil)), line 253= 6 in "daemon=3D > > .c" > > unnamed block in slapd_daemon_task(ptr =3D3D (nil)), line 253= 6 in "daemon=3D > > .c" > > slapd_daemon_task(ptr =3D3D (nil)), line 2536 in "daemon= .c" > > > > (dbx)  thread current -3 > > (dbx) where > > search.base_candidate(be =3D3D (nil), e =3D3D (nil), ids =3D3= D (nil)), line 3=3D > > 71 in > > "search.c" > > glue_sub_search(op =3D3D 0xf061b148, rs =3D3D 0xf061b108, b0 = =3D3D 0x00000002=3D > > , on =3D3D > > 0xf0240744), line 380 in "backglue.c" > > glue_op_search(op =3D3D 0x301185f8, rs =3D3D 0x303d5a78), lin= e 537 in "back=3D > > glue.c" > > overlay_op_walk(op =3D3D (nil), rs =3D3D (nil), which =3D3D o= p_bind, oi =3D3D (=3D > > nil), on =3D3D > > 0x01000000), line 661 in "backover.c" > > over_op_func(op =3D3D (nil), rs =3D3D 0x102c9510, which =3D3D= op_bind), line =3D > > 723 in > > "backover.c" > > fe_op_search(op =3D3D 0x00004105, rs =3D3D 0x00000100), line = 402 in "search=3D > > .c" > > do_search(op =3D3D 0x000003e8, rs =3D3D (nil)), line 247 in &= quot;search.c" > > unnamed block in connection_operation(ctx =3D3D 0x00000114, a= rg_v =3D3D > > 0x00000045), line 1155 in "connection.c" > > connection_operation(ctx =3D3D 0x00000114, arg_v =3D3D 0x0000= 0045), line 11=3D > > 55 in > > "connection.c" > > connection_read_thread(ctx =3D3D (nil), argv =3D3D (nil)), li= ne 1291 in > > "connection.c" > > ldap_int_thread_pool_wrapper(xpool =3D3D (nil)), line 688 in = "tpool.c" > > > > (dbx) thread current -4 > > (dbx) where > > search.base_candidate(be =3D3D (nil), e =3D3D (nil), ids =3D3= D (nil)), line 3=3D > > 71 in > > "search.c" > > glue_sub_search(op =3D3D 0xf061b148, rs =3D3D 0xf061b108, b0 = =3D3D 0x00000002=3D > > , on =3D3D > > 0xf0240744), line 380 in "backglue.c" > > glue_op_search(op =3D3D 0x301185f8, rs =3D3D 0x303e4ee8), lin= e 537 in "back=3D > > glue.c" > > overlay_op_walk(op =3D3D (nil), rs =3D3D (nil), which =3D3D o= p_bind, oi =3D3D (=3D > > nil), on =3D3D > > 0x01000000), line 661 in "backover.c" > > over_op_func(op =3D3D (nil), rs =3D3D 0x102c9510, which =3D3D= op_bind), line =3D > > 723 in > > "backover.c" > > fe_op_search(op =3D3D 0x00004105, rs =3D3D 0x00000100), line = 402 in "search=3D > > .c" > > do_search(op =3D3D 0x000003e9, rs =3D3D (nil)), line 247 in &= quot;search.c" > > unnamed block in connection_operation(ctx =3D3D 0x0000019c, a= rg_v =3D3D > > 0x00000067), line 1155 in "connection.c" > > connection_operation(ctx =3D3D 0x0000019c, arg_v =3D3D 0x0000= 0067), line 11=3D > > 55 in > > "connection.c" > > connection_read_thread(ctx =3D3D (nil), argv =3D3D (nil)), li= ne 1291 in > > "connection.c" > > ldap_int_thread_pool_wrapper(xpool =3D3D (nil)), line 688 in = "tpool.c" > > > > > > LDAPSEARCH: > > Waiting to attach to process 11272394 ... > > Successfully attached to ldapsearch. > > warning: Directory containing ldapsearch could not be determi= ned. > > Apply 'use' command to initialize source path. > > > > Type 'help' for help. > > reading symbolic information ... > > stopped in __fd_poll at 0xd0262734 ($t1) > > 0xd0262734 (__fd_poll+0xb4) 80410014       &nb= sp; lwz   r2,0x14(r1) > > (dbx) where > > __fd_poll(??, ??, ??) at 0xd0262734 > > os-ip.poll(__listptr =3D3D 0x00000001, __nfds =3D3D 429496729= 4, __timeout =3D3D=3D > > > > 1000000), line 107 in "poll.h" > > ldap_int_select(ld =3D3D (nil), timeout =3D3D 0x3002a9c8), li= ne 1139 in "os=3D > > -ip.c" > > wait4msg(ld =3D3D 0xd0f6bb50, msgid =3D3D 804398239, all =3D3= D 804389024, tim=3D > > eout =3D3D > > (nil), result =3D3D 0x2ff200e0), line 312 in "result.c&q= uot; > > ldap_result(ld =3D3D (nil), msgid =3D3D 805309096, all =3D3D = 804389216, timeo=3D > > ut =3D3D > > 0x28224243, result =3D3D 0x1000866c), line 117 in "resul= t.c" > > dosearch(ld =3D3D 0x30009c18, base =3D3D "<a href=3D"fil= e:///%s/">file:///%s/</a>", scope =3D3D 268504837=3D > > , filtpatt > > =3D3D (nil), value =3D3D (nil), attrs =3D3D (nil), attrsonly = =3D3D -261995236, =3D > > sctrls =3D3D > > 0x10010f08, cctrls =3D3D (nil), timeout =3D3D (nil), sizelimi= t =3D3D -1), lin=3D > > e 1447 in > > "ldapsearch.c" > > main(argc =3D3D 0, argv =3D3D (nil)), line 1222 in "ldap= search.c" > > > > (dbx) thread > >   thread  state-k     wchan    = state-u    k-tid   mode held scope functi=3D > > on > >> $t1     run           =        running  35192885     k &nbsp= ; no   sys  __fd_=3D > > poll > > > -- >    -- Howard Chu >    CTO, Symas Corp.           <= a href=3D"http://www.symas.com">http://www.symas.com</a> >    Director, Highland Sun     <a href=3D"http:= //highlandsun.com/hyc/">http://highlandsun.com/hyc/</a> >    Chief Architect, OpenLDAP  <a href=3D"http://www= .openldap.org/project/">http://www.openldap.org/project/</a> This happens on the first backend that isn't MDB - I've tried disabling= BDB and HDB separately and it hangs on both.The slapd is the test5 sla= pd(it's been a while, but I seem to recall checking the start time of t= he daemon)</tt> <tt>Howard</tt>   ---------------------------= -----------------------------------------------------------------------= ------ VERTRAULICHKEIT: Diese Nach= richt ist ausschlie=DFlich f=FCr denjenigen bestimmt, an den sie adress= iert ist und kann vertrauliche Informationen enthalten. Falls Sie nicht= der Empf=E4nger dieser Nachricht sind, weisen wir Sie darauf hin, dass= die unberechtigte Weitergabe oder Verwendung sowie das unberechtigte V= erteilen oder Kopieren dieser Nachricht strikt untersagt sind. Falls Si= e diese Nachricht irrt=FCmlich erhalten haben, vernichten Sie sie bitte= sofort. CONFIDENTIALITY: This messa= ge is intended only for the use of the individuality or entity to which= it is addressed and may contain information that is privileged, confid= ential and exempt from disclosure. If you are not the intended recipien= t you are notified that any dissemination, distribution, use or copying= of this communication is strictly prohibited. If you received this mes= sage in error, please immediately destroy this message. ---------------------------= -----------------------------------------------------------------------= ------ </body></html>= --0__=4EBBF697DF89C4868f9e8a93df938690918c4EBBF697DF89C486--

1 0

Re: (ITS#7573) back-perl not working with cn=config
by hyc＠symas.com 12 Oct '13

12 Oct '13

benintechnologies(a)yahoo.fr wrote: > Full_Name: Ben > Version: 2.4.34 > OS: Debian 6.0.4 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (41.79.217.116) > > > Hi, > > I'm unable to set up a back-perl backend directly in cn=config mode. However, if > I set it up in slapd.conf mode, and then convert it to cn=config mode, it works > fine. It's not convenient, because I have to set all my perl backends up before > converting to cn=config. The crash is deep inside libperl. It appears to affect other platforms as well: https://bugzilla.redhat.com/show_bug.cgi?id=967719 Most likey you will need to build your own libperl in order to fix this, tho at the moment I have no idea what perl configuration changes will be required. 5259e408 conn=1000 op=1 do_add ber_scanf fmt ({m) ber: 5259e408 conn=1000 op=1 do_add: dn (olcDatabase=perl,cn=config) ber_scanf fmt ({m{W}}) ber: ber_scanf fmt ({m{W}}) ber: ber_scanf fmt ({m{W}}) ber: ber_scanf fmt ({m{W}}) ber: ber_scanf fmt ({m{W}}) ber: ber_scanf fmt ({m{W}}) ber: ber_scanf fmt ({m{W}}) ber: ber_scanf fmt ({m{W}}) ber: ber_scanf fmt ({m{W}}) ber: ber_scanf fmt ({m{W}}) ber: ber_scanf fmt ({m{W}}) ber: ber_scanf fmt ({m{W}}) ber: ber_scanf fmt ({m{W}}) ber: ber_scanf fmt ({m{W}}) ber: ber_scanf fmt (}) ber: 5259e408 >>> dnPrettyNormal: <olcDatabase=perl,cn=config> => ldap_bv2dn(olcDatabase=perl,cn=config,0) <= ldap_bv2dn(olcDatabase=perl,cn=config)=0 => ldap_dn2bv(272) <= ldap_dn2bv(olcDatabase=perl,cn=config)=0 => ldap_dn2bv(272) <= ldap_dn2bv(olcDatabase=perl,cn=config)=0 5259e408 <<< dnPrettyNormal: <olcDatabase=perl,cn=config>, <olcDatabase=perl,cn=config> 5259e408 >>> dnPretty: <dc=mydomain,dc=org> => ldap_bv2dn(dc=mydomain,dc=org,0) <= ldap_bv2dn(dc=mydomain,dc=org)=0 => ldap_dn2bv(272) <= ldap_dn2bv(dc=mydomain,dc=org)=0 5259e408 <<< dnPretty: <dc=mydomain,dc=org> 5259e408 >>> dnNormalize: <dc=mydomain,dc=org> => ldap_bv2dn(dc=mydomain,dc=org,0) <= ldap_bv2dn(dc=mydomain,dc=org)=0 => ldap_dn2bv(272) <= ldap_dn2bv(dc=mydomain,dc=org)=0 5259e408 <<< dnNormalize: <dc=mydomain,dc=org> 5259e408 >>> dnPretty: <cn=Manager,dc=mydomain,dc=org> => ldap_bv2dn(cn=Manager,dc=mydomain,dc=org,0) <= ldap_bv2dn(cn=Manager,dc=mydomain,dc=org)=0 => ldap_dn2bv(272) <= ldap_dn2bv(cn=Manager,dc=mydomain,dc=org)=0 5259e408 <<< dnPretty: <cn=Manager,dc=mydomain,dc=org> 5259e408 >>> dnNormalize: <cn=Manager,dc=mydomain,dc=org> => ldap_bv2dn(cn=Manager,dc=mydomain,dc=org,0) <= ldap_bv2dn(cn=Manager,dc=mydomain,dc=org)=0 => ldap_dn2bv(272) <= ldap_dn2bv(cn=manager,dc=mydomain,dc=org)=0 5259e408 <<< dnNormalize: <cn=manager,dc=mydomain,dc=org> 5259e408 oc_check_required entry (olcDatabase=perl,cn=config), objectClass "olcDbPerlConfig" 5259e408 oc_check_allowed type "objectClass" 5259e408 oc_check_allowed type "olcDatabase" 5259e408 oc_check_allowed type "olcSuffix" 5259e408 oc_check_allowed type "olcAddContentAcl" 5259e408 oc_check_allowed type "olcLastMod" 5259e408 oc_check_allowed type "olcMaxDerefDepth" 5259e408 oc_check_allowed type "olcReadOnly" 5259e408 oc_check_allowed type "olcRootDN" 5259e408 oc_check_allowed type "olcRootPW" 5259e408 oc_check_allowed type "olcSyncUseSubentry" 5259e408 oc_check_allowed type "olcMonitoring" 5259e408 oc_check_allowed type "olcPerlModulePath" 5259e408 oc_check_allowed type "olcPerlModule" 5259e408 oc_check_allowed type "olcPerlFilterSearchResults" 5259e408 oc_check_allowed type "structuralObjectClass" 5259e408 >>> dnNormalize: <olcDatabase={3}perl> 5259e408 <<< dnNormalize: <olcDatabase={3}perl> 5259e408 >>> dnPrettyNormal: <dc=mydomain,dc=org> => ldap_bv2dn(dc=mydomain,dc=org,0) <= ldap_bv2dn(dc=mydomain,dc=org)=0 => ldap_dn2bv(272) <= ldap_dn2bv(dc=mydomain,dc=org)=0 => ldap_dn2bv(272) <= ldap_dn2bv(dc=mydomain,dc=org)=0 5259e408 <<< dnPrettyNormal: <dc=mydomain,dc=org>, <dc=mydomain,dc=org> 5259e408 >>> dnPrettyNormal: <cn=Manager,dc=mydomain,dc=org> => ldap_bv2dn(cn=Manager,dc=mydomain,dc=org,0) <= ldap_bv2dn(cn=Manager,dc=mydomain,dc=org)=0 => ldap_dn2bv(272) <= ldap_dn2bv(cn=Manager,dc=mydomain,dc=org)=0 => ldap_dn2bv(272) <= ldap_dn2bv(cn=manager,dc=mydomain,dc=org)=0 5259e408 <<< dnPrettyNormal: <cn=Manager,dc=mydomain,dc=org>, <cn=manager,dc=mydomain,dc=org> 5259e408 perl backend db init Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 0x7fffebfff700 (LWP 20520)] 0x00007ffff74f5b7d in Perl_gv_fetchpvn_flags () from /usr/lib/libperl.so.5.14 (gdb) bt #0 0x00007ffff74f5b7d in Perl_gv_fetchpvn_flags () from /usr/lib/libperl.so.5.14 #1 0x00007ffff74ea3ed in Perl_get_hv () from /usr/lib/libperl.so.5.14 #2 0x00007ffff00a1241 in boot_Fcntl () from /usr/lib/perl/5.14/auto/Fcntl/Fcntl.so #3 0x00007ffff755982f in Perl_pp_entersub () from /usr/lib/libperl.so.5.14 #4 0x00007ffff7550cc6 in Perl_runops_standard () from /usr/lib/libperl.so.5.14 #5 0x00007ffff74ec5ee in Perl_call_sv () from /usr/lib/libperl.so.5.14 #6 0x00007ffff74ecc2d in Perl_call_list () from /usr/lib/libperl.so.5.14 #7 0x00007ffff74d6739 in ?? () from /usr/lib/libperl.so.5.14 #8 0x00007ffff74e3e11 in Perl_newATTRSUB () from /usr/lib/libperl.so.5.14 #9 0x00007ffff74e4518 in Perl_utilize () from /usr/lib/libperl.so.5.14 #10 0x00007ffff7512b3f in Perl_yyparse () from /usr/lib/libperl.so.5.14 #11 0x00007ffff758b38d in ?? () from /usr/lib/libperl.so.5.14 #12 0x00007ffff7595821 in Perl_pp_require () from /usr/lib/libperl.so.5.14 #13 0x00007ffff7550cc6 in Perl_runops_standard () from /usr/lib/libperl.so.5.14 #14 0x00007ffff74ec5ee in Perl_call_sv () from /usr/lib/libperl.so.5.14 #15 0x00007ffff74ecc2d in Perl_call_list () from /usr/lib/libperl.so.5.14 #16 0x00007ffff74d6739 in ?? () from /usr/lib/libperl.so.5.14 #17 0x00007ffff74e3e11 in Perl_newATTRSUB () from /usr/lib/libperl.so.5.14 #18 0x00007ffff74e4518 in Perl_utilize () from /usr/lib/libperl.so.5.14 #19 0x00007ffff7512b3f in Perl_yyparse () from /usr/lib/libperl.so.5.14 #20 0x00007ffff758b38d in ?? () from /usr/lib/libperl.so.5.14 #21 0x00007ffff7595821 in Perl_pp_require () from /usr/lib/libperl.so.5.14 #22 0x00007ffff7550cc6 in Perl_runops_standard () from /usr/lib/libperl.so.5.14 #23 0x00007ffff74ec5ee in Perl_call_sv () from /usr/lib/libperl.so.5.14 #24 0x00007ffff74ecc2d in Perl_call_list () from /usr/lib/libperl.so.5.14 #25 0x00007ffff74d6739 in ?? () from /usr/lib/libperl.so.5.14 #26 0x00007ffff74e3e11 in Perl_newATTRSUB () from /usr/lib/libperl.so.5.14 #27 0x00007ffff74e4518 in Perl_utilize () from /usr/lib/libperl.so.5.14 #28 0x00007ffff7512b3f in Perl_yyparse () from /usr/lib/libperl.so.5.14 #29 0x00007ffff758b38d in ?? () from /usr/lib/libperl.so.5.14 #30 0x00007ffff7596824 in Perl_pp_entereval () from /usr/lib/libperl.so.5.14 #31 0x00007ffff74ebd31 in Perl_eval_sv () from /usr/lib/libperl.so.5.14 #32 0x00007ffff74ebe84 in Perl_eval_pv () from /usr/lib/libperl.so.5.14 ---Type <return> to continue, or q <return> to quit--- #33 0x00000000005f345a in perl_cf (c=0x7fffebffd2f0) at ../../../../head/servers/slapd/back-perl/config.c:177 #34 0x0000000000442a7b in config_set_vals (Conf=0x90ed60, c=0x7fffebffd2f0) at ../../../head/servers/slapd/config.c:345 #35 0x0000000000442fcf in config_add_vals (Conf=0x90ed60, c=0x7fffebffd2f0) at ../../../head/servers/slapd/config.c:418 #36 0x0000000000443c9a in config_parse_add (ct=0x90ed60, c=0x7fffebffd2f0, valx=0) at ../../../head/servers/slapd/config.c:689 #37 0x0000000000439c1b in config_add_internal (cfb=0x9105e0, e=0xa52bb8, ca=0x7fffebffd2f0, rs=0x7fffebffe970, renum=0x7fffebffd2e8, op=0x7fffe4002670) at ../../../head/servers/slapd/bconfig.c:5439 #38 0x000000000043a83e in config_back_add (op=0x7fffe4002670, rs=0x7fffebffe970) at ../../../head/servers/slapd/bconfig.c:5666 #39 0x000000000045ba65 in fe_op_add (op=0x7fffe4002670, rs=0x7fffebffe970) at ../../../head/servers/slapd/add.c:334 #40 0x000000000045b2e2 in do_add (op=0x7fffe4002670, rs=0x7fffebffe970) at ../../../head/servers/slapd/add.c:194 #41 0x00000000004524a1 in connection_operation (ctx=0x7fffebffeb60, arg_v=0x7fffe4002670) at ../../../head/servers/slapd/connection.c:1134 #42 0x0000000000452b1b in connection_read_thread (ctx=0x7fffebffeb60, argv=<optimized out>) at ../../../head/servers/slapd/connection.c:1270 #43 0x000000000061435a in ldap_int_thread_pool_wrapper (xpool=0x9e4d00) at ../../../head/libraries/libldap_r/tpool.c:945 #44 0x00007ffff728ee9a in start_thread (arg=0x7fffebfff700) at pthread_create.c:308 #45 0x00007ffff62f6cbd in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:112 #46 0x0000000000000000 in ?? () > > Here's the ldif file I'm using to set up a back-perl backend in cn=config mode > (it's inspired from the files I get by converting slapd.conf into cn=config with > slaptest) > > # Load dynamic backend modules > dn: cn=module,cn=config > objectClass: olcModuleList > cn: module > olcModulepath: /usr/local/libexec/openldap > olcModuleload: back_perl.la > > # Database settings > dn: olcDatabase=perl,cn=config > objectClass: olcDatabaseConfig > objectClass: olcDbPerlConfig > olcDatabase: perl > olcSuffix: dc=mydomain,dc=org > olcAddContentAcl: FALSE > olcLastMod: TRUE > olcMaxDerefDepth: 15 > olcReadOnly: FALSE > olcRootDN: cn=Manager,dc=mydomain,dc=org > olcRootPW:: c2VjcmV0 > olcSyncUseSubentry: FALSE > olcMonitoring: FALSE > olcPerlModulePath: /usr/local/etc/openldap/perl > olcPerlModule: SampleLDAP > olcPerlFilterSearchResults: FALSE > > > And here's what I get when I try to load the file: > ldapadd -Y EXTERNAL -H ldapi:/// -f perl-backend.ldif > SASL/EXTERNAL authentication started > SASL username: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth > SASL SSF: 0 > adding new entry "cn=module,cn=config" > adding new entry "olcDatabase=perl,cn=config" > ldap_result: Can't contact LDAP server (-1) > > After that, if I start OpenLDAP I get a segmentation fault: > root@ldap:/tmp# /usr/local/libexec/slapd -u openldap -g openldap -h "ldap:/// > ldapi:///" -d 16383 > . > 51585496 perl backend db init > Segmentation fault > > Like I said, if I set back-perl up in slapd.conf mode and then convert it to > cn=config, everything works fine. > > Ben > > -- -- 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#7725) LMDB readahead should be configurable
by hyc＠OpenLDAP.org 12 Oct '13

12 Oct '13

Full_Name: Howard Chu Version: 2.4.35+ OS: Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (78.155.233.73) Submitted by: hyc In 2.4.35 (commit b1da555c4c7275d7f756d693c42814388a9aa839) code was added to unconditionally turn off readahead, because it is harmful to random read performance when a DB is larger than RAM and/or system RAM is already full. Unfortunately turning it off harms sequential read performance. It should be configurable, since different behaviors are needed in different use cases.

1 0

Re: Antwort: Re: (ITS#7653) Test Build Version 2.4.36 hangs
by hyc＠symas.com 12 Oct '13

12 Oct '13

howard.allison(a)pensionsversicherung.at wrote: > --0__=4EBBF156DFB715BF8f9e8a93df938690918c4EBBF156DFB715BF > Content-type: multipart/alternative; > Boundary="1__=4EBBF156DFB715BF8f9e8a93df938690918c4EBBF156DFB715BF" > > --1__=4EBBF156DFB715BF8f9e8a93df938690918c4EBBF156DFB715BF > Content-type: text/plain; charset=ISO-8859-1 > Content-transfer-encoding: quoted-printable > > > Hi! > Sorry - here's the stack trace: Which backend were you testing, it's not shown in any of your output. Your trace is strange because it shows overlays being used, but test005 doesn't use any overlays. Seems like you may have a slapd left over from some other test. > > SLAPD: > (dbx) thread info > thread state-k wchan state-u k-tid mode held scope functi= > on > $t1 wait 0xf1000f0a1000ee40 blocked 15597767 k no sy= > s > > general: > pthread addr =3D 0x3009f56c size =3D 0x290 > vp addr =3D 0x300a15b0 size =3D 0x2e0 > thread errno =3D 0 > start pc =3D 0x10000420 > joinable =3D yes > pthread_t =3D 1 > scheduler: > kernel =3D > user =3D 1 (other) > nice =3D 60 > event : > event =3D 0x0 > cancel =3D enabled, deferred, not pending > stack storage: > base =3D 0x20000000 size =3D 0xff22190= > > limit =3D 0x2ff22190 > sp =3D 0x2ff21e90 > thread state-k wchan state-u k-tid mode held scope functi= > on >> $t2 run running 36372639 k no sys > __fd_select > > general: > pthread addr =3D 0x308e5cf0 size =3D 0x290 > vp addr =3D 0x303d3780 size =3D 0x2e0 > thread errno =3D 4 > start pc =3D 0x3001f600 > joinable =3D yes > pthread_t =3D 102 > scheduler: > kernel =3D > user =3D 1 (other) > nice =3D 60 > event : > event =3D 0x0 > cancel =3D enabled, deferred, not pending > stack storage: > base =3D 0x304e5000 size =3D 0x400000 > limit =3D 0x308e5b90 > sp =3D 0x308e4530 > thread state-k wchan state-u k-tid mode held scope functi= > on > $t3 run running 30015693 u no sys > base_candidate > > general: > pthread addr =3D 0x30ce9cf0 size =3D 0x290 > vp addr =3D 0x303d5790 size =3D 0x2e0 > thread errno =3D 11 > start pc =3D 0xf0391ec0 > joinable =3D no > pthread_t =3D 203 > scheduler: > kernel =3D > user =3D 1 (other) > nice =3D 60 > event : > event =3D 0x0 > cancel =3D enabled, deferred, not pending > stack storage: > base =3D 0x308e9000 size =3D 0x400000 > limit =3D 0x30ce9b90 > sp =3D 0x30c286f0 > thread state-k wchan state-u k-tid mode held scope functi= > on > $t4 run running 21561505 u no sys > base_candidate > > general: > pthread addr =3D 0x319eecf0 size =3D 0x290 > vp addr =3D 0x303e4b60 size =3D 0x2e0 > thread errno =3D 11 > start pc =3D 0xf0391ec0 > joinable =3D no > pthread_t =3D 304 > scheduler: > kernel =3D > user =3D 1 (other) > nice =3D 60 > event : > event =3D 0x0 > cancel =3D enabled, deferred, not pending > stack storage: > base =3D 0x315ed000 size =3D 0x400000 > limit =3D 0x319eeb90 > sp =3D 0x3192d6f0 > > (dbx) thread current -1 > warning: Thread is in kernel mode, not all registers can be accessed. > (dbx) where > .() at 0x11c501d40 > _event_wait(??, ??) at 0xd0502be4 > _cond_wait_local(??, ??, ??) at 0xd0510f40 > _cond_wait(??, ??, ??) at 0xd0511510 > pthread_join(??, ??) at 0xd04f91b0 > ldap_pvt_thread_join(thread =3D 8, thread_return =3D 0x00000008), line = > 197 in > "thr_posix.c" > slapd_daemon(), line 2929 in "daemon.c" > main(argc =3D 0, argv =3D (nil)), line 1012 in "main.c" > > (dbx) thread current -2 > (dbx) where > __fd_select(??, ??, ??, ??, ??) at 0xd0262f2c > daemon.select(__fds =3D 0, __readlist =3D (nil), __writelist =3D (nil),= > > __exceptlist =3D (nil), __timeout =3D (nil)), line 234 in "time.h" > unnamed block in slapd_daemon_task(ptr =3D (nil)), line 2536 in "daemon= > .c" > unnamed block in slapd_daemon_task(ptr =3D (nil)), line 2536 in "daemon= > .c" > slapd_daemon_task(ptr =3D (nil)), line 2536 in "daemon.c" > > (dbx) thread current -3 > (dbx) where > search.base_candidate(be =3D (nil), e =3D (nil), ids =3D (nil)), line 3= > 71 in > "search.c" > glue_sub_search(op =3D 0xf061b148, rs =3D 0xf061b108, b0 =3D 0x00000002= > , on =3D > 0xf0240744), line 380 in "backglue.c" > glue_op_search(op =3D 0x301185f8, rs =3D 0x303d5a78), line 537 in "back= > glue.c" > overlay_op_walk(op =3D (nil), rs =3D (nil), which =3D op_bind, oi =3D (= > nil), on =3D > 0x01000000), line 661 in "backover.c" > over_op_func(op =3D (nil), rs =3D 0x102c9510, which =3D op_bind), line = > 723 in > "backover.c" > fe_op_search(op =3D 0x00004105, rs =3D 0x00000100), line 402 in "search= > .c" > do_search(op =3D 0x000003e8, rs =3D (nil)), line 247 in "search.c" > unnamed block in connection_operation(ctx =3D 0x00000114, arg_v =3D > 0x00000045), line 1155 in "connection.c" > connection_operation(ctx =3D 0x00000114, arg_v =3D 0x00000045), line 11= > 55 in > "connection.c" > connection_read_thread(ctx =3D (nil), argv =3D (nil)), line 1291 in > "connection.c" > ldap_int_thread_pool_wrapper(xpool =3D (nil)), line 688 in "tpool.c" > > (dbx) thread current -4 > (dbx) where > search.base_candidate(be =3D (nil), e =3D (nil), ids =3D (nil)), line 3= > 71 in > "search.c" > glue_sub_search(op =3D 0xf061b148, rs =3D 0xf061b108, b0 =3D 0x00000002= > , on =3D > 0xf0240744), line 380 in "backglue.c" > glue_op_search(op =3D 0x301185f8, rs =3D 0x303e4ee8), line 537 in "back= > glue.c" > overlay_op_walk(op =3D (nil), rs =3D (nil), which =3D op_bind, oi =3D (= > nil), on =3D > 0x01000000), line 661 in "backover.c" > over_op_func(op =3D (nil), rs =3D 0x102c9510, which =3D op_bind), line = > 723 in > "backover.c" > fe_op_search(op =3D 0x00004105, rs =3D 0x00000100), line 402 in "search= > .c" > do_search(op =3D 0x000003e9, rs =3D (nil)), line 247 in "search.c" > unnamed block in connection_operation(ctx =3D 0x0000019c, arg_v =3D > 0x00000067), line 1155 in "connection.c" > connection_operation(ctx =3D 0x0000019c, arg_v =3D 0x00000067), line 11= > 55 in > "connection.c" > connection_read_thread(ctx =3D (nil), argv =3D (nil)), line 1291 in > "connection.c" > ldap_int_thread_pool_wrapper(xpool =3D (nil)), line 688 in "tpool.c" > > > LDAPSEARCH: > Waiting to attach to process 11272394 ... > Successfully attached to ldapsearch. > warning: Directory containing ldapsearch could not be determined. > Apply 'use' command to initialize source path. > > Type 'help' for help. > reading symbolic information ... > stopped in __fd_poll at 0xd0262734 ($t1) > 0xd0262734 (__fd_poll+0xb4) 80410014 lwz r2,0x14(r1) > (dbx) where > __fd_poll(??, ??, ??) at 0xd0262734 > os-ip.poll(__listptr =3D 0x00000001, __nfds =3D 4294967294, __timeout =3D= > > 1000000), line 107 in "poll.h" > ldap_int_select(ld =3D (nil), timeout =3D 0x3002a9c8), line 1139 in "os= > -ip.c" > wait4msg(ld =3D 0xd0f6bb50, msgid =3D 804398239, all =3D 804389024, tim= > eout =3D > (nil), result =3D 0x2ff200e0), line 312 in "result.c" > ldap_result(ld =3D (nil), msgid =3D 805309096, all =3D 804389216, timeo= > ut =3D > 0x28224243, result =3D 0x1000866c), line 117 in "result.c" > dosearch(ld =3D 0x30009c18, base =3D "file:///%s/", scope =3D 268504837= > , filtpatt > =3D (nil), value =3D (nil), attrs =3D (nil), attrsonly =3D -261995236, = > sctrls =3D > 0x10010f08, cctrls =3D (nil), timeout =3D (nil), sizelimit =3D -1), lin= > e 1447 in > "ldapsearch.c" > main(argc =3D 0, argv =3D (nil)), line 1222 in "ldapsearch.c" > > (dbx) thread > thread state-k wchan state-u k-tid mode held scope functi= > on >> $t1 run running 35192885 k no sys __fd_= > poll -- -- 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#7692) segfault in overlay constraint - constraint_check_restrict (op=0x7fffa8000960, c=0x9e60f0, e=0x0) at constraint.c:713
by hyc＠symas.com 12 Oct '13

12 Oct '13

coudot(a)linagora.com wrote: > Full_Name: Clement OUDOT > Version: 2.4.35 > OS: CentOS 6 64bits > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (83.145.72.122) > > > I use the overlay constraint to check that a value of the attribute ssoRoles > exists in the directory. The configuration looks like this: Thanks for the report, fixed now in master > > ---------------------------------------------- > overlay constraint > constraint_attribute ssoRoles uri > ldap:///ou=applications,dc=cirra,dc=net?entrydn?sub?(&(objectClass=organizationalUnit)(ou:dn:=roles)) > restrict="ldap:///ou=users,dc=cirra,dc=net??one?(objectClass=inetOrgPerson)" > ---------------------------------------------- > > An ldapmodify with this LDIF crash the slapd process: > ---------------------------------------------- > dn: uid=toto,ou=users,dc=cirra,dc=net > changetype: modify > add: ssoRoles > ssoRoles: ou=ROLE_PES,ou=roles,ou=simabo,ou=applications,dc=cirra,dc=net > ---------------------------------------------- > > The crash occurs because the entry uid=toto,ou=users,dc=cirra,dc=net do not > exist. The same LDIF on an existing entry works well. > > > Below is the stacktrace generated with gdb: > ---------------------------------------------- > > (gdb) run -d 0 > Starting program: /usr/local/openldap/libexec/slapd -d 0 > [Thread debugging using libthread_db enabled] > [New Thread 0x7fffb3d42700 (LWP 16519)] > [New Thread 0x7fffb3541700 (LWP 16521)] > [New Thread 0x7fffb2d40700 (LWP 16522)] > > Program received signal SIGSEGV, Segmentation fault. > [Switching to Thread 0x7fffb2d40700 (LWP 16522)] > constraint_check_restrict (op=0x7fffa8000960, c=0x9e60f0, e=0x0) at > constraint.c:713 > 713 int diff = e->e_nname.bv_len - c->restrict_ndn.bv_len; > Missing separate debuginfos, use: debuginfo-install > berkeleydb-ltb-4.6.21.NC-4.el6.patch4.x86_64 > cyrus-sasl-gssapi-2.1.23-13.el6_3.1.x86_64 > cyrus-sasl-ldap-2.1.23-13.el6_3.1.x86_64 cyrus-sasl-lib-2.1.23-13.el6_3.1.x86_64 > cyrus-sasl-plain-2.1.23-13.el6_3.1.x86_64 db4-4.7.25-17.el6.x86_64 > glibc-2.12-1.107.el6.x86_64 keyutils-libs-1.4-4.el6.x86_64 > krb5-libs-1.10.3-10.el6.x86_64 libcom_err-1.41.12-14.el6.x86_64 > libselinux-2.0.94-5.3.el6.x86_64 libtool-ltdl-2.2.6-15.5.el6.x86_64 > nss-softokn-freebl-3.12.9-11.el6.x86_64 openssl-1.0.0-27.el6.x86_64 > zlib-1.2.3-29.el6.x86_64 > (gdb) bt full > #0 constraint_check_restrict (op=0x7fffa8000960, c=0x9e60f0, e=0x0) at > constraint.c:713 > diff = <value optimized out> > __PRETTY_FUNCTION__ = "constraint_check_restrict" > #1 0x000000000054b39f in constraint_update (op=<value optimized out>, > rs=0x7fffb2d3f950) at constraint.c:989 > j = <value optimized out> > ce = 0 > on = 0x9e5e30 > be = 0x7fffb2d3e4e0 > c = 0x9e60f0 > cp = <value optimized out> > target_entry = 0x0 > target_entry_copy = 0x0 > modlist = 0x7fffa8000920 > m = 0x7fffa8000920 > b = 0x7fffa81015c0 > i = <value optimized out> > rsv = {bv_len = 24, bv_val = 0x60f2a4 "modify breaks constraint"} > rc = <value optimized out> > msg = 0x0 > is_v = <value optimized out> > #2 0x00000000004a6d7a in overlay_op_walk (op=0x7fffa8000960, rs=0x7fffb2d3f950, > which=op_modify, oi=0x9e1020, on=0x9e5e30) > at backover.c:661 > func = 0x9e5e88 > rc = 32768 > #3 0x00000000004a7847 in over_op_func (op=0x7fffa8000960, rs=<value optimized > out>, which=<value optimized out>) > at backover.c:723 > oi = <value optimized out> > on = <value optimized out> > be = 0x9ba220 > db = {bd_info = 0x9e5e30, bd_self = 0x9ba220, > be_ctrls = > "\000\000\000\001\001\001\000\001\000\000\001\000\000\001\001\000\001\000\000\001", > '\000' <repeats 12 times>, "\001", be_flags = 2312, 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 = 0x9dca20, > be_nsuffix = 0x9dca50, be_schemadn = { > bv_len = 0, bv_val = 0x0}, be_schemandn = {bv_len = 0, bv_val = > 0x0}, be_rootdn = {bv_len = 26, > bv_val = 0x9dcb70 "cn=manager,dc=cirra,dc=net"}, be_rootndn = > {bv_len = 26, > bv_val = 0x9dcbc0 "cn=manager,dc=cirra,dc=net"}, be_rootpw = {bv_len > = 38, > bv_val = 0x9dc8b0 "{SSHA}2S9rqrduHEq4AcNIfS+wxClQwbD5aoLn"}, > be_max_deref_depth = 15, be_def_limit = { > lms_t_soft = 3600, lms_t_hard = 0, lms_s_soft = 500, lms_s_hard = 0, > lms_s_unchecked = -1, lms_s_pr = 0, > lms_s_pr_hide = 0, lms_s_pr_total = 0}, be_limits = 0x9e01a0, be_acl > = 0x9b9850, be_dfltaccess = ACL_READ, > be_extra_anlist = 0x0, be_update_ndn = {bv_len = 0, bv_val = 0x0}, > be_update_refs = 0x0, > ---Type <return> to continue, or q <return> to quit--- > be_pending_csn_list = 0xa6f7f0, be_pcl_mutex = {__data = {__lock = 0, > __count = 0, __owner = 0, __nusers = 0, > __kind = 0, __spins = 0, __list = {__prev = 0x0, __next = 0x0}}, > __size = '\000' <repeats 39 times>, > __align = 0}, be_syncinfo = 0x0, be_pb = 0x0, be_cf_ocs = 0x8838c0, > be_private = 0x9ba3c0, be_next = { > stqe_next = 0x9e6470}} > cb = {sc_next = 0x0, sc_response = 0x4a6af0 <over_back_response>, > sc_cleanup = 0, sc_private = 0x9e1020} > sc = <value optimized out> > rc = 32768 > __PRETTY_FUNCTION__ = "over_op_func" > #4 0x000000000045728b in fe_op_modify (op=0x7fffa8000960, rs=0x7fffb2d3f950) at > modify.c:303 > update = <value optimized out> > repl_user = <value optimized out> > op_be = <value optimized out> > bd = 0x88c200 > textbuf = ">\000\000\000\000\000\000\000\240\030\020\250\377\177\000\000\000\000\000\000\000\000\000\000@\026\020\250\377\177\000\000\240\235G\000\000\000\000\000\267\244E", > '\000' <repeats 13 times>, "\003\000\000\000\060\000\000\000[\000\000\000|", > '\000' <repeats 11 times>, "\b", '\000' <repeats 31 times>, > ">\000\000\000\000\000\000\000\360\025\020\250\377\177\000\000\000\000\000\000\000\000\000\000 > \t\000\250\377\177\000\000\000\000\000\000\000\000\000\000@É > > #5 0x0000000000457bb6 in do_modify (op=0x7fffa8000960, > rs=0x7fffb2d3f950) at modify.c:177 > dn = {bv_len = 33, bv_val = 0x7fffa8101507 > "uid=toto,ou=users,dc=cirra,dc=net"} > textbuf = "\027\f\000\250\377\177", '\000' <repeats 42 times>, > "PG\253\367\000\000\000\000P\333\377\367\377\177\000\000\000\000A", '\000' > <repeats 13 times>, "\030f@\000\000\000\000\000Y\345`\237\064", '\000' <repeats > 11 times>"\351, \363[\000\000\000\000\000`\t\000\250\377\177\000\000\340\024\302\236\064\000\000\000\377\377\377\377\377\177\000\000\030\372Ó²\377\177\000\000\210\021\302\236\064\000\000\000@\304X\237\064", > '\000' <repeats 11 times>, > ":\236\240\236\064\000\000\000\320\016\000\250\377\177\000\000\000\000\020\000\000\000\000\000\001\000\000\000\000\000\000\000\001\000\000\000\000\000\000\000\260\372Ó²\377\177\000\000\360.I", > '\000' <repeats 13 times>, > "\t\000\000\000\062\000\000\000`\t\000\250\377\177\000\000\320\016\000\250\377\177\000" > tmp = <value optimized out> > #6 0x000000000043f9a9 in connection_operation (ctx=0x7fffb2d3fab0, > arg_v=0x7fffa8000960) at connection.c:1155 > rc = 80 > cancel = <value optimized out> > op = 0x7fffa8000960 > rs = {sr_type = REP_RESULT, sr_tag = 0, sr_msgid = 0, sr_err = 0, > sr_matched = 0x0, sr_text = 0x0, sr_ref = 0x0, > sr_ctrls = 0x0, sr_un = {sru_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 = 102 > opidx = SLAP_OP_MODIFY > conn = 0x7ffff632bc10 > ---Type <return> to continue, or q <return> to quit--- > memctx = 0x7fffa8000ed0 > memctx_null = 0x0 > memsiz = 1048576 > __PRETTY_FUNCTION__ = "connection_operation" > #7 0x0000000000440195 in connection_read_thread (ctx=0x7fffb2d3fab0, > argv=<value optimized out>) at connection.c:1291 > rc = <value optimized out> > cri = {op = 0x7fffa8000960, func = 0, arg = 0x0, ctx = 0x7fffb2d3fab0, > nullop = <value optimized out>} > s = <value optimized out> > #8 0x0000000000593d00 in ldap_int_thread_pool_wrapper (xpool=0x960c00) at > tpool.c:688 > pool = 0x960c00 > task = 0x7fffac0008c0 > work_list = <value optimized out> > ctx = {ltu_id = 140736193627904, ltu_key = {{ltk_key = 0x43e7c0, > ltk_data = 0x7fffa8000dc0, > ltk_free = 0x43e890 <conn_counter_destroy>}, {ltk_key = 0x492d40, > ltk_data = 0x7fffa8000ed0, > ltk_free = 0x492d60 <slap_sl_mem_destroy>}, {ltk_key = 0xa6f810, > ltk_data = 0x7fffa8100f80, > ltk_free = 0x4f7280 <bdb_reader_free>}, {ltk_key = 0x452ba0, > ltk_data = 0x0, > ltk_free = 0x452970 <slap_op_q_destroy>}, {ltk_key = 0x0, ltk_data > = 0x0, ltk_free = 0} <repeats 25 times>, { > ltk_key = 0x0, ltk_data = 0x349f607eea, ltk_free = 0}, {ltk_key = > 0x0, ltk_data = 0x0, ltk_free = 0}, { > ltk_key = 0x0, ltk_data = 0x0, ltk_free = 0}}} > kctx = <value optimized out> > keyslot = 555 > hash = <value optimized out> > __PRETTY_FUNCTION__ = "ldap_int_thread_pool_wrapper" > #9 0x000000349f607851 in start_thread () from /lib64/libpthread.so.0 > No symbol table info available. > #10 0x000000349f2e890d in clone () from /lib64/libc.so.6 > No symbol table info available. > (gdb) > > > ---------------------------------------------- > > > > Please tell me if something else is needed in this bug report. > > > Regards, > > > Clement OUDOT. > > -- -- 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#7589) MDB nodesize issues
by hyc＠symas.com 12 Oct '13

12 Oct '13

h.b.furuseth(a)usit.uio.no wrote: > I wrote: >> OTOH if you add a bunch of slightly smaller nodes, mdb will put >> most of them in separate pages anyway without MDB_APPEND. > > ...because mdb_page_split() has been wasteful since 48ef27b6f5c804eca6a9 > "ITS#7385 fix mdb_page_split (again)". When a txn put()s ascending > keys with nodes of the same size, the new item goes in the fullest page. > > E.g. put data size 1010 with 'int' keys 1,2,3... to an MDB_INTEGERKEY > DB. As the txn progresses, (page: #key #key...) get distributed thus: > > Page 2: #1. > Page 2: #1 #2. > Page 2: #1 #2 #3. > Page 2: #1. Page 3: #2 #3 #4. > Page 2: #1. Page 3: #2. Page 5: #3 #4 #5. > Page 2: #1. Page 3: #2. Page 5: #3. Page 6: #4 #5 #6. > > 2/3 wasted space. Descending put() work better: > > Page 2: #6. > Page 2: #5 #6. > Page 2: #4 #5 #6. > Page 2: #3 #4. Page 3: #5 #6. > Page 2: #2 #3 #4. Page 3: #5 #6. > Page 2: #2 #1. Page 3: #5 #6. Page 5: #3 #4. > > Ascending put() with datasize 1348, so only 2 nodes fit in a page: > > Page 2: #1. > Page 2: #1 #2. > Page 2: #1. Page 3: #2 #3. > Page 2: #1. Page 3: #2. Page 5: #3 #4. > > Half of the space is wasted. Descending order does not help. > > page_split() cannot know which split is best in this case. But it'll > help to guess that the next put() key sometimes will be near this one, > and ensure that the node with the new key will be the smallest. That > will also avoid touching the old page when the nodes are that large, > since the "split" will keep all old nodes in the old page. Fixed now in mdb.master. On a large DB, the previous code used 3276587 pages in slapadd -q, and the new code uses 3272633 pages. It's only a 0.13% savings in this case, it seems the frequency of these insert patterns is quite rare. The runtime is also 1.1% faster going from real 41m35.8s user 50m57.6s sys 5m11.4s to real 41m1.7s user 50m25.8s sys 4m55.3s -- -- 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#7723) slapd crashes on multi core machines if a search request is *immediately* followed by an unbind
by hyc＠symas.com 11 Oct '13

11 Oct '13

hyc(a)symas.com wrote: > michael.vishchers(a)7p-group.com wrote: >> Full_Name: Michael Vishchers >> Version: 2.4.36 >> OS: RHEL 6.3 >> URL: ftp://ftp.openldap.org/incoming/ >> Submission from: (NULL) (109.41.86.33) >> >> >> The bug mentioned in ITS #7716 unfortunately still persists in 2.4.36. >> >> We now found a way to reproduce it: If you want anyone to spend time on this: Send the stack trace from the crash. Also send your slapd config, sample data, and the actual query used in your client. >> >> - make sure that threads can run freely (i.e., provide enough cpus) > >> - start slapd with the rwm overlay >> - run a client loop that >> -- binds as a valid user >> -- sends a valid search request that is *immediately* (i.e., don't wait for any >> answers) followed by an unbind request >> >> after several iterations (with 2.4.23 it was between 2 and 7, with 2.4.36 it was >> about 30) slapd crashes in malloc.c >> >> > > -- -- 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#7723) slapd crashes on multi core machines if a search request is *immediately* followed by an unbind
by hyc＠symas.com 11 Oct '13

11 Oct '13

michael.vishchers(a)7p-group.com wrote: > Full_Name: Michael Vishchers > Version: 2.4.36 > OS: RHEL 6.3 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (109.41.86.33) > > > The bug mentioned in ITS #7716 unfortunately still persists in 2.4.36. > > We now found a way to reproduce it: > > - make sure that threads can run freely (i.e., provide enough cpus) If your client loop is running as a single thread then the number of CPUs and running threads should be irrelevant. If the number of threads and CPUs matter then you're misusing the API. Closing this ITS. > - start slapd with the rwm overlay > - run a client loop that > -- binds as a valid user > -- sends a valid search request that is *immediately* (i.e., don't wait for any > answers) followed by an unbind request > > after several iterations (with 2.4.23 it was between 2 and 7, with 2.4.36 it was > about 30) slapd crashes in malloc.c > > -- -- 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#7724) Invalid FREE suspected in unbind.c
by hyc＠symas.com 11 Oct '13

11 Oct '13

michael.vishchers(a)7p-group.com wrote: > Full_Name: Michael Vishchers > Version: 2.4.36 > OS: RHEL 6.3 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (109.41.86.33) > > > This may be connected to ITS #7723: > > in unbind.c, there is new code (newer than 2.4.23, i.e.) that takes care not to > free the ld struct if some other thread is using it (line 82ff) > > Unfortunately, in line 102, after decrementing the ref count in this struct, > this struct is freed nonetheless. The struct is freed because it should only be used by one thread. Read draft-zeilenga-ldap-c-api-concurrency. Closing this ITS. -- -- 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#7720) 2.4.36 build failure on HP-UX
by h.b.furuseth＠usit.uio.no 11 Oct '13

11 Oct '13

On 2013-10-08 19:42, hyc(a)symas.com wrote: > Thanks for the report. Interesting, this should also have been flagged > as > illegal in gcc but wasn't. Fixed now in master. void* pointer arithmetic is a gcc extension, it's treated as char*. gcc warns about it if you use -pedantic or -Wpointer-arith. -- Hallvard

1 0

(ITS#7724) Invalid FREE suspected in unbind.c
by michael.vishchers＠7p-group.com 11 Oct '13

11 Oct '13

Full_Name: Michael Vishchers Version: 2.4.36 OS: RHEL 6.3 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (109.41.86.33) This may be connected to ITS #7723: in unbind.c, there is new code (newer than 2.4.23, i.e.) that takes care not to free the ld struct if some other thread is using it (line 82ff) Unfortunately, in line 102, after decrementing the ref count in this struct, this struct is freed nonetheless.

1 0

(ITS#7723) slapd crashes on multi core machines if a search request is *immediately* followed by an unbind
by michael.vishchers＠7p-group.com 11 Oct '13

11 Oct '13

Full_Name: Michael Vishchers Version: 2.4.36 OS: RHEL 6.3 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (109.41.86.33) The bug mentioned in ITS #7716 unfortunately still persists in 2.4.36. We now found a way to reproduce it: - make sure that threads can run freely (i.e., provide enough cpus) - start slapd with the rwm overlay - run a client loop that -- binds as a valid user -- sends a valid search request that is *immediately* (i.e., don't wait for any answers) followed by an unbind request after several iterations (with 2.4.23 it was between 2 and 7, with 2.4.36 it was about 30) slapd crashes in malloc.c

1 0

Re: (ITS#7710) contextCSN values not updated by internal non-replicated ops
by quanah＠zimbra.com 10 Oct '13

10 Oct '13

--On Thursday, October 10, 2013 11:22 AM +0000 michael(a)stroeder.com wrote: > On Thu, 10 Oct 2013 11:05:28 GMT hyc(a)symas.com wrote >> michael(a)stroeder.com wrote: >> > With current master and re24 which have the fix for this ITS I now see >> > seg faults in test023-refint test057-memberof-refint. >> >> Fixed now in master. > > Thanks. These tests are passing now. > > @Quanah: Would be nice if this last fix could be also ported to RE24. > Thanks in advance. Not particularly necessary to make requests like this. I read all ITS mail and commit traffic. --Quanah -- Quanah Gibson-Mount Architect - Server Zimbra Software, LLC -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#7694) cldap fails with IPv6 due to wrong size sockaddr
by stefw＠redhat.com 10 Oct '13

10 Oct '13

On 10.10.2013 13:59, Howard Chu wrote: > Stef Walter wrote: >> On 10.10.2013 12:59, Howard Chu wrote: >>> stefw(a)redhat.com wrote: >>>> Full_Name: Stef Walter >>>> Version: 2.4.35 >>>> OS: Fedora 19 >>>> Submission from: (NULL) (46.5.2.70) >>>> >>>> >>>> Connectionless LDAP (ie: cldap enabled with -DLDAP_CONNECTIONLESS) is >>>> broken for >>>> IPv6 for current versions of openldap. Tested with version 2.4.35 >>>> >>>> It's not clear if this ever worked properly. >>> >>> No, clearly not, the code was written and deprecated before IPv6 >>> existed. Nobody should be using this code today. >> >> Interesting. FWIW, the code is packaged by RHEL and Fedora, and is in >> use by several projects. > > Can you list any of these, offhand? The original spec, RFC1798, is long > obsoleted. There is no such thing as CLDAP in LDAPv3. Support in > OpenLDAP was first removed back in 2000. (commit > 25a9f7427ddc1b584a721ceb0e12690a96d3639e ) > Any apps using this must be quite ancient code and in serious need of a > rewrite. Well, there's still lots of libldap client code around to support LDAP over UDP. Guarded with LDAP_CONNECTIONLESS #defines, and one can use "cldap://xxxx" urls with ldap_initialize() and do basic cldap searches and so on. Windows Server is accessed via CLDAP during discovery. Although there is normative documentation for this, it's easier to understand via these descriptions: http://wiki.wireshark.org/MS-CLDAP https://fedorahosted.org/sssd/wiki/DesignDocs/ActiveDirectoryDNSSites#Sendi… So things like samba, IPA, realmd, adcli, and so on ... use and support cldap for talking with AD. I know Samba has reimplemented cldap but the others use libldap for this. Cheers, Stef

1 0

Re: (ITS#7694) cldap fails with IPv6 due to wrong size sockaddr
by hyc＠symas.com 10 Oct '13

10 Oct '13

Stef Walter wrote: > On 10.10.2013 12:59, Howard Chu wrote: >> stefw(a)redhat.com wrote: >>> Full_Name: Stef Walter >>> Version: 2.4.35 >>> OS: Fedora 19 >>> Submission from: (NULL) (46.5.2.70) >>> >>> >>> Connectionless LDAP (ie: cldap enabled with -DLDAP_CONNECTIONLESS) is >>> broken for >>> IPv6 for current versions of openldap. Tested with version 2.4.35 >>> >>> It's not clear if this ever worked properly. >> >> No, clearly not, the code was written and deprecated before IPv6 >> existed. Nobody should be using this code today. > > Interesting. FWIW, the code is packaged by RHEL and Fedora, and is in > use by several projects. Can you list any of these, offhand? The original spec, RFC1798, is long obsoleted. There is no such thing as CLDAP in LDAPv3. Support in OpenLDAP was first removed back in 2000. (commit 25a9f7427ddc1b584a721ceb0e12690a96d3639e ) Any apps using this must be quite ancient code and in serious need of a rewrite. -- -- 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#7694) cldap fails with IPv6 due to wrong size sockaddr
by stefw＠redhat.com 10 Oct '13

10 Oct '13

On 10.10.2013 12:59, Howard Chu wrote: > stefw(a)redhat.com wrote: >> Full_Name: Stef Walter >> Version: 2.4.35 >> OS: Fedora 19 >> Submission from: (NULL) (46.5.2.70) >> >> >> Connectionless LDAP (ie: cldap enabled with -DLDAP_CONNECTIONLESS) is >> broken for >> IPv6 for current versions of openldap. Tested with version 2.4.35 >> >> It's not clear if this ever worked properly. > > No, clearly not, the code was written and deprecated before IPv6 > existed. Nobody should be using this code today. Interesting. FWIW, the code is packaged by RHEL and Fedora, and is in use by several projects. > Even if it were to be used, the patch would break slapd; your > getnameinfo patch changes the format of the peername string. The format > of this string is not arbitrary, it's used in ACLs and the format is > documented in slapd.access(5). > > In the future, write patches that fix one single issue. Don't make > gratuitous changes, particularly if you haven't researched what you're > changing. Sorry bout that. Here's a new patch without the slapd change: ftp://ftp.openldap.org/incoming/stef-walter-131010.patch Cheers, Stef

1 0

Re: (ITS#7710) contextCSN values not updated by internal non-replicated ops
by michael＠stroeder.com 10 Oct '13

10 Oct '13

On Thu, 10 Oct 2013 11:05:28 GMT hyc(a)symas.com wrote > michael(a)stroeder.com wrote: > > With current master and re24 which have the fix for this ITS I now see seg > > faults in test023-refint test057-memberof-refint. > > Fixed now in master. Thanks. These tests are passing now. @Quanah: Would be nice if this last fix could be also ported to RE24. Thanks in advance. Ciao, Michael.

1 0

Re: (ITS#7710) contextCSN values not updated by internal non-replicated ops
by hyc＠symas.com 10 Oct '13

10 Oct '13

michael(a)stroeder.com wrote: > With current master and re24 which have the fix for this ITS I now see seg > faults in test023-refint test057-memberof-refint. Fixed now in master. -- -- 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#7694) cldap fails with IPv6 due to wrong size sockaddr
by hyc＠symas.com 10 Oct '13

10 Oct '13

stefw(a)redhat.com wrote: > Full_Name: Stef Walter > Version: 2.4.35 > OS: Fedora 19 > URL: ftp://ftp.openldap.org/incoming/stef-walter-130912.patch > Submission from: (NULL) (46.5.2.70) > > > Connectionless LDAP (ie: cldap enabled with -DLDAP_CONNECTIONLESS) is broken for > IPv6 for current versions of openldap. Tested with version 2.4.35 > > It's not clear if this ever worked properly. No, clearly not, the code was written and deprecated before IPv6 existed. Nobody should be using this code today. Even if it were to be used, the patch would break slapd; your getnameinfo patch changes the format of the peername string. The format of this string is not arbitrary, it's used in ACLs and the format is documented in slapd.access(5). In the future, write patches that fix one single issue. Don't make gratuitous changes, particularly if you haven't researched what you're changing. > Connections immediately fail with: > > ldap_search_ext: Can't contact LDAP server (-1) > > The reason for this is that the LDAP_CONNECTIONLESS buffers include a prefix > containing an address in a "struct sockaddr". However, struct sockaddr, is not a > concrete type. In particular struct sockaddr_in6 is longer than struct > sockaddr. > > Noted here: http://www.openldap.org/devel/gitweb.cgi?p=openldap.git;a=blob;f=libraries/… > > So this leads to failures when using IPv6 as the code assumes that the address > length is equal to sizeof (struct sockaddr). Seen here: > > http://www.openldap.org/devel/gitweb.cgi?p=openldap.git;a=blob;f=libraries/… > > Example command: > > $ ldapsearch -d -1 -LL -H 'cldap://[2620:52:0:2223::1:1]' -b '' -s base > '(&(DnsDomain=ad.baseos.qe)(NtVer=\06\00\00\00))' NetLogon > > Output will contain this: > > ldap_write: want=96 error=Invalid argument > > Which is the EINVAL resulting from bad value passed to sendto(). > > -- -- 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#7694) cldap fails with IPv6 due to wrong size sockaddr
by hyc＠symas.com 10 Oct '13

10 Oct '13

quanah(a)zimbra.com wrote: > --On Thursday, September 12, 2013 4:04 PM +0000 stefw(a)redhat.com wrote: > >>> 2.4.35 is not the current version of OpenLDAP, 2.4.36 is. There were >>> fixes to CLDAP made in 2.4.36. Please test against 2.4.36 and report >>> back, thanks. >> >> This patch is against master. >> >> However master cldap support is broken in additional ways, and I'll be >> filing further bugs/patches. > > Hi Stef, > > Thanks! In the future then, if it is an issue with the current 2.4 release > series still, you can just put RE24 as the version. ;) Then I won't spend > time trying to see if it's a known issue already fixed via the changes log. The CLDAP code is a remnant from pre-LDAPv3, there was no such thing as IPv6 when it was written, so no, this has never worked with IPv6. Who still uses CLDAP today? This code has no valid reason to exist any more. -- -- 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#7710) contextCSN values not updated by internal non-replicated ops
by michael＠stroeder.com 10 Oct '13

10 Oct '13

With current master and re24 which have the fix for this ITS I now see seg faults in test023-refint test057-memberof-refint.

1 0

Re: (ITS#7710) contextCSN values not updated by internal non-replicated ops
by michael＠stroeder.com 09 Oct '13

09 Oct '13

michael(a)stroeder.com wrote: > On Wed, 09 Oct 2013 08:13:24 -0700 Howard Chu <hyc(a)symas.com> wrote >> slapd already strips DSA-specific attributes before sending a syncrepl entry. >> memberOf is not marked in the schema as DSA-specific. This is working as >> designed. > > IIRC attribute 'memberOf' was replicated in former releases. So it was not > DSA-specific back then. > > Then the behaviour was changed in a more recent OpenLDAP release. Nowadays each > replica has to be configured with slapo-memberof performing *local* operations. > Therefore I'd argue that 'memberOf' should be marked DSA-specific now since the > *local* configuration is significant for its content. > Note that there is no formal specification for attribute 'memberOf' at all. > > I have deployments where most users are member of more than 10 groups, > sometimes more than 20. So not sending 'memberOf' could save quite a lot of > network traffic. > > What are your objections against marking 'memberOf' as DSA-specific? > > (I vaguely remember this being discussed before without result though.) Additionally consider partial replication where only a subset of group entries is present on a certain consumer. One would not want to have 'memberOf' point to group entries not really existing on that consumer. => 'memberOf' is definitely DSA-specific. Ciao, Michael.

1 0

Re: (ITS#7710) contextCSN values not updated by internal non-replicated ops
by michael＠stroeder.com 09 Oct '13

09 Oct '13

On Wed, 09 Oct 2013 08:13:24 -0700 Howard Chu <hyc(a)symas.com> wrote > slapd already strips DSA-specific attributes before sending a syncrepl entry. > memberOf is not marked in the schema as DSA-specific. This is working as > designed. IIRC attribute 'memberOf' was replicated in former releases. So it was not DSA-specific back then. Then the behaviour was changed in a more recent OpenLDAP release. Nowadays each replica has to be configured with slapo-memberof performing *local* operations. Therefore I'd argue that 'memberOf' should be marked DSA-specific now since the *local* configuration is significant for its content. Note that there is no formal specification for attribute 'memberOf' at all. I have deployments where most users are member of more than 10 groups, sometimes more than 20. So not sending 'memberOf' could save quite a lot of network traffic. What are your objections against marking 'memberOf' as DSA-specific? (I vaguely remember this being discussed before without result though.) Ciao, Michael.

1 0

Re: (ITS#7710) contextCSN values not updated by internal non-replicated ops
by hyc＠symas.com 09 Oct '13

09 Oct '13

Michael Ströder wrote: > On Wed, 9 Oct 2013 14:05:52 GMT hyc(a)symas.com wrote >> Howard Chu wrote: >>> Michael Ströder wrote: >>>> But now I see this during initial refresh phase of second server: >>>> >>>> send_ldap_result: err=20 matched="" text="modify/add: memberOf: value #0 >>>> already exists" >>>> >>>> Is that expected? >>> >>> Not seeing that with your testcase. >>> >> Ah, I see it now. Yes, it's normal; memberOf on the provider already added >> the relevant values. The consumer receives a group entry and performs the >> same set of memberof updates, which are redundant at that point. It's >> harmless. > > Hmm, wouldn't it be reasonable to strip those attributes marked as > non-replication attrs when generating syncrepl search results at the provider? > (Even if consumer asks for attrs=*,+) slapd already strips DSA-specific attributes before sending a syncrepl entry. memberOf is not marked in the schema as DSA-specific. This is working as designed. -- -- 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#7710) contextCSN values not updated by internal non-replicated ops
by michael＠stroeder.com 09 Oct '13

09 Oct '13

On Wed, 9 Oct 2013 14:05:52 GMT hyc(a)symas.com wrote > Howard Chu wrote: > > Michael Ströder wrote: > >> But now I see this during initial refresh phase of second server: > >> > >> send_ldap_result: err=20 matched="" text="modify/add: memberOf: value #0 > >> already exists" > >> > >> Is that expected? > > > > Not seeing that with your testcase. > > > Ah, I see it now. Yes, it's normal; memberOf on the provider already added > the relevant values. The consumer receives a group entry and performs the > same set of memberof updates, which are redundant at that point. It's > harmless. Hmm, wouldn't it be reasonable to strip those attributes marked as non-replication attrs when generating syncrepl search results at the provider? (Even if consumer asks for attrs=*,+) Ciao, Michael.

1 0

Re: (ITS#7710) contextCSN values not updated by internal non-replicated ops
by hyc＠symas.com 09 Oct '13

09 Oct '13

Howard Chu wrote: > Michael Ströder wrote: >> On Wed, 09 Oct 2013 05:01:40 -0700 Howard Chu <hyc(a)symas.com> wrote >> >>> michael(a)stroeder.com wrote: >>>> I've updated the test data with LDIF files and a README describing the LDAP >>>> operations to perform: >>>> >>>> http://www.stroeder.com/temp/openldap-testbed-its7710.tar.bz2 >>>> >>>> I consider this to be a serious issue which could be the cause for other >>>> replication issues including dead-locks we're experiencing. (Maybe there >>>> are similar issues in slapo-refint since dead-locks in our deployment >>>> arised when moving entries into different subtree.) >>> >>> Thanks, fixed now in master. Looks like refint may have run into the same >>> issue, also patched in master. >> >> contextCSN values are correct now. >> >> But now I see this during initial refresh phase of second server: >> >> send_ldap_result: err=20 matched="" text="modify/add: memberOf: value #0 >> already exists" >> >> Is that expected? > > Not seeing that with your testcase. > Ah, I see it now. Yes, it's normal; memberOf on the provider already added the relevant values. The consumer receives a group entry and performs the same set of memberof updates, which are redundant at that point. It's harmless. -- -- 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#7710) contextCSN values not updated by internal non-replicated ops
by hyc＠symas.com 09 Oct '13

09 Oct '13

Michael Ströder wrote: > On Wed, 09 Oct 2013 05:01:40 -0700 Howard Chu <hyc(a)symas.com> wrote > >> michael(a)stroeder.com wrote: >>> I've updated the test data with LDIF files and a README describing the LDAP >>> operations to perform: >>> >>> http://www.stroeder.com/temp/openldap-testbed-its7710.tar.bz2 >>> >>> I consider this to be a serious issue which could be the cause for other >>> replication issues including dead-locks we're experiencing. (Maybe there >>> are similar issues in slapo-refint since dead-locks in our deployment >>> arised when moving entries into different subtree.) >> >> Thanks, fixed now in master. Looks like refint may have run into the same >> issue, also patched in master. > > contextCSN values are correct now. > > But now I see this during initial refresh phase of second server: > > send_ldap_result: err=20 matched="" text="modify/add: memberOf: value #0 > already exists" > > Is that expected? Not seeing that with your testcase. -- -- 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#7717) Sudden memory increase leading to Master LDAP crash
by marco.pizzoli＠gmail.com 09 Oct '13

09 Oct '13

--089e0115ff765de02a04e84f36b1 Content-Type: text/plain; charset=ISO-8859-1 I think I faced this same problem last week during a massive load of users (300K +) using a single ldapadd execution. My db "exploded" (MDB_MAP_FULL) after about 120K users populated. The main issue was related to the size of the db than to the actual memory allocated. It grew up to over 12GB before reaching the limit of my file system. But with memory-mapped files topics are close, I suppose. Curious enough, populating the same db from a full syncrepl led the db to grew to only (more or less) 500MB. As additional information, this server was part of a 5-node multi-master. And after the ldapadd the db -size was very different on each of the servers being part of the cluster. I cannot share any conf, I'm sorry. Marco --089e0115ff765de02a04e84f36b1 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr"><div><div><div>I think I faced this same problem last week= during a massive load of users (300K +) using a single ldapadd execution.<= br>My db "exploded" (MDB_MAP_FULL) after about 120K users populat= ed. The main issue was related to the size of the db than to the actual memory = allocated. It grew up to over 12GB before reaching the limit of my file sys= tem. But with memory-mapped files topics are close, I suppose. </div> Curious enough, populating the same db from a full syncrepl led the db to g= rew to only (more or less) 500MB. As additional information, this se= rver was part of a 5-node multi-master. And after the ldapadd the db -size = was very different on each of the servers being part of the cluster. </div>I cannot share any conf, I'm sorry. </div>Marco </div> --089e0115ff765de02a04e84f36b1--

1 0

Re: (ITS#7710) contextCSN values not updated by internal non-replicated ops
by michael＠stroeder.com 09 Oct '13

09 Oct '13

On Wed, 09 Oct 2013 05:01:40 -0700 Howard Chu <hyc(a)symas.com> wrote > michael(a)stroeder.com wrote: > > I've updated the test data with LDIF files and a README describing the LDAP > > operations to perform: > > > > http://www.stroeder.com/temp/openldap-testbed-its7710.tar.bz2 > > > > I consider this to be a serious issue which could be the cause for other > > replication issues including dead-locks we're experiencing. (Maybe there > > are similar issues in slapo-refint since dead-locks in our deployment > > arised when moving entries into different subtree.) > > Thanks, fixed now in master. Looks like refint may have run into the same > issue, also patched in master. contextCSN values are correct now. But now I see this during initial refresh phase of second server: send_ldap_result: err=20 matched="" text="modify/add: memberOf: value #0 already exists" Is that expected? Ciao, Michael. 52555576 syncrepl_entry: rid=002 LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_ADD) 52555576 syncrepl_entry: rid=002 inserted UUID b5736b9e-c52f-1032-99c4-31a68f008587 52555576 mdb_idl_fetch_key: [3bec70f1] 52555576 send_ldap_result: err=0 matched="" text="" 52555576 syncrepl_entry: rid=002 be_search (0) 52555576 syncrepl_entry: rid=002 cn=replicas,ou=groups,dc=example,dc=com 52555576 ==> mdb_add: cn=replicas,ou=groups,dc=example,dc=com 52555576 mdb_idl_insert_keys: b [f4f2ead9] 52555576 mdb_idl_insert_keys: b [8f2b53e8] 52555576 mdb_idl_insert_keys: b [cb13035d] 52555576 mdb_idl_insert_keys: b [c14a3e76] 52555576 mdb_idl_insert_keys: b [3bec70f1] 52555576 mdb_idl_insert_keys: b 52555576 send_ldap_result: err=0 matched="" text="" 52555576 mdb_modify: cn=slapd-1,ou=sys,dc=example,dc=com 52555576 mdb_modify_internal: add memberOf 52555576 dnMatch 0 "cn=replicas,ou=groups,dc=example,dc=com" "cn=replicas,ou=groups,dc=example,dc=com" 52555576 mdb_modify_internal: 20 modify/add: memberOf: value #0 already exists 52555576 send_ldap_result: err=20 matched="" text="modify/add: memberOf: value #0 already exists" 52555576 conn=-1 op=0: memberof_value_modify DN="cn=slapd-1,ou=sys,dc=example,dc=com" add memberOf="cn=replicas,ou=groups,dc=example,dc=com" failed err=20 52555576 mdb_modify: cn=slapd-2,ou=sys,dc=example,dc=com 52555576 mdb_modify_internal: add memberOf 52555576 dnMatch 0 "cn=replicas,ou=groups,dc=example,dc=com" "cn=replicas,ou=groups,dc=example,dc=com" 52555576 mdb_modify_internal: 20 modify/add: memberOf: value #0 already exists 52555576 send_ldap_result: err=20 matched="" text="modify/add: memberOf: value #0 already exists" 52555576 conn=-1 op=0: memberof_value_modify DN="cn=slapd-2,ou=sys,dc=example,dc=com" add memberOf="cn=replicas,ou=groups,dc=example,dc=com" failed err=20 52555576 syncrepl_entry: rid=002 be_add cn=replicas,ou=groups,dc=example,dc=com (0) 52555576 do_syncrep2: rid=002 LDAP_RES_INTERMEDIATE - REFRESH_DELETE 52555576 do_syncrep2: rid=002 cookie=rid=002,sid=001,csn=20131009130900.890770Z#000000#001#000000 52555576 slap_queue_csn: queing 0x7fd79c10c200 20131009130900.890770Z#000000#001#000000 52555576 base_candidates: base: "dc=example,dc=com" (0x00000001) 52555576 send_ldap_result: err=0 matched="" text="" 52555576 mdb_modify: dc=example,dc=com 52555576 mdb_modify_internal: replace contextCSN 52555576 send_ldap_result: err=0 matched="" text="" 52555576 slap_graduate_commit_csn: removing 0x7fd79c10c170 20131009130900.890770Z#000000#001#000000

1 0

Re: (ITS#7710) contextCSN values not updated by internal non-replicated ops
by hyc＠symas.com 09 Oct '13

09 Oct '13

michael(a)stroeder.com wrote: > I've updated the test data with LDIF files and a README describing the LDAP > operations to perform: > > http://www.stroeder.com/temp/openldap-testbed-its7710.tar.bz2 > > I consider this to be a serious issue which could be the cause for other > replication issues including dead-locks we're experiencing. (Maybe there are > similar issues in slapo-refint since dead-locks in our deployment arised when > moving entries into different subtree.) Thanks, fixed now in master. Looks like refint may have run into the same issue, also patched in master. -- -- 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#7722) Assertion failure on MDB_NEXT of existing cursor following delete
by hyc＠symas.com 09 Oct '13

09 Oct '13

dw(a)botanicus.net wrote: > Full_Name: David Wilson > Version: bf0e97aa0e9 @ git://gitorious.org/mdb/mdb.git > OS: Linux > URL: https://gist.github.com/dw/ba100e59b42ed5fccb67/raw/f25b08334e6956d9558bb05… > Submission from: (NULL) (178.238.153.20) > > > The attached cursor-del-break.c exhibits an assertion failure after successfully > deleting 1246 256-byte records from a set of 2048. This hammers the case where > one cursor is used to iterate, while a temporary cursor is used to delete the > record currently pointed to by the first cursor. > > cursor-del-break: src/py-lmdb/lib/mdb.c:5025: mdb_cursor_next: Assertion > `((((mp)->mp_flags) & (0x02)) == (0x02))' failed. > > > Thanks for the report, fixed now in mdb.master. -- -- 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#7722) Assertion failure on MDB_NEXT of existing cursor following delete
by dw＠botanicus.net 08 Oct '13

08 Oct '13

Full_Name: David Wilson Version: bf0e97aa0e9 @ git://gitorious.org/mdb/mdb.git OS: Linux URL: https://gist.github.com/dw/ba100e59b42ed5fccb67/raw/f25b08334e6956d9558bb05… Submission from: (NULL) (178.238.153.20) The attached cursor-del-break.c exhibits an assertion failure after successfully deleting 1246 256-byte records from a set of 2048. This hammers the case where one cursor is used to iterate, while a temporary cursor is used to delete the record currently pointed to by the first cursor. cursor-del-break: src/py-lmdb/lib/mdb.c:5025: mdb_cursor_next: Assertion `((((mp)->mp_flags) & (0x02)) == (0x02))' failed.

1 0

(ITS#7721) slapo-lastbind patch to allow authTimestamp updates to be forwarded via updateref
by ck＠cksoft.de 08 Oct '13

08 Oct '13

Full_Name: Christian Kratzer Version: HEAD OS: CentOS 6.4 URL: http://www.cksoft.de/paste/34e81be96925e5ea28daea7da2b84b09049f7f3d/0001-Al… Submission from: (NULL) (2003:41:c010:8001:8de8:2245:8dd7:5c5e) I, Christian Kratzer, 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. I have adapted code from slapo-ppolicy to slapo-lastbind from contrib to allow forwarding of updates to authTimestamp via updateref and chaining. The patch introduces a new lastbind_forward_updates (olcLastBindForwardUpdates ) boolean parameter to slapo-lastbind that has the same semantics as ppolicy_forward_updates (olcPPolicyForwardUpdates) in slapo-ppolicy. I have a 2 master, 2 slave syncrepl test setup which chaining from the slaves to the masters ( to one of them to be precise ). - Bind on master1 results in authTimestamp getting replicated to master2 and both slaves. - Bind on slave1 with olcLastBindForwardUpdates=TRUE results in authTimestamp getting forwarded to the master with updateRef and chaining and replicated from there. Please review especially the one from ppolicy I did not merge marked with TODO. Greetings Christian

1 0

Re: (ITS#7720) 2.4.36 build failure on HP-UX
by hyc＠symas.com 08 Oct '13

08 Oct '13

bugs-openldap(a)vendor.thewrittenword.com wrote: > Full_Name: Albert Chin > Version: 2.4.36 > OS: HP-UX 11.23/PA > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (69.67.212.94) Thanks for the report. Interesting, this should also have been flagged as illegal in gcc but wasn't. Fixed now in master. > While trying to build 2.4.36 on HP-UX 11.23/PA with the HP C compiler: > cc -z +O2 +Olit=all +Ofltacc +Oentrysched +Odataprefetch +Onolimit > -I../../../include -I../../../include -I.. -I./.. -I./../../../libraries/liblmdb > -I/opt/TWWfsw/tcpwrap/include -I/opt/TWWfsw/libsasl21/include > -I/opt/TWWfsw/libopenssl10/include -I/opt/TWWfsw/libdb47/include -c tools.c -o > tools.o > cc: "tools.c", line 1384: error 1539: Cannot do arithmetic with pointers to > objects of unknown size. > cc: "tools.c", line 1410: error 1539: Cannot do arithmetic with pointers to > objects of unknown size. > gmake[3]: *** [tools.lo] Error 1 > gmake[3]: Leaving directory `/opt/build/openldap-2.4.36/servers/slapd/back-mdb' > > ... > > cc -z +O2 +Olit=all +Ofltacc +Oentrysched +Odataprefetch +Onolimit > -I../../../include -I../../../include -I.. -I./.. -I./../../../libraries/liblmdb > -I/opt/TWWfsw/tcpwrap/include -I/opt/TWWfsw/libsasl21/include > -I/opt/TWWfsw/libopenssl10/include -I/opt/TWWfsw/libdb47/include -c dn2id.c -o > dn2id.o > cc: "dn2id.c", line 168: error 1539: Cannot do arithmetic with pointers to > objects of unknown size. > cc: "dn2id.c", line 181: error 1539: Cannot do arithmetic with pointers to > objects of unknown size. > cc: "dn2id.c", line 249: error 1539: Cannot do arithmetic with pointers to > objects of unknown size. > cc: "dn2id.c", line 262: error 1539: Cannot do arithmetic with pointers to > objects of unknown size. > cc: "dn2id.c", line 402: error 1539: Cannot do arithmetic with pointers to > objects of unknown size. > cc: "dn2id.c", line 798: error 1539: Cannot do arithmetic with pointers to > objects of unknown size. > gmake[3]: *** [dn2id.lo] Error 1 > gmake[3]: Leaving directory `/opt/build/openldap-2.4.36/servers/slapd/back-mdb' > > -- -- 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#7720) 2.4.36 build failure on HP-UX
by bugs-openldap＠vendor.thewrittenword.com 08 Oct '13

08 Oct '13

Full_Name: Albert Chin Version: 2.4.36 OS: HP-UX 11.23/PA URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (69.67.212.94) While trying to build 2.4.36 on HP-UX 11.23/PA with the HP C compiler: cc -z +O2 +Olit=all +Ofltacc +Oentrysched +Odataprefetch +Onolimit -I../../../include -I../../../include -I.. -I./.. -I./../../../libraries/liblmdb -I/opt/TWWfsw/tcpwrap/include -I/opt/TWWfsw/libsasl21/include -I/opt/TWWfsw/libopenssl10/include -I/opt/TWWfsw/libdb47/include -c tools.c -o tools.o cc: "tools.c", line 1384: error 1539: Cannot do arithmetic with pointers to objects of unknown size. cc: "tools.c", line 1410: error 1539: Cannot do arithmetic with pointers to objects of unknown size. gmake[3]: *** [tools.lo] Error 1 gmake[3]: Leaving directory `/opt/build/openldap-2.4.36/servers/slapd/back-mdb' ... cc -z +O2 +Olit=all +Ofltacc +Oentrysched +Odataprefetch +Onolimit -I../../../include -I../../../include -I.. -I./.. -I./../../../libraries/liblmdb -I/opt/TWWfsw/tcpwrap/include -I/opt/TWWfsw/libsasl21/include -I/opt/TWWfsw/libopenssl10/include -I/opt/TWWfsw/libdb47/include -c dn2id.c -o dn2id.o cc: "dn2id.c", line 168: error 1539: Cannot do arithmetic with pointers to objects of unknown size. cc: "dn2id.c", line 181: error 1539: Cannot do arithmetic with pointers to objects of unknown size. cc: "dn2id.c", line 249: error 1539: Cannot do arithmetic with pointers to objects of unknown size. cc: "dn2id.c", line 262: error 1539: Cannot do arithmetic with pointers to objects of unknown size. cc: "dn2id.c", line 402: error 1539: Cannot do arithmetic with pointers to objects of unknown size. cc: "dn2id.c", line 798: error 1539: Cannot do arithmetic with pointers to objects of unknown size. gmake[3]: *** [dn2id.lo] Error 1 gmake[3]: Leaving directory `/opt/build/openldap-2.4.36/servers/slapd/back-mdb'

1 0

Re: (ITS#7719) configure delayed response time
by quanah＠zimbra.com 08 Oct '13

08 Oct '13

--On Tuesday, October 08, 2013 3:59 AM +0000 rashtrapathy(a)gmail.com wrote: > Full_Name: Rashtrapathy > Version: 2.4.36 > OS: GNU/Linux > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (72.163.217.105) > > > Dear All, > > I want my openldap server to send a delayed searchResEntry & > searchResDone for any searchRequest. > > Where i need to change the configuration file for this delayed response? The ITS system is for reporting bugs, not asking usage questions. I would however suggest you look at contrib modules like the noop module to see about how to insert a delay into the slapd stack. This ITS will be closed. --Quanah -- Quanah Gibson-Mount Architect - Server Zimbra Software, LLC -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#7718) mdb_cursor_del() segfault on last entry
by hyc＠symas.com 08 Oct '13

08 Oct '13

matthew.monaco(a)colorado.edu wrote: > Full_Name: Matthew Monaco > Version: mdb-0.9.8, mdb-d327a36 > OS: linux-3.11.4 > URL: http://pastie.org/8385142 > Submission from: (NULL) (128.138.64.206) > > > I'm getting a segfault with MDB when using mdb_cursor_del() on the last entry in > the database. Example on pastie.org [1]. Thanks for the report and testcase, fixed now in mdb.master/ > > [1] http://pastie.org/8385142 > > -- -- 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#7719) configure delayed response time
by rashtrapathy＠gmail.com 07 Oct '13

07 Oct '13

Full_Name: Rashtrapathy Version: 2.4.36 OS: GNU/Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (72.163.217.105) Dear All, I want my openldap server to send a delayed searchResEntry & searchResDone for any searchRequest. Where i need to change the configuration file for this delayed response? Please help me ASAP. Thanks, Rash.

1 0

(ITS#7718) mdb_cursor_del() segfault on last entry
by matthew.monaco＠colorado.edu 07 Oct '13

07 Oct '13

Full_Name: Matthew Monaco Version: mdb-0.9.8, mdb-d327a36 OS: linux-3.11.4 URL: http://pastie.org/8385142 Submission from: (NULL) (128.138.64.206) I'm getting a segfault with MDB when using mdb_cursor_del() on the last entry in the database. Example on pastie.org [1]. [1] http://pastie.org/8385142

1 0

Re: (ITS#7717) Sudden memory increase leading to Master LDAP crash
by quanah＠zimbra.com 07 Oct '13

07 Oct '13

--On Thursday, October 03, 2013 1:14 PM +0000 marcon.bruno(a)free.fr wrote: > The problem is very easy to replay : one master and one slave are > sufficient. Then run 9 windows with a script adding an entry and > modifying an entry. Please provide full configuration details. --Quanah -- Quanah Gibson-Mount Architect - Server Zimbra Software, LLC -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#7710) contextCSN values not updated by internal non-replicated ops
by ck＠cksoft.de 07 Oct '13

07 Oct '13

Hi Michael, On Sun, 6 Oct 2013, michael(a)stroeder.com wrote: > I've updated the test data with LDIF files and a README describing the LDAP > operations to perform: > > http://www.stroeder.com/temp/openldap-testbed-its7710.tar.bz2 > > I consider this to be a serious issue which could be the cause for other > replication issues including dead-locks we're experiencing. (Maybe there are > similar issues in slapo-refint since dead-locks in our deployment arised when > moving entries into different subtree.) I can confirm that I can see the same bug with your testcase. It seems that restarting the second slapd instance fixes the contextCSN issue just because it scans all it's entries and does the right thing. Even a slapcat of both directories shows the issue. Things that I find disturbing: After applying the group membership the member dn: gets it's memberOf attribute updated accordingly. But the entryCSN stays unchanged. Entry before applying group membership: # michael, users, example.com dn: uid=michael,ou=users,dc=example,dc=com uid: michael objectClass: account objectClass: simpleSecurityObject userPassword:: dGVzdHNlY3JldA== description: test entryCSN: 20131006193757.912740Z#000000#002#000000 Entry after applying group membership is obviously updated but still has the same entryCSN: # michael, users, example.com dn: uid=michael,ou=users,dc=example,dc=com uid: michael objectClass: account objectClass: simpleSecurityObject userPassword:: dGVzdHNlY3JldA== memberOf: cn=admins,ou=groups,dc=example,dc=com memberOf: cn=testgroup1,ou=groups,dc=example,dc=com description: test entryCSN: 20131006193757.912740Z#000000#002#000000 I can also confirm the subsequent contextCSN mismatch. I too consider this a serious issue. If I read Howards reply correctly and from what I see in the source code of the memberOf overlay the strategy here seems to be not to replicate the side effect of adding the memberOf: entry. OpenLDAP relies on the side effect happening on the replicas through the same codepath when the member: attribute in the group gets updated through replication. This sounds very similar to the difference between: 1. statement replication in sql databases ala mysql 2. log based replication ala postgresql OpenLDAP is doing 1. here while 2. would perhaps have been the better option. I understand turning this around is propably too late at this point in time. Looks like we will just have to work out the bugs the hard way. I am using slapo-lastbind and slapo-ppolicy extensively in my current project and will keep my eyes open for similar issues resulting from not replicating the side effects that these overlays produce. Greetings Christian -- Christian Kratzer CK Software GmbH Email: ck(a)cksoft.de Wildberger Weg 24/2 Phone: +49 7032 893 997 - 0 D-71126 Gaeufelden Fax: +49 7032 893 997 - 9 HRB 245288, Amtsgericht Stuttgart Web: http://www.cksoft.de/ Geschaeftsfuehrer: Christian Kratzer

1 0

Re: (ITS#7710) contextCSN values not updated by internal non-replicated ops
by michael＠stroeder.com 07 Oct '13

07 Oct '13

Christian Kratzer wrote: > This sounds very similar to the difference between: > > 1. statement replication in sql databases ala mysql > > 2. log based replication ala postgresql > > OpenLDAP is doing 1. here while 2. would perhaps have been the better option. >From my understanding 2. is OpenLDAP's delta-syncrepl. Ciao, Michael.

1 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs