- openldap-bugs - openldap.org

Re: (ITS#9162) dbMaxSize property does not as expected
by quanah＠symas.com 03 Feb '20

03 Feb '20

--On Monday, February 3, 2020 9:49 AM +0000 pasumarthivijaykumar(a)gmail.com wrote: > Full_Name: Vijay Kumar > Version: 2.4.48 > OS: windows > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (103.204.96.6) Please stop filing ITSes, as you clearly are working with an already broken database. This ITS will be closed. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

Re: (ITS#8988) Undefined Behavior in slapadd
by hyc＠symas.com 03 Feb '20

03 Feb '20

openldap-technical(a)kolttonen.fi wrote: > This message is in MIME format. The first part should be readable text, > while the remaining parts are likely unreadable without MIME-aware tools. > > ---1463811718-806940296-1580670508=:196090 > Content-Type: text/plain; charset=ISO-8859-15 > Content-Transfer-Encoding: 8BIT > > > Hello, > > On Sat, 8 Jun 2019, hyc(a)symas.com wrote: > >> The gcc/clang folks have their heads up their asses. They've >> deliberately misinterpreted the spec claiming undefined behaviors are >> forbidden, supposedly to enable essential optimizations. Most of which >> only apply to obscure corner cases in compiler benchmark suites, that >> nobody in the real world ever benefits from. > > I realize this thread is very old, but Jeff and the C compiler folks are > right. All C programs that invoke undefined behavior are illegal C > programs and should be fixed. > > Posix threads are well-defined by Posix standards, so calling them > "undefined behaviour" is not a valid argument. No. The POSIX spec is *not* a part of the C spec - yet it is still valid. Which simply proves the point that just because something is not defined in the C spec does not make it invalid. The compiler guys are idiots for taking this position. -- -- 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#9162) dbMaxSize property does not as expected
by pasumarthivijaykumar＠gmail.com 03 Feb '20

03 Feb '20

Full_Name: Vijay Kumar Version: 2.4.48 OS: windows URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (103.204.96.6) if i try to set the value from property, i dont understand from where the value 1406945XXXXXX and getting set. Please check the details mentioned. 1) olcDbMaxSize: 10485760 >mdb_stat.exe -rne "C:\testMaxSize2\mdb\data.mdb" Environment Info Map address: 0000000000000000 Map size: 140694549168128 Page size: 4096 Max pages: 34349255168 Number of pages used: 2 Last transaction ID: 0 Max readers: 126 Number of readers used: 0 Reader Table Status (no active readers) >slapd.exe -T add -F ..\slapd.d -l backupContent.ldif 5e37a371 mdb_db_open: database "o=abc.net" cannot be opened: ⁿ (87). Restore from backup! 5e37a371 backend_startup_one (type=mdb, suffix="o=abc.net"): bi_db_open failed! (87) slap_startup failed 2) olcDbMaxSize: 1048576 >slapd.exe -T add -F ..\slapd.d -l backupContent.ldif 5e37a5ef mdb_db_open: database "o=abc.net" cannot be opened: ⁿ (87). Restore from backup! 5e37a5ef backend_startup_one (type=mdb, suffix="o=abc.net"): bi_db_open failed! (87) slap_startup failed >mdb_stat.exe -rne "C:\testMaxSize2\mdb\data.mdb" Environment Info Map address: 0000000000000000 Map size: 140694539730944 Page size: 4096 Max pages: 34349252864 Number of pages used: 2 Last transaction ID: 0 Max readers: 126 Number of readers used: 0 Reader Table Status (no active readers) 3) olcDbMaxSize: 1024 >slapd.exe -T add -F ..\slapd.d -l backupContent.ldif 5e37a7fd mdb_db_open: database "o=abc.net" cannot be opened: ⁿ (87). Restore from backup! 5e37a7fd backend_startup_one (type=mdb, suffix="o=abc.net"): bi_db_open failed! (87) slap_startup failed >mdb_stat.exe -rne "C:\testMaxSize2\mdb\data.mdb" Environment Info Map address: 0000000000000000 Map size: 140694538683392 Page size: 4096 Max pages: 34349252608 Number of pages used: 2 Last transaction ID: 0 Max readers: 126 Number of readers used: 0 Reader Table Status (no active readers) 5) olcDbMaxSize 10 >slapd.exe -T add -F ..\slapd.d -l backupContent.ldif 5e37a92b mdb_db_open: database "o=abc.net" cannot be opened: ⁿ (87). Restore from backup! 5e37a92b backend_startup_one (type=mdb, suffix="o=abc.net"): bi_db_open failed! (87) slap_startup failed >mdb_stat.exe -rne "C:\testMaxSize2\mdb\data.mdb" Environment Info Map address: 0000000000000000 Map size: 140694538682378 Page size: 4096 Max pages: 34349252608 Number of pages used: 2 Last transaction ID: 0 Max readers: 126 Number of readers used: 0 Reader Table Status (no active readers) 6) olcDbMaxSize 1 >slapd.exe -T add -F ..\slapd.d -l backupContent.ldif 5e37a92b mdb_db_open: database "o=abc.net" cannot be opened: ⁿ (87). Restore from backup! 5e37a92b backend_startup_one (type=mdb, suffix="o=abc.net"): bi_db_open failed! (87) slap_startup failed >mdb_stat.exe -rne "C:\testMaxSize2\mdb\data.mdb" Environment Info Map address: 0000000000000000 Map size: 140694538682369 Page size: 4096 Max pages: 34349252608 Number of pages used: 2 Last transaction ID: 0 Max readers: 126 Number of readers used: 0 Reader Table Status (no active readers) 7) olcDbMaxSize not set >mdb_stat.exe -rne "C:\testMaxSize2\mdb\data.mdb" Environment Info Map address: 0000000000000000 Map size: 1048576 Page size: 4096 Max pages: 256 Number of pages used: 254 Last transaction ID: 104 Max readers: 126 Number of readers used: 0 Reader Table Status (no active readers)

1 0

Re: (ITS#8988) Undefined Behavior in slapadd
by openldap-technical＠kolttonen.fi 02 Feb '20

02 Feb '20

This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. ---1463811718-326687762-1580674674=:196994 Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 8BIT On Sun, 2 Feb 2020, openldap-technical(a)kolttonen.fi wrote: > I realize this thread is very old, but Jeff and the C compiler folks are > right. All C programs that invoke undefined behavior are illegal C > programs and should be fixed. > > Posix threads are well-defined by Posix standards, so calling them > "undefined behaviour" is not a valid argument. To make it clear that UB in C programs is horrible, let me provide a real world example of UB: Cyrus IMAPD had an unnoticed dormant strcpy() related UB bug for several years. You see, the manual page of strcpy() says that the src and dst strings must not overlap, or else the C program invokes UB. For many years, Cyrus operated correctly even though the src and dst strings *did* overlap in one part of their database code. UB of course allows this behaviour too. The reason was because GNU libc folks had written their strcpy() implementation in such a way that breaking the contract of having non-overlapping strings did not cause any problems. Then, years later, GNU libc folks deciced to optimize (or otherwise change) their strcpy() implementation. Now the new implementation punished all UB invokers, and we saw our Cyrus mailbox database slowly but surely getting corrupted. It is indeed shocking to hear that LMDB implementation invokes UB. GCC and Clang could change their behaviour tomorrow, and LMDB could get corrupted, crash or whatever. And certainly the blame would be on LMDB code, not the compiler writers. Best Regards, Jokke Hämäläinen ---1463811718-326687762-1580674674=:196994--

1 0

Re: (ITS#8988) Undefined Behavior in slapadd
by openldap-technical＠kolttonen.fi 02 Feb '20

02 Feb '20

This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. ---1463811718-806940296-1580670508=:196090 Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 8BIT Hello, On Sat, 8 Jun 2019, hyc(a)symas.com wrote: > The gcc/clang folks have their heads up their asses. They've > deliberately misinterpreted the spec claiming undefined behaviors are > forbidden, supposedly to enable essential optimizations. Most of which > only apply to obscure corner cases in compiler benchmark suites, that > nobody in the real world ever benefits from. I realize this thread is very old, but Jeff and the C compiler folks are right. All C programs that invoke undefined behavior are illegal C programs and should be fixed. Posix threads are well-defined by Posix standards, so calling them "undefined behaviour" is not a valid argument. Best regards, Jokke Hämäläinen ---1463811718-806940296-1580670508=:196090--

1 0

Re: (ITS#9161) Codespell report for "OpenLDAP" (on fossies.org)
by quanah＠symas.com 30 Jan '20

30 Jan '20

--On Thursday, January 30, 2020 8:48 PM +0000 Jens.Schleusener(a)fossies.org wrote: > Full_Name: Jens Schleusener > Version: 2.4.49 > OS: (irrelevant) > URL: https://fossies.org/linux/misc/openldap/codespell.html > Submission from: (NULL) (2003:cf:71a:5655:2905:9b7a:fef1:ab74) > > > The FOSS server fossies.org - also supporting "OpenLDAP" - offers a new > feature "Source code misspelling reports": This is very nice, thank you. Definitely some items in here that need fixing. Regards, Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

(ITS#9161) Codespell report for "OpenLDAP" (on fossies.org)
by Jens.Schleusener＠fossies.org 30 Jan '20

30 Jan '20

Full_Name: Jens Schleusener Version: 2.4.49 OS: (irrelevant) URL: https://fossies.org/linux/misc/openldap/codespell.html Submission from: (NULL) (2003:cf:71a:5655:2905:9b7a:fef1:ab74) The FOSS server fossies.org - also supporting "OpenLDAP" - offers a new feature "Source code misspelling reports": https://fossies.org/features.html#codespell Such reports are normally only generated on request, but as Fossies administrator I have just created (for testing purposes) an analysis for the new "OpenLDAP" release 2.4.49: https://fossies.org/linux/misc/openldap/codespell.html That version-independent (not linked) URL should redirect always to the last report (if available), so currently to https://fossies.org/linux/misc/openldap-2.4.49.tgz/codespell.html Although after a first review some obviously wrong matches ("false positives") are already filtered out (ignored) please inform me if you find more of them so that I can force a new improved check if applicable. Just for information there are also two supplemental pages https://fossies.org/linux/misc/openldap/codespell_conf.html showing some used "codespell" configurations and https://fossies.org/linux/misc/openldap/codespell_fps.html showing all resulting obvious "false positives". If appropriate, additional reports for the current or also future development versions (these in a special "test" folder) could be willingly created.

1 0

Re: (ITS#9159) mdb_put failed: MDB_MAP_FULL: Environment mapsize limit reached(-30792)
by quanah＠symas.com 30 Jan '20

30 Jan '20

--On Thursday, January 30, 2020 2:38 PM +0530 Vijay Kumar <pasumarthivijaykumar(a)gmail.com> wrote: > > > Thank you Quanah, > > I am not familiar about your process of subscribing to lists. > I have gone though the documentation to understand the mdb size for > windows. Can you please share me the documentation you might referring? The information on the mailing lists and how to subscribe is directly accessible from the main page for the OpenLDAP project: <https://www.openldap.org/> Click on the link that says "Mailing lists" Click on the link that says "OpenLDAP-technical" to get to: <https://www.openldap.org/lists/mm/listinfo/openldap-technical> The man page for slapd-mdb(5) has all of the documentation: <https://www.openldap.org/software/man.cgi?query=slapd-mdb&apropos=0&sektion…> Again, the default MAXIMUM size for an MDB database is 10MB if the maxsize parameter is not set. You *must* set this value to something larger. Regards, Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

Re: (ITS#9159) mdb_put failed: MDB_MAP_FULL: Environment mapsize limit reached(-30792)
by pasumarthivijaykumar＠gmail.com 30 Jan '20

30 Jan '20

--0000000000008f08ba059d57cdcc Content-Type: text/plain; charset="UTF-8" Thank you Quanah, I am not familiar about your process of subscribing to lists. I have gone though the documentation to understand the mdb size for windows. Can you please share me the documentation you might referring? Thank you. Regards, Vijay Kumar On Thu, Jan 30, 2020 at 12:46 PM Quanah Gibson-Mount <quanah(a)symas.com> wrote: > > > --On Thursday, January 30, 2020 6:09 AM +0000 > pasumarthivijaykumar(a)gmail.com wrote: > > > --00000000000025b743059d554b79 > > Content-Type: text/plain; charset="UTF-8" > > Content-Transfer-Encoding: quoted-printable > > > > Thanks for your reply I do know that info for windows also is it the > > same.? I am unable to use stats tool also. > > As I already stated, the maxsize parameter specifies the maximum size the > database can reach. > > > As I don=E2=80=99t see any reply from our many mails to > > openldap-technical(a)openldap.org I have created this case to clarify. > > > The openldap-technical list is only open to subscribers, if you want to > post to it you must subscribe first. > > > > Why don=E2=80=99t you forward the query to the concerned team instead > > closi= ng. > > Your query would not be forwarded because you failed to read and/or > understand the documentation. This system is for bug reports only. > > > No reply to us.! > > I did reply. This is clearly shown in the ITS. > > > Please let us know answer to solve a issue.! > > > I already provided you the answer in my earlier response. Set an > approprate maxsize setting, the default of 10MB is clearly too low. > > Regards, > Quanah > > > -- > > Quanah Gibson-Mount > Product Architect > Symas Corporation > Packaged, certified, and supported LDAP solutions powered by OpenLDAP: > <http://www.symas.com> > -- Thanks & Regards, Vijay Kumar *+91-94944 44009* --0000000000008f08ba059d57cdcc Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr"><div>Thank you Quanah,</div><div><br></div>I am not famili= ar about your process of subscribing to lists.<div>I have gone though the d= ocumentation to understand the mdb size for windows. Can you please share m= e the documentation you might referring?</div><div><br></div><div>Thank you= .</div><div><br></div><div>Regards,</div><div>Vijay Kumar<br><div><br></div= ></div></div><br><div class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail= _attr">On Thu, Jan 30, 2020 at 12:46 PM Quanah Gibson-Mount <<a href=3D"= mailto:quanah@symas.com">quanah(a)symas.com</a>> wrote:<br></div><blockquo= te class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px = solid rgb(204,204,204);padding-left:1ex"><br> <br> --On Thursday, January 30, 2020 6:09 AM +0000 <br> <a href=3D"mailto:pasumarthivijaykumar@gmail.com" target=3D"_blank">pasumar= thivijaykumar(a)gmail.com</a> wrote:<br> <br> > --00000000000025b743059d554b79<br> > Content-Type: text/plain; charset=3D"UTF-8"<br> > Content-Transfer-Encoding: quoted-printable<br> ><br> > Thanks for your reply I do know that info for windows also is it the<b= r> > same.? I am unable to use stats tool also.<br> <br> As I already stated, the maxsize parameter specifies the maximum size the <= br> database can reach.<br> <br> > As I don=3DE2=3D80=3D99t see any reply from our many mails to<br> > <a href=3D"mailto:openldap-technical@openldap.org" target=3D"_blank">o= penldap-technical(a)openldap.org</a> I have created this case to clarify.<br> <br> <br> The openldap-technical list is only open to subscribers, if you want to <br= > post to it you must subscribe first.<br> <br> <br> > Why don=3DE2=3D80=3D99t you forward the query to the concerned team in= stead<br> > closi=3D ng.<br> <br> Your query would not be forwarded because you failed to read and/or <br> understand the documentation.=C2=A0 This system is for bug reports only.<br= > <br> > No reply to us.!<br> <br> I did reply.=C2=A0 This is clearly shown in the ITS.<br> <br> > Please let us know answer to solve a issue.!<br> <br> <br> I already provided you the answer in my earlier response.=C2=A0 Set an <br> approprate maxsize setting, the default of 10MB is clearly too low.<br> <br> Regards,<br> Quanah<br> <br> <br> --<br> <br> Quanah Gibson-Mount<br> Product Architect<br> Symas Corporation<br> Packaged, certified, and supported LDAP solutions powered by OpenLDAP:<br> <<a href=3D"http://www.symas.com" rel=3D"noreferrer" target=3D"_blank">h= ttp://www.symas.com</a>><br> </blockquote></div><br clear=3D"all"><div><br></div>-- <br><div dir=3D"ltr"= class=3D"gmail_signature"><div dir=3D"ltr"><div><div><font color=3D"#00006= 6">Thanks & Regards,</font></div> <div>=C2=A0</div> <div><font face=3D"arial black,sans-serif">Vijay Kumar</font></div> <div><strong>+91-94944 44009</strong></div></div></div></div> --0000000000008f08ba059d57cdcc--

1 0

Re: (ITS#9159) mdb_put failed: MDB_MAP_FULL: Environment mapsize limit reached(-30792)
by quanah＠symas.com 30 Jan '20

30 Jan '20

--On Thursday, January 30, 2020 6:09 AM +0000 pasumarthivijaykumar(a)gmail.com wrote: > --00000000000025b743059d554b79 > Content-Type: text/plain; charset="UTF-8" > Content-Transfer-Encoding: quoted-printable > > Thanks for your reply I do know that info for windows also is it the > same.? I am unable to use stats tool also. As I already stated, the maxsize parameter specifies the maximum size the database can reach. > As I don=E2=80=99t see any reply from our many mails to > openldap-technical(a)openldap.org I have created this case to clarify. The openldap-technical list is only open to subscribers, if you want to post to it you must subscribe first. > Why don=E2=80=99t you forward the query to the concerned team instead > closi= ng. Your query would not be forwarded because you failed to read and/or understand the documentation. This system is for bug reports only. > No reply to us.! I did reply. This is clearly shown in the ITS. > Please let us know answer to solve a issue.! I already provided you the answer in my earlier response. Set an approprate maxsize setting, the default of 10MB is clearly too low. Regards, Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

Re: (ITS#9159) mdb_put failed: MDB_MAP_FULL: Environment mapsize limit reached(-30792)
by pasumarthivijaykumar＠gmail.com 30 Jan '20

30 Jan '20

--00000000000025b743059d554b79 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Thanks for your reply I do know that info for windows also is it the same.? I am unable to use stats tool also. As I don=E2=80=99t see any reply from our many mails to openldap-technical(a)openldap.org I have created this case to clarify. Why don=E2=80=99t you forward the query to the concerned team instead closi= ng. No reply to us.! Please let us know answer to solve a issue.! On Wed, Jan 29, 2020 at 4:24 PM <openldap-its(a)openldap.org> wrote: > > *** THIS IS AN AUTOMATICALLY GENERATED REPLY *** > > Thanks for your report to the OpenLDAP Issue Tracking System. Your > report has been assigned the tracking number ITS#9159. > > One of our support engineers will look at your report in due course. > Note that this may take some time because our support engineers > are volunteers. They only work on OpenLDAP when they have spare > time. > > If you need to provide additional information in regards to your > issue report, you may do so by replying to this message. Note that > any mail sent to openldap-its(a)openldap.org with (ITS#9159) > in the subject will automatically be attached to the issue report. > > mailto:openldap-its@openldap.org?subject=3D(ITS#9159) > > You may follow the progress of this report by loading the following > URL in a web browser: > http://www.OpenLDAP.org/its/index.cgi?findid=3D9159 > > Please remember to retain your issue tracking number (ITS#9159) > on any further messages you send to us regarding this report. If > you don't then you'll just waste our time and yours because we > won't be able to properly track the report. > > Please note that the Issue Tracking System is not intended to > be used to seek help in the proper use of OpenLDAP Software. > Such requests will be closed. > > OpenLDAP Software is user supported. > http://www.OpenLDAP.org/support/ > > -------------- > Copyright 1998-2007 The OpenLDAP Foundation, All Rights Reserved. > > --=20 Thanks & Regards, Vijay Kumar *+91-94944 44009* --00000000000025b743059d554b79 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr"><pre style=3D"background-image:initial;background-position= :initial;background-size:initial;background-repeat:initial;background-origi= n:initial;background-clip:initial;margin:0in 0in 0.0001pt;font-size:10pt;fo= nt-family:"Courier New""><span style=3D"color:black">Thanks for y= our reply I do know that info for windows also is it the same.? I am unable= to use stats tool also.</span></pre><pre style=3D"background-image:initial= ;background-position:initial;background-size:initial;background-repeat:init= ial;background-origin:initial;background-clip:initial;margin:0in 0in 0.0001= pt;font-size:10pt;font-family:"Courier New"">=C2=A0</pre><pre sty= le=3D"background-image:initial;background-position:initial;background-size:= initial;background-repeat:initial;background-origin:initial;background-clip= :initial;margin:0in 0in 0.0001pt;font-size:10pt;font-family:"Courier N= ew""><span style=3D"color:black">As I don=E2=80=99t see any reply from= our many mails to <a href=3D"mailto:openldap-technical@openldap.org" style= =3D"color:rgb(5,99,193)">openldap-technical(a)openldap.org</a> I have created= this case to clarify.</span></pre><pre style=3D"background-image:initial;b= ackground-position:initial;background-size:initial;background-repeat:initia= l;background-origin:initial;background-clip:initial;margin:0in 0in 0.0001pt= ;font-size:10pt;font-family:"Courier New""><span style=3D"color:b= lack">=C2=A0</span></pre><pre style=3D"background-image:initial;background-= position:initial;background-size:initial;background-repeat:initial;backgrou= nd-origin:initial;background-clip:initial;margin:0in 0in 0.0001pt;font-size= :10pt;font-family:"Courier New""><span style=3D"color:black">Why = don=E2=80=99t you forward the query to the concerned team instead closing.<= /span></pre><pre style=3D"background-image:initial;background-position:init= ial;background-size:initial;background-repeat:initial;background-origin:ini= tial;background-clip:initial;margin:0in 0in 0.0001pt;font-size:10pt;font-fa= mily:"Courier New""><span style=3D"color:black">=C2=A0</span></pr= e><pre style=3D"background-image:initial;background-position:initial;backgr= ound-size:initial;background-repeat:initial;background-origin:initial;backg= round-clip:initial;margin:0in 0in 0.0001pt;font-size:10pt;font-family:&quot= ;Courier New""><span style=3D"color:black">No reply to us.!</span></pr= e><pre style=3D"background-image:initial;background-position:initial;backgr= ound-size:initial;background-repeat:initial;background-origin:initial;backg= round-clip:initial;margin:0in 0in 0.0001pt;font-size:10pt;font-family:&quot= ;Courier New""><span style=3D"color:black">=C2=A0</span></pre><pre sty= le=3D"background-image:initial;background-position:initial;background-size:= initial;background-repeat:initial;background-origin:initial;background-clip= :initial;margin:0in 0in 0.0001pt;font-size:10pt;font-family:"Courier N= ew""><span style=3D"color:black">Please let us know answer to solve a = issue.!</span></pre></div><br><div class=3D"gmail_quote"><div dir=3D"ltr" c= lass=3D"gmail_attr">On Wed, Jan 29, 2020 at 4:24 PM <<a href=3D"mailto:o= penldap-its(a)openldap.org">openldap-its(a)openldap.org</a>> wrote:<br></div= ><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border= -left:1px solid rgb(204,204,204);padding-left:1ex"><br> *** THIS IS AN AUTOMATICALLY GENERATED REPLY ***<br> <br> Thanks for your report to the OpenLDAP Issue Tracking System.=C2=A0 Your<br= > report has been assigned the tracking number ITS#9159.<br> <br> One of our support engineers will look at your report in due course.<br> Note that this may take some time because our support engineers<br> are volunteers.=C2=A0 They only work on OpenLDAP when they have spare<br> time.<br> <br> If you need to provide additional information in regards to your<br> issue report, you may do so by replying to this message.=C2=A0 Note that<br= > any mail sent to <a href=3D"mailto:openldap-its@openldap.org" target=3D"_bl= ank">openldap-its(a)openldap.org</a> with (ITS#9159)<br> in the subject will automatically be attached to the issue report.<br> <br> =C2=A0 =C2=A0 =C2=A0 =C2=A0 mailto:<a href=3D"mailto:openldap-its@openldap.= org" target=3D"_blank">openldap-its(a)openldap.org</a>?subject=3D(ITS#9159)<b= r> <br> You may follow the progress of this report by loading the following<br> URL in a web browser:<br> =C2=A0 =C2=A0 <a href=3D"http://www.OpenLDAP.org/its/index.cgi?findid=3D915= 9" rel=3D"noreferrer" target=3D"_blank">http://www.OpenLDAP.org/its/index.c= gi?findid=3D9159</a><br> <br> Please remember to retain your issue tracking number (ITS#9159)<br> on any further messages you send to us regarding this report.=C2=A0 If<br> you don't then you'll just waste our time and yours because we<br> won't be able to properly track the report.<br> <br> Please note that the Issue Tracking System is not intended to<br> be used to seek help in the proper use of OpenLDAP Software.<br> Such requests will be closed.<br> <br> OpenLDAP Software is user supported.<br> =C2=A0 =C2=A0 =C2=A0 =C2=A0 <a href=3D"http://www.OpenLDAP.org/support/" re= l=3D"noreferrer" target=3D"_blank">http://www.OpenLDAP.org/support/</a><br> <br> --------------<br> Copyright 1998-2007 The OpenLDAP Foundation, All Rights Reserved.<br> <br> </blockquote></div><br clear=3D"all"><div><br></div>-- <br><div dir=3D"ltr"= class=3D"gmail_signature"><div dir=3D"ltr"><div><div><font color=3D"#00006= 6">Thanks & Regards,</font></div> <div>=C2=A0</div> <div><font face=3D"arial black,sans-serif">Vijay Kumar</font></div> <div><strong>+91-94944 44009</strong></div></div></div></div> --00000000000025b743059d554b79--

1 0

Re: (ITS#9159) mdb_put failed: MDB_MAP_FULL: Environment mapsize limit reached(-30792)
by quanah＠symas.com 29 Jan '20

29 Jan '20

--On Wednesday, January 29, 2020 10:54 AM +0000 pasumarthivijaykumar(a)gmail.com wrote: > Full_Name: Vijay Kumar > Version: 2.4.48 > OS: Windows > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (103.204.96.6) > > > I am not setting any map size for openldap with mdb configuration in > windows. Hello, Usage questions need to be sent to the openldap-technical(a)openldap.org email discussion list. The ITS system is for bug reports only. However, I would suggest carefully reading the slapd-mdb(5) man page, and consider the fact that the maxsize parameter determines what the allowed maximum size of the database is. If you do not set the parameter, it limits the database to 10MB in size (The default value). Regards, Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

Re: (ITS#9160) Out-of-memory handling issues
by ondra＠openldap.org 29 Jan '20

29 Jan '20

On Wed, Jan 29, 2020 at 11:46:23AM +0000, Howard Chu wrote: > ondra(a)openldap.org wrote: >> --- malloc_check.cocci --- >> @@ >> expression E, E1; >> identifier ch_alloc =~ "^(ch|slap)_.*alloc.*"; >> identifier f =~ "(?i).*alloc.*"; >> identifier foo; >> @@ >> >> E = >> ( >> ch_alloc > > ch_malloc always aborts if it fails, therefore failure checks are not used. > >> | >> entry_alloc >> | >> attr_alloc >> | > > These rely on ch_malloc, therefore failure checks are not used. > >> metaconn_alloc >> | >> asyncmeta_conn_alloc >> | >> CompAlloc /* component matching has massively bitrotted */ >> | >> * f Which is why only the last one is actually used - '*'. >> )(...); >> ... when != E = E1 >> when != E == NULL >> when != E != NULL >> ( >> E->foo >> | >> E[...] >> | >> *(E) >> ) >> --- malloc_check.cocci --- -- Ondřej Kuzník Senior Software Engineer Symas Corporation http://www.symas.com Packaged, certified, and supported LDAP solutions powered by OpenLDAP

1 0

Re: (ITS#9160) Out-of-memory handling issues
by hyc＠symas.com 29 Jan '20

29 Jan '20

ondra(a)openldap.org wrote: > Full_Name: Ondrej Kuznik > Version: re24/master > OS: > URL: > Submission from: (NULL) (212.159.69.225) > > > A look at the code highlights a few places where *alloc responses are used > unchecked. > > The following semantic patch is a good starting point. Currently it lists 87 > sites most of which probably need adjusting. > > --- malloc_check.cocci --- > @@ > expression E, E1; > identifier ch_alloc =~ "^(ch|slap)_.*alloc.*"; > identifier f =~ "(?i).*alloc.*"; > identifier foo; > @@ > > E = > ( > ch_alloc ch_malloc always aborts if it fails, therefore failure checks are not used. > | > entry_alloc> | > attr_alloc > | These rely on ch_malloc, therefore failure checks are not used. > metaconn_alloc > | > asyncmeta_conn_alloc > | > CompAlloc /* component matching has massively bitrotted */ > | > * f > )(...); > ... when != E = E1 > when != E == NULL > when != E != NULL > ( > E->foo > | > E[...] > | > *(E) > ) > --- malloc_check.cocci --- > > Patches coming soon. > > -- -- 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#9160) Out-of-memory handling issues
by ondra＠openldap.org 29 Jan '20

29 Jan '20

Full_Name: Ondrej Kuznik Version: re24/master OS: URL: Submission from: (NULL) (212.159.69.225) A look at the code highlights a few places where *alloc responses are used unchecked. The following semantic patch is a good starting point. Currently it lists 87 sites most of which probably need adjusting. --- malloc_check.cocci --- @@ expression E, E1; identifier ch_alloc =~ "^(ch|slap)_.*alloc.*"; identifier f =~ "(?i).*alloc.*"; identifier foo; @@ E = ( ch_alloc | entry_alloc | attr_alloc | metaconn_alloc | asyncmeta_conn_alloc | CompAlloc /* component matching has massively bitrotted */ | * f )(...); ... when != E = E1 when != E == NULL when != E != NULL ( E->foo | E[...] | *(E) ) --- malloc_check.cocci --- Patches coming soon.

1 0

(ITS#9159) mdb_put failed: MDB_MAP_FULL: Environment mapsize limit reached(-30792)
by pasumarthivijaykumar＠gmail.com 29 Jan '20

29 Jan '20

Full_Name: Vijay Kumar Version: 2.4.48 OS: Windows URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (103.204.96.6) I am not setting any map size for openldap with mdb configuration in windows. It throws me an error as mentioned below 5e315f30 mdb_id2entry_put: mdb_put failed: MDB_MAP_FULL: Environment mapsize limit reached(-30792) "cn=azrbasisschema.xsd,cn=nl.ciz.awbz.webservice.awbztransformaties.aanvraag_2_io31_transformatie,cn=method sets,o=system,cn=abc,cn=defaultinst,o=abc.net" 5e315f30 conn=1000 op=8 RESULT tag=105 err=80 text=entry store failed 5e315f30 slap_graduate_commit_csn: removing 0000006519FF99A0 20200129103216.169110Z#000000#000#000000 can you please let me know what could be the issue.? I checked the memory used by customer; file system 30GB available out of 200GB, RAM is 24GB. all the way i see suggestions on linux olxDbMaxsize but for windows we dont set that.

1 0

Re: (ITS#9157) return additional error code information when OPT_X_TLS_NEWCTX fails
by shawn.michael.mckinney＠gmail.com 27 Jan '20

27 Jan '20

In one of our test envs, had the path wrong in replication config for = encryption artifacts: *** Conf excerpt: *** syncrepl =E2=80=A6 tls_key=3D/opt/symas/etc/openldap/file-name.pem *** Which gives generic error: *** Log Trace: *** an 27 17:25:17 sapz1a slapd[6203]: slapd starting =E2=80=A6 TLS context initialization failed (-1) Jan 27 17:25:17 hostname slapd[6203]: do_syncrepl: rid=3D031 rc -1 = retrying (4 retries left) *** Would have been helpful for the message to specify which artifact = wasn=E2=80=99t found, the line number of the config, or some other way = of narrowing the problem. =E2=80=94 Shawn

1 0

(ITS#9157) return additional error code information when OPT_X_TLS_NEWCTX fails
by tagrain＠gmail.com 24 Jan '20

24 Jan '20

Full_Name: Thomas Grainger Version: libldap-2.4-2 OS: Ubuntu URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (62.60.6.23) when setting OPT_X_TLS_NEWCTX after an invalid OPT_X_TLS_CACERTFILE libldap returns a generic error code would it be possible to pass the underlying TLS library's error code instead or in addition? https://github.com/python-ldap/python-ldap/issues/55#issuecomment-577831055

1 0

(ITS#9156) latest ppolicy draft support
by ondra＠openldap.org 24 Jan '20

24 Jan '20

Full_Name: Ondrej Kuznik Version: master OS: URL: https://github.com/mistotebe/openldap/tree/ppolicy10 Submission from: (NULL) (212.159.69.225) There have been a few iterations of the ppolicy behera draft and it would be useful to support (some) of the documented features. The following are coming: - pwdGraceExpiry - pwdMaxLength - pwdStartTime and pwdEndTime - pwdMinDelay and pwdMaxDelay (as a soft-lockout, contingent with other implementations based on an informal survey during latest LDAPCon) - pwdMaxIdle (and moving the relevant parts of lastbind overlay into slapd code as it is a shared dependency of a few things now) - the ability to store per-policy arguments to check_password() - updates/fixes to the draft that should have been identified before some of the above were proposed (mostly typos and ASN.1 schema updates)

1 0

Re: (ITS#9155) LMDB: List of spill pages leaks after transaction
by hyc＠symas.com 23 Jan '20

23 Jan '20

babayants.alexander(a)gmail.com wrote: > Full_Name: Alexander Babayants > Version: LMDB 0.9.24 > OS: Linux > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (188.170.78.53) > > > Hi! > > ASAN shows that the list of spill pages is not freed after transaction: Thanks for the report. Fixed now in mdb.master and mdb.RE/0.9 > ================================================================= > ==test==13046==ERROR: LeakSanitizer: detected memory leaks > > Direct leak of 20971376 byte(s) in 1 object(s) allocated from: > #0 0x4bcbb2 in realloc (test+0x4bcbb2) > #1 0x7f067ef5ed59 in mdb_midl_grow liblmdb/src/midl.c:135:8 > #2 0x7f067ef5ec83 in mdb_midl_append liblmdb/src/midl.c:162:7 > #3 0x7f067ef4456b in mdb_page_spill liblmdb/src/mdb.c:2077:13 > #4 0x7f067ef3960b in mdb_cursor_put liblmdb/src/mdb.c:6640:14 > #5 0x7f067ef5106c in mdb_put liblmdb/src/mdb.c:9027:7 > #6 0x4ec674 in main test.c:28:14 > #7 0x7f067b46d544 in __libc_start_main (/lib64/libc.so.6+0x22544) > > SUMMARY: AddressSanitizer: 20971376 byte(s) leaked in 1 allocation(s). > > Reproducible on LMDB 0.9.24 with the following code (anything doing > long write transaction will trigger this): > #include "lmdb.h" > > int main(int argc,char * argv[]) > { > int rc; > MDB_env *env; > MDB_dbi dbi; > MDB_val key, data; > MDB_txn *txn; > int kval; > char sval[1024] = {0}; // fine to fill with zeroes > > rc = mdb_env_create(&env); > rc = mdb_env_set_mapsize(env, 10ULL * 1024 * 1024 * 1024); // 10 GiB > rc = mdb_env_open(env, "./testdb", 0, 0664); > rc = mdb_txn_begin(env, NULL, 0, &txn); > rc = mdb_dbi_open(txn, NULL, 0, &dbi); > > key.mv_size = sizeof(int); > key.mv_data = &kval; > data.mv_size = sizeof(sval); > data.mv_data = sval; > > for (kval = 0; kval < 100'000'000; ++kval) { > rc = mdb_put(txn, dbi, &key, &data, 0); > } > rc = mdb_txn_commit(txn); > > mdb_dbi_close(env, dbi); > mdb_env_close(env); > return 0; > } > >>From my point of view the leak looks benign (=does not lead to > database corruption or such), but I didn't dive deep enough in LMDB > internals to be completely certain about that. > > Regards, > Alexander Babayants. > > -- -- 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#9126) add: pwdChangedTime leads to seg fault
by ondra＠mistotebe.net 23 Jan '20

23 Jan '20

On Mon, Jan 13, 2020 at 09:35:18PM +0000, michael(a)stroeder.com wrote: > This still happens with current RE24 snapshot. > > Is more information needed to address this? Hi, had a look at it and a proposed patch is in a branch in my GitHub repo: https://github.com/mistotebe/openldap/tree/its9126 Let me know if this fixes the issue for you. As far as I have been able to figure out, the database content generated by ppolicy until now was inconsistent with the schema (normalised value was missing) and existing values will still cause the crash to happen. A fix is to replace the affected values or export/reload the database. Thanks, -- Ondřej Kuzník Senior Software Engineer Symas Corporation http://www.symas.com Packaged, certified, and supported LDAP solutions powered by OpenLDAP

1 0

(ITS#9155) LMDB: List of spill pages leaks after transaction
by babayants.alexander＠gmail.com 23 Jan '20

23 Jan '20

Full_Name: Alexander Babayants Version: LMDB 0.9.24 OS: Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (188.170.78.53) Hi! ASAN shows that the list of spill pages is not freed after transaction: ================================================================= ==test==13046==ERROR: LeakSanitizer: detected memory leaks Direct leak of 20971376 byte(s) in 1 object(s) allocated from: #0 0x4bcbb2 in realloc (test+0x4bcbb2) #1 0x7f067ef5ed59 in mdb_midl_grow liblmdb/src/midl.c:135:8 #2 0x7f067ef5ec83 in mdb_midl_append liblmdb/src/midl.c:162:7 #3 0x7f067ef4456b in mdb_page_spill liblmdb/src/mdb.c:2077:13 #4 0x7f067ef3960b in mdb_cursor_put liblmdb/src/mdb.c:6640:14 #5 0x7f067ef5106c in mdb_put liblmdb/src/mdb.c:9027:7 #6 0x4ec674 in main test.c:28:14 #7 0x7f067b46d544 in __libc_start_main (/lib64/libc.so.6+0x22544) SUMMARY: AddressSanitizer: 20971376 byte(s) leaked in 1 allocation(s). Reproducible on LMDB 0.9.24 with the following code (anything doing long write transaction will trigger this): #include "lmdb.h" int main(int argc,char * argv[]) { int rc; MDB_env *env; MDB_dbi dbi; MDB_val key, data; MDB_txn *txn; int kval; char sval[1024] = {0}; // fine to fill with zeroes rc = mdb_env_create(&env); rc = mdb_env_set_mapsize(env, 10ULL * 1024 * 1024 * 1024); // 10 GiB rc = mdb_env_open(env, "./testdb", 0, 0664); rc = mdb_txn_begin(env, NULL, 0, &txn); rc = mdb_dbi_open(txn, NULL, 0, &dbi); key.mv_size = sizeof(int); key.mv_data = &kval; data.mv_size = sizeof(sval); data.mv_data = sval; for (kval = 0; kval < 100'000'000; ++kval) { rc = mdb_put(txn, dbi, &key, &data, 0); } rc = mdb_txn_commit(txn); mdb_dbi_close(env, dbi); mdb_env_close(env); return 0; } >From my point of view the leak looks benign (=does not lead to database corruption or such), but I didn't dive deep enough in LMDB internals to be completely certain about that. Regards, Alexander Babayants.

1 0

Re: (ITS#9154) RFE: Number of entries in MDB database in cn=monitor
by michael＠stroeder.com 18 Jan '20

18 Jan '20

On 1/18/20 1:54 PM, Howard Chu wrote: > michael(a)stroeder.com wrote: >> The number of entries could be added there as attribute 'olmMDBEntries' or >> similar. > > Added in git master Great! Thank you. Any chance to see it in RE24? At least the back-port patch seems to work smoothly in my local test environment. Ciao, Michael.

1 0

Re: (ITS#9154) RFE: Number of entries in MDB database in cn=monitor
by hyc＠symas.com 18 Jan '20

18 Jan '20

michael(a)stroeder.com wrote: > Full_Name: Michael Str.der > Version: master > OS: > URL: > Submission from: (NULL) (213.240.182.99) > > > As a system engineer I want to see the number of entries within a mdb database > in the monitoring (e.g. to alarm unusual fast changes due to false deletions). > > While one can use mdb_stat or other custom scripts to monitor the number of > entries of the id2e sub-DB this requires read access to the MDB environment. But > for security reasons this should be avoided. > > olmMDBDatabase entries in cn=monitor already have attributes for MDB page > counts. > The number of entries could be added there as attribute 'olmMDBEntries' or > similar. Added in git 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#9154) RFE: Number of entries in MDB database in cn=monitor
by michael＠stroeder.com 17 Jan '20

17 Jan '20

Full_Name: Michael Str.der Version: master OS: URL: Submission from: (NULL) (213.240.182.99) As a system engineer I want to see the number of entries within a mdb database in the monitoring (e.g. to alarm unusual fast changes due to false deletions). While one can use mdb_stat or other custom scripts to monitor the number of entries of the id2e sub-DB this requires read access to the MDB environment. But for security reasons this should be avoided. olmMDBDatabase entries in cn=monitor already have attributes for MDB page counts. The number of entries could be added there as attribute 'olmMDBEntries' or similar.

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs