- openldap-bugs - openldap.org

(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 07 Jun '19

07 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 07 Jun '19

07 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 07 Jun '19

07 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 07 Jun '19

07 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 07 Jun '19

07 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 07 Jun '19

07 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 07 Jun '19

07 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 06 Jun '19

06 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

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs