- openldap-bugs - openldap.org

(ITS#9033) Computer Object
by jgbuenaventura＠gmail.com 13 Jun '19

13 Jun '19

Full_Name: JP Buenaventura Version: 2.4.45 OS: Rhel 6 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (222.127.115.105) Hi, I am trying to add a computer/network device (windows, linux, routers) in Openldap, but i cannot find a specific, schema/objectclass/attribute for that. Any advice? Thanks! JP

1 0

Re: (ITS#9032) need to create custom attributes in openldap schema
by ryan＠nardis.ca 08 Jun '19

08 Jun '19

Hello Suresh, The ITS is for reporting bugs, not for usage questions. For support, please write to the openldap-technical(a)openldap.org mailing list. See https://www.openldap.org/support/ for more details. This ITS will be closed. Thank you, Ryan.

1 0

(ITS#9032) need to create custom attributes in openldap schema
by sureshd＠nihontechnology.com 08 Jun '19

08 Jun '19

Full_Name: Suresh Dhayalan Version: 1.2.2 OS: ubuntu 18.6 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (164.164.10.1) Dear sir, I need to create custom schema attributes, in my AWS cloud I am using ubuntu 18.6. I will create additional attributes to my project related apart from in build attributes, so kindly send me the steps to create my custom attributes. Regards, D Suresh

1 0

Re: (ITS#8988) Undefined Behavior in slapadd
by hyc＠symas.com 08 Jun '19

08 Jun '19

Jeffrey Walton wrote: > On Sat, Jun 8, 2019 at 3:47 AM Howard Chu <hyc(a)symas.com> wrote: >> >> Jeffrey Walton wrote: >>> On Fri, Jun 7, 2019 at 2:37 PM Howard Chu <hyc(a)symas.com> wrote: >>>> >>>> Jeffrey Walton wrote: >>>>> On Fri, Jun 7, 2019 at 10:08 AM Howard Chu <hyc(a)symas.com> wrote: >>>>>> >>>>>> Jeffrey Walton wrote: >>>>>>> On Fri, Jun 7, 2019 at 9:59 AM Howard Chu <hyc(a)symas.com> wrote: >>>>>>>> >>>>>>>> noloader(a)gmail.com wrote: >>>>>>>>> On Fri, Jun 7, 2019 at 9:32 AM Howard Chu <hyc(a)symas.com> wrote: >>>>>>>>>> >>>>>>>>>> noloader(a)gmail.com wrote: >>>>>>>>>> ... >>>>>>>>>>> I encourage OpenLDAP to fix the undefined behavior. OpenLDAP is an >>>>>>>>>>> important project, and the undefined behavior is causing too many >>>>>>>>>>> tangential problems. >>>>>>>>>> >>>>>>>>>> Undefined behavior is not a bug, nor is it prohibited by the C spec. It is a necessary >>>>>>>>>> part of the language for its intended use as a system programming language, writing >>>>>>>>>> machine-specific programs. Anyone who says it is prohibited by the spec is wrong. >>>>>>>>> >>>>>>>>> I don't believe this is correct. >>>>>>>>> >>>>>>>>> Maybe you are thinking of implementation defined behavior? >>>>>>>> >>>>>>>> That would apply to how a particular compiler implementation treats some piece of code. >>>>>>>> Whether a CPU supports unaligned access is machine-defined. Since our code is already >>>>>>>> properly ifdef'd for the machines which do or don't support it, the fact that this is >>>>>>>> "non-portable" is not an issue. >>>>>>> >>>>>>> The undefined behavior is causing OpenLDAP to fail testing. >>>>>>> >>>>>>> Worse, it is causing test failures in programs and libraries which use >>>>>>> OpenLDAP. The OpenLDAP bugs have cross-pollinated into other programs >>>>>>> and libraries. It is not simply contained or limited to OpenLDAP. >>>>>>> >>>>>>> That's a big problem for testing a QA folks. >>>>>> >>>>>> Then the tests are broken, because these are not bugs. >>>>> >>>>> They are absolutely OpenLDAP bugs. The unaligned accesses are >>>>> Undefined Behavior. >>>> >>>> Simply because the C standard doesn't specify what the behavior is doesn't make it a bug. >>> >>> The C standard does specify the behavior. It falls clearly in >>> Undefined Behavior. >> >> The fact a behavior is undefined does not make it illegal. > > A program with undefined behavior is, by definition, and illegal program. This is pure nonsense. You realize, don't you, that the C spec has no definition of threads? All multithreaded programs are using undefined behavior. And yet here we are, using threads for over 2 decades. 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. -- -- 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#8988) Undefined Behavior in slapadd
by noloader＠gmail.com 08 Jun '19

08 Jun '19

On Sat, Jun 8, 2019 at 3:47 AM Howard Chu <hyc(a)symas.com> wrote: > > Jeffrey Walton wrote: > > On Fri, Jun 7, 2019 at 2:37 PM Howard Chu <hyc(a)symas.com> wrote: > >> > >> Jeffrey Walton wrote: > >>> On Fri, Jun 7, 2019 at 10:08 AM Howard Chu <hyc(a)symas.com> wrote: > >>>> > >>>> Jeffrey Walton wrote: > >>>>> On Fri, Jun 7, 2019 at 9:59 AM Howard Chu <hyc(a)symas.com> wrote: > >>>>>> > >>>>>> noloader(a)gmail.com wrote: > >>>>>>> On Fri, Jun 7, 2019 at 9:32 AM Howard Chu <hyc(a)symas.com> wrote: > >>>>>>>> > >>>>>>>> noloader(a)gmail.com wrote: > >>>>>>>> ... > >>>>>>>>> I encourage OpenLDAP to fix the undefined behavior. OpenLDAP is an > >>>>>>>>> important project, and the undefined behavior is causing too many > >>>>>>>>> tangential problems. > >>>>>>>> > >>>>>>>> Undefined behavior is not a bug, nor is it prohibited by the C spec. It is a necessary > >>>>>>>> part of the language for its intended use as a system programming language, writing > >>>>>>>> machine-specific programs. Anyone who says it is prohibited by the spec is wrong. > >>>>>>> > >>>>>>> I don't believe this is correct. > >>>>>>> > >>>>>>> Maybe you are thinking of implementation defined behavior? > >>>>>> > >>>>>> That would apply to how a particular compiler implementation treats some piece of code. > >>>>>> Whether a CPU supports unaligned access is machine-defined. Since our code is already > >>>>>> properly ifdef'd for the machines which do or don't support it, the fact that this is > >>>>>> "non-portable" is not an issue. > >>>>> > >>>>> The undefined behavior is causing OpenLDAP to fail testing. > >>>>> > >>>>> Worse, it is causing test failures in programs and libraries which use > >>>>> OpenLDAP. The OpenLDAP bugs have cross-pollinated into other programs > >>>>> and libraries. It is not simply contained or limited to OpenLDAP. > >>>>> > >>>>> That's a big problem for testing a QA folks. > >>>> > >>>> Then the tests are broken, because these are not bugs. > >>> > >>> They are absolutely OpenLDAP bugs. The unaligned accesses are > >>> Undefined Behavior. > >> > >> Simply because the C standard doesn't specify what the behavior is doesn't make it a bug. > > > > The C standard does specify the behavior. It falls clearly in > > Undefined Behavior. > > The fact a behavior is undefined does not make it illegal. A program with undefined behavior is, by definition, and illegal program. > > And Appendix J.2, Undefined Behavior, says: > > > > Conversion between two pointer types produces a result > > that is incorrectly aligned (6.3.2.3). > > > > You are violating the C standard in macros like COPY_PGNO. Effectively > > you are casting a uint8_t array to an uint16_t*. You cannot do that > > because uint16_t* increases the alignment requirements. > > All internal fields of LMDB are (at least) 2-byte aligned, so these copies always > meet alignment requirements. No, they are not. Some of them are 1-byte aligned. UBsan tells you that. Others require 4-byte alignment. UBsan tells you that, too. Jeff

1 0

Re: (ITS#8988) Undefined Behavior in slapadd
by hyc＠symas.com 08 Jun '19

08 Jun '19

Jeffrey Walton wrote: > On Fri, Jun 7, 2019 at 2:37 PM Howard Chu <hyc(a)symas.com> wrote: >> >> Jeffrey Walton wrote: >>> On Fri, Jun 7, 2019 at 10:08 AM Howard Chu <hyc(a)symas.com> wrote: >>>> >>>> Jeffrey Walton wrote: >>>>> On Fri, Jun 7, 2019 at 9:59 AM Howard Chu <hyc(a)symas.com> wrote: >>>>>> >>>>>> noloader(a)gmail.com wrote: >>>>>>> On Fri, Jun 7, 2019 at 9:32 AM Howard Chu <hyc(a)symas.com> wrote: >>>>>>>> >>>>>>>> noloader(a)gmail.com wrote: >>>>>>>> ... >>>>>>>>> I encourage OpenLDAP to fix the undefined behavior. OpenLDAP is an >>>>>>>>> important project, and the undefined behavior is causing too many >>>>>>>>> tangential problems. >>>>>>>> >>>>>>>> Undefined behavior is not a bug, nor is it prohibited by the C spec. It is a necessary >>>>>>>> part of the language for its intended use as a system programming language, writing >>>>>>>> machine-specific programs. Anyone who says it is prohibited by the spec is wrong. >>>>>>> >>>>>>> I don't believe this is correct. >>>>>>> >>>>>>> Maybe you are thinking of implementation defined behavior? >>>>>> >>>>>> That would apply to how a particular compiler implementation treats some piece of code. >>>>>> Whether a CPU supports unaligned access is machine-defined. Since our code is already >>>>>> properly ifdef'd for the machines which do or don't support it, the fact that this is >>>>>> "non-portable" is not an issue. >>>>> >>>>> The undefined behavior is causing OpenLDAP to fail testing. >>>>> >>>>> Worse, it is causing test failures in programs and libraries which use >>>>> OpenLDAP. The OpenLDAP bugs have cross-pollinated into other programs >>>>> and libraries. It is not simply contained or limited to OpenLDAP. >>>>> >>>>> That's a big problem for testing a QA folks. >>>> >>>> Then the tests are broken, because these are not bugs. >>> >>> They are absolutely OpenLDAP bugs. The unaligned accesses are >>> Undefined Behavior. >> >> Simply because the C standard doesn't specify what the behavior is doesn't make it a bug. > > The C standard does specify the behavior. It falls clearly in > Undefined Behavior. The fact a behavior is undefined does not make it illegal. > And Appendix J.2, Undefined Behavior, says: > > Conversion between two pointer types produces a result > that is incorrectly aligned (6.3.2.3). > > You are violating the C standard in macros like COPY_PGNO. Effectively > you are casting a uint8_t array to an uint16_t*. You cannot do that > because uint16_t* increases the alignment requirements. All internal fields of LMDB are (at least) 2-byte aligned, so these copies always meet alignment requirements. -- -- 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#8988) Undefined Behavior in slapadd
by noloader＠gmail.com 08 Jun '19

08 Jun '19

On Fri, Jun 7, 2019 at 2:37 PM Howard Chu <hyc(a)symas.com> wrote: > > Jeffrey Walton wrote: > > On Fri, Jun 7, 2019 at 10:08 AM Howard Chu <hyc(a)symas.com> wrote: > >> > >> Jeffrey Walton wrote: > >>> On Fri, Jun 7, 2019 at 9:59 AM Howard Chu <hyc(a)symas.com> wrote: > >>>> > >>>> noloader(a)gmail.com wrote: > >>>>> On Fri, Jun 7, 2019 at 9:32 AM Howard Chu <hyc(a)symas.com> wrote: > >>>>>> > >>>>>> noloader(a)gmail.com wrote: > >>>>>> ... > >>>>>>> I encourage OpenLDAP to fix the undefined behavior. OpenLDAP is an > >>>>>>> important project, and the undefined behavior is causing too many > >>>>>>> tangential problems. > >>>>>> > >>>>>> Undefined behavior is not a bug, nor is it prohibited by the C spec. It is a necessary > >>>>>> part of the language for its intended use as a system programming language, writing > >>>>>> machine-specific programs. Anyone who says it is prohibited by the spec is wrong. > >>>>> > >>>>> I don't believe this is correct. > >>>>> > >>>>> Maybe you are thinking of implementation defined behavior? > >>>> > >>>> That would apply to how a particular compiler implementation treats some piece of code. > >>>> Whether a CPU supports unaligned access is machine-defined. Since our code is already > >>>> properly ifdef'd for the machines which do or don't support it, the fact that this is > >>>> "non-portable" is not an issue. > >>> > >>> The undefined behavior is causing OpenLDAP to fail testing. > >>> > >>> Worse, it is causing test failures in programs and libraries which use > >>> OpenLDAP. The OpenLDAP bugs have cross-pollinated into other programs > >>> and libraries. It is not simply contained or limited to OpenLDAP. > >>> > >>> That's a big problem for testing a QA folks. > >> > >> Then the tests are broken, because these are not bugs. > > > > They are absolutely OpenLDAP bugs. The unaligned accesses are > > Undefined Behavior. > > Simply because the C standard doesn't specify what the behavior is doesn't make it a bug. The C standard does specify the behavior. It falls clearly in Undefined Behavior. > It would be unreasonable to expect the standards body to exhaustively list all of the > possible behaviors on all of the possible hardware architectures that the language is > implemented for. Leaving it undefined in the spec only means they chose not to specify > a behavior. That means the actual behavior depends on the underlying machine. On the > x86 family the behavior is well defined. You seem to have a misunderstanding of the standard and unaligned accesses. You also seem to be conflating two different concepts. First, unaligned accesses, are undefined behavior. They are forbidden by the standard in 6.3.2.3 Pointers: 7. A pointer to an object type may be converted to a pointer to a different object type. If the resulting pointer is not correctly aligned for the referenced type, the behavior is undefined. And Appendix J.2, Undefined Behavior, says: Conversion between two pointer types produces a result that is incorrectly aligned (6.3.2.3). You are violating the C standard in macros like COPY_PGNO. Effectively you are casting a uint8_t array to an uint16_t*. You cannot do that because uint16_t* increases the alignment requirements. Tools like UBsan are telling you when you violate the rules. They specifically flagged COPY_PGNO as incurring undefined behavior. (Tools like UBsan will miss some UB, but that's a different error and not applicable to this discussion). You insistence on claiming the code is correct is befuddling. You are effectively saying the world is wrong, including the C standard, the compiler writers, other projects, the QA personnel testing the software and users like me. There's nothing special about me being wrong. I've had to acknowledged that often. However, I would take pause in claiming the C standard is wrong or the compiler writers, like GCC and LLVM devs, are wrong. That's pretty bold. Second, conflating concepts, is the difference between the C standard and processor capabilities. The C code has undefined behavior, and it does not matter what the processor is capable of. And it does not matter if the compiler decides to generate code that performs unaligned accesses. The compiler is free to do what it wants, even when it frustrates the user or makes the user envious. However, you cannot wrote code that uses unaligned objects even though the compiler may generate equivalent code. Jeff

1 0

Re: (ITS#8988) Undefined Behavior in slapadd
by hyc＠symas.com 07 Jun '19

07 Jun '19

Howard Chu wrote: > hyc(a)symas.com wrote: >> Jeffrey Walton wrote: >>> On Fri, Jun 7, 2019 at 10:08 AM Howard Chu <hyc(a)symas.com> wrote: >>>> >>>> Jeffrey Walton wrote: >>>>> On Fri, Jun 7, 2019 at 9:59 AM Howard Chu <hyc(a)symas.com> wrote: >>>>>> >>>>>> noloader(a)gmail.com wrote: >>>>>>> On Fri, Jun 7, 2019 at 9:32 AM Howard Chu <hyc(a)symas.com> wrote: >>>>>>>> >>>>>>>> noloader(a)gmail.com wrote: >>>>>>>> ... >>>>>>>>> I encourage OpenLDAP to fix the undefined behavior. OpenLDAP is an >>>>>>>>> important project, and the undefined behavior is causing too many >>>>>>>>> tangential problems. >>>>>>>> >>>>>>>> Undefined behavior is not a bug, nor is it prohibited by the C spec. It is a necessary >>>>>>>> part of the language for its intended use as a system programming language, writing >>>>>>>> machine-specific programs. Anyone who says it is prohibited by the spec is wrong. >>>>>>> >>>>>>> I don't believe this is correct. >>>>>>> >>>>>>> Maybe you are thinking of implementation defined behavior? >>>>>> >>>>>> That would apply to how a particular compiler implementation treats some piece of code. >>>>>> Whether a CPU supports unaligned access is machine-defined. Since our code is already >>>>>> properly ifdef'd for the machines which do or don't support it, the fact that this is >>>>>> "non-portable" is not an issue. >>>>> >>>>> The undefined behavior is causing OpenLDAP to fail testing. >>>>> >>>>> Worse, it is causing test failures in programs and libraries which use >>>>> OpenLDAP. The OpenLDAP bugs have cross-pollinated into other programs >>>>> and libraries. It is not simply contained or limited to OpenLDAP. >>>>> >>>>> That's a big problem for testing a QA folks. >>>> >>>> Then the tests are broken, because these are not bugs. >>> >>> They are absolutely OpenLDAP bugs. The unaligned accesses are >>> Undefined Behavior. >> >> Simply because the C standard doesn't specify what the behavior is doesn't make it a bug. >> It would be unreasonable to expect the standards body to exhaustively list all of the >> possible behaviors on all of the possible hardware architectures that the language is >> implemented for. Leaving it undefined in the spec only means they chose not to specify >> a behavior. That means the actual behavior depends on the underlying machine. On the >> x86 family the behavior is well defined. > > Also note: Behaviors are left undefined when they are non-portable. But being non-portable > isn't illegal in C. The entire purpose of conditional compilation is to support non-portable > code. > Worth reading https://www.yodaiken.com/2018/12/31/undefined-behavior-and-the-purpose-of-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#8988) Undefined Behavior in slapadd
by hyc＠symas.com 07 Jun '19

07 Jun '19

hyc(a)symas.com wrote: > Jeffrey Walton wrote: >> On Fri, Jun 7, 2019 at 10:08 AM Howard Chu <hyc(a)symas.com> wrote: >>> >>> Jeffrey Walton wrote: >>>> On Fri, Jun 7, 2019 at 9:59 AM Howard Chu <hyc(a)symas.com> wrote: >>>>> >>>>> noloader(a)gmail.com wrote: >>>>>> On Fri, Jun 7, 2019 at 9:32 AM Howard Chu <hyc(a)symas.com> wrote: >>>>>>> >>>>>>> noloader(a)gmail.com wrote: >>>>>>> ... >>>>>>>> I encourage OpenLDAP to fix the undefined behavior. OpenLDAP is an >>>>>>>> important project, and the undefined behavior is causing too many >>>>>>>> tangential problems. >>>>>>> >>>>>>> Undefined behavior is not a bug, nor is it prohibited by the C spec. It is a necessary >>>>>>> part of the language for its intended use as a system programming language, writing >>>>>>> machine-specific programs. Anyone who says it is prohibited by the spec is wrong. >>>>>> >>>>>> I don't believe this is correct. >>>>>> >>>>>> Maybe you are thinking of implementation defined behavior? >>>>> >>>>> That would apply to how a particular compiler implementation treats some piece of code. >>>>> Whether a CPU supports unaligned access is machine-defined. Since our code is already >>>>> properly ifdef'd for the machines which do or don't support it, the fact that this is >>>>> "non-portable" is not an issue. >>>> >>>> The undefined behavior is causing OpenLDAP to fail testing. >>>> >>>> Worse, it is causing test failures in programs and libraries which use >>>> OpenLDAP. The OpenLDAP bugs have cross-pollinated into other programs >>>> and libraries. It is not simply contained or limited to OpenLDAP. >>>> >>>> That's a big problem for testing a QA folks. >>> >>> Then the tests are broken, because these are not bugs. >> >> They are absolutely OpenLDAP bugs. The unaligned accesses are >> Undefined Behavior. > > Simply because the C standard doesn't specify what the behavior is doesn't make it a bug. > It would be unreasonable to expect the standards body to exhaustively list all of the > possible behaviors on all of the possible hardware architectures that the language is > implemented for. Leaving it undefined in the spec only means they chose not to specify > a behavior. That means the actual behavior depends on the underlying machine. On the > x86 family the behavior is well defined. Also note: Behaviors are left undefined when they are non-portable. But being non-portable isn't illegal in C. The entire purpose of conditional compilation is to support non-portable code. -- -- 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#8988) Undefined Behavior in slapadd
by hyc＠symas.com 07 Jun '19

07 Jun '19

Jeffrey Walton wrote: > On Fri, Jun 7, 2019 at 10:08 AM Howard Chu <hyc(a)symas.com> wrote: >> >> Jeffrey Walton wrote: >>> On Fri, Jun 7, 2019 at 9:59 AM Howard Chu <hyc(a)symas.com> wrote: >>>> >>>> noloader(a)gmail.com wrote: >>>>> On Fri, Jun 7, 2019 at 9:32 AM Howard Chu <hyc(a)symas.com> wrote: >>>>>> >>>>>> noloader(a)gmail.com wrote: >>>>>> ... >>>>>>> I encourage OpenLDAP to fix the undefined behavior. OpenLDAP is an >>>>>>> important project, and the undefined behavior is causing too many >>>>>>> tangential problems. >>>>>> >>>>>> Undefined behavior is not a bug, nor is it prohibited by the C spec. It is a necessary >>>>>> part of the language for its intended use as a system programming language, writing >>>>>> machine-specific programs. Anyone who says it is prohibited by the spec is wrong. >>>>> >>>>> I don't believe this is correct. >>>>> >>>>> Maybe you are thinking of implementation defined behavior? >>>> >>>> That would apply to how a particular compiler implementation treats some piece of code. >>>> Whether a CPU supports unaligned access is machine-defined. Since our code is already >>>> properly ifdef'd for the machines which do or don't support it, the fact that this is >>>> "non-portable" is not an issue. >>> >>> The undefined behavior is causing OpenLDAP to fail testing. >>> >>> Worse, it is causing test failures in programs and libraries which use >>> OpenLDAP. The OpenLDAP bugs have cross-pollinated into other programs >>> and libraries. It is not simply contained or limited to OpenLDAP. >>> >>> That's a big problem for testing a QA folks. >> >> Then the tests are broken, because these are not bugs. > > They are absolutely OpenLDAP bugs. The unaligned accesses are > Undefined Behavior. Simply because the C standard doesn't specify what the behavior is doesn't make it a bug. It would be unreasonable to expect the standards body to exhaustively list all of the possible behaviors on all of the possible hardware architectures that the language is implemented for. Leaving it undefined in the spec only means they chose not to specify a behavior. That means the actual behavior depends on the underlying machine. On the x86 family the behavior is well defined. -- -- 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#8988) Undefined Behavior in slapadd
by noloader＠gmail.com 07 Jun '19

07 Jun '19

On Fri, Jun 7, 2019 at 10:08 AM Howard Chu <hyc(a)symas.com> wrote: > > Jeffrey Walton wrote: > > On Fri, Jun 7, 2019 at 9:59 AM Howard Chu <hyc(a)symas.com> wrote: > >> > >> noloader(a)gmail.com wrote: > >>> On Fri, Jun 7, 2019 at 9:32 AM Howard Chu <hyc(a)symas.com> wrote: > >>>> > >>>> noloader(a)gmail.com wrote: > >>>> ... > >>>>> I encourage OpenLDAP to fix the undefined behavior. OpenLDAP is an > >>>>> important project, and the undefined behavior is causing too many > >>>>> tangential problems. > >>>> > >>>> Undefined behavior is not a bug, nor is it prohibited by the C spec. It is a necessary > >>>> part of the language for its intended use as a system programming language, writing > >>>> machine-specific programs. Anyone who says it is prohibited by the spec is wrong. > >>> > >>> I don't believe this is correct. > >>> > >>> Maybe you are thinking of implementation defined behavior? > >> > >> That would apply to how a particular compiler implementation treats some piece of code. > >> Whether a CPU supports unaligned access is machine-defined. Since our code is already > >> properly ifdef'd for the machines which do or don't support it, the fact that this is > >> "non-portable" is not an issue. > > > > The undefined behavior is causing OpenLDAP to fail testing. > > > > Worse, it is causing test failures in programs and libraries which use > > OpenLDAP. The OpenLDAP bugs have cross-pollinated into other programs > > and libraries. It is not simply contained or limited to OpenLDAP. > > > > That's a big problem for testing a QA folks. > > Then the tests are broken, because these are not bugs. They are absolutely OpenLDAP bugs. The unaligned accesses are Undefined Behavior. * https://stackoverflow.com/a/46790815/608639 * https://stackoverflow.com/a/46790813/608639 * https://stackoverflow.com/a/28895321/608639 * https://stackoverflow.com/a/51126453/608639 * https://stackoverflow.com/q/39908946/608639 ... I get that you think your project is fine. Many folks take that myopic view of the world. I call it the greedy model. Greedy models show up all over the place. For example, every website that requires a different account and different 16 character password. That's the greedy password model where a site think it is the only one someone visits. What baffles me is your insistence on polluting other program and library results. That's not your place to screw up testing for other programs and libraries. Jeff

1 0

(ITS#9031) Guide updates for 2.4
by quanah＠openldap.org 07 Jun '19

07 Jun '19

Full_Name: Quanah Gibson-Mount Version: 2.4.47 OS: N/A URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (47.208.128.44) The admin guide for delta-syncrepl needs updating. For example, it is missing the reqDN attribute being indexed. Additionally, it should be updated to reference mdb rather than hdb, since it is the preferred backend now in 2.4

1 0

Re: (ITS#8988) Undefined Behavior in slapadd
by hyc＠symas.com 07 Jun '19

07 Jun '19

Jeffrey Walton wrote: > On Fri, Jun 7, 2019 at 9:59 AM Howard Chu <hyc(a)symas.com> wrote: >> >> noloader(a)gmail.com wrote: >>> On Fri, Jun 7, 2019 at 9:32 AM Howard Chu <hyc(a)symas.com> wrote: >>>> >>>> noloader(a)gmail.com wrote: >>>> ... >>>>> I encourage OpenLDAP to fix the undefined behavior. OpenLDAP is an >>>>> important project, and the undefined behavior is causing too many >>>>> tangential problems. >>>> >>>> Undefined behavior is not a bug, nor is it prohibited by the C spec. It is a necessary >>>> part of the language for its intended use as a system programming language, writing >>>> machine-specific programs. Anyone who says it is prohibited by the spec is wrong. >>> >>> I don't believe this is correct. >>> >>> Maybe you are thinking of implementation defined behavior? >> >> That would apply to how a particular compiler implementation treats some piece of code. >> Whether a CPU supports unaligned access is machine-defined. Since our code is already >> properly ifdef'd for the machines which do or don't support it, the fact that this is >> "non-portable" is not an issue. > > The undefined behavior is causing OpenLDAP to fail testing. > > Worse, it is causing test failures in programs and libraries which use > OpenLDAP. The OpenLDAP bugs have cross-pollinated into other programs > and libraries. It is not simply contained or limited to OpenLDAP. > > That's a big problem for testing a QA folks. Then the tests are broken, because these are not bugs. -- -- 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#8962) Dead links in FAQ page "Where can I find listings of schema items?"
by quanah＠symas.com 07 Jun '19

07 Jun '19

--On Friday, June 07, 2019 8:53 AM +0200 Michael Str=C3=B6der=20 <michael(a)stroeder.com> wrote: > The FAQ contains the only documentation for set-based ACLs. > > So it's not an option to just shutdown FAQ-O-MATIC. Sure, any useful articles need to get moved to something. Just saying=20 overall, I think it's time for the existing FAQ to die. --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 noloader＠gmail.com 07 Jun '19

07 Jun '19

On Fri, Jun 7, 2019 at 9:59 AM Howard Chu <hyc(a)symas.com> wrote: > > noloader(a)gmail.com wrote: > > On Fri, Jun 7, 2019 at 9:32 AM Howard Chu <hyc(a)symas.com> wrote: > >> > >> noloader(a)gmail.com wrote: > >> ... > >>> I encourage OpenLDAP to fix the undefined behavior. OpenLDAP is an > >>> important project, and the undefined behavior is causing too many > >>> tangential problems. > >> > >> Undefined behavior is not a bug, nor is it prohibited by the C spec. It is a necessary > >> part of the language for its intended use as a system programming language, writing > >> machine-specific programs. Anyone who says it is prohibited by the spec is wrong. > > > > I don't believe this is correct. > > > > Maybe you are thinking of implementation defined behavior? > > That would apply to how a particular compiler implementation treats some piece of code. > Whether a CPU supports unaligned access is machine-defined. Since our code is already > properly ifdef'd for the machines which do or don't support it, the fact that this is > "non-portable" is not an issue. The undefined behavior is causing OpenLDAP to fail testing. Worse, it is causing test failures in programs and libraries which use OpenLDAP. The OpenLDAP bugs have cross-pollinated into other programs and libraries. It is not simply contained or limited to OpenLDAP. That's a big problem for testing a QA folks. Jeff

1 0

Re: (ITS#8988) Undefined Behavior in slapadd
by hyc＠symas.com 07 Jun '19

07 Jun '19

noloader(a)gmail.com wrote: > On Fri, Jun 7, 2019 at 9:32 AM Howard Chu <hyc(a)symas.com> wrote: >> >> noloader(a)gmail.com wrote: >> ... >>> I encourage OpenLDAP to fix the undefined behavior. OpenLDAP is an >>> important project, and the undefined behavior is causing too many >>> tangential problems. >> >> Undefined behavior is not a bug, nor is it prohibited by the C spec. It is a necessary >> part of the language for its intended use as a system programming language, writing >> machine-specific programs. Anyone who says it is prohibited by the spec is wrong. > > I don't believe this is correct. > > Maybe you are thinking of implementation defined behavior? That would apply to how a particular compiler implementation treats some piece of code. Whether a CPU supports unaligned access is machine-defined. Since our code is already properly ifdef'd for the machines which do or don't support it, the fact that this is "non-portable" is not an issue. -- -- 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#8988) Undefined Behavior in slapadd
by noloader＠gmail.com 07 Jun '19

07 Jun '19

On Fri, Jun 7, 2019 at 9:32 AM Howard Chu <hyc(a)symas.com> wrote: > > noloader(a)gmail.com wrote: > ... > > I encourage OpenLDAP to fix the undefined behavior. OpenLDAP is an > > important project, and the undefined behavior is causing too many > > tangential problems. > > Undefined behavior is not a bug, nor is it prohibited by the C spec. It is a necessary > part of the language for its intended use as a system programming language, writing > machine-specific programs. Anyone who says it is prohibited by the spec is wrong. I don't believe this is correct. Maybe you are thinking of implementation defined behavior? Jeff

1 0

Re: (ITS#8988) Undefined Behavior in slapadd
by hyc＠symas.com 07 Jun '19

07 Jun '19

noloader(a)gmail.com wrote: > On Thu, Jun 6, 2019 at 7:39 PM Quanah Gibson-Mount <quanah(a)symas.com> wrote: >> >> --On Thursday, March 07, 2019 10:10 AM +0000 noloader(a)gmail.com wrote: >> >>> Full_Name: JW >>> Version: 2.4.47 >>> OS: Linux (Fedora 29, x86_64, fully patched) >>> URL: ftp://ftp.openldap.org/incoming/ >>> Submission from: (NULL) (151.196.22.177) >>> >>> I added -fsanitize=undefined to CFLAGS. >> >> In this case, the compiler is the problem. > > I'm pretty sure the compiler is correct. > > The instrumentation does not produce false positives. It operates on > real data and simply does not produce false positives. > >> LMDB is 100% correct regarding >> alignment on all supported CPUs (which is most of them). The x86 family >> fully supports unaligned access, so LMDB makes use of this. > > It is not the processor; it is the C language. The C language does not allow it. That is incorrect. The C language allows it, but does not fully specify the behavior. On some machines unaligned accesses are allowed, on others it is not. On X86 family it is allowed, and we use it. > >> On other CPUs, >> which do not support unaligned access (e.g., SPARC), LMDB doesn't use them. > > The undefined behavior exists even after disabling the unaligned > accesses with custom patches. For example, there is still undefined > behavior even after changes like this: > > -#if defined(__i386) || defined(__x86_64) > -#define MISALIGNED_OK 1 > -#else > #define ALIGNER (sizeof(size_t)-1) > -#endif > > We also fixed COPY_PGNO but the undefined behavior remained. > > The GCC Compile Farm (https://cfarm.tetaneutral.net/machines/list/) > has three SPARC machines. SPARC does not tolerate unaligned accesses > well, especially due to the optimized 64-bit move instruction. We have already tested on SPARC and as we already noted above, we do not use unaligned accesses on SPARC. > OpenLDAP might consider testing on the SPARC machines. > > In the bigger picture, OpenLDAP is causing other program and library > testing to fail testing. When we test other programs and libraries > that depend upon OpenLDAP in a similar fashion, the undefined behavior > in OpenLDAP surfaces in the other program and libraries. It is making > a lot of extra work for folks who perform extra testing. > > I encourage OpenLDAP to fix the undefined behavior. OpenLDAP is an > important project, and the undefined behavior is causing too many > tangential problems. Undefined behavior is not a bug, nor is it prohibited by the C spec. It is a necessary part of the language for its intended use as a system programming language, writing machine-specific programs. Anyone who says it is prohibited by the spec is wrong. > Jeff > > > > -- -- 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#8962) Dead links in FAQ page "Where can I find listings of schema items?"
by michael＠stroeder.com 06 Jun '19

06 Jun '19

On 6/7/19 1:49 AM, quanah(a)symas.com wrote: > --On Friday, January 25, 2019 9:25 PM +0000 michael(a)stroeder.com wrote: > >> All links herein are dead: >> https://www.openldap.org/faq/data/cache/220.html >> >> I'd suggest to remove this FAQ page completely. > > I tried, but unfortunatley the FAQ software breaks Apache when you try and > delete an answer. I think the better solution is just to remove the FAQ > software completely. The FAQ contains the only documentation for set-based ACLs. So it's not an option to just shutdown FAQ-O-MATIC. Ciao, Michael.

1 0

Re: (ITS#8988) Undefined Behavior in slapadd
by noloader＠gmail.com 06 Jun '19

06 Jun '19

On Thu, Jun 6, 2019 at 7:39 PM Quanah Gibson-Mount <quanah(a)symas.com> wrote: > > --On Thursday, March 07, 2019 10:10 AM +0000 noloader(a)gmail.com wrote: > > > Full_Name: JW > > Version: 2.4.47 > > OS: Linux (Fedora 29, x86_64, fully patched) > > URL: ftp://ftp.openldap.org/incoming/ > > Submission from: (NULL) (151.196.22.177) > > > > I added -fsanitize=undefined to CFLAGS. > > In this case, the compiler is the problem. I'm pretty sure the compiler is correct. The instrumentation does not produce false positives. It operates on real data and simply does not produce false positives. > LMDB is 100% correct regarding > alignment on all supported CPUs (which is most of them). The x86 family > fully supports unaligned access, so LMDB makes use of this. It is not the processor; it is the C language. The C language does not allow it. > On other CPUs, > which do not support unaligned access (e.g., SPARC), LMDB doesn't use them. The undefined behavior exists even after disabling the unaligned accesses with custom patches. For example, there is still undefined behavior even after changes like this: -#if defined(__i386) || defined(__x86_64) -#define MISALIGNED_OK 1 -#else #define ALIGNER (sizeof(size_t)-1) -#endif We also fixed COPY_PGNO but the undefined behavior remained. The GCC Compile Farm (https://cfarm.tetaneutral.net/machines/list/) has three SPARC machines. SPARC does not tolerate unaligned accesses well, especially due to the optimized 64-bit move instruction. OpenLDAP might consider testing on the SPARC machines. In the bigger picture, OpenLDAP is causing other program and library testing to fail testing. When we test other programs and libraries that depend upon OpenLDAP in a similar fashion, the undefined behavior in OpenLDAP surfaces in the other program and libraries. It is making a lot of extra work for folks who perform extra testing. I encourage OpenLDAP to fix the undefined behavior. OpenLDAP is an important project, and the undefined behavior is causing too many tangential problems. Jeff

1 0

Re: (ITS#8946) openldap bug
by quanah＠symas.com 06 Jun '19

06 Jun '19

Hello, There is no bug here. Your configuration is invalid. If you need help with configuring OpenLDAP, then please use the openldap-technical(a)openldap.org mailing list. 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#8962) Dead links in FAQ page "Where can I find listings of schema items?"
by quanah＠symas.com 06 Jun '19

06 Jun '19

--On Friday, January 25, 2019 9:25 PM +0000 michael(a)stroeder.com wrote: > All links herein are dead: > https://www.openldap.org/faq/data/cache/220.html > > I'd suggest to remove this FAQ page completely. I tried, but unfortunatley the FAQ software breaks Apache when you try and delete an answer. I think the better solution is just to remove the FAQ software completely. --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 quanah＠symas.com 06 Jun '19

06 Jun '19

--On Thursday, March 07, 2019 10:10 AM +0000 noloader(a)gmail.com wrote: > Full_Name: JW > Version: 2.4.47 > OS: Linux (Fedora 29, x86_64, fully patched) > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (151.196.22.177) > > > I added -fsanitize=undefined to CFLAGS. Hello, In this case, the compiler is the problem. LMDB is 100% correct regarding alignment on all supported CPUs (which is most of them). The x86 family fully supports unaligned access, so LMDB makes use of this. On other CPUs, which do not support unaligned access (e.g., SPARC), LMDB doesn't use them. 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

ITS#8993 published: SECURITY: OpenLdap (SyncRepl + Mirror Mode) issue
by openldap-its＠OpenLDAP.org 06 Jun '19

06 Jun '19

Private ITS#8993 is now publicly readable URL: http://www.OpenLDAP.org/its/?findid=8993

1 0

ITS#8994 published: SECURITY: OpenLdap (SyncRepl + Mirror Mode) issue
by openldap-its＠OpenLDAP.org 06 Jun '19

06 Jun '19

Private ITS#8994 is now publicly readable URL: http://www.OpenLDAP.org/its/?findid=8994

1 0

Re: (ITS#9029) MDB_MAP_FULL error after removing some records from DB
by adubovkin＠linkedin.com 06 Jun '19

06 Jun '19

WW91J3JlIHJpZ2h0LiBJZiBJIHN0YXJ0IHdpdGggYSBtYXAgc2l6ZSBvZiAxME1CIEkgY2FuJ3Qg cmVwcm9kdWNlIGl0IGFueW1vcmUgd2l0aCBteSB0ZXN0Lg0KVGhhbmtzIGZvciBjbGFyaWZ5aW5n IGl0Lg0KDQpCZXN0IHdpc2hlcywNCkFsZXhleQ0KDQrvu79PbiA2LzUvMTksIDEyOjI5IFBNLCAi UXVhbmFoIEdpYnNvbi1Nb3VudCIgPHF1YW5haEBzeW1hcy5jb20+IHdyb3RlOg0KDQogICAgLS1P biBXZWRuZXNkYXksIEp1bmUgMDUsIDIwMTkgNzo1MyBQTSArMDAwMCBBbGV4ZXkgRHVib3ZraW4g DQogICAgPGFkdWJvdmtpbkBsaW5rZWRpbi5jb20+IHdyb3RlOg0KICAgIA0KICAgID4gVGhhbmsg eW91IQ0KICAgID4gQWxleGV5DQogICAgDQogICAgSGkgQWxleGV5LA0KICAgIA0KICAgIEFzIEhv d2FyZCBhbHJlYWR5IG5vdGVkIGluIGhpcyByZXNwb25zZSB0byB0aGUgSVRTLCB0aGVyZSBpcyBu byANCiAgICBkZW1vbnN0cmF0ZWQgYnVnIGhlcmUuICBJdCB3b3VsZCBhcHBlYXIgeW91J3ZlIHJ1 biBvdXQgb2YgZnJlZSBwYWdlcyBnaXZlbiANCiAgICB0aGUgbWFwc2l6ZSB5b3Ugc3RhcnRlZCB3 aXRoLiAgQXMgbm90ZWQgaW4gdGhlIGRvY3VtZW50YXRpb24sIHRoZSBnZW5lcmFsIA0KICAgIGV4 cGVjdGF0aW9uIGlzIG9uZSBzZXRzIGEgdmVyeSBsYXJnZSBtYXBzaXplIGZyb20gdGhlIHN0YXJ0 LiAgSG9wZSB0aGF0IA0KICAgIGhlbHBzIQ0KICAgIA0KICAgIC0tUXVhbmFoDQogICAgDQogICAg DQogICAgDQogICAgLS0NCiAgICANCiAgICBRdWFuYWggR2lic29uLU1vdW50DQogICAgUHJvZHVj dCBBcmNoaXRlY3QNCiAgICBTeW1hcyBDb3Jwb3JhdGlvbg0KICAgIFBhY2thZ2VkLCBjZXJ0aWZp ZWQsIGFuZCBzdXBwb3J0ZWQgTERBUCBzb2x1dGlvbnMgcG93ZXJlZCBieSBPcGVuTERBUDoNCiAg ICA8aHR0cHM6Ly9uYW0wNi5zYWZlbGlua3MucHJvdGVjdGlvbi5vdXRsb29rLmNvbS8/dXJsPWh0 dHAlM0ElMkYlMkZ3d3cuc3ltYXMuY29tJmFtcDtkYXRhPTAyJTdDMDElN0NhZHVib3ZraW4lNDBs aW5rZWRpbi5jb20lN0NjODkxMDQyNzM3OTQ0NjEzZWYyZDA4ZDZlOWVjMmJmOSU3QzcyZjk4OGJm ODZmMTQxYWY5MWFiMmQ3Y2QwMTFkYjQ3JTdDMSU3QzElN0M2MzY5NTM1OTc4OTk3NDAxOTAmYW1w O3NkYXRhPVRQcUVDY0lwJTJGcGFNQlJwSHlpOW03ZDk1R084NXk0ZEIzTU4xYUw1c1dsVSUzRCZh bXA7cmVzZXJ2ZWQ9MD4NCiAgICANCiAgICANCg0K

1 0

(ITS#9030) Use sys/cachectl.h rather than asm/cachectl.h on mips
by mh-bcrayqnc＠glandium.org 05 Jun '19

05 Jun '19

Full_Name: Mike Hommey Version: OS: Linux URL: https://github.com/glandium/lmdb/commit/3e9a0dfc718699671ac2f21d40ef259b5da… Submission from: (NULL) (153.194.155.35) asm/cachectl.h doesn't contain the function declaration for cacheflush, but sys/cachectl.h does. Having the declaration in mdb.c can cause linkage issues when using things like -fvisibility=hidden.

1 0

Re: (ITS#9029) MDB_MAP_FULL error after removing some records from DB
by quanah＠symas.com 05 Jun '19

05 Jun '19

--On Wednesday, June 05, 2019 7:53 PM +0000 Alexey Dubovkin <adubovkin(a)linkedin.com> wrote: > Thank you! > Alexey Hi Alexey, As Howard already noted in his response to the ITS, there is no demonstrated bug here. It would appear you've run out of free pages given the mapsize you started with. As noted in the documentation, the general expectation is one sets a very large mapsize from the start. Hope that helps! --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#9029) MDB_MAP_FULL error after removing some records from DB
by adubovkin＠linkedin.com 05 Jun '19

05 Jun '19

--_002_0D2DCEC482B542758A1B48103AF58106linkedinbiz_ Content-Type: text/plain; charset="utf-8" Content-ID: <BEC9A5920C66A44D82684553337AA3F9(a)namprd21.prod.outlook.com> Content-Transfer-Encoding: base64 ICAgICAgICAtLU9uIFR1ZXNkYXksIE1heSAyOCwgMjAxOSAxMDoxMiBQTSArMDAwMCBhZHVib3Zr aW5AbGlua2VkaW4uY29tIHdyb3RlOg0KICAgICAgICANCiAgICAgICAgPiBGdWxsX05hbWU6IEFs ZXgNCiAgICAgICAgPiBWZXJzaW9uOiBMTURCIDAuOS4yMw0KICAgICAgICA+IE9TOiBpT1MNCiAg ICAgICAgPiBVUkw6IGh0dHBzOi8vbmFtMDYuc2FmZWxpbmtzLnByb3RlY3Rpb24ub3V0bG9vay5j b20vP3VybD1odHRwcyUzQSUyRiUyRmhhc3RlYmluLmNvbSUyRnJhdyUyRmFyZXhlY2VmZXcmYW1w O2RhdGE9MDIlN0MwMSU3Q2FkdWJvdmtpbiU0MGxpbmtlZGluLmNvbSU3QzllYWUyMGQ5NDJlNDQ1 NzM1YjE0MDhkNmU5MzBjMTA1JTdDNzJmOTg4YmY4NmYxNDFhZjkxYWIyZDdjZDAxMWRiNDclN0Mx JTdDMSU3QzYzNjk1Mjc5Mjk0OTU1MjUzNiZhbXA7c2RhdGE9a2VtNmQzdHJ0MjJHdWpLQlJuV3Jq OFA4QUk3RlhBJTJGOEpCT2ZHeThZZUFJJTNEJmFtcDtyZXNlcnZlZD0wDQogICAgICAgID4gU3Vi bWlzc2lvbiBmcm9tOiAoTlVMTCkgKDI2MjA6MTE5OjUwMDE6MzAwMDoyNDJjOjNiZWE6YWNlYzo2 YTdkKQ0KICAgIA0KICAgIE9uIDYvNC8xOSwgMjowOCBQTSwgIlF1YW5haCBHaWJzb24tTW91bnQi IDxxdWFuYWhAc3ltYXMuY29tPiB3cm90ZToNCiAgICANCiAgICAgICAgSVRTIzg5NjkgcGVyaGFw cz8NCiAgICAgICAgDQogICAgICAgIDxodHRwczovL25hbTA2LnNhZmVsaW5rcy5wcm90ZWN0aW9u Lm91dGxvb2suY29tLz91cmw9aHR0cHMlM0ElMkYlMkZ3d3cub3BlbmxkYXAub3JnJTJGaXRzJTJG aW5kZXguY2dpJTJGJTNGZmluZGlkJTNEODk2OSZhbXA7ZGF0YT0wMiU3QzAxJTdDYWR1Ym92a2lu JTQwbGlua2VkaW4uY29tJTdDOWVhZTIwZDk0MmU0NDU3MzViMTQwOGQ2ZTkzMGMxMDUlN0M3MmY5 ODhiZjg2ZjE0MWFmOTFhYjJkN2NkMDExZGI0NyU3QzElN0MxJTdDNjM2OTUyNzkyOTQ5NTUyNTM2 JmFtcDtzZGF0YT1KUk56c1dKS0QzaFJYMmJNcmpWSWVkTm9kUW9XNjJvajRIQUY3ZHFXdzJzJTNE JmFtcDtyZXNlcnZlZD0wPg0KICAgICAgICANCiAgICAgICAgLS1RdWFuYWgNCiAgICAgICAgDQog ICAgICAgIA0KICAgICAgICAtLQ0KICAgICAgICANCiAgICAgICAgUXVhbmFoIEdpYnNvbi1Nb3Vu dA0KICAgICAgICBQcm9kdWN0IEFyY2hpdGVjdA0KICAgICAgICBTeW1hcyBDb3Jwb3JhdGlvbg0K ICAgICAgICBQYWNrYWdlZCwgY2VydGlmaWVkLCBhbmQgc3VwcG9ydGVkIExEQVAgc29sdXRpb25z IHBvd2VyZWQgYnkgT3BlbkxEQVA6DQogICAgDQogICAgLS0tLS0tLS0tDQogICAgSSB0ZXN0ZWQg aXQgd2l0aCB0aGUgbGF0ZXN0IG1hc3RlciBhbmQgdGhlIGJ1ZyBpcyBzdGlsbCB0aGVyZSAoKCgN CiAgICANCiAgICBUaGFua3MsDQogICAgQWxleGV5DQoNCi0tLS0tLS0tLQ0KDQpIaSBRdWFuYWgs DQoNCkkgd3JvdGUgYSBzaW1wbGUgdGVzdCB0byByZXByb2R1Y2UgdGhlIGlzc3VlLiBJdCB3cml0 ZXMgc29tZSByZWNvcmRzIHVudGlsIGl0IGhpdCBNREJfTUFQX0ZVTEwgZXJyb3IsIHRoZW4gcmVt b3ZlIGhhbGYgb2YgdGhlbSBhbmQgdHJpZXMgdG8gcmUtaW5zZXJ0IGxhc3QgZmFpbGVkIHJlY29y ZC4gVGhpcyBpcyByZXBlYXRlZCBpbiBhIGxvb3Agc2luY2UgaXQncyBub3QgcmVwcm9kdWNpYmxl IG9mdGVuLiBIb3BlIHRoaXMgd291bGQgaGVscCB0byByZXByb2R1Y2UgYW5kIGFkZHJlc3MgdGhl IGlzc3VlLg0KSGVyZSdzIHRoZSBsb2c6DQoNCkZpbGxpbmcgdXAgREIgdW50aWwgd2UgZ2V0IE1E Ql9GVUxMIGVycm9yIChjeWNsZSAwKQ0KICAgIEdvdCBNREJfTUFQX0ZVTEwgYXQgbWRiX3B1dC4g UmVjb3JkIHNpemU6IDQzMTANCiAgICBTdGF0czogZW50cmllcyA9IDEyMiAgcGFnZXMgPSAxICsg MjQgKyA4OQ0KICAgIFJlbW92aW5nIHNvbWUgcmVjb3JkczogMTIyIC0+IDYxDQogICAgU3RhdHM6 IGVudHJpZXMgPSA2MSAgcGFnZXMgPSAxICsgMjAgKyAzOA0KICAgIFJlLWluc2VydGluZyBmYWls ZWQgcmVjb3JkIGFnYWluDQpGaWxsaW5nIHVwIERCIHVudGlsIHdlIGdldCBNREJfRlVMTCBlcnJv ciAoY3ljbGUgMSkNCiAgICBHb3QgTURCX01BUF9GVUxMIGF0IG1kYl9wdXQuIFJlY29yZCBzaXpl OiA0MzMzDQogICAgU3RhdHM6IGVudHJpZXMgPSAxMTMgIHBhZ2VzID0gMSArIDI4ICsgNzkNCiAg ICBSZW1vdmluZyBzb21lIHJlY29yZHM6IDExMyAtPiA1Ng0KICAgIFN0YXRzOiBlbnRyaWVzID0g NTYgIHBhZ2VzID0gMSArIDIyICsgMzUNCiAgICBSZS1pbnNlcnRpbmcgZmFpbGVkIHJlY29yZCBh Z2Fpbg0KRmlsbGluZyB1cCBEQiB1bnRpbCB3ZSBnZXQgTURCX0ZVTEwgZXJyb3IgKGN5Y2xlIDIp DQogICAgR290IE1EQl9NQVBfRlVMTCBhdCBtZGJfdHhuX2NvbW1pdC4gUmVjb3JkIHNpemU6IDY0 NQ0KICAgIFN0YXRzOiBlbnRyaWVzID0gMTE5ICBwYWdlcyA9IDEgKyAyNSArIDg5DQogICAgUmVt b3Zpbmcgc29tZSByZWNvcmRzOiAxMTkgLT4gNTkNCm10ZXN0Ny5jOjg4OiBtZGJfdHhuX2NvbW1p dCh0eG4pOiBNREJfTUFQX0ZVTEw6IEVudmlyb25tZW50IG1hcHNpemUgbGltaXQgcmVhY2hlZA0K DQpUaGFuayB5b3UhDQpBbGV4ZXkNCg0KICAgICAgICANCiAgICAgICAgDQogICAgDQogICAgDQoN Cg== --_002_0D2DCEC482B542758A1B48103AF58106linkedinbiz_ Content-Type: application/octet-stream; name="mtest7.c" Content-Description: mtest7.c Content-Disposition: attachment; filename="mtest7.c"; size=3693; creation-date="Wed, 05 Jun 2019 18:53:58 GMT"; modification-date="Wed, 05 Jun 2019 18:53:58 GMT" Content-ID: <EE5D0AC6F9292F4AB9464B44632025A8(a)namprd21.prod.outlook.com> Content-Transfer-Encoding: base64 LyogbXRlc3Q3LmMgLSBtZW1vcnktbWFwcGVkIGRhdGFiYXNlIHRlc3Rlci90b3kgKi8KLyoKICog Q29weXJpZ2h0IDIwMTEtMjAxOCBIb3dhcmQgQ2h1LCBTeW1hcyBDb3JwLgogKiBBbGwgcmlnaHRz IHJlc2VydmVkLgogKgogKiBSZWRpc3RyaWJ1dGlvbiBhbmQgdXNlIGluIHNvdXJjZSBhbmQgYmlu YXJ5IGZvcm1zLCB3aXRoIG9yIHdpdGhvdXQKICogbW9kaWZpY2F0aW9uLCBhcmUgcGVybWl0dGVk IG9ubHkgYXMgYXV0aG9yaXplZCBieSB0aGUgT3BlbkxEQVAKICogUHVibGljIExpY2Vuc2UuCiAq CiAqIEEgY29weSBvZiB0aGlzIGxpY2Vuc2UgaXMgYXZhaWxhYmxlIGluIHRoZSBmaWxlIExJQ0VO U0UgaW4gdGhlCiAqIHRvcC1sZXZlbCBkaXJlY3Rvcnkgb2YgdGhlIGRpc3RyaWJ1dGlvbiBvciwg YWx0ZXJuYXRpdmVseSwgYXQKICogPGh0dHA6Ly93d3cuT3BlbkxEQVAub3JnL2xpY2Vuc2UuaHRt bD4uCiAqLwoKLyogVHJpZ2dlciBNREJfTUFQX0ZVTEwgZXJyb3IsIHJlbW92ZSBoYWxmIG9mIHRo ZSByZWNvcmRzIGFuZCB0cnkgdG8gCiAgIGluc2VydCBsYXN0IGZhaWxlZCByZWNvcmQgYWdhaW4g Ki8KCiNpbmNsdWRlIDxzdGRpby5oPgojaW5jbHVkZSA8c3RkbGliLmg+CiNpbmNsdWRlIDx0aW1l Lmg+CiNpbmNsdWRlICJsbWRiLmgiCgojZGVmaW5lIEUoZXhwcikgQ0hFQ0soKHJjID0gKGV4cHIp KSA9PSBNREJfU1VDQ0VTUywgI2V4cHIpCiNkZWZpbmUgUkVTKGVyciwgZXhwcikgKChyYyA9IGV4 cHIpID09IChlcnIpIHx8IChDSEVDSyghcmMsICNleHByKSwgMCkpCiNkZWZpbmUgQ0hFQ0sodGVz dCwgbXNnKSAoKHRlc3QpID8gKHZvaWQpMCA6ICgodm9pZClmcHJpbnRmKHN0ZGVyciwgXAoJIiVz OiVkOiAlczogJXNcbiIsIF9fRklMRV9fLCBfX0xJTkVfXywgbXNnLCBtZGJfc3RyZXJyb3IocmMp KSwgYWJvcnQoKSkpCgojZGVmaW5lIE1BWF9LRVlTIDEwMjQKI2RlZmluZSBSRVBFQVQgMTAwCgpN REJfdmFsIHJhbmRvbV9tZGJfdmFsKHNpemVfdCBzaXplKTsKdm9pZCBwcmludF9zdGF0cyhNREJf ZW52ICplbnYsIE1EQl9kYmkgZGJpKTsKCmludCBtYWluKGludCBhcmdjLGNoYXIgKiBhcmd2W10p CnsKCWludCByZWNvcmRzID0gMCwgaSwgcmM7CglpbnQgbGFzdERhdGFTaXplLCB0cmltVGFyZ2V0 OwoJTURCX2VudiAqZW52OwoJTURCX2RiaSBkYmk7CglNREJfdmFsIGtleSwgZGF0YTsKCU1EQl92 YWwga2V5c1tNQVhfS0VZU10sIHZhbHVlc1tNQVhfS0VZU107CglNREJfdHhuICp0eG47CgoJc3Jh bmQodGltZShOVUxMKSk7CgoJRShtZGJfZW52X2NyZWF0ZSgmZW52KSk7CglFKG1kYl9lbnZfc2V0 X21heHJlYWRlcnMoZW52LCAxKSk7CglFKG1kYl9lbnZfc2V0X21hcHNpemUoZW52LCA1MTIgKiAx MDI0KSk7CglFKG1kYl9lbnZfc2V0X21heGRicyhlbnYsIDQpKTsKCUUobWRiX2Vudl9vcGVuKGVu diwgIi4vdGVzdGRiIiwgTURCX0ZJWEVETUFQfE1EQl9OT1NZTkMsIDA2NjQpKTsKCglFKG1kYl90 eG5fYmVnaW4oZW52LCBOVUxMLCAwLCAmdHhuKSk7CglFKG1kYl9kYmlfb3Blbih0eG4sICJpZDEi LCBNREJfQ1JFQVRFLCAmZGJpKSk7CiAgICBFKG1kYl90eG5fY29tbWl0KHR4bikpOwoKICAgIGZv ciAoaSA9IDA7IGkgPCBSRVBFQVQ7IGkrKykgewoJCXByaW50ZigiRmlsbGluZyB1cCBEQiB1bnRp bCB3ZSBnZXQgTURCX0ZVTEwgZXJyb3IgKGN5Y2xlICVkKVxuIiwgaSk7CgkJd2hpbGUgKHJlY29y ZHMgPCBNQVhfS0VZUykgewkKCQkJa2V5ID0gcmFuZG9tX21kYl92YWwoMTYpOwoJCQlsYXN0RGF0 YVNpemUgPSByYW5kKCkgJSA1MDAwICsgNjQ7CgkJCWRhdGEgPSByYW5kb21fbWRiX3ZhbChsYXN0 RGF0YVNpemUpOwoKCQkJRShtZGJfdHhuX2JlZ2luKGVudiwgTlVMTCwgMCwgJnR4bikpOwoJCQlp ZiAobWRiX3B1dCh0eG4sIGRiaSwgJmtleSwgJmRhdGEsIE1EQl9OT09WRVJXUklURSkgPT0gTURC X01BUF9GVUxMKSB7CgkJCQlwcmludGYoIiAgICBHb3QgTURCX01BUF9GVUxMIGF0IG1kYl9wdXQu IFJlY29yZCBzaXplOiAlZFxuIiwgbGFzdERhdGFTaXplKTsKCQkJCW1kYl90eG5fYWJvcnQodHhu KTsKCQkJICAgIGZyZWUoa2V5Lm12X2RhdGEpOwoJCQkgICAgZnJlZShkYXRhLm12X2RhdGEpOwoJ CQkJYnJlYWs7CgkJCX0KCQkJaWYgKG1kYl90eG5fY29tbWl0KHR4bikgPT0gTURCX01BUF9GVUxM KSB7CgkJCQlwcmludGYoIiAgICBHb3QgTURCX01BUF9GVUxMIGF0IG1kYl90eG5fY29tbWl0LiBS ZWNvcmQgc2l6ZTogJWRcbiIsIGxhc3REYXRhU2l6ZSk7CgkJCSAgICBmcmVlKGtleS5tdl9kYXRh KTsKCQkJICAgIGZyZWUoZGF0YS5tdl9kYXRhKTsKCQkJCWJyZWFrOwkJCQoJCQl9CgkJCWtleXNb cmVjb3Jkc10gPSBrZXk7CgkJCXZhbHVlc1tyZWNvcmRzKytdID0gZGF0YTsKCQl9CgkJcHJpbnRf c3RhdHMoZW52LCBkYmkpOwoJCXRyaW1UYXJnZXQgPSByZWNvcmRzIC8gMjsKCQlwcmludGYoIiAg ICBSZW1vdmluZyBzb21lIHJlY29yZHM6ICVkIC0+ICVkXG4iLCByZWNvcmRzLCB0cmltVGFyZ2V0 KTsKCQl3aGlsZSAodHJpbVRhcmdldCA8IHJlY29yZHMpIHsKCQkJa2V5ID0ga2V5c1stLXJlY29y ZHNdOwoJCQlkYXRhID0gdmFsdWVzW3JlY29yZHNdOwoJCQlFKG1kYl90eG5fYmVnaW4oZW52LCBO VUxMLCAwLCAmdHhuKSk7CgkJCUUobWRiX2RlbCh0eG4sIGRiaSwgJmtleSwgTlVMTCkpOwoJCSAg ICBFKG1kYl90eG5fY29tbWl0KHR4bikpOwoJCSAgICBmcmVlKGtleS5tdl9kYXRhKTsKCQkgICAg ZnJlZShkYXRhLm12X2RhdGEpOwoJCX0KCQlwcmludF9zdGF0cyhlbnYsIGRiaSk7CgoJCXByaW50 ZigiICAgIFJlLWluc2VydGluZyBmYWlsZWQgcmVjb3JkIGFnYWluXG4iKTsKCQlrZXkgPSByYW5k b21fbWRiX3ZhbCgxNik7CgkJZGF0YSA9IHJhbmRvbV9tZGJfdmFsKGxhc3REYXRhU2l6ZSk7CgkJ a2V5c1tyZWNvcmRzXSA9IGtleTsKCQl2YWx1ZXNbcmVjb3JkcysrXSA9IGRhdGE7CgoJCUUobWRi X3R4bl9iZWdpbihlbnYsIE5VTEwsIDAsICZ0eG4pKTsKCQlFKG1kYl9wdXQodHhuLCBkYmksICZr ZXksICZkYXRhLCBNREJfTk9PVkVSV1JJVEUpKTsKCSAgICBFKG1kYl90eG5fY29tbWl0KHR4bikp OwoJfQoKCW1kYl9kYmlfY2xvc2UoZW52LCBkYmkpOwoJbWRiX2Vudl9jbG9zZShlbnYpOwoJcmV0 dXJuIDA7Cn0KCnZvaWQgcHJpbnRfc3RhdHMoTURCX2VudiAqZW52LCBNREJfZGJpIGRiaSkKewoJ aW50IHJjOwoJTURCX3R4biAqdHhuOwoJTURCX3N0YXQgbXN0OwoKCUUobWRiX3R4bl9iZWdpbihl bnYsIE5VTEwsIDAsICZ0eG4pKTsKCUUobWRiX3N0YXQodHhuLCBkYmksICZtc3QpKTsKCW1kYl90 eG5fYWJvcnQodHhuKTsKCXByaW50ZigiICAgIFN0YXRzOiBlbnRyaWVzID0gJXp1ICBwYWdlcyA9 ICV6dSArICV6dSArICV6dVxuIiwgbXN0Lm1zX2VudHJpZXMsIAoJCW1zdC5tc19icmFuY2hfcGFn ZXMsIG1zdC5tc19sZWFmX3BhZ2VzLCBtc3QubXNfb3ZlcmZsb3dfcGFnZXMpOwp9CgpNREJfdmFs IHJhbmRvbV9tZGJfdmFsKHNpemVfdCBzaXplKQp7CglzaXplX3QgaTsKCU1EQl92YWwgdmFsOwoJ Y2hhciAqZGF0YTsKCglkYXRhID0gKGNoYXIgKiltYWxsb2Moc2l6ZSk7Cglmb3IgKGkgPSAwOyBp IDwgc2l6ZTsgaSsrKSB7CgkJZGF0YVtpXSA9IHJhbmQoKSAlIDI1NjsKCX0KCXZhbC5tdl9zaXpl ID0gc2l6ZTsKCXZhbC5tdl9kYXRhID0gZGF0YTsKCXJldHVybiB2YWw7Cn0K --_002_0D2DCEC482B542758A1B48103AF58106linkedinbiz_--

1 0

Re: (ITS#9000) memberOf value is lost when group DN is modified with only case change
by clement.oudot＠worteks.com 05 Jun '19

05 Jun '19

Le 05/06/2019 à 15:30, ondra(a)mistotebe.net a écrit : > On Wed, Mar 27, 2019 at 04:39:14PM +0000, clement.oudot(a)worteks.com wrote: >> Seems it is because memberof try to add the new value before deleting the old >> one. As the values are the same when ignoring the case, the modification is >> rejected. >> >> I would say that doing the LDAP_SLIST_REMOVE before the LDAP_SLIST_INSERT_HEAD >> in memberof.c should be enough but I don't know if this is safe. > Alternatively checking that the new DN is not equivalent to the old and > if so, noop it? That's just been uploaded to > https://github.com/mistotebe/openldap/tree/its9000 Seems indeed a better solution! -- Clément Oudot | Identity Solutions Manager clement.oudot(a)worteks.com Worteks | https://www.worteks.com

1 0

Re: (ITS#9000) memberOf value is lost when group DN is modified with only case change
by ondra＠mistotebe.net 05 Jun '19

05 Jun '19

On Wed, Mar 27, 2019 at 04:39:14PM +0000, clement.oudot(a)worteks.com wrote: > Seems it is because memberof try to add the new value before deleting the old > one. As the values are the same when ignoring the case, the modification is > rejected. > > I would say that doing the LDAP_SLIST_REMOVE before the LDAP_SLIST_INSERT_HEAD > in memberof.c should be enough but I don't know if this is safe. Alternatively checking that the new DN is not equivalent to the old and if so, noop it? That's just been uploaded to https://github.com/mistotebe/openldap/tree/its9000 Regards, -- 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#9029) MDB_MAP_FULL error after removing some records from DB
by adubovkin＠linkedin.com 04 Jun '19

04 Jun '19

ICAgIC0tT24gVHVlc2RheSwgTWF5IDI4LCAyMDE5IDEwOjEyIFBNICswMDAwIGFkdWJvdmtpbkBs aW5rZWRpbi5jb20gd3JvdGU6DQogICAgDQogICAgPiBGdWxsX05hbWU6IEFsZXgNCiAgICA+IFZl cnNpb246IExNREIgMC45LjIzDQogICAgPiBPUzogaU9TDQogICAgPiBVUkw6IGh0dHBzOi8vbmFt MDYuc2FmZWxpbmtzLnByb3RlY3Rpb24ub3V0bG9vay5jb20vP3VybD1odHRwcyUzQSUyRiUyRmhh c3RlYmluLmNvbSUyRnJhdyUyRmFyZXhlY2VmZXcmYW1wO2RhdGE9MDIlN0MwMSU3Q2FkdWJvdmtp biU0MGxpbmtlZGluLmNvbSU3QzllYWUyMGQ5NDJlNDQ1NzM1YjE0MDhkNmU5MzBjMTA1JTdDNzJm OTg4YmY4NmYxNDFhZjkxYWIyZDdjZDAxMWRiNDclN0MxJTdDMSU3QzYzNjk1Mjc5Mjk0OTU1MjUz NiZhbXA7c2RhdGE9a2VtNmQzdHJ0MjJHdWpLQlJuV3JqOFA4QUk3RlhBJTJGOEpCT2ZHeThZZUFJ JTNEJmFtcDtyZXNlcnZlZD0wDQogICAgPiBTdWJtaXNzaW9uIGZyb206IChOVUxMKSAoMjYyMDox MTk6NTAwMTozMDAwOjI0MmM6M2JlYTphY2VjOjZhN2QpDQoNCk9uIDYvNC8xOSwgMjowOCBQTSwg IlF1YW5haCBHaWJzb24tTW91bnQiIDxxdWFuYWhAc3ltYXMuY29tPiB3cm90ZToNCg0KICAgIElU UyM4OTY5IHBlcmhhcHM/DQogICAgDQogICAgPGh0dHBzOi8vbmFtMDYuc2FmZWxpbmtzLnByb3Rl Y3Rpb24ub3V0bG9vay5jb20vP3VybD1odHRwcyUzQSUyRiUyRnd3dy5vcGVubGRhcC5vcmclMkZp dHMlMkZpbmRleC5jZ2klMkYlM0ZmaW5kaWQlM0Q4OTY5JmFtcDtkYXRhPTAyJTdDMDElN0NhZHVi b3ZraW4lNDBsaW5rZWRpbi5jb20lN0M5ZWFlMjBkOTQyZTQ0NTczNWIxNDA4ZDZlOTMwYzEwNSU3 QzcyZjk4OGJmODZmMTQxYWY5MWFiMmQ3Y2QwMTFkYjQ3JTdDMSU3QzElN0M2MzY5NTI3OTI5NDk1 NTI1MzYmYW1wO3NkYXRhPUpSTnpzV0pLRDNoUlgyYk1yalZJZWROb2RRb1c2Mm9qNEhBRjdkcVd3 MnMlM0QmYW1wO3Jlc2VydmVkPTA+DQogICAgDQogICAgLS1RdWFuYWgNCiAgICANCiAgICANCiAg ICAtLQ0KICAgIA0KICAgIFF1YW5haCBHaWJzb24tTW91bnQNCiAgICBQcm9kdWN0IEFyY2hpdGVj dA0KICAgIFN5bWFzIENvcnBvcmF0aW9uDQogICAgUGFja2FnZWQsIGNlcnRpZmllZCwgYW5kIHN1 cHBvcnRlZCBMREFQIHNvbHV0aW9ucyBwb3dlcmVkIGJ5IE9wZW5MREFQOg0KDQotLS0tLS0tLS0N CkkgdGVzdGVkIGl0IHdpdGggdGhlIGxhdGVzdCBtYXN0ZXIgYW5kIHRoZSBidWcgaXMgc3RpbGwg dGhlcmUgKCgoDQoNClRoYW5rcywNCkFsZXhleQ0KICAgIA0KICAgIA0KDQo=

1 0

Re: (ITS#9029) MDB_MAP_FULL error after removing some records from DB
by hyc＠symas.com 04 Jun '19

04 Jun '19

quanah(a)symas.com wrote: > --On Tuesday, May 28, 2019 10:12 PM +0000 adubovkin(a)linkedin.com wrote: > >> Full_Name: Alex >> Version: LMDB 0.9.23 >> OS: iOS >> URL: https://hastebin.com/raw/arexecefew >> Submission from: (NULL) (2620:119:5001:3000:242c:3bea:acec:6a7d) > > ITS#8969 perhaps? > > <https://www.openldap.org/its/index.cgi/?findid=8969> No. MAP_FULL is a user error, PAGE_FULL is an internal bug. ITS#8969 has nothing to do with this. As the doc says, use a large enough mapsize when you create the environment. You can also use mdb_env_set_mapsize() to change the size of an existing env. This is not a bug in LMDB, this ITS will be closed. -- -- 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#9029) MDB_MAP_FULL error after removing some records from DB
by quanah＠symas.com 04 Jun '19

04 Jun '19

--On Tuesday, May 28, 2019 10:12 PM +0000 adubovkin(a)linkedin.com wrote: > Full_Name: Alex > Version: LMDB 0.9.23 > OS: iOS > URL: https://hastebin.com/raw/arexecefew > Submission from: (NULL) (2620:119:5001:3000:242c:3bea:acec:6a7d) ITS#8969 perhaps? <https://www.openldap.org/its/index.cgi/?findid=8969> --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#8417) mdb_load could use an option to specify the mapsize.
by quanah＠symas.com 04 Jun '19

04 Jun '19

--On Tuesday, May 03, 2016 12:48 PM +0000 eriixblaike+git(a)gmail.com wrote: > I, Eric Monson, 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. > > https://eriix.org/download_file/eric-monson-16-05-03.patch This URL is not accessible (requires a login?). I suggest uploading it to our FTP server as documented for contributed patches. Thanks! --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#9023) crash using ppolicy chaining from slave to master
by ondra＠mistotebe.net 03 Jun '19

03 Jun '19

On Mon, Jun 03, 2019 at 09:43:11AM +0000, jpayanides(a)prosodie.com wrote: > Hello Ondřej, Hi Jean-Philippe, > sorry to answer so late, I was off (sick). > > Answering your questions: > > I didn't try to reproduce the crash on a different system. this will be the easiest way to get more information both on whether the crash might be coming from another of the system and, with newer tools, more about the crash itself. > What is the goal of installing an new version of gdb on my system ? I am > not sure it will be easy to proceed. >From what you have provided, the version of gdb you have used seems to have issues debugging this program, a newer tool might be able to do a better job (or you can try remote debugging with gdbserver). But if you can, trying to reproduce this on a different (newer) system should be a priority. > Following your advise, I have corrected the chain configuration with > removing mode=self, but it didn't change nothing regarding the crash. > > do you think it could be possible that the glibc contains bugs resulting > that crash? Hard to tell, your system is ancient and I have no idea how stable any part of it was. > I do not know what to do. Would it be relevant to upgrade the OS? If you can upgrade the system at all, please do so, it has been about 12 years since Debian Etch was released and many things have happened since. Regards, -- 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#9023) crash using ppolicy chaining from slave to master
by jpayanides＠prosodie.com 03 Jun '19

03 Jun '19

--_000_AM0PR0202MB35530E1160E3DCDDFBD1D06ABA140AM0PR0202MB3553_ Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 SGVsbG8gT25kxZllaiwNCg0Kc29ycnkgdG8gYW5zd2VyIHNvIGxhdGUsIEkgd2FzIG9mZiAoc2lj aykuDQoNCg0KQW5zd2VyaW5nIHlvdXIgcXVlc3Rpb25zOg0KDQoNCkkgZGlkbid0IHRyeSB0byBy ZXByb2R1Y2UgdGhlIGNyYXNoIG9uIGEgZGlmZmVyZW50IHN5c3RlbS4NCg0KV2hhdCBpcyB0aGUg Z29hbCBvZiBpbnN0YWxsaW5nIGFuIG5ldyB2ZXJzaW9uIG9mIGdkYiBvbiBteSBzeXN0ZW0gPyBJ IGFtIG5vdCBzdXJlIGl0IHdpbGwgYmUgZWFzeSB0byBwcm9jZWVkLg0KDQpGb2xsb3dpbmcgeW91 ciBhZHZpc2UsIEkgaGF2ZSBjb3JyZWN0ZWQgdGhlIGNoYWluIGNvbmZpZ3VyYXRpb24gd2l0aCBy ZW1vdmluZyBtb2RlPXNlbGYsIGJ1dCBpdCBkaWRuJ3QgY2hhbmdlIG5vdGhpbmcgcmVnYXJkaW5n IHRoZSBjcmFzaC4NCg0KDQpkbyB5b3UgdGhpbmsgaXQgY291bGQgYmUgcG9zc2libGUgdGhhdCB0 aGUgZ2xpYmMgY29udGFpbnMgYnVncyByZXN1bHRpbmcgdGhhdCBjcmFzaD8NCg0KDQpJIGRvIG5v dCBrbm93IHdoYXQgdG8gZG8uIFdvdWxkIGl0IGJlIHJlbGV2YW50IHRvIHVwZ3JhZGUgdGhlIE9T Pw0KDQoNCmtpbmQgcmVnYXJkcw0KDQoNCkplYW4tUGhpbGlwcGUgQXlhbmlkZXMNCkNvbmNlcHRp b24gZXQgYXJjaGl0ZWN0dXJlIHPDqWN1cml0w6kNClNlcnZpY2UgJiBPcGVyYXRpb24gLyBJbmZy YXN0cnVjdHVyZSBOZXR3b3JrIFNlY3VyaXR5IEJhY2tib25lDQp0w6lsICszMzEzNDQ5MDYyOA0K UHJvc29kaWUtQ2FwZ2VtaW5pDQpQZW9wbGUgbWF0dGVyLCByZXN1bHRzIGNvdW50Lg0KX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX18NCkRlIDogT25kxZllaiBLdXpuw61rIDxvbmRyYUBt aXN0b3RlYmUubmV0Pg0KRW52b3nDqSA6IGx1bmRpIDIwIG1haSAyMDE5IDE2OjE1OjMxDQrDgCA6 IEFZQU5JREVTLCBKRUFOLVBISUxJUFBFDQpDYyA6IG9wZW5sZGFwLWl0c0BPcGVuTERBUC5vcmcN Ck9iamV0IDogUmU6IChJVFMjOTAyMykgY3Jhc2ggdXNpbmcgcHBvbGljeSBjaGFpbmluZyBmcm9t IHNsYXZlIHRvIG1hc3Rlcg0KDQpPbiBNb24sIE1heSAyMCwgMjAxOSBhdCAxMDoyOTowMkFNICsw MDAwLCBBWUFOSURFUywgSkVBTi1QSElMSVBQRSB3cm90ZToNCj4gWWVzLCBpdCBzZXJ2ZXMgdHJh ZmZpYy4gSXQgZG9lc24ndCBjcmFzaCB1bnRpbCBJIHJ1biBhIGJpbmQgd2l0aCBhDQo+IHdyb25n IHBhc3N3b3JkLg0KPg0KPj4gKGdkYikgY29udA0KPj4gQ29udGludWluZy4NCj4NCj4gW0xEQVAg c2VhcmNoIHdpdGggd3JvbmcgcGFzc3dvcmRdDQo+DQo+PiBbTmV3IFRocmVhZCAtMTIzNzU0MTk2 OCAoTFdQIDI5MzgwKV0NCj4NCj4+IFByb2dyYW0gZXhpdGVkIHdpdGggY29kZSAwMTc3Lg0KPj4g KGdkYikgdGhyZWFkIGFwcGx5IGFsbCBidCBmdWxsDQo+DQo+IFllcyBzb3JyeSwgSXQgcnVucyBv biBhbiBvbGQgdmVyc2lvbiBvZiBkZWJpYW46IDQ6MCAzMiBiaXRzIHRoYXQgSSBhbQ0KPiBub3Qg YXV0aG9yaXNlZCB0byB1cGdyYWRlLg0KPg0KPiBJdCB0aGUgZmlyc3QgdGltZSB3ZSByZWNvcmQg dGhhdCBzb3J0IG9mIGlzc3VlIG9uIHRoYXQgcGxhdGZvcm3igKYNCg0KSGkgSmVhbi1QaGlsaXBw ZSwNCmFyZSB5b3UgYWJsZSB0byByZXByb2R1Y2UgdGhpcyBvbiBhIGRpZmZlcmVudCBzeXN0ZW0s IGlmIG5vdCwgY2FuIHlvdQ0KZ2V0IGEgbW9yZSByZWNlbnQgZ2RiIG9uIHRoYXQgc3lzdGVtPw0K DQpJIGhhdmUgdHJpZWQgdG8gcmVwcm9kdWNlIHdpdGggYSBjb25maWcgc2ltaWxhciB0byB0aGUg b25lIHlvdSBkZXNjcmliZQ0KZGlkbid0IG1hbmFnZSB0byBwcm92b2tlIGEgc2VnZmF1bHQgd2l0 aCByZTI0IG5vciBtYXN0ZXIuDQoNCk9uIGEgc2lkZSBub3RlLCBJIGRvbid0IHRoaW5rIHJ1bm5p bmcgdGhlIGNoYWluIG92ZXJsYXkgd2l0aCBtb2RlPXNlbGYNCndpbGwgd29yayB0byBwcm9wYWdh dGUgdGhlIHBwb2xpY3kgaW5mb3JtYXRpb24gdGhlIHdheSB5b3Ugd2FudC4gVGhlDQpzYW1lIGZh aWxpbmcgY3JlZGVudGlhbHMgd2lsbCBiZSB1c2VkIHRvIGNvbnRhY3QgdGhlIHVwc3RyZWFtIHNl cnZlciBhbmQNCnNvIHRoZSBpbml0aWFsIGJpbmQgd2lsbCBiZSByZWplY3RlZCBhZ2Fpbiwgbm90 IGFsbG93aW5nIHRoZQ0KbW9kaWZpY2F0aW9uIHRvIGJlIHBlcmZvcm1lZC4NCg0KUmVnYXJkcywN Cg0KLS0NCk9uZMWZZWogS3V6bsOtaw0KU2VuaW9yIFNvZnR3YXJlIEVuZ2luZWVyDQpTeW1hcyBD b3Jwb3JhdGlvbiAgICAgICAgICAgICAgICAgICAgICAgaHR0cDovL3d3dy5zeW1hcy5jb20NClBh Y2thZ2VkLCBjZXJ0aWZpZWQsIGFuZCBzdXBwb3J0ZWQgTERBUCBzb2x1dGlvbnMgcG93ZXJlZCBi eSBPcGVuTERBUA0KVGhpcyBtZXNzYWdlIGNvbnRhaW5zIGluZm9ybWF0aW9uIHRoYXQgbWF5IGJl IHByaXZpbGVnZWQgb3IgY29uZmlkZW50aWFsIGFuZCBpcyB0aGUgcHJvcGVydHkgb2YgdGhlIENh cGdlbWluaSBHcm91cC4gSXQgaXMgaW50ZW5kZWQgb25seSBmb3IgdGhlIHBlcnNvbiB0byB3aG9t IGl0IGlzIGFkZHJlc3NlZC4gSWYgeW91IGFyZSBub3QgdGhlIGludGVuZGVkIHJlY2lwaWVudCwg eW91IGFyZSBub3QgYXV0aG9yaXplZCB0byByZWFkLCBwcmludCwgcmV0YWluLCBjb3B5LCBkaXNz ZW1pbmF0ZSwgZGlzdHJpYnV0ZSwgb3IgdXNlIHRoaXMgbWVzc2FnZSBvciBhbnkgcGFydCB0aGVy ZW9mLiBJZiB5b3UgcmVjZWl2ZSB0aGlzIG1lc3NhZ2UgaW4gZXJyb3IsIHBsZWFzZSBub3RpZnkg dGhlIHNlbmRlciBpbW1lZGlhdGVseSBhbmQgZGVsZXRlIGFsbCBjb3BpZXMgb2YgdGhpcyBtZXNz YWdlLgo= --_000_AM0PR0202MB35530E1160E3DCDDFBD1D06ABA140AM0PR0202MB3553_ Content-Type: text/html; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxzdHlsZSB0eXBlPSJ0ZXh0L2NzcyIgc3R5bGU9 ImRpc3BsYXk6bm9uZTsiPjwhLS0gUCB7bWFyZ2luLXRvcDowO21hcmdpbi1ib3R0b206MDt9IC0t Pjwvc3R5bGU+DQo8L2hlYWQ+DQo8Ym9keSBkaXI9Imx0ciI+DQo8ZGl2IGlkPSJkaXZ0YWdkZWZh dWx0d3JhcHBlciIgc3R5bGU9ImZvbnQtc2l6ZToxMnB0O2NvbG9yOiMwMDAwMDA7Zm9udC1mYW1p bHk6Q2FsaWJyaSxIZWx2ZXRpY2Esc2Fucy1zZXJpZjsiIGRpcj0ibHRyIj4NCjxwIHN0eWxlPSJt YXJnaW4tdG9wOjA7bWFyZ2luLWJvdHRvbTowIj5IZWxsbyA8Zm9udCBzaXplPSIyIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExcHQ7Ij5PbmTFmWVqLDwvc3Bhbj48L2ZvbnQ+PC9wPg0KPHAgc3R5 bGU9Im1hcmdpbi10b3A6MDttYXJnaW4tYm90dG9tOjAiPjxmb250IHNpemU9IjIiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTFwdDsiPnNvcnJ5IHRvIGFuc3dlciBzbyBsYXRlLCBJIHdhcyBvZmYg KHNpY2spLjwvc3Bhbj48L2ZvbnQ+PC9wPg0KPHAgc3R5bGU9Im1hcmdpbi10b3A6MDttYXJnaW4t Ym90dG9tOjAiPjxmb250IHNpemU9IjIiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTFwdDsiPjxi cj4NCjwvc3Bhbj48L2ZvbnQ+PC9wPg0KPHAgc3R5bGU9Im1hcmdpbi10b3A6MDttYXJnaW4tYm90 dG9tOjAiPjxmb250IHNpemU9IjIiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTFwdDsiPkFuc3dl cmluZyB5b3VyIHF1ZXN0aW9uczo8L3NwYW4+PC9mb250PjwvcD4NCjxwIHN0eWxlPSJtYXJnaW4t dG9wOjA7bWFyZ2luLWJvdHRvbTowIj48Zm9udCBzaXplPSIyIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExcHQ7Ij48YnI+DQo8L3NwYW4+PC9mb250PjwvcD4NCjxwIHN0eWxlPSJtYXJnaW4tdG9w OjA7bWFyZ2luLWJvdHRvbTowIj48Zm9udCBzaXplPSIyIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExcHQ7Ij5JIGRpZG4ndCB0cnkgdG8gcmVwcm9kdWNlIHRoZSBjcmFzaCBvbiBhIGRpZmZlcmVu dCBzeXN0ZW0uPC9zcGFuPjwvZm9udD48L3A+DQo8cCBzdHlsZT0ibWFyZ2luLXRvcDowO21hcmdp bi1ib3R0b206MCI+PGZvbnQgc2l6ZT0iMiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMXB0OyI+ V2hhdCBpcyB0aGUgZ29hbCBvZiBpbnN0YWxsaW5nIGFuIG5ldyB2ZXJzaW9uIG9mIGdkYiBvbiBt eSBzeXN0ZW0gPyBJIGFtIG5vdCBzdXJlIGl0IHdpbGwgYmUgZWFzeSB0byBwcm9jZWVkLjwvc3Bh bj48L2ZvbnQ+PC9wPg0KPHAgc3R5bGU9Im1hcmdpbi10b3A6MDttYXJnaW4tYm90dG9tOjAiPjxm b250IHNpemU9IjIiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTFwdDsiPkZvbGxvd2luZyB5b3Vy IGFkdmlzZSwgSSBoYXZlIGNvcnJlY3RlZDwvc3Bhbj48L2ZvbnQ+IHRoZSBjaGFpbiBjb25maWd1 cmF0aW9uIHdpdGggcmVtb3ZpbmcgbW9kZT1zZWxmLCBidXQgaXQgZGlkbid0IGNoYW5nZSBub3Ro aW5nIHJlZ2FyZGluZyB0aGUgY3Jhc2guPC9wPg0KPHAgc3R5bGU9Im1hcmdpbi10b3A6MDttYXJn aW4tYm90dG9tOjAiPjxicj4NCjwvcD4NCjxwIHN0eWxlPSJtYXJnaW4tdG9wOjA7bWFyZ2luLWJv dHRvbTowIj5kbyB5b3UgdGhpbmsgaXQgY291bGQgYmUgcG9zc2libGUgdGhhdCB0aGUgZ2xpYmMg Y29udGFpbnMgYnVncyByZXN1bHRpbmcgdGhhdCBjcmFzaD88YnI+DQo8L3A+DQo8cCBzdHlsZT0i bWFyZ2luLXRvcDowO21hcmdpbi1ib3R0b206MCI+PGJyPg0KPC9wPg0KPHAgc3R5bGU9Im1hcmdp bi10b3A6MDttYXJnaW4tYm90dG9tOjAiPkkgZG8gbm90IGtub3cgd2hhdCB0byBkby4gV291bGQg aXQgYmUgcmVsZXZhbnQgdG8gdXBncmFkZSB0aGUgT1M/PC9wPg0KPHAgc3R5bGU9Im1hcmdpbi10 b3A6MDttYXJnaW4tYm90dG9tOjAiPjxicj4NCjwvcD4NCjxwIHN0eWxlPSJtYXJnaW4tdG9wOjA7 bWFyZ2luLWJvdHRvbTowIj5raW5kIHJlZ2FyZHM8YnI+DQo8L3A+DQo8cCBzdHlsZT0ibWFyZ2lu LXRvcDowO21hcmdpbi1ib3R0b206MCI+PGJyPg0KPC9wPg0KPGRpdiBpZD0iU2lnbmF0dXJlIj4N CjxtZXRhIGNvbnRlbnQ9InRleHQvaHRtbDsgY2hhcnNldD1VVEYtOCI+DQo8ZGl2IGlkPSJkaXZ0 YWdkZWZhdWx0d3JhcHBlciIgZGlyPSJsdHIiIHN0eWxlPSJmb250LXNpemU6IDEycHQ7IGNvbG9y OiByZ2IoMCwgMCwgMCk7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBIZWx2ZXRpY2EsIHNhbnMtc2Vy aWYsICZxdW90O0Vtb2ppRm9udCZxdW90OywgJnF1b3Q7QXBwbGUgQ29sb3IgRW1vamkmcXVvdDss ICZxdW90O1NlZ29lIFVJIEVtb2ppJnF1b3Q7LCBOb3RvQ29sb3JFbW9qaSwgJnF1b3Q7U2Vnb2Ug VUkgU3ltYm9sJnF1b3Q7LCAmcXVvdDtBbmRyb2lkIEVtb2ppJnF1b3Q7LCBFbW9qaVN5bWJvbHM7 Ij4NCjxkaXYgaWQ9ImRpdnRhZ2RlZmF1bHR3cmFwcGVyIiBkaXI9Imx0ciIgc3R5bGU9ImZvbnQt c2l6ZTogMTJwdDsgY29sb3I6IHJnYigwLCAwLCAwKTsgYmFja2dyb3VuZC1jb2xvcjogcmdiKDI1 NSwgMjU1LCAyNTUpOyBmb250LWZhbWlseTogQ2FsaWJyaSwgQXJpYWwsIEhlbHZldGljYSwgc2Fu cy1zZXJpZiwgJnF1b3Q7RW1vamlGb250JnF1b3Q7LCAmcXVvdDtBcHBsZSBDb2xvciBFbW9qaSZx dW90OywgJnF1b3Q7U2Vnb2UgVUkgRW1vamkmcXVvdDssIE5vdG9Db2xvckVtb2ppLCAmcXVvdDtT ZWdvZSBVSSBTeW1ib2wmcXVvdDssICZxdW90O0FuZHJvaWQgRW1vamkmcXVvdDssIEVtb2ppU3lt Ym9sczsiPg0KPHA+PHNwYW4gbGFuZz0iZnIiPjwvc3Bhbj48L3A+DQo8ZGl2IHN0eWxlPSJtYXJn aW46MCI+PGZvbnQgc2l6ZT0iMyIgZmFjZT0iVGltZXMgTmV3IFJvbWFuLHNlcmlmIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjEycHQiPjxmb250IHNpemU9IjIiIGZhY2U9IlZlcmRhbmEsc2Fucy1z ZXJpZiIgY29sb3I9IiMwMDQ2OEMiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OXB0Ij48Yj5KZWFu LVBoaWxpcHBlIEF5YW5pZGVzPGJyPg0KPC9iPjwvc3Bhbj48L2ZvbnQ+PC9zcGFuPjwvZm9udD48 L2Rpdj4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6Ny41cHQ7IGZvbnQtZmFtaWx5OiZxdW90O0Fy aWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7IGNvbG9yOmJsYWNrIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjcuNXB0OyBmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7OyBjb2xvcjpibGFjayI+Q29uY2VwdGlvbiBldCBhcmNoaXRlY3R1cmUg c8OpY3VyaXTDqTwvc3Bhbj48YnI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjhwdDsgZm9udC1m YW1pbHk6QXJpYWwsSGVsdmV0aWNhLHNhbnMtc2VyaWYiPlNlcnZpY2UgJmFtcDsgT3BlcmF0aW9u IC8gSW5mcmFzdHJ1Y3R1cmU8L3NwYW4+PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4w cHQ7IGZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7 IGNvbG9yOmJsYWNrIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjhwdDsgZm9udC1mYW1pbHk6QXJp YWwsSGVsdmV0aWNhLHNhbnMtc2VyaWYiPg0KIE5ldHdvcmsgU2VjdXJpdHkgQmFja2JvbmU8L3Nw YW4+PGJyPg0KPGEgY2xhc3M9Im8zNjVidXR0b24iIGlkPSJMUE5vTFAiPjxzcGFuIGNsYXNzPSJt cy1mb250LXMgbXMtZm9udC1jb2xvci10aGVtZVByaW1hcnkiIHRpdGxlPSImIzQzOzMzMTM0NDkw NjI4Ij50w6lsICYjNDM7MzMxMzQ0OTA2Mjg8L3NwYW4+PC9hPjxicj4NClByb3NvZGllLUNhcGdl bWluaTxicj4NCjwvc3Bhbj48c3Ryb25nPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtB cmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7OyBjb2xvcjojMDA5OENDIj5QZW9wbGUg bWF0dGVyLCByZXN1bHRzIGNvdW50Ljwvc3Bhbj48L3N0cm9uZz48L2Rpdj4NCjxzdHJvbmc+PHNw YW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDs7IGNvbG9yOiMwMDk4Q0MiPjwvc3Bhbj48L3N0cm9uZz48L2Rpdj4NCjwvZGl2Pg0KPC9k aXY+DQo8aHIgc3R5bGU9ImRpc3BsYXk6aW5saW5lLWJsb2NrO3dpZHRoOjk4JSIgdGFiaW5kZXg9 Ii0xIj4NCjxkaXYgaWQ9ImRpdlJwbHlGd2RNc2ciIGRpcj0ibHRyIj48Zm9udCBmYWNlPSJDYWxp YnJpLCBzYW5zLXNlcmlmIiBzdHlsZT0iZm9udC1zaXplOjExcHQiIGNvbG9yPSIjMDAwMDAwIj48 Yj5EZSA6PC9iPiBPbmTFmWVqIEt1em7DrWsgJmx0O29uZHJhQG1pc3RvdGViZS5uZXQmZ3Q7PGJy Pg0KPGI+RW52b3nDqSA6PC9iPiBsdW5kaSAyMCBtYWkgMjAxOSAxNjoxNTozMTxicj4NCjxiPsOA IDo8L2I+IEFZQU5JREVTLCBKRUFOLVBISUxJUFBFPGJyPg0KPGI+Q2MmbmJzcDs6PC9iPiBvcGVu bGRhcC1pdHNAT3BlbkxEQVAub3JnPGJyPg0KPGI+T2JqZXQgOjwvYj4gUmU6IChJVFMjOTAyMykg Y3Jhc2ggdXNpbmcgcHBvbGljeSBjaGFpbmluZyBmcm9tIHNsYXZlIHRvIG1hc3RlcjwvZm9udD4N CjxkaXY+Jm5ic3A7PC9kaXY+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IkJvZHlGcmFnbWVudCI+PGZv bnQgc2l6ZT0iMiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMXB0OyI+DQo8ZGl2IGNsYXNzPSJQ bGFpblRleHQiPk9uIE1vbiwgTWF5IDIwLCAyMDE5IGF0IDEwOjI5OjAyQU0gJiM0MzswMDAwLCBB WUFOSURFUywgSkVBTi1QSElMSVBQRSB3cm90ZTo8YnI+DQomZ3Q7IFllcywgaXQgc2VydmVzIHRy YWZmaWMuIEl0IGRvZXNuJ3QgY3Jhc2ggdW50aWwgSSBydW4gYSBiaW5kIHdpdGggYTxicj4NCiZn dDsgd3JvbmcgcGFzc3dvcmQuPGJyPg0KJmd0OyA8YnI+DQomZ3Q7Jmd0OyAoZ2RiKSBjb250PGJy Pg0KJmd0OyZndDsgQ29udGludWluZy48YnI+DQomZ3Q7IDxicj4NCiZndDsgW0xEQVAgc2VhcmNo IHdpdGggd3JvbmcgcGFzc3dvcmRdPGJyPg0KJmd0OyA8YnI+DQomZ3Q7Jmd0OyBbTmV3IFRocmVh ZCAtMTIzNzU0MTk2OCAoTFdQIDI5MzgwKV08YnI+DQomZ3Q7IDxicj4NCiZndDsmZ3Q7IFByb2dy YW0gZXhpdGVkIHdpdGggY29kZSAwMTc3Ljxicj4NCiZndDsmZ3Q7IChnZGIpIHRocmVhZCBhcHBs eSBhbGwgYnQgZnVsbDxicj4NCiZndDsgPGJyPg0KJmd0OyBZZXMgc29ycnksIEl0IHJ1bnMgb24g YW4gb2xkIHZlcnNpb24gb2YgZGViaWFuOiA0OjAgMzIgYml0cyB0aGF0IEkgYW08YnI+DQomZ3Q7 IG5vdCBhdXRob3Jpc2VkIHRvIHVwZ3JhZGUuPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IEl0IHRoZSBm aXJzdCB0aW1lIHdlIHJlY29yZCB0aGF0IHNvcnQgb2YgaXNzdWUgb24gdGhhdCBwbGF0Zm9ybeKA pjxicj4NCjxicj4NCkhpIEplYW4tUGhpbGlwcGUsPGJyPg0KYXJlIHlvdSBhYmxlIHRvIHJlcHJv ZHVjZSB0aGlzIG9uIGEgZGlmZmVyZW50IHN5c3RlbSwgaWYgbm90LCBjYW4geW91PGJyPg0KZ2V0 IGEgbW9yZSByZWNlbnQgZ2RiIG9uIHRoYXQgc3lzdGVtPzxicj4NCjxicj4NCkkgaGF2ZSB0cmll ZCB0byByZXByb2R1Y2Ugd2l0aCBhIGNvbmZpZyBzaW1pbGFyIHRvIHRoZSBvbmUgeW91IGRlc2Ny aWJlPGJyPg0KZGlkbid0IG1hbmFnZSB0byBwcm92b2tlIGEgc2VnZmF1bHQgd2l0aCByZTI0IG5v ciBtYXN0ZXIuPGJyPg0KPGJyPg0KT24gYSBzaWRlIG5vdGUsIEkgZG9uJ3QgdGhpbmsgcnVubmlu ZyB0aGUgY2hhaW4gb3ZlcmxheSB3aXRoIG1vZGU9c2VsZjxicj4NCndpbGwgd29yayB0byBwcm9w YWdhdGUgdGhlIHBwb2xpY3kgaW5mb3JtYXRpb24gdGhlIHdheSB5b3Ugd2FudC4gVGhlPGJyPg0K c2FtZSBmYWlsaW5nIGNyZWRlbnRpYWxzIHdpbGwgYmUgdXNlZCB0byBjb250YWN0IHRoZSB1cHN0 cmVhbSBzZXJ2ZXIgYW5kPGJyPg0Kc28gdGhlIGluaXRpYWwgYmluZCB3aWxsIGJlIHJlamVjdGVk IGFnYWluLCBub3QgYWxsb3dpbmcgdGhlPGJyPg0KbW9kaWZpY2F0aW9uIHRvIGJlIHBlcmZvcm1l ZC48YnI+DQo8YnI+DQpSZWdhcmRzLDxicj4NCjxicj4NCi0tIDxicj4NCk9uZMWZZWogS3V6bsOt azxicj4NClNlbmlvciBTb2Z0d2FyZSBFbmdpbmVlcjxicj4NClN5bWFzIENvcnBvcmF0aW9uJm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7IDxhIGhyZWY9Imh0dHA6Ly93d3cuc3ltYXMuY29tIj5odHRwOi8vd3d3 LnN5bWFzLmNvbTwvYT48YnI+DQpQYWNrYWdlZCwgY2VydGlmaWVkLCBhbmQgc3VwcG9ydGVkIExE QVAgc29sdXRpb25zIHBvd2VyZWQgYnkgT3BlbkxEQVA8YnI+DQo8L2Rpdj4NCjwvc3Bhbj48L2Zv bnQ+PC9kaXY+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOiA5cHg7IGxpbmUtaGVpZ2h0OiAxMHB4 OyI+VGhpcyBtZXNzYWdlIGNvbnRhaW5zIGluZm9ybWF0aW9uIHRoYXQgbWF5IGJlIHByaXZpbGVn ZWQgb3IgY29uZmlkZW50aWFsIGFuZCBpcyB0aGUgcHJvcGVydHkgb2YgdGhlIENhcGdlbWluaSBH cm91cC4gSXQgaXMgaW50ZW5kZWQgb25seSBmb3IgdGhlIHBlcnNvbiB0byB3aG9tIGl0IGlzIGFk ZHJlc3NlZC4gSWYgeW91IGFyZSBub3QgdGhlIGludGVuZGVkIHJlY2lwaWVudCwgeW91IGFyZSBu b3QgYXV0aG9yaXplZCB0byByZWFkLCBwcmludCwgcmV0YWluLCBjb3B5LCBkaXNzZW1pbmF0ZSwg ZGlzdHJpYnV0ZSwgb3IgdXNlIHRoaXMgbWVzc2FnZSBvciBhbnkgcGFydCB0aGVyZW9mLiBJZiB5 b3UgcmVjZWl2ZSB0aGlzIG1lc3NhZ2UgaW4gZXJyb3IsIHBsZWFzZSBub3RpZnkgdGhlIHNlbmRl ciBpbW1lZGlhdGVseSBhbmQgZGVsZXRlIGFsbCBjb3BpZXMgb2YgdGhpcyBtZXNzYWdlLjwvc3Bh bj48L2JvZHk+DQo8L2h0bWw+DQo= --_000_AM0PR0202MB35530E1160E3DCDDFBD1D06ABA140AM0PR0202MB3553_--

1 0

(ITS#9029) MDB_MAP_FULL error after removing some records from DB
by adubovkin＠linkedin.com 28 May '19

28 May '19

Full_Name: Alex Version: LMDB 0.9.23 OS: iOS URL: https://hastebin.com/raw/arexecefew Submission from: (NULL) (2620:119:5001:3000:242c:3bea:acec:6a7d) Hey guys, We are using LMDB in our LRUCache implementation and facing the issue: when we evict old records from this cache sometimes we have MDB_MAP_FULL error though record eviction by using mdb_del() went fine. We were able to isolate an issue in the unit test which is run from just one thread. Since there are no any concurrent readers for this case we are expecting LMDB to claim free pages immediately after we commit "deletion" transaction, but in some rare cases it still raises MDB_MAP_FULL error. The unit test scenario is as follows: 1) start with empty DB 2) keep inserting random records until hi the first MDB_FULL 3) delete some old recrods to some pages 4) try to insert new record and check that is succeeded. The step 4 fails with another MDB_FULL error We enable debugging and attached a debug logs from LDMB. Hope it would be helpful.

1 0

Re: (ITS#9028) Not able to add 'syncprov' module
by quanah＠symas.com 26 May '19

26 May '19

--On Sunday, May 26, 2019 12:47 PM +0000 danybensighar(a)gmail.com wrote: > Full_Name: Dany Bensighar Hello, The ITS system is for bug reports. Usage questions such as this should be sent to the openldap-technical(a)openldap.org mailing list (<https://www.openldap.org/lists/mm/listinfo/openldap-technical>) This ITS will be closed. 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#9028) Not able to add 'syncprov' module
by danybensighar＠gmail.com 26 May '19

26 May '19

Full_Name: Dany Bensighar Version: 2.4.44 OS: Red Hat Enterprise Linux Server release 7.6 (Maipo) URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (212.138.78.4) Hello, Iam setting up a master slave openldap configuration in rhel 7, while adding the syncprov module I am getting the below error. I have checked openspaces and special characters but nothing found Please find the syncprov.ldif file dn: olcOverlay=syncprov,olcDatabase={2}hdb,cn=config objectClass: olcOverlayConfig objectClass: olcSyncProvConfig olcOverlay: syncprov olcSpSessionLog: 100 Please find the error ldapadd -Y EXTERNAL -H ldapi:/// -f syncprov.ldif SASL/EXTERNAL authentication started SASL username: gidNumber=1001+uidNumber=1001,cn=peercred,cn=external,cn=auth SASL SSF: 0 adding new entry "olcOverlay=syncprov,olcDatabase={2}hdb,cn=config" ldap_add: Invalid syntax (21) additional info: objectClass: value #1 invalid per syntax Your support will be highly appreciated

1 0

Re: (ITS#9027) LMDB: API to retrieve map address
by nic＠nicwatson.org 23 May '19

23 May '19

--000000000000856dab058992e756 Content-Type: text/plain; charset="UTF-8" The short answer is yes. Our mappings are now bigger than 1TiB (out of 2TiB total available). Also, it *seems* to be that it is just way faster for Linux to map things in order all at once. Additionally, we have some boxes that still have spinning disks, and sequential access is a couple orders of magnitude faster on those. I haven't looked at the logic in the Linux pager, but it seems to be fairly aggressive about taking memory pages back from large memory maps, even though it doesn't strictly need to. Locking the memory is a bit of a sledgehammer, but in our experience it is an effective one. On Thu, May 23, 2019 at 2:23 PM Howard Chu <hyc(a)symas.com> wrote: > github(a)nicwatson.org wrote: > > Full_Name: Nic Watson > > Version: > > OS: Linux > > URL: ftp://ftp.openldap.org/incoming/ > > Submission from: (NULL) (73.132.68.128) > > > > > > Goal: > > I'd like a clean way to get at the address of the data memory map in > LMDB. > > > > MDB_envinfo.me_mapaddr only returns the map address if MAP_FIXED is used. > > > > Current Workarounds: > > * Use OS-specific mechanism to retrieve all memory maps (e.g. > > /proc/<pid>/smaps). > > * Defeat opaque handle and reach into the MDB_env struct directly and > grab the > > me_map field. > > > > Justification: > > In my current application, I notice a significant performance increase > if I > > mlock the mapfile. In order to do that cleanly, I need the address of > the map. > > That sounds odd. Is there a lot of memory pressure from other processes on > the machine? > Where is the performance loss or gain coming from? > > -- > -- Howard Chu > CTO, Symas Corp. http://www.symas.com > Director, Highland Sun http://highlandsun.com/hyc/ > Chief Architect, OpenLDAP http://www.openldap.org/project/ > --000000000000856dab058992e756 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr">The short answer is yes. Our mappings are now bigger than = 1TiB (out of 2TiB total available). Also, it *seems* to be that it is just = way faster for Linux to map things in order all at once. Additionally, we h= ave some boxes that still have spinning disks, and sequential access is a c= ouple orders of magnitude faster on those.<div><br></div><div>I haven't= looked at the logic in the Linux pager, but it seems to be fairly aggressi= ve about taking memory pages back from large memory maps, even though it do= esn't strictly need to. Locking the memory is a bit of a sledgehammer, = but in our experience it is an effective one.</div></div><br><div class=3D"= gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr">On Thu, May 23, 2019 at = 2:23 PM Howard Chu <<a href=3D"mailto:hyc@symas.com">hyc(a)symas.com</a>&g= t; wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0p= x 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><a hre= f=3D"mailto:github@nicwatson.org" target=3D"_blank">github(a)nicwatson.org</a= > wrote:<br> > Full_Name: Nic Watson<br> > Version: <br> > OS: Linux<br> > URL: <a href=3D"ftp://ftp.openldap.org/incoming/" rel=3D"noreferrer" t= arget=3D"_blank">ftp://ftp.openldap.org/incoming/</a><br> > Submission from: (NULL) (73.132.68.128)<br> > <br> > <br> > Goal:<br> > I'd like a clean way to get at the address of the data memory map = in LMDB.<br> > <br> > MDB_envinfo.me_mapaddr only returns the map address if MAP_FIXED is us= ed.<br> > <br> > Current Workarounds:<br> > * Use OS-specific mechanism to retrieve all memory maps (e.g.<br> > /proc/<pid>/smaps). <br> > * Defeat opaque handle and reach into the MDB_env struct directly and = grab the<br> > me_map field.<br> > <br> > Justification:<br> > In my current application, I notice a significant performance increase= if I<br> > mlock the mapfile.=C2=A0 In order to do that cleanly, I need the addre= ss of the map.<br> <br> That sounds odd. Is there a lot of memory pressure from other processes on = the machine?<br> Where is the performance loss or gain coming from?<br> <br> -- <br> =C2=A0 -- Howard Chu<br> =C2=A0 CTO, Symas Corp.=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<a href=3D"= http://www.symas.com" rel=3D"noreferrer" target=3D"_blank">http://www.symas= .com</a><br> =C2=A0 Director, Highland Sun=C2=A0 =C2=A0 =C2=A0<a href=3D"http://highland= sun.com/hyc/" rel=3D"noreferrer" target=3D"_blank">http://highlandsun.com/h= yc/</a><br> =C2=A0 Chief Architect, OpenLDAP=C2=A0 <a href=3D"http://www.openldap.org/p= roject/" rel=3D"noreferrer" target=3D"_blank">http://www.openldap.org/proje= ct/</a><br> </blockquote></div> --000000000000856dab058992e756--

1 0

Re: (ITS#9027) LMDB: API to retrieve map address
by hyc＠symas.com 23 May '19

23 May '19

github(a)nicwatson.org wrote: > Full_Name: Nic Watson > Version: > OS: Linux > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (73.132.68.128) > > > Goal: > I'd like a clean way to get at the address of the data memory map in LMDB. > > MDB_envinfo.me_mapaddr only returns the map address if MAP_FIXED is used. > > Current Workarounds: > * Use OS-specific mechanism to retrieve all memory maps (e.g. > /proc/<pid>/smaps). > * Defeat opaque handle and reach into the MDB_env struct directly and grab the > me_map field. > > Justification: > In my current application, I notice a significant performance increase if I > mlock the mapfile. In order to do that cleanly, I need the address of the map. That sounds odd. Is there a lot of memory pressure from other processes on the machine? Where is the performance loss or gain coming from? -- -- 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#9027) LMDB: API to retrieve map address
by github＠nicwatson.org 23 May '19

23 May '19

Full_Name: Nic Watson Version: OS: Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (73.132.68.128) Goal: I'd like a clean way to get at the address of the data memory map in LMDB. MDB_envinfo.me_mapaddr only returns the map address if MAP_FIXED is used. Current Workarounds: * Use OS-specific mechanism to retrieve all memory maps (e.g. /proc/<pid>/smaps). * Defeat opaque handle and reach into the MDB_env struct directly and grab the me_map field. Justification: In my current application, I notice a significant performance increase if I mlock the mapfile. In order to do that cleanly, I need the address of the map.

1 0

Re: (ITS#9023) crash using ppolicy chaining from slave to master
by ondra＠mistotebe.net 20 May '19

20 May '19

On Mon, May 20, 2019 at 10:29:02AM +0000, AYANIDES, JEAN-PHILIPPE wrote: > Yes, it serves traffic. It doesn't crash until I run a bind with a > wrong password. > >> (gdb) cont >> Continuing. > > [LDAP search with wrong password] > >> [New Thread -1237541968 (LWP 29380)] > >> Program exited with code 0177. >> (gdb) thread apply all bt full > > Yes sorry, It runs on an old version of debian: 4:0 32 bits that I am > not authorised to upgrade. > > It the first time we record that sort of issue on that platform… Hi Jean-Philippe, are you able to reproduce this on a different system, if not, can you get a more recent gdb on that system? I have tried to reproduce with a config similar to the one you describe didn't manage to provoke a segfault with re24 nor master. On a side note, I don't think running the chain overlay with mode=self will work to propagate the ppolicy information the way you want. The same failing credentials will be used to contact the upstream server and so the initial bind will be rejected again, not allowing the modification to be performed. Regards, -- 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#9023) crash using ppolicy chaining from slave to master
by jpayanides＠prosodie.com 20 May '19

20 May '19

--_000_AM0PR0202MB35537CBC3DAD8A9A24C85FF4BA060AM0PR0202MB3553_ Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 WWVzLCBpdCBzZXJ2ZXMgdHJhZmZpYy4gSXQgZG9lc24ndCBjcmFzaCB1bnRpbCBJIHJ1biBhIGJp bmQgd2l0aCBhIHdyb25nIHBhc3N3b3JkLg0KDQo+IChnZGIpIGNvbnQNCg0KPiBDb250aW51aW5n Lg0KDQoNCltMREFQIHNlYXJjaCB3aXRoIHdyb25nIHBhc3N3b3JkXQ0KDQoNCj4gW05ldyBUaHJl YWQgLTEyMzc1NDE5NjggKExXUCAyOTM4MCldDQoNCj4gUHJvZ3JhbSBleGl0ZWQgd2l0aCBjb2Rl IDAxNzcuDQo+IChnZGIpIHRocmVhZCBhcHBseSBhbGwgYnQgZnVsbA0KDQoNClllcyBzb3JyeSwg SXQgcnVucyBvbiBhbiBvbGQgdmVyc2lvbiBvZiBkZWJpYW46IDQ6MCAzMiBiaXRzIHRoYXQgSSBh bSBub3QgYXV0aG9yaXNlZCB0byB1cGdyYWRlLg0KDQpJdCB0aGUgZmlyc3QgdGltZSB3ZSByZWNv cmQgdGhhdCBzb3J0IG9mIGlzc3VlIG9uIHRoYXQgcGxhdGZvcm3igKYNCg0KDQpKZWFuLVBoaWxp cHBlDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpEZSA6IE9uZMWZZWogS3V6 bsOtayA8b25kcmFAbWlzdG90ZWJlLm5ldD4NCkVudm95w6kgOiBsdW5kaSAyMCBtYWkgMjAxOSAx MjoyMDo0NQ0Kw4AgOiBBWUFOSURFUywgSkVBTi1QSElMSVBQRQ0KQ2MgOiBvcGVubGRhcC1pdHNA T3BlbkxEQVAub3JnDQpPYmpldCA6IFJlOiAoSVRTIzkwMjMpIGNyYXNoIHVzaW5nIHBwb2xpY3kg Y2hhaW5pbmcgZnJvbSBzbGF2ZSB0byBtYXN0ZXINCg0KT24gTW9uLCBNYXkgMjAsIDIwMTkgYXQg MDk6NDQ6NDVBTSArMDAwMCwgQVlBTklERVMsIEpFQU4tUEhJTElQUEUgd3JvdGU6DQo+IEhlbGxv IE9uZMWZZWoNCj4NCj4gSSBoYXZlIHByb2NlZWRlZCBsaWtlIHRoaXMgYmVjYXVzZSBJIGhhZCBu b3RoaW5nIG1vcmUgdG8gc2hvdyENCg0KSGkgSmVhbi1QaGlsaXBwZSwNCmlzIHNsYXBkIGFjdHVh bGx5IHdpbGxpbmcgdG8gc2VydmUgYW55IHRyYWZmaWMgd2hpbGUgeW91IGxldCBnZGINCmNvbnRp bnVlIG9yIGRvZXMgaXQgc2F5IHNsYXBkIHN0b3BwZWQgaW1tZWRpYXRlbHk/DQoNCkFsc28sIHdo aWxlIHRoaXMgbWlnaHQgYmUgYSByZWQgaGVycmluZywgd2hhdCB2ZXJzaW9uIGFuZCBhcmNoaXRl Y3R1cmUNCm9mIERlYmlhbiBkbyB5b3UgdXNlPyBUaGVyZSBhcmUgc29tZSB0aGluZ3MgYWJvdXQg eW91ciBnZGIgb3V0cHV0IGFuZA0KbGlicmFyeSBsb2NhdGlvbnMgdGhhdCBJIGNhbid0IHJlY29u Y2lsZSB3aXRoIGFueSByZWNlbnQgRGViaWFuIHJlbGVhc2UuDQoNCj4gSWYgSSBydW4gdGhlIGNv bW1hbmRzIGFzIHlvdSBzYWlkOg0KPiAo4oCmKQ0KPg0KPiBMb2FkZWQgc3ltYm9scyBmb3IgL2Fw cGxpL29wZW5sZGFwLTIuNC40Ny9saWJleGVjL29wZW5sZGFwL3Bwb2xpY3ktMi40LnNvLjINCj4g UmVhZGluZyBzeW1ib2xzIGZyb20gL2FwcGxpL29wZW5sZGFwLTIuNC40Ny9saWJleGVjL29wZW5s ZGFwL2JhY2tfbGRhcC0yLjQuc28uMi4uLmRvbmUuDQo+IExvYWRlZCBzeW1ib2xzIGZvciAvYXBw bGkvb3BlbmxkYXAtMi40LjQ3L2xpYmV4ZWMvb3BlbmxkYXAvYmFja19sZGFwLTIuNC5zby4yDQo+ IFJlYWRpbmcgc3ltYm9scyBmcm9tIC9hcHBsaS9vcGVubGRhcC0yLjQuNDcvbGliZXhlYy9vcGVu bGRhcC9wdy1zaGEyLnNvLjAuLi5kb25lLg0KPiBMb2FkZWQgc3ltYm9scyBmb3IgL2FwcGxpL29w ZW5sZGFwLTIuNC40Ny9saWJleGVjL29wZW5sZGFwL3B3LXNoYTIuc28uMA0KPiBSZWFkaW5nIHN5 bWJvbHMgZnJvbSAvYXBwbGkvb3BlbmxkYXAtMi40LjQ3L2xpYi9saWJsZGFwX3ItMi40LnNvLjIu Li5kb25lLg0KPiBMb2FkZWQgc3ltYm9scyBmb3IgL2FwcGxpL29wZW5sZGFwLTIuNC40Ny9saWIv bGlibGRhcF9yLTIuNC5zby4yDQo+IFJlYWRpbmcgc3ltYm9scyBmcm9tIC9hcHBsaS9vcGVubGRh cC0yLjQuNDcvbGliL2xpYmxiZXItMi40LnNvLjIuLi5kb25lLg0KPiBMb2FkZWQgc3ltYm9scyBm b3IgL2FwcGxpL29wZW5sZGFwLTIuNC40Ny9saWIvbGlibGJlci0yLjQuc28uMg0KPiBGYWlsZWQg dG8gcmVhZCBhIHZhbGlkIG9iamVjdCBmaWxlIGltYWdlIGZyb20gbWVtb3J5Lg0KPiAweGI3Yzkz MTgzIGluIHB0aHJlYWRfam9pbiAoKSBmcm9tIC9saWIvdGxzL2xpYnB0aHJlYWQuc28uMA0KPiAo Z2RiKSBzZXQgbG9nZ2luZyBvbg0KPiBDb3B5aW5nIG91dHB1dCB0byBnZGIudHh0Lg0KPiAoZ2Ri KSBjb250DQo+IENvbnRpbnVpbmcuDQo+IFtOZXcgVGhyZWFkIC0xMjM3NTQxOTY4IChMV1AgMjkz ODApXQ0KPg0KPiBQcm9ncmFtIGV4aXRlZCB3aXRoIGNvZGUgMDE3Ny4NCj4gKGdkYikgdGhyZWFk IGFwcGx5IGFsbCBidCBmdWxsDQo+IChnZGIpDQo+IChnZGIpIHF1aXQNCg0KLS0NCk9uZMWZZWog S3V6bsOtaw0KU2VuaW9yIFNvZnR3YXJlIEVuZ2luZWVyDQpTeW1hcyBDb3Jwb3JhdGlvbiAgICAg ICAgICAgICAgICAgICAgICAgaHR0cDovL3d3dy5zeW1hcy5jb20NClBhY2thZ2VkLCBjZXJ0aWZp ZWQsIGFuZCBzdXBwb3J0ZWQgTERBUCBzb2x1dGlvbnMgcG93ZXJlZCBieSBPcGVuTERBUA0KVGhp cyBtZXNzYWdlIGNvbnRhaW5zIGluZm9ybWF0aW9uIHRoYXQgbWF5IGJlIHByaXZpbGVnZWQgb3Ig Y29uZmlkZW50aWFsIGFuZCBpcyB0aGUgcHJvcGVydHkgb2YgdGhlIENhcGdlbWluaSBHcm91cC4g SXQgaXMgaW50ZW5kZWQgb25seSBmb3IgdGhlIHBlcnNvbiB0byB3aG9tIGl0IGlzIGFkZHJlc3Nl ZC4gSWYgeW91IGFyZSBub3QgdGhlIGludGVuZGVkIHJlY2lwaWVudCwgeW91IGFyZSBub3QgYXV0 aG9yaXplZCB0byByZWFkLCBwcmludCwgcmV0YWluLCBjb3B5LCBkaXNzZW1pbmF0ZSwgZGlzdHJp YnV0ZSwgb3IgdXNlIHRoaXMgbWVzc2FnZSBvciBhbnkgcGFydCB0aGVyZW9mLiBJZiB5b3UgcmVj ZWl2ZSB0aGlzIG1lc3NhZ2UgaW4gZXJyb3IsIHBsZWFzZSBub3RpZnkgdGhlIHNlbmRlciBpbW1l ZGlhdGVseSBhbmQgZGVsZXRlIGFsbCBjb3BpZXMgb2YgdGhpcyBtZXNzYWdlLgo= --_000_AM0PR0202MB35537CBC3DAD8A9A24C85FF4BA060AM0PR0202MB3553_ Content-Type: text/html; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxzdHlsZSB0eXBlPSJ0ZXh0L2NzcyIgc3R5bGU9 ImRpc3BsYXk6bm9uZTsiPjwhLS0gUCB7bWFyZ2luLXRvcDowO21hcmdpbi1ib3R0b206MDt9IC0t Pjwvc3R5bGU+DQo8L2hlYWQ+DQo8Ym9keSBkaXI9Imx0ciI+DQo8ZGl2IGlkPSJkaXZ0YWdkZWZh dWx0d3JhcHBlciIgc3R5bGU9ImZvbnQtc2l6ZToxMnB0O2NvbG9yOiMwMDAwMDA7Zm9udC1mYW1p bHk6Q2FsaWJyaSxIZWx2ZXRpY2Esc2Fucy1zZXJpZjsiIGRpcj0ibHRyIj4NCjxwIHN0eWxlPSJt YXJnaW4tdG9wOjA7bWFyZ2luLWJvdHRvbTowIj5ZZXMsIGl0IHNlcnZlcyB0cmFmZmljLiBJdCBk b2Vzbid0IGNyYXNoIHVudGlsIEkgcnVuIGEgYmluZCB3aXRoIGEgd3JvbmcgcGFzc3dvcmQuPC9w Pg0KPHAgc3R5bGU9Im1hcmdpbi10b3A6MDttYXJnaW4tYm90dG9tOjAiPjxmb250IHNpemU9IjIi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTFwdDsiPiZndDsgKGdkYikgY29udDxicj4NCjwvc3Bh bj48L2ZvbnQ+PC9wPg0KPHAgc3R5bGU9Im1hcmdpbi10b3A6MDttYXJnaW4tYm90dG9tOjAiPjxm b250IHNpemU9IjIiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTFwdDsiPiZndDsgQ29udGludWlu Zy48YnI+DQo8L3NwYW4+PC9mb250PjwvcD4NCjxwIHN0eWxlPSJtYXJnaW4tdG9wOjA7bWFyZ2lu LWJvdHRvbTowIj48Zm9udCBzaXplPSIyIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExcHQ7Ij48 L3A+DQo8cCBzdHlsZT0ibWFyZ2luLXRvcDowO21hcmdpbi1ib3R0b206MCI+PGZvbnQgc2l6ZT0i MiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMXB0OyI+PGJyPg0KPC9zcGFuPjwvZm9udD48L3A+ DQo8cCBzdHlsZT0ibWFyZ2luLXRvcDowO21hcmdpbi1ib3R0b206MCI+PGZvbnQgc2l6ZT0iMiI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMXB0OyI+W0xEQVAgc2VhcmNoIHdpdGggd3JvbmcgcGFz c3dvcmRdPGJyPg0KPC9zcGFuPjwvZm9udD48L3A+DQo8YnI+DQo8L3NwYW4+PC9mb250Pg0KPHA+ PC9wPg0KPHAgc3R5bGU9Im1hcmdpbi10b3A6MDttYXJnaW4tYm90dG9tOjAiPjxmb250IHNpemU9 IjIiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTFwdDsiPiZndDsgW05ldyBUaHJlYWQgLTEyMzc1 NDE5NjggKExXUCAyOTM4MCldPC9zcGFuPjwvZm9udD48L3A+DQo8cCBzdHlsZT0ibWFyZ2luLXRv cDowO21hcmdpbi1ib3R0b206MCI+PGZvbnQgc2l6ZT0iMiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMXB0OyI+Jmd0OyBQcm9ncmFtIGV4aXRlZCB3aXRoIGNvZGUgMDE3Ny48YnI+DQomZ3Q7IChn ZGIpIHRocmVhZCBhcHBseSBhbGwgYnQgZnVsbDwvc3Bhbj48L2ZvbnQ+PC9wPg0KPHAgc3R5bGU9 Im1hcmdpbi10b3A6MDttYXJnaW4tYm90dG9tOjAiPjxicj4NCjwvcD4NCjxwIHN0eWxlPSJtYXJn aW4tdG9wOjA7bWFyZ2luLWJvdHRvbTowIj5ZZXMgc29ycnksIEl0IHJ1bnMgb24gYW4gb2xkIHZl cnNpb24gb2YgZGViaWFuOiA0OjAgMzIgYml0cyB0aGF0IEkgYW0gbm90IGF1dGhvcmlzZWQgdG8g dXBncmFkZS48L3A+DQo8cCBzdHlsZT0ibWFyZ2luLXRvcDowO21hcmdpbi1ib3R0b206MCI+SXQg dGhlIGZpcnN0IHRpbWUgd2UgcmVjb3JkIHRoYXQgc29ydCBvZiBpc3N1ZSBvbiB0aGF0IHBsYXRm b3Jt4oCmPGJyPg0KPC9wPg0KPHAgc3R5bGU9Im1hcmdpbi10b3A6MDttYXJnaW4tYm90dG9tOjAi Pjxicj4NCjwvcD4NCjxwIHN0eWxlPSJtYXJnaW4tdG9wOjA7bWFyZ2luLWJvdHRvbTowIj5KZWFu LVBoaWxpcHBlPGJyPg0KPC9wPg0KPHN0cm9uZz48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1 b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OzsgY29sb3I6IzAwOThDQyI+PC9z cGFuPjwvc3Ryb25nPg0KPGRpdiBpZD0iU2lnbmF0dXJlIj48L2Rpdj4NCjwvZGl2Pg0KPGhyIHN0 eWxlPSJkaXNwbGF5OmlubGluZS1ibG9jazt3aWR0aDo5OCUiIHRhYmluZGV4PSItMSI+DQo8ZGl2 IGlkPSJkaXZScGx5RndkTXNnIiBkaXI9Imx0ciI+PGZvbnQgZmFjZT0iQ2FsaWJyaSwgc2Fucy1z ZXJpZiIgc3R5bGU9ImZvbnQtc2l6ZToxMXB0IiBjb2xvcj0iIzAwMDAwMCI+PGI+RGUgOjwvYj4g T25kxZllaiBLdXpuw61rICZsdDtvbmRyYUBtaXN0b3RlYmUubmV0Jmd0Ozxicj4NCjxiPkVudm95 w6kgOjwvYj4gbHVuZGkgMjAgbWFpIDIwMTkgMTI6MjA6NDU8YnI+DQo8Yj7DgCA6PC9iPiBBWUFO SURFUywgSkVBTi1QSElMSVBQRTxicj4NCjxiPkNjJm5ic3A7OjwvYj4gb3BlbmxkYXAtaXRzQE9w ZW5MREFQLm9yZzxicj4NCjxiPk9iamV0IDo8L2I+IFJlOiAoSVRTIzkwMjMpIGNyYXNoIHVzaW5n IHBwb2xpY3kgY2hhaW5pbmcgZnJvbSBzbGF2ZSB0byBtYXN0ZXI8L2ZvbnQ+DQo8ZGl2PiZuYnNw OzwvZGl2Pg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSJCb2R5RnJhZ21lbnQiPjxmb250IHNpemU9IjIi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTFwdDsiPg0KPGRpdiBjbGFzcz0iUGxhaW5UZXh0Ij5P biBNb24sIE1heSAyMCwgMjAxOSBhdCAwOTo0NDo0NUFNICYjNDM7MDAwMCwgQVlBTklERVMsIEpF QU4tUEhJTElQUEUgd3JvdGU6PGJyPg0KJmd0OyBIZWxsbyBPbmTFmWVqPGJyPg0KJmd0OyA8YnI+ DQomZ3Q7IEkgaGF2ZSBwcm9jZWVkZWQgbGlrZSB0aGlzIGJlY2F1c2UgSSBoYWQgbm90aGluZyBt b3JlIHRvIHNob3chPGJyPg0KPGJyPg0KSGkgSmVhbi1QaGlsaXBwZSw8YnI+DQppcyBzbGFwZCBh Y3R1YWxseSB3aWxsaW5nIHRvIHNlcnZlIGFueSB0cmFmZmljIHdoaWxlIHlvdSBsZXQgZ2RiPGJy Pg0KY29udGludWUgb3IgZG9lcyBpdCBzYXkgc2xhcGQgc3RvcHBlZCBpbW1lZGlhdGVseT88YnI+ DQo8YnI+DQpBbHNvLCB3aGlsZSB0aGlzIG1pZ2h0IGJlIGEgcmVkIGhlcnJpbmcsIHdoYXQgdmVy c2lvbiBhbmQgYXJjaGl0ZWN0dXJlPGJyPg0Kb2YgRGViaWFuIGRvIHlvdSB1c2U/IFRoZXJlIGFy ZSBzb21lIHRoaW5ncyBhYm91dCB5b3VyIGdkYiBvdXRwdXQgYW5kPGJyPg0KbGlicmFyeSBsb2Nh dGlvbnMgdGhhdCBJIGNhbid0IHJlY29uY2lsZSB3aXRoIGFueSByZWNlbnQgRGViaWFuIHJlbGVh c2UuPGJyPg0KPGJyPg0KJmd0OyBJZiBJIHJ1biB0aGUgY29tbWFuZHMgYXMgeW91IHNhaWQ6PGJy Pg0KJmd0OyAo4oCmKTxicj4NCiZndDsgPGJyPg0KJmd0OyBMb2FkZWQgc3ltYm9scyBmb3IgL2Fw cGxpL29wZW5sZGFwLTIuNC40Ny9saWJleGVjL29wZW5sZGFwL3Bwb2xpY3ktMi40LnNvLjI8YnI+ DQomZ3Q7IFJlYWRpbmcgc3ltYm9scyBmcm9tIC9hcHBsaS9vcGVubGRhcC0yLjQuNDcvbGliZXhl Yy9vcGVubGRhcC9iYWNrX2xkYXAtMi40LnNvLjIuLi5kb25lLjxicj4NCiZndDsgTG9hZGVkIHN5 bWJvbHMgZm9yIC9hcHBsaS9vcGVubGRhcC0yLjQuNDcvbGliZXhlYy9vcGVubGRhcC9iYWNrX2xk YXAtMi40LnNvLjI8YnI+DQomZ3Q7IFJlYWRpbmcgc3ltYm9scyBmcm9tIC9hcHBsaS9vcGVubGRh cC0yLjQuNDcvbGliZXhlYy9vcGVubGRhcC9wdy1zaGEyLnNvLjAuLi5kb25lLjxicj4NCiZndDsg TG9hZGVkIHN5bWJvbHMgZm9yIC9hcHBsaS9vcGVubGRhcC0yLjQuNDcvbGliZXhlYy9vcGVubGRh cC9wdy1zaGEyLnNvLjA8YnI+DQomZ3Q7IFJlYWRpbmcgc3ltYm9scyBmcm9tIC9hcHBsaS9vcGVu bGRhcC0yLjQuNDcvbGliL2xpYmxkYXBfci0yLjQuc28uMi4uLmRvbmUuPGJyPg0KJmd0OyBMb2Fk ZWQgc3ltYm9scyBmb3IgL2FwcGxpL29wZW5sZGFwLTIuNC40Ny9saWIvbGlibGRhcF9yLTIuNC5z by4yPGJyPg0KJmd0OyBSZWFkaW5nIHN5bWJvbHMgZnJvbSAvYXBwbGkvb3BlbmxkYXAtMi40LjQ3 L2xpYi9saWJsYmVyLTIuNC5zby4yLi4uZG9uZS48YnI+DQomZ3Q7IExvYWRlZCBzeW1ib2xzIGZv ciAvYXBwbGkvb3BlbmxkYXAtMi40LjQ3L2xpYi9saWJsYmVyLTIuNC5zby4yPGJyPg0KJmd0OyBG YWlsZWQgdG8gcmVhZCBhIHZhbGlkIG9iamVjdCBmaWxlIGltYWdlIGZyb20gbWVtb3J5Ljxicj4N CiZndDsgMHhiN2M5MzE4MyBpbiBwdGhyZWFkX2pvaW4gKCkgZnJvbSAvbGliL3Rscy9saWJwdGhy ZWFkLnNvLjA8YnI+DQomZ3Q7IChnZGIpIHNldCBsb2dnaW5nIG9uPGJyPg0KJmd0OyBDb3B5aW5n IG91dHB1dCB0byBnZGIudHh0Ljxicj4NCiZndDsgKGdkYikgY29udDxicj4NCiZndDsgQ29udGlu dWluZy48YnI+DQomZ3Q7IFtOZXcgVGhyZWFkIC0xMjM3NTQxOTY4IChMV1AgMjkzODApXTxicj4N CiZndDsgPGJyPg0KJmd0OyBQcm9ncmFtIGV4aXRlZCB3aXRoIGNvZGUgMDE3Ny48YnI+DQomZ3Q7 IChnZGIpIHRocmVhZCBhcHBseSBhbGwgYnQgZnVsbDxicj4NCiZndDsgKGdkYik8YnI+DQomZ3Q7 IChnZGIpIHF1aXQ8YnI+DQo8YnI+DQotLSA8YnI+DQpPbmTFmWVqIEt1em7DrWs8YnI+DQpTZW5p b3IgU29mdHdhcmUgRW5naW5lZXI8YnI+DQpTeW1hcyBDb3Jwb3JhdGlvbiZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyA8YSBocmVmPSJodHRwOi8vd3d3LnN5bWFzLmNvbSI+aHR0cDovL3d3dy5zeW1hcy5jb208 L2E+PGJyPg0KUGFja2FnZWQsIGNlcnRpZmllZCwgYW5kIHN1cHBvcnRlZCBMREFQIHNvbHV0aW9u cyBwb3dlcmVkIGJ5IE9wZW5MREFQPGJyPg0KPC9kaXY+DQo8L3NwYW4+PC9mb250PjwvZGl2Pg0K PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogOXB4OyBsaW5lLWhlaWdodDogMTBweDsiPlRoaXMgbWVz c2FnZSBjb250YWlucyBpbmZvcm1hdGlvbiB0aGF0IG1heSBiZSBwcml2aWxlZ2VkIG9yIGNvbmZp ZGVudGlhbCBhbmQgaXMgdGhlIHByb3BlcnR5IG9mIHRoZSBDYXBnZW1pbmkgR3JvdXAuIEl0IGlz IGludGVuZGVkIG9ubHkgZm9yIHRoZSBwZXJzb24gdG8gd2hvbSBpdCBpcyBhZGRyZXNzZWQuIElm IHlvdSBhcmUgbm90IHRoZSBpbnRlbmRlZCByZWNpcGllbnQsIHlvdSBhcmUgbm90IGF1dGhvcml6 ZWQgdG8gcmVhZCwgcHJpbnQsIHJldGFpbiwgY29weSwgZGlzc2VtaW5hdGUsIGRpc3RyaWJ1dGUs IG9yIHVzZSB0aGlzIG1lc3NhZ2Ugb3IgYW55IHBhcnQgdGhlcmVvZi4gSWYgeW91IHJlY2VpdmUg dGhpcyBtZXNzYWdlIGluIGVycm9yLCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXIgaW1tZWRpYXRl bHkgYW5kIGRlbGV0ZSBhbGwgY29waWVzIG9mIHRoaXMgbWVzc2FnZS48L3NwYW4+PC9ib2R5Pg0K PC9odG1sPg0K --_000_AM0PR0202MB35537CBC3DAD8A9A24C85FF4BA060AM0PR0202MB3553_--

1 0

Re: (ITS#9023) crash using ppolicy chaining from slave to master
by ondra＠mistotebe.net 20 May '19

20 May '19

On Mon, May 20, 2019 at 09:44:45AM +0000, AYANIDES, JEAN-PHILIPPE wrote: > Hello Ondřej > > I have proceeded like this because I had nothing more to show! Hi Jean-Philippe, is slapd actually willing to serve any traffic while you let gdb continue or does it say slapd stopped immediately? Also, while this might be a red herring, what version and architecture of Debian do you use? There are some things about your gdb output and library locations that I can't reconcile with any recent Debian release. > If I run the commands as you said: > (…) > > Loaded symbols for /appli/openldap-2.4.47/libexec/openldap/ppolicy-2.4.so.2 > Reading symbols from /appli/openldap-2.4.47/libexec/openldap/back_ldap-2.4.so.2...done. > Loaded symbols for /appli/openldap-2.4.47/libexec/openldap/back_ldap-2.4.so.2 > Reading symbols from /appli/openldap-2.4.47/libexec/openldap/pw-sha2.so.0...done. > Loaded symbols for /appli/openldap-2.4.47/libexec/openldap/pw-sha2.so.0 > Reading symbols from /appli/openldap-2.4.47/lib/libldap_r-2.4.so.2...done. > Loaded symbols for /appli/openldap-2.4.47/lib/libldap_r-2.4.so.2 > Reading symbols from /appli/openldap-2.4.47/lib/liblber-2.4.so.2...done. > Loaded symbols for /appli/openldap-2.4.47/lib/liblber-2.4.so.2 > Failed to read a valid object file image from memory. > 0xb7c93183 in pthread_join () from /lib/tls/libpthread.so.0 > (gdb) set logging on > Copying output to gdb.txt. > (gdb) cont > Continuing. > [New Thread -1237541968 (LWP 29380)] > > Program exited with code 0177. > (gdb) thread apply all bt full > (gdb) > (gdb) quit -- 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#9023) crash using ppolicy chaining from slave to master
by jpayanides＠prosodie.com 20 May '19

20 May '19

--_000_AM0PR0202MB3553B6F7E1BAA0A82AF24A4FBA060AM0PR0202MB3553_ Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 SGVsbG8gT25kxZllag0KDQpJIGhhdmUgcHJvY2VlZGVkIGxpa2UgdGhpcyBiZWNhdXNlIEkgaGFk IG5vdGhpbmcgbW9yZSB0byBzaG93IQ0KDQpJZiBJIHJ1biB0aGUgY29tbWFuZHMgYXMgeW91IHNh aWQ6DQoNCg0KKOKApikNCg0KTG9hZGVkIHN5bWJvbHMgZm9yIC9hcHBsaS9vcGVubGRhcC0yLjQu NDcvbGliZXhlYy9vcGVubGRhcC9wcG9saWN5LTIuNC5zby4yDQpSZWFkaW5nIHN5bWJvbHMgZnJv bSAvYXBwbGkvb3BlbmxkYXAtMi40LjQ3L2xpYmV4ZWMvb3BlbmxkYXAvYmFja19sZGFwLTIuNC5z by4yLi4uZG9uZS4NCkxvYWRlZCBzeW1ib2xzIGZvciAvYXBwbGkvb3BlbmxkYXAtMi40LjQ3L2xp YmV4ZWMvb3BlbmxkYXAvYmFja19sZGFwLTIuNC5zby4yDQpSZWFkaW5nIHN5bWJvbHMgZnJvbSAv YXBwbGkvb3BlbmxkYXAtMi40LjQ3L2xpYmV4ZWMvb3BlbmxkYXAvcHctc2hhMi5zby4wLi4uZG9u ZS4NCkxvYWRlZCBzeW1ib2xzIGZvciAvYXBwbGkvb3BlbmxkYXAtMi40LjQ3L2xpYmV4ZWMvb3Bl bmxkYXAvcHctc2hhMi5zby4wDQpSZWFkaW5nIHN5bWJvbHMgZnJvbSAvYXBwbGkvb3BlbmxkYXAt Mi40LjQ3L2xpYi9saWJsZGFwX3ItMi40LnNvLjIuLi5kb25lLg0KTG9hZGVkIHN5bWJvbHMgZm9y IC9hcHBsaS9vcGVubGRhcC0yLjQuNDcvbGliL2xpYmxkYXBfci0yLjQuc28uMg0KUmVhZGluZyBz eW1ib2xzIGZyb20gL2FwcGxpL29wZW5sZGFwLTIuNC40Ny9saWIvbGlibGJlci0yLjQuc28uMi4u LmRvbmUuDQpMb2FkZWQgc3ltYm9scyBmb3IgL2FwcGxpL29wZW5sZGFwLTIuNC40Ny9saWIvbGli bGJlci0yLjQuc28uMg0KRmFpbGVkIHRvIHJlYWQgYSB2YWxpZCBvYmplY3QgZmlsZSBpbWFnZSBm cm9tIG1lbW9yeS4NCjB4YjdjOTMxODMgaW4gcHRocmVhZF9qb2luICgpIGZyb20gL2xpYi90bHMv bGlicHRocmVhZC5zby4wDQooZ2RiKSBzZXQgbG9nZ2luZyBvbg0KQ29weWluZyBvdXRwdXQgdG8g Z2RiLnR4dC4NCihnZGIpIGNvbnQNCkNvbnRpbnVpbmcuDQpbTmV3IFRocmVhZCAtMTIzNzU0MTk2 OCAoTFdQIDI5MzgwKV0NCg0KUHJvZ3JhbSBleGl0ZWQgd2l0aCBjb2RlIDAxNzcuDQooZ2RiKSB0 aHJlYWQgYXBwbHkgYWxsIGJ0IGZ1bGwNCihnZGIpDQooZ2RiKSBxdWl0DQoNCg0KSSBnZXQgdGhl IGZpbGUgZ2RiLnR4dCBjb250YWluaW5nIG9ubHkgdGhhdDoNCg0KDQpyb290QHJhZGE6fiQgY2F0 IGdkYi50eHQNCkNvbnRpbnVpbmcuDQpbTmV3IFRocmVhZCAtMTIzNzQyNzI4MCAoTFdQIDMwODMp XQ0KDQpQcm9ncmFtIGV4aXRlZCB3aXRoIGNvZGUgMDE3Ny4NCnJvb3RAcmFkYTp+JA0KDQoNCl9f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpEZSA6IE9uZMWZZWogS3V6bsOtayA8b25k cmFAbWlzdG90ZWJlLm5ldD4NCkVudm95w6kgOiBsdW5kaSAyMCBtYWkgMjAxOSAxMTozMDowMw0K w4AgOiBBWUFOSURFUywgSkVBTi1QSElMSVBQRQ0KQ2MgOiBvcGVubGRhcC1pdHNAT3BlbkxEQVAu b3JnDQpPYmpldCA6IFJlOiAoSVRTIzkwMjMpIGNyYXNoIHVzaW5nIHBwb2xpY3kgY2hhaW5pbmcg ZnJvbSBzbGF2ZSB0byBtYXN0ZXINCg0KT24gTW9uLCBNYXkgMjAsIDIwMTkgYXQgMDk6MTE6MjFB TSArMDAwMCwganBheWFuaWRlc0Bwcm9zb2RpZS5jb20gd3JvdGU6DQo+IEhlbGxvIFF1YW5haCwN Cj4NCj4gd2hhdCBJIGhhdmUgZG9uZToNCj4NCj4NCj4gL3Zhci9pbnN0YWxsL29wZW5sZGFwLTIu NC40Ny9zZXJ2ZXJzL3NsYXBkL3NsYXBkIC1oICJsZGFwOi8vKjozOTAgbGRhcHM6Ly8qPQ0KPiA6 NjM3IiAtbCBMT0NBTDUgLWYgL2FwcGxpL29wZW5sZGFwLXByZXByb2QvZXRjL3NsYXBkLmNvbmYg LXUgcm9vdCAtZyByb290IDs9DQo+ICBwcyBhdXggfCBncmVwIGxkYXANCj4NCj4gZ2RiIC92YXIv aW5zdGFsbC9vcGVubGRhcC0yLjQuNDcvc2VydmVycy9zbGFwZC9zbGFwZCAxNTY4NA0KPg0KPiAo Z2RiKSBzZXQgbG9nZ2luZyBvbg0KPiAoZ2RiKSB0aHJlYWQgYXBwbHkgYWxsIGJ0IGZ1bGwNCj4g KGdkYikgY29udA0KPiA8Y3Jhc2hpbmcgb3BlcmF0aW9uPg0KPg0KPiBIZXJlIGlzIHRoZSBkdW1w Lg0KPg0KPiBTZWVtcyB0byBjcmFzaCB3aGVuIHJldHVybmluZyBmcm9tIGxpYnB0aHJlYWQNCg0K SGkgSmVhbi1QaGlsaXBwZSwNCnRoZSBiYWNrdHJhY2UgeW91IHJlY29yZGVkIHdhcyBkdXJpbmcg bm9ybWFsIG9wZXJhdGlvbiwgeW91IG5lZWQgdG8gZG8NCnRoZSBvcHBvc2l0ZSwgY29udGludWUg dG8gbGV0IHRoZSBwcm9ncmFtIGNyYXNoLCB3aXRoIGdkYiBpbnRlcmNlcHRpbmcNCnRoYXQuIFRo ZW4geW91IGNhbiB1c2UgJ3RocmVhZCBhcHBseSBhbGwgYnQgZnVsbCcgdG8gaW5zcGVjdCB0aGUg c3RhdGUNCm9mIHNsYXBkIGF0IHRoZSBwb2ludCBpdCBjcmFzaGVkLCBzbyB3aGF0IHNob3VsZCB5 b3UgZG86DQoNCj4gKGdkYikgY29udA0KPiA8Y3Jhc2hpbmcgb3BlcmF0aW9uPg0KPiAoZ2RiKSB0 aHJlYWQgYXBwbHkgYWxsIGJ0IGZ1bGwNCg0KUmVnYXJkcywNCg0KLS0NCk9uZMWZZWogS3V6bsOt aw0KU2VuaW9yIFNvZnR3YXJlIEVuZ2luZWVyDQpTeW1hcyBDb3Jwb3JhdGlvbiAgICAgICAgICAg ICAgICAgICAgICAgaHR0cDovL3d3dy5zeW1hcy5jb20NClBhY2thZ2VkLCBjZXJ0aWZpZWQsIGFu ZCBzdXBwb3J0ZWQgTERBUCBzb2x1dGlvbnMgcG93ZXJlZCBieSBPcGVuTERBUA0KVGhpcyBtZXNz YWdlIGNvbnRhaW5zIGluZm9ybWF0aW9uIHRoYXQgbWF5IGJlIHByaXZpbGVnZWQgb3IgY29uZmlk ZW50aWFsIGFuZCBpcyB0aGUgcHJvcGVydHkgb2YgdGhlIENhcGdlbWluaSBHcm91cC4gSXQgaXMg aW50ZW5kZWQgb25seSBmb3IgdGhlIHBlcnNvbiB0byB3aG9tIGl0IGlzIGFkZHJlc3NlZC4gSWYg eW91IGFyZSBub3QgdGhlIGludGVuZGVkIHJlY2lwaWVudCwgeW91IGFyZSBub3QgYXV0aG9yaXpl ZCB0byByZWFkLCBwcmludCwgcmV0YWluLCBjb3B5LCBkaXNzZW1pbmF0ZSwgZGlzdHJpYnV0ZSwg b3IgdXNlIHRoaXMgbWVzc2FnZSBvciBhbnkgcGFydCB0aGVyZW9mLiBJZiB5b3UgcmVjZWl2ZSB0 aGlzIG1lc3NhZ2UgaW4gZXJyb3IsIHBsZWFzZSBub3RpZnkgdGhlIHNlbmRlciBpbW1lZGlhdGVs eSBhbmQgZGVsZXRlIGFsbCBjb3BpZXMgb2YgdGhpcyBtZXNzYWdlLgo= --_000_AM0PR0202MB3553B6F7E1BAA0A82AF24A4FBA060AM0PR0202MB3553_ Content-Type: text/html; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxzdHlsZSB0eXBlPSJ0ZXh0L2NzcyIgc3R5bGU9 ImRpc3BsYXk6bm9uZTsiPjwhLS0gUCB7bWFyZ2luLXRvcDowO21hcmdpbi1ib3R0b206MDt9IC0t Pjwvc3R5bGU+DQo8L2hlYWQ+DQo8Ym9keSBkaXI9Imx0ciI+DQo8ZGl2IGlkPSJkaXZ0YWdkZWZh dWx0d3JhcHBlciIgc3R5bGU9ImZvbnQtc2l6ZToxMnB0O2NvbG9yOiMwMDAwMDA7Zm9udC1mYW1p bHk6Q2FsaWJyaSxIZWx2ZXRpY2Esc2Fucy1zZXJpZjsiIGRpcj0ibHRyIj4NCjxwIHN0eWxlPSJt YXJnaW4tdG9wOjA7bWFyZ2luLWJvdHRvbTowIj5IZWxsbyZuYnNwOzxmb250IHNpemU9IjIiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTFwdDsiPk9uZMWZZWombmJzcDs8L3NwYW4+PC9mb250Pjwv cD4NCjxwIHN0eWxlPSJtYXJnaW4tdG9wOjA7bWFyZ2luLWJvdHRvbTowIj5JIGhhdmUgcHJvY2Vl ZGVkIGxpa2UgdGhpcyBiZWNhdXNlIEkgaGFkIG5vdGhpbmcgbW9yZSB0byBzaG93ITwvcD4NCjxw IHN0eWxlPSJtYXJnaW4tdG9wOjA7bWFyZ2luLWJvdHRvbTowIj5JZiBJIHJ1biB0aGUgY29tbWFu ZHMgYXMgeW91IHNhaWQ6PC9wPg0KPHAgc3R5bGU9Im1hcmdpbi10b3A6MDttYXJnaW4tYm90dG9t OjAiPjxicj4NCjwvcD4NCjxwIHN0eWxlPSJtYXJnaW4tdG9wOjA7bWFyZ2luLWJvdHRvbTowIj4o 4oCmKTwvcD4NCjxwIHN0eWxlPSJtYXJnaW4tdG9wOjA7bWFyZ2luLWJvdHRvbTowIj48L3A+DQo8 ZGl2PkxvYWRlZCBzeW1ib2xzIGZvciAvYXBwbGkvb3BlbmxkYXAtMi40LjQ3L2xpYmV4ZWMvb3Bl bmxkYXAvcHBvbGljeS0yLjQuc28uMjxicj4NClJlYWRpbmcgc3ltYm9scyBmcm9tIC9hcHBsaS9v cGVubGRhcC0yLjQuNDcvbGliZXhlYy9vcGVubGRhcC9iYWNrX2xkYXAtMi40LnNvLjIuLi5kb25l Ljxicj4NCkxvYWRlZCBzeW1ib2xzIGZvciAvYXBwbGkvb3BlbmxkYXAtMi40LjQ3L2xpYmV4ZWMv b3BlbmxkYXAvYmFja19sZGFwLTIuNC5zby4yPGJyPg0KUmVhZGluZyBzeW1ib2xzIGZyb20gL2Fw cGxpL29wZW5sZGFwLTIuNC40Ny9saWJleGVjL29wZW5sZGFwL3B3LXNoYTIuc28uMC4uLmRvbmUu PGJyPg0KTG9hZGVkIHN5bWJvbHMgZm9yIC9hcHBsaS9vcGVubGRhcC0yLjQuNDcvbGliZXhlYy9v cGVubGRhcC9wdy1zaGEyLnNvLjA8YnI+DQpSZWFkaW5nIHN5bWJvbHMgZnJvbSAvYXBwbGkvb3Bl bmxkYXAtMi40LjQ3L2xpYi9saWJsZGFwX3ItMi40LnNvLjIuLi5kb25lLjxicj4NCkxvYWRlZCBz eW1ib2xzIGZvciAvYXBwbGkvb3BlbmxkYXAtMi40LjQ3L2xpYi9saWJsZGFwX3ItMi40LnNvLjI8 YnI+DQpSZWFkaW5nIHN5bWJvbHMgZnJvbSAvYXBwbGkvb3BlbmxkYXAtMi40LjQ3L2xpYi9saWJs YmVyLTIuNC5zby4yLi4uZG9uZS48YnI+DQpMb2FkZWQgc3ltYm9scyBmb3IgL2FwcGxpL29wZW5s ZGFwLTIuNC40Ny9saWIvbGlibGJlci0yLjQuc28uMjxicj4NCkZhaWxlZCB0byByZWFkIGEgdmFs aWQgb2JqZWN0IGZpbGUgaW1hZ2UgZnJvbSBtZW1vcnkuPGJyPg0KMHhiN2M5MzE4MyBpbiBwdGhy ZWFkX2pvaW4gKCkgZnJvbSAvbGliL3Rscy9saWJwdGhyZWFkLnNvLjA8YnI+DQooZ2RiKSBzZXQg bG9nZ2luZyBvbjxicj4NCkNvcHlpbmcgb3V0cHV0IHRvIGdkYi50eHQuPGJyPg0KKGdkYikgY29u dDxicj4NCkNvbnRpbnVpbmcuPGJyPg0KW05ldyBUaHJlYWQgLTEyMzc1NDE5NjggKExXUCAyOTM4 MCldPGJyPg0KPGJyPg0KUHJvZ3JhbSBleGl0ZWQgd2l0aCBjb2RlIDAxNzcuPGJyPg0KKGdkYikg dGhyZWFkIGFwcGx5IGFsbCBidCBmdWxsPGJyPg0KKGdkYik8YnI+DQooZ2RiKSBxdWl0PGJyPg0K PGJyPg0KPC9kaXY+DQo8cD48L3A+DQo8cCBzdHlsZT0ibWFyZ2luLXRvcDowO21hcmdpbi1ib3R0 b206MCI+SSBnZXQgdGhlIGZpbGUgZ2RiLnR4dCBjb250YWluaW5nIG9ubHkgdGhhdDo8L3A+DQo8 cCBzdHlsZT0ibWFyZ2luLXRvcDowO21hcmdpbi1ib3R0b206MCI+PGJyPg0KPC9wPg0KPHAgc3R5 bGU9Im1hcmdpbi10b3A6MDttYXJnaW4tYm90dG9tOjAiPjwvcD4NCjxkaXY+cm9vdEByYWRhOn4k IGNhdCBnZGIudHh0PGJyPg0KQ29udGludWluZy48YnI+DQpbTmV3IFRocmVhZCAtMTIzNzQyNzI4 MCAoTFdQIDMwODMpXTxicj4NCjxicj4NClByb2dyYW0gZXhpdGVkIHdpdGggY29kZSAwMTc3Ljxi cj4NCnJvb3RAcmFkYTp+JDxicj4NCjxicj4NCjwvZGl2Pg0KPHN0cm9uZz48c3BhbiBzdHlsZT0i Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OzsgY29s b3I6IzAwOThDQyI+PC9zcGFuPjwvc3Ryb25nPg0KPHA+PC9wPg0KPGRpdiBpZD0iU2lnbmF0dXJl Ij48L2Rpdj4NCjwvZGl2Pg0KPGhyIHN0eWxlPSJkaXNwbGF5OmlubGluZS1ibG9jazt3aWR0aDo5 OCUiIHRhYmluZGV4PSItMSI+DQo8ZGl2IGlkPSJkaXZScGx5RndkTXNnIiBkaXI9Imx0ciI+PGZv bnQgZmFjZT0iQ2FsaWJyaSwgc2Fucy1zZXJpZiIgc3R5bGU9ImZvbnQtc2l6ZToxMXB0IiBjb2xv cj0iIzAwMDAwMCI+PGI+RGUgOjwvYj4gT25kxZllaiBLdXpuw61rICZsdDtvbmRyYUBtaXN0b3Rl YmUubmV0Jmd0Ozxicj4NCjxiPkVudm95w6kgOjwvYj4gbHVuZGkgMjAgbWFpIDIwMTkgMTE6MzA6 MDM8YnI+DQo8Yj7DgCA6PC9iPiBBWUFOSURFUywgSkVBTi1QSElMSVBQRTxicj4NCjxiPkNjJm5i c3A7OjwvYj4gb3BlbmxkYXAtaXRzQE9wZW5MREFQLm9yZzxicj4NCjxiPk9iamV0IDo8L2I+IFJl OiAoSVRTIzkwMjMpIGNyYXNoIHVzaW5nIHBwb2xpY3kgY2hhaW5pbmcgZnJvbSBzbGF2ZSB0byBt YXN0ZXI8L2ZvbnQ+DQo8ZGl2PiZuYnNwOzwvZGl2Pg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSJCb2R5 RnJhZ21lbnQiPjxmb250IHNpemU9IjIiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTFwdDsiPg0K PGRpdiBjbGFzcz0iUGxhaW5UZXh0Ij5PbiBNb24sIE1heSAyMCwgMjAxOSBhdCAwOToxMToyMUFN ICYjNDM7MDAwMCwganBheWFuaWRlc0Bwcm9zb2RpZS5jb20gd3JvdGU6PGJyPg0KJmd0OyBIZWxs byBRdWFuYWgsPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IHdoYXQgSSBoYXZlIGRvbmU6PGJyPg0KJmd0 OyA8YnI+DQomZ3Q7IDxicj4NCiZndDsgL3Zhci9pbnN0YWxsL29wZW5sZGFwLTIuNC40Ny9zZXJ2 ZXJzL3NsYXBkL3NsYXBkIC1oICZxdW90O2xkYXA6Ly8qOjM5MCBsZGFwczovLyo9PGJyPg0KJmd0 OyA6NjM3JnF1b3Q7IC1sIExPQ0FMNSAtZiAvYXBwbGkvb3BlbmxkYXAtcHJlcHJvZC9ldGMvc2xh cGQuY29uZiAtdSByb290IC1nIHJvb3QgOz08YnI+DQomZ3Q7Jm5ic3A7IHBzIGF1eCB8IGdyZXAg bGRhcDxicj4NCiZndDsgPGJyPg0KJmd0OyBnZGIgL3Zhci9pbnN0YWxsL29wZW5sZGFwLTIuNC40 Ny9zZXJ2ZXJzL3NsYXBkL3NsYXBkIDE1Njg0PGJyPg0KJmd0OyA8YnI+DQomZ3Q7IChnZGIpIHNl dCBsb2dnaW5nIG9uPGJyPg0KJmd0OyAoZ2RiKSB0aHJlYWQgYXBwbHkgYWxsIGJ0IGZ1bGw8YnI+ DQomZ3Q7IChnZGIpIGNvbnQ8YnI+DQomZ3Q7ICZsdDtjcmFzaGluZyBvcGVyYXRpb24mZ3Q7PGJy Pg0KJmd0OyA8YnI+DQomZ3Q7IEhlcmUgaXMgdGhlIGR1bXAuPGJyPg0KJmd0OyA8YnI+DQomZ3Q7 IFNlZW1zIHRvIGNyYXNoIHdoZW4gcmV0dXJuaW5nIGZyb20gbGlicHRocmVhZDxicj4NCjxicj4N CkhpIEplYW4tUGhpbGlwcGUsPGJyPg0KdGhlIGJhY2t0cmFjZSB5b3UgcmVjb3JkZWQgd2FzIGR1 cmluZyBub3JtYWwgb3BlcmF0aW9uLCB5b3UgbmVlZCB0byBkbzxicj4NCnRoZSBvcHBvc2l0ZSwg Y29udGludWUgdG8gbGV0IHRoZSBwcm9ncmFtIGNyYXNoLCB3aXRoIGdkYiBpbnRlcmNlcHRpbmc8 YnI+DQp0aGF0LiBUaGVuIHlvdSBjYW4gdXNlICd0aHJlYWQgYXBwbHkgYWxsIGJ0IGZ1bGwnIHRv IGluc3BlY3QgdGhlIHN0YXRlPGJyPg0Kb2Ygc2xhcGQgYXQgdGhlIHBvaW50IGl0IGNyYXNoZWQs IHNvIHdoYXQgc2hvdWxkIHlvdSBkbzo8YnI+DQo8YnI+DQomZ3Q7IChnZGIpIGNvbnQ8YnI+DQom Z3Q7ICZsdDtjcmFzaGluZyBvcGVyYXRpb24mZ3Q7PGJyPg0KJmd0OyAoZ2RiKSB0aHJlYWQgYXBw bHkgYWxsIGJ0IGZ1bGw8YnI+DQo8YnI+DQpSZWdhcmRzLDxicj4NCjxicj4NCi0tIDxicj4NCk9u ZMWZZWogS3V6bsOtazxicj4NClNlbmlvciBTb2Z0d2FyZSBFbmdpbmVlcjxicj4NClN5bWFzIENv cnBvcmF0aW9uJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDxhIGhyZWY9Imh0dHA6Ly93d3cuc3ltYXMuY29t Ij5odHRwOi8vd3d3LnN5bWFzLmNvbTwvYT48YnI+DQpQYWNrYWdlZCwgY2VydGlmaWVkLCBhbmQg c3VwcG9ydGVkIExEQVAgc29sdXRpb25zIHBvd2VyZWQgYnkgT3BlbkxEQVA8YnI+DQo8L2Rpdj4N Cjwvc3Bhbj48L2ZvbnQ+PC9kaXY+DQo8cD48L3A+DQoNCjxwPjwvcD4NCg0KPHA+PC9wPg0KDQo8 cCBzdHlsZT0iZm9udC1zaXplOiA5cHg7ICI+VGhpcyBtZXNzYWdlIGNvbnRhaW5zIGluZm9ybWF0 aW9uIHRoYXQgbWF5IGJlIHByaXZpbGVnZWQgb3IgY29uZmlkZW50aWFsIGFuZCBpcyB0aGUgcHJv cGVydHkgb2YgdGhlIENhcGdlbWluaSBHcm91cC4gSXQgaXMgaW50ZW5kZWQgb25seSBmb3IgdGhl IHBlcnNvbiB0byB3aG9tIGl0IGlzIGFkZHJlc3NlZC4gSWYgeW91IGFyZSBub3QgdGhlIGludGVu ZGVkIHJlY2lwaWVudCwgeW91IGFyZSBub3QgYXV0aG9yaXplZCB0byByZWFkLCBwcmludCwgcmV0 YWluLCBjb3B5LCBkaXNzZW1pbmF0ZSwgZGlzdHJpYnV0ZSwgb3IgdXNlIHRoaXMgbWVzc2FnZSBv ciBhbnkgcGFydCB0aGVyZW9mLiBJZiB5b3UgcmVjZWl2ZSB0aGlzIG1lc3NhZ2UgaW4gZXJyb3Is IHBsZWFzZSBub3RpZnkgdGhlIHNlbmRlciBpbW1lZGlhdGVseSBhbmQgZGVsZXRlIGFsbCBjb3Bp ZXMgb2YgdGhpcyBtZXNzYWdlLjwvcD48L2JvZHk+DQo8L2h0bWw+DQo= --_000_AM0PR0202MB3553B6F7E1BAA0A82AF24A4FBA060AM0PR0202MB3553_--

1 0

Re: (ITS#9023) crash using ppolicy chaining from slave to master
by ondra＠mistotebe.net 20 May '19

20 May '19

On Mon, May 20, 2019 at 09:11:21AM +0000, jpayanides(a)prosodie.com wrote: > Hello Quanah, > > what I have done: > > > /var/install/openldap-2.4.47/servers/slapd/slapd -h "ldap://*:390 ldaps://*= > :637" -l LOCAL5 -f /appli/openldap-preprod/etc/slapd.conf -u root -g root ;= > ps aux | grep ldap > > gdb /var/install/openldap-2.4.47/servers/slapd/slapd 15684 > > (gdb) set logging on > (gdb) thread apply all bt full > (gdb) cont > <crashing operation> > > Here is the dump. > > Seems to crash when returning from libpthread Hi Jean-Philippe, the backtrace you recorded was during normal operation, you need to do the opposite, continue to let the program crash, with gdb intercepting that. Then you can use 'thread apply all bt full' to inspect the state of slapd at the point it crashed, so what should you do: > (gdb) cont > <crashing operation> > (gdb) thread apply all bt full Regards, -- 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#9023) crash using ppolicy chaining from slave to master
by jpayanides＠prosodie.com 20 May '19

20 May '19

--_004_AM0PR0202MB355397966458DFBCF87CDE19BA060AM0PR0202MB3553_ Content-Type: multipart/alternative; boundary="_000_AM0PR0202MB355397966458DFBCF87CDE19BA060AM0PR0202MB3553_" --_000_AM0PR0202MB355397966458DFBCF87CDE19BA060AM0PR0202MB3553_ Content-Type: text/plain; charset="iso-8859-1" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Hello Quanah, what I have done: /var/install/openldap-2.4.47/servers/slapd/slapd -h "ldap://*:390 ldaps://*= :637" -l LOCAL5 -f /appli/openldap-preprod/etc/slapd.conf -u root -g root ;= ps aux | grep ldap gdb /var/install/openldap-2.4.47/servers/slapd/slapd 15684 (gdb) set logging on (gdb) thread apply all bt full (gdb) cont <crashing operation> Here is the dump. Seems to crash when returning from libpthread -- Jean-Philippe ________________________________ De : Quanah Gibson-Mount <quanah(a)symas.com> Envoy=E9 : vendredi 17 mai 2019 17:30:42 =C0 : AYANIDES, JEAN-PHILIPPE; openldap-its(a)OpenLDAP.org Objet : RE: (ITS#9023) crash using ppolicy chaining from slave to master --On Friday, May 17, 2019 4:09 PM +0000 "AYANIDES, JEAN-PHILIPPE" <jpayanides(a)prosodie.com> wrote: > > > Hello Quanah, > > I am not very familiar with gdb. Can you help me doing that? Start slapd on the server that's crashing Get the process ID of slapd gdb /path/to/slapd PID For example, if slapd is located in /usr/sbin, and the process ID is 1234: gdb /usr/sbin/slapd 1234 At the (gdb) prompt, enter the command "cont" to continue execution Run your operation that causes slapd to crash. This should drop you back to the (gdb) prompt. Then run the command: thr apply all bt full This will provide the full backtrace. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com> This message contains information that may be privileged or confidential an= d is the property of the Capgemini Group. It is intended only for the perso= n to whom it is addressed. If you are not the intended recipient, you are n= ot authorized to read, print, retain, copy, disseminate, distribute, or use= this message or any part thereof. If you receive this message in error, pl= ease notify the sender immediately and delete all copies of this message. --_000_AM0PR0202MB355397966458DFBCF87CDE19BA060AM0PR0202MB3553_ Content-Type: text/html; charset="iso-8859-1" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable <html> <head> <meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Diso-8859-= 1"> <style type=3D"text/css" style=3D"display:none;"></style> </head> <body dir=3D"ltr"> <div id=3D"divtagdefaultwrapper" style=3D"font-size:12pt;color:#000000;font= -family:Calibri,Helvetica,sans-serif;" dir=3D"ltr"> <p style=3D"margin-top:0;margin-bottom:0">Hello Quanah,</p> <p style=3D"margin-top:0;margin-bottom:0">what I have done:</p> <p style=3D"margin-top:0;margin-bottom:0"><br> </p> <p style=3D"margin-top:0;margin-bottom:0"></p> <div>/var/install/openldap-2.4.47/servers/slapd/slapd -h "ldap://*:390= ldaps://*:637" -l LOCAL5 -f /appli/openldap-preprod/etc/slapd.conf -u= root -g root ; ps aux | grep ldap<br> </div> <div> <div><br> </div> <div>gdb /var/install/openldap-2.4.47/servers/slapd/slapd 15684<br> <br> </div> (gdb) set logging on</div> <div>(gdb) thread apply all bt full</div> <div>(gdb) cont</div> <div><crashing operation><br> </div> <br> <p></p> <p style=3D"margin-top:0;margin-bottom:0">Here is the dump.</p> <p style=3D"margin-top:0;margin-bottom:0"><br> </p> <p style=3D"margin-top:0;margin-bottom:0">Seems to crash when returning fro= m libpthread<br> </p> <p style=3D"margin-top:0;margin-bottom:0">--</p> <p style=3D"margin-top:0;margin-bottom:0">Jean-Philippe<br> </p> <div id=3D"Signature"> <meta content=3D"text/html; charset=3DUTF-8"> </div> </div> <hr style=3D"display:inline-block;width:98%" tabindex=3D"-1"> <div id=3D"divRplyFwdMsg" dir=3D"ltr"><font face=3D"Calibri, sans-serif" st= yle=3D"font-size:11pt" color=3D"#000000"><b>De :</b> Quanah Gibson-Mount &l= t;quanah(a)symas.com><br> <b>Envoy=E9 :</b> vendredi 17 mai 2019 17:30:42<br> <b>=C0 :</b> AYANIDES, JEAN-PHILIPPE; openldap-its(a)OpenLDAP.org<br> <b>Objet :</b> RE: (ITS#9023) crash using ppolicy chaining from slave to ma= ster</font> <div> </div> </div> <div class=3D"BodyFragment"><font size=3D"2"><span style=3D"font-size:11pt;= "> <div class=3D"PlainText">--On Friday, May 17, 2019 4:09 PM +0000 "= AYANIDES, JEAN-PHILIPPE" <br> <jpayanides(a)prosodie.com> wrote:<br> <br> ><br> ><br> > Hello Quanah,<br> ><br> > I am not very familiar with gdb. Can you help me doing that?<br> <br> <br> Start slapd on the server that's crashing<br> Get the process ID of slapd<br> <br> gdb /path/to/slapd PID<br> <br> For example, if slapd is located in /usr/sbin, and the process ID is 1234:<= br> <br> gdb /usr/sbin/slapd 1234<br> <br> At the (gdb) prompt, enter the command "cont" to continue executi= on<br> <br> Run your operation that causes slapd to crash.  This should drop you b= ack <br> to the (gdb) prompt.<br> <br> Then run the command:<br> <br> thr apply all bt full<br> <br> This will provide the full backtrace.<br> <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">http://www.symas.com</a>><br> <br> </div> </span></font></div> <span style=3D"font-size: 9px; line-height: 10px;">This message contains in= formation that may be privileged or confidential and is the property of the= Capgemini Group. It is intended only for the person to whom it is addresse= d. If you are not the intended recipient, you are not authorized to read, p= rint, retain, copy, disseminate, distribute, or use this message or any par= t thereof. If you receive this message in error, please notify the sender i= mmediately and delete all copies of this message.</span></body> </html> --_000_AM0PR0202MB355397966458DFBCF87CDE19BA060AM0PR0202MB3553_-- --_004_AM0PR0202MB355397966458DFBCF87CDE19BA060AM0PR0202MB3553_ Content-Type: text/plain; name="gdb.txt" Content-Description: gdb.txt Content-Disposition: attachment; filename="gdb.txt"; size=2695; creation-date="Mon, 20 May 2019 09:10:06 GMT"; modification-date="Mon, 20 May 2019 09:10:06 GMT" Content-Transfer-Encoding: base64 ClRocmVhZCAzIChUaHJlYWQgLTEyMjc2OTkyODAgKExXUCAxNTY4NykpOgojMCAgMHhiN2M4ODY3 OSBpbiBlcG9sbF93YWl0ICgpIGZyb20gL2xpYi90bHMvbGliYy5zby42Ck5vIHN5bWJvbCB0YWJs ZSBpbmZvIGF2YWlsYWJsZS4KIzEgIDB4MDgwNzljYmQgaW4gc2xhcGRfZGFlbW9uX3Rhc2sgKHB0 cj0weDApIGF0IGRhZW1vbi5jOjI1MzkKICAgICAgICBhY3RpdmUgPSAwCiAgICAgICAgbCA9IDx2 YWx1ZSBvcHRpbWl6ZWQgb3V0PgogICAgICAgIGxhc3RfaWRsZV9jaGVjayA9IDE1NTgzNDMwMzgK ICAgICAgICBlYmFkZiA9IDAKIzIgIDB4YjdjZjQwYmQgaW4gc3RhcnRfdGhyZWFkICgpIGZyb20g L2xpYi90bHMvbGlicHRocmVhZC5zby4wCk5vIHN5bWJvbCB0YWJsZSBpbmZvIGF2YWlsYWJsZS4K IzMgIDB4YjdjODgwMWUgaW4gY2xvbmUgKCkgZnJvbSAvbGliL3Rscy9saWJjLnNvLjYKTm8gc3lt Ym9sIHRhYmxlIGluZm8gYXZhaWxhYmxlLgoKVGhyZWFkIDIgKFRocmVhZCAtMTIzMTg5MzU4NCAo TFdQIDE1Njg4KSk6CiMwICAweGI3Y2Y2YzAxIGluIHB0aHJlYWRfY29uZF93YWl0QEBHTElCQ18y LjMuMiAoKSBmcm9tIC9saWIvdGxzL2xpYnB0aHJlYWQuc28uMApObyBzeW1ib2wgdGFibGUgaW5m byBhdmFpbGFibGUuCiMxICAweDA4MTc4ZGNmIGluIGxkYXBfaW50X3RocmVhZF9wb29sX3dyYXBw ZXIgKHhwb29sPTB4ODJhOWMzMCkgYXQgdHBvb2wuYzo2ODMKICAgICAgICB0YXNrID0gKGxkYXBf aW50X3RocmVhZF90YXNrX3QgKikgMHgwCiAgICAgICAgd29ya19saXN0ID0gKGxkYXBfaW50X3Rw b29sX3BsaXN0X3QgKikgMHgxCiAgICAgICAgY3R4ID0ge2x0dV9pZCA9IDMwNjMwNzM3MTIsIGx0 dV9rZXkgPSB7e2x0a19rZXkgPSAweDgwZDM3ZjAsIGx0a19kYXRhID0gMHg4MzViNGQwLAogICAg ICBsdGtfZnJlZSA9IDB4ODBkMzgyMCA8c2xhcF9zbF9tZW1fZGVzdHJveT59LCB7bHRrX2tleSA9 IDB4ODMzZmE4OCwgbHRrX2RhdGEgPSAweDgzNjZkNTAsCiAgICAgIGx0a19mcmVlID0gMHg4MTMz OGQwIDxiZGJfcmVhZGVyX2ZyZWU+fSwge2x0a19rZXkgPSAweDAsIGx0a19kYXRhID0gMHgwLAog ICAgICBsdGtfZnJlZSA9IDB9IDxyZXBlYXRzIDMwIHRpbWVzPn19CiAgICAgICAga2N0eCA9IDx2 YWx1ZSBvcHRpbWl6ZWQgb3V0PgogICAgICAgIGtleXNsb3QgPSAxMzEKICAgICAgICBoYXNoID0g PHZhbHVlIG9wdGltaXplZCBvdXQ+CiAgICAgICAgX19QUkVUVFlfRlVOQ1RJT05fXyA9ICJsZGFw X2ludF90aHJlYWRfcG9vbF93cmFwcGVyIgojMiAgMHhiN2NmNDBiZCBpbiBzdGFydF90aHJlYWQg KCkgZnJvbSAvbGliL3Rscy9saWJwdGhyZWFkLnNvLjAKTm8gc3ltYm9sIHRhYmxlIGluZm8gYXZh aWxhYmxlLgojMyAgMHhiN2M4ODAxZSBpbiBjbG9uZSAoKSBmcm9tIC9saWIvdGxzL2xpYmMuc28u NgpObyBzeW1ib2wgdGFibGUgaW5mbyBhdmFpbGFibGUuCgpUaHJlYWQgMSAoVGhyZWFkIC0xMjEy NTE2MTI4IChMV1AgMTU2ODQpKToKIzAgIDB4YjdjZjUxODMgaW4gcHRocmVhZF9qb2luICgpIGZy b20gL2xpYi90bHMvbGlicHRocmVhZC5zby4wCk5vIHN5bWJvbCB0YWJsZSBpbmZvIGF2YWlsYWJs ZS4KIzEgIDB4MDgwNzZmMWEgaW4gc2xhcGRfZGFlbW9uICgpIGF0IGRhZW1vbi5jOjI5MzIKICAg ICAgICBpID0gPHZhbHVlIG9wdGltaXplZCBvdXQ+CiAgICAgICAgcmMgPSA8dmFsdWUgb3B0aW1p emVkIG91dD4KIzIgIDB4MDgwNjI5NTcgaW4gbWFpbiAoYXJnYz0xMSwgYXJndj0weGJmODA3NDI0 KSBhdCBtYWluLmM6MTAxNwogICAgICAgIGkgPSAxMQogICAgICAgIG5vX2RldGFjaCA9IDAKICAg ICAgICByYyA9IDAKICAgICAgICB1cmxzID0gMHg4MjgwMDA4ICJsZGFwOi8vKjozOTAgbGRhcHM6 Ly8qOjYzNyIKICAgICAgICB1c2VybmFtZSA9IDB4ODI4MDA1OCAicm9vdCIKICAgICAgICBncm91 cG5hbWUgPSAweDgyODAwNjggImxkYXAiCiAgICAgICAgc2FuZGJveCA9IDB4MAogICAgICAgIHN5 c2xvZ1VzZXIgPSAxNjgKICAgICAgICBwaWQgPSA8dmFsdWUgb3B0aW1pemVkIG91dD4KICAgICAg ICB3YWl0ZmRzID0gezExLCAxMn0KICAgICAgICBjb25maWdmaWxlID0gMHg4MjgwMDI4ICIvYXBw bGkvb3BlbmxkYXAtcHJlcHJvZC9ldGMvc2xhcGQuY29uZiIKICAgICAgICBjb25maWdkaXIgPSAw eDAKICAgICAgICBzZXJ2ZXJOYW1lID0gPHZhbHVlIG9wdGltaXplZCBvdXQ+CiAgICAgICAgc2Nw ID0gPHZhbHVlIG9wdGltaXplZCBvdXQ+CiAgICAgICAgc2NwX2VudHJ5ID0gPHZhbHVlIG9wdGlt aXplZCBvdXQ+CiAgICAgICAgZGVidWdfdW5rbm93bnMgPSAoY2hhciAqKikgMHgwCiAgICAgICAg c3lzbG9nX3Vua25vd25zID0gKGNoYXIgKiopIDB4MAogICAgICAgIGwgPSA8dmFsdWUgb3B0aW1p emVkIG91dD4KICAgICAgICBzbGFwZF9waWRfZmlsZV91bmxpbmsgPSAxCiAgICAgICAgc2xhcGRf YXJnc19maWxlX3VubGluayA9IDEKICAgICAgICBmaXJzdG9wdCA9IDx2YWx1ZSBvcHRpbWl6ZWQg b3V0PgogICAgICAgIF9fUFJFVFRZX0ZVTkNUSU9OX18gPSAibWFpbiIKIzAgIDB4YjdjZjUxODMg aW4gcHRocmVhZF9qb2luICgpIGZyb20gL2xpYi90bHMvbGlicHRocmVhZC5zby4wCkNvbnRpbnVp bmcuCltOZXcgVGhyZWFkIC0xMjM3MTQwNTYwIChMV1AgMTY4NzYpXQoKUHJvZ3JhbSBleGl0ZWQg d2l0aCBjb2RlIDAxNzcuCg== --_004_AM0PR0202MB355397966458DFBCF87CDE19BA060AM0PR0202MB3553_--

1 0

Re: (ITS#9026) slapd
by ryan＠nardis.ca 20 May '19

20 May '19

Hello, On Mon, May 20, 2019 at 03:38:49AM +0000, vkelkar(a)ucsd.edu wrote: >Version: 2.4.47 >OS: ubuntu This ITS tracks issues about OpenLDAP software itself. It sounds like your issue relates to the Ubuntu slapd package. In that case it should be reported in the Ubuntu tracker (Launchpad), or to Canonical support. In any case, your message did not really include enough information to diagnose your issue. When you report the issue elsewhere, please include the complete terminal output from the apt-get or dpkg command you ran, and the exact version of the slapd package (can be obtained from e.g. 'dpkg-query -W slapd'). I will close this ITS for now. It can be reopened if the issue actually turns out to be a problem with OpenLDAP software. Thanks Ryan

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