- openldap-bugs - openldap.org

(ITS#8209) Broken MDB_CP_COMPACT threading
by h.b.furuseth＠usit.uio.no 29 Jul '15

29 Jul '15

Full_Name: Hallvard B Furuseth Version: LMDB_0.9.15 OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (81.191.45.5) Submitted by: hallvard mdb_env_copyfd1() and mdb_env_copythr() synchronize via my->mc_new, but incorrectly. copythr() starts before there is any data to consume, and copyfd1() does not tell it (by setting mc_new and signalling) when there is data. Instead it sets mc_new before it has finished producing the data. I suppose copythr just waits for a spurious wakeup, I haven't looked closely. It got it right originally when copyfd1 did not start the new thread until data (metapages) was ready. Or copyfd1 could start with mc_new = 0, and set it and signal when data is ready. copythr holds the mutex while writing. That's not how conds are supposed to be used. Threads are supposed to grab the mutex briefly around code which operates on mc_new. mc_status can be lost. Copyfd1 does not always use it, or it discards it. And copythr should set mc_new=0 before exiting also when setting mc_status. so copyfd1 won't just sit and wait.

1 0

Re: (ITS#8208) ppolicy supportedControl not visible in root DSE
by michael＠stroeder.com 29 Jul '15

29 Jul '15

robert.brooks(a)reporo.com wrote: > with ppolicy overlay loaded (and functioning) the following root DSE is= : > [..] > I would expect to see output similar to... >=20 > http://docs.forgerock.org/en/opendj/2.6.0/dev-guide/index/chap-getting-= directory-info.html#read-root-dse > D0D > specifilllly line 12 (and maybe line 40). It's a bit hard to follow line number references in a web page. :-/ But I guess you mean the OIDs coming from draft-vchu-ldap-pwd-policy [1].= Note that AFAIK OpenDJ supports old draft-vchu-ldap-pwd-policy which is v= ery outdated and not supported by LDAP servers without Netscape roots. slapo-ppolicy implements draft-behera-ldap-password-policy [2]. > # Search the root DSE for the password policy (works > # with Netscape Directory Server) > pam_lookup_policy yes >=20 > does not make pam_ldap to interact with password policies against when > configured in openldap. Using pam_ldap is NOT recommended nowadays for a bunch of reasons. Use nss-pam-ldapd, sssd or OpenLDAP's slapo-nssov. AFAIK all of them support draft-behera-ldap-password-policy. But such usage discussion belong on the openldap-technical mailing list a= nd not in the ITS. Ciao, Michael. [1] https://tools.ietf.org/html/draft-vchu-ldap-pwd-policy [2] https://tools.ietf.org/html/draft-behera-ldap-password-policy

1 0

Re: (ITS#8208) ppolicy supportedControl not visible in root DSE
by hyc＠symas.com 29 Jul '15

29 Jul '15

robert.brooks(a)reporo.com wrote: > Full_Name: Robert Brooks > Version: openldap-2.4.41 > OS: Ubuntu 14.04 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (38.99.38.134) > > > Hi, > > with ppolicy overlay loaded (and functioning) the following root DSE is: > I believe this is why the following pam_ldap config: > > # Search the root DSE for the password policy (works > # with Netscape Directory Server) > pam_lookup_policy yes > > does not make pam_ldap to interact with password policies against when > configured in openldap. No. That controls compatibility with the obsolete/non-standard Netscape-specific password policy attributes. But pam_ldap itself is also obsolete. Pretty sure Ubuntu ships with nslcd and nss-pam-ldapd now. -- -- 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#8208) ppolicy supportedControl not visible in root DSE
by robert.brooks＠reporo.com 29 Jul '15

29 Jul '15

Full_Name: Robert Brooks Version: openldap-2.4.41 OS: Ubuntu 14.04 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (38.99.38.134) Hi, with ppolicy overlay loaded (and functioning) the following root DSE is: structuralObjectClass: OpenLDAProotDSE configContext: cn=config namingContexts: dc=ldap,dc=example,dc=org supportedControl: 2.16.840.1.113730.3.4.18 supportedControl: 2.16.840.1.113730.3.4.2 supportedControl: 1.3.6.1.4.1.4203.1.10.1 supportedControl: 1.2.840.113556.1.4.319 supportedControl: 1.2.826.0.1.3344810.2.3 supportedControl: 1.3.6.1.1.13.2 supportedControl: 1.3.6.1.1.13.1 supportedControl: 1.3.6.1.1.12 supportedExtension: 1.3.6.1.4.1.1466.20037 supportedExtension: 1.3.6.1.4.1.4203.1.11.1 supportedExtension: 1.3.6.1.4.1.4203.1.11.3 supportedExtension: 1.3.6.1.1.8 supportedFeatures: 1.3.6.1.1.14 supportedFeatures: 1.3.6.1.4.1.4203.1.5.1 supportedFeatures: 1.3.6.1.4.1.4203.1.5.2 supportedFeatures: 1.3.6.1.4.1.4203.1.5.3 supportedFeatures: 1.3.6.1.4.1.4203.1.5.4 supportedFeatures: 1.3.6.1.4.1.4203.1.5.5 supportedLDAPVersion: 3 supportedSASLMechanisms: DIGEST-MD5 supportedSASLMechanisms: NTLM supportedSASLMechanisms: CRAM-MD5 entryDN: subschemaSubentry: cn=Subschema I would expect to see output similar to... http://docs.forgerock.org/en/opendj/2.6.0/dev-guide/index/chap-getting-dire… D0D specifilllly line 12 (and maybe line 40). I believe this is why the following pam_ldap config: # Search the root DSE for the password policy (works # with Netscape Directory Server) pam_lookup_policy yes does not make pam_ldap to interact with password policies against when configured in openldap. Regards, Rob

1 0

Re: (ITS#8206) ldapsearch incorrectly cannonicalizes dns names for GSSAPI
by michael＠stroeder.com 29 Jul '15

29 Jul '15

Calvin Winkowski wrote: >> Did you already try with -N? > > Nope, a bit embarrassed that I didn't find that on my own. Thanks! It > does work with the -N flag. > > I think there is still argument for making that the default and > providing a flag to canonicalize the hostname, but I don't know enough > about GSSAPI's standard to say for certain. I've only used it with > Kerberos. IIRC there was a long-winding sasl-no-canonicalize debate on the mailing lists a while ago. I'm pretty sure nobody wants to repeat that. Ciao, Michael.

1 0

Re: (ITS#8207) ppolicy: pwdMinLength not checked if pwdInHistory == 0
by michael＠stroeder.com 29 Jul '15

29 Jul '15

porjo38(a)yahoo.com.au wrote: > Using password policy overlay, pwdMinLength is not checked when pwdInHistory == > 0. I tried to reproduce this with my local OpenLDAP 2.4.41 installation. In one case I thought to see this but I could not reproduce all the time. Maybe there's another condition for this to happen. Could you please also test with release 2.4.41? And please also post the entry with the password (and relevant pwd* attrs) and the pwdPolicy entry used, both as LDIF (minus sensitive data). Ciao, Michael.

1 0

Re: (ITS#8206) ldapsearch incorrectly cannonicalizes dns names for GSSAPI
by michael＠stroeder.com 29 Jul '15

29 Jul '15

cwinkows(a)vt.edu wrote: > When using ldapsearch GSSAPI mechanism with a server whose reverse DNS name > doesn't match its DNS name, ldapsearch will do the DNS lookups and hand the > reverse DNS entry to GSSAPI. If the reverse DNS entry is not what is used by > kerberos then kerberos will fail. Did you already try with -N? $ ldapsearch -h [..] -N do not use reverse DNS to canonicalize SASL host name [..] Ciao, Michael.

1 0

(ITS#8207) ppolicy: pwdMinLength not checked if pwdInHistory == 0
by porjo38＠yahoo.com.au 29 Jul '15

29 Jul '15

Full_Name: Ian Bishop Version: 2.4.39 OS: Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (2001:388:e001:ce00:f2de:f1ff:fea7:d755) Using password policy overlay, pwdMinLength is not checked when pwdInHistory == 0. I tested this by setting pwdMinLength=6 and pwdInHistory=0. I was then able to set a 3 character password. When I changed pwdInHistory > 0 and tried to set a 3 charactepapassword, the attempt was denied. I repeated this several times, and also restarted slapd just in case - same result. Running Openldap 2.4.39 on Centos7, installed from Centos RPM repo.

1 0

(ITS#8206) ldapsearch incorrectly cannonicalizes dns names for GSSAPI
by cwinkows＠vt.edu 28 Jul '15

28 Jul '15

Full_Name: Calvin Winkowski Version: 2.4.41 OS: ArchLinux URL: Submission from: (NULL) (2001:468:c80:a202:3b1d:f567:f43c:7b3a) When using ldapsearch GSSAPI mechanism with a server whose reverse DNS name doesn't match its DNS name, ldapsearch will do the DNS lookups and hand the reverse DNS entry to GSSAPI. If the reverse DNS entry is not what is used by kerberos then kerberos will fail. There are settings in /etc/krb5.conf to disable canonicalizing the hostname provided. I have a server with a record example.ad.example.com whose PTR record is example.example.com, but the realm is ad.example.com and it's entry in the kerberos database is example.ad.example.com, not example.example.com. If I execute the command ``ldapsearch -b "" -s base -Y GSSAPI -D "dn" -H ldap://example.ad.example.com'' GSSAPI will submit a ticket request for example.example.com instead and result in a failure. All other services I've tested with this setup (disabling reverse dns in kerberos) do not give the PTR record, but the user provided hostname. These include mbsync, msmtp, and another ldap utility. I believe that the correct behaviour should be to provide the hostname provided to the utility to GSSAPI. I can provide packet captures illustrating the incorrect lookup if needed.

1 0

(ITS#8205) [PATCH] man pages in contrib
by peter＠adpm.de 26 Jul '15

26 Jul '15

Full_Name: Peter Marschall Version: 2.4.41 OS: Linux URL: Submission from: (NULL) (84.57.119.212) Hi, it always troubled me that the modules in contrib/slapd-modules did either not have a manual page, or - when there was one - did not install it. This week-end Iat down and tried to fix the issue by * amending the Makefiles in contrib to also Rdeal with man page in their install target * writing some man-pages for contrib modules You can find them in ther github branch: https://github.com/marschap/openldap/tree/contrib-manpages It differs from today's master by these commits: * https://github.com/marschap/openldap/commit/25ea4e1e7ab6a6f6a609b70095a0c47… contrib/smbk5pwd: add man page, install it too * https://github.com/marschap/openldap/commit/16395e3b971e3d1734fc1294b5e9ada… contrib/lastbind: install man page * https://github.com/marschap/openldap/commit/2ede55ce9ada228c7382b5bee9e0d29… contrib/passwd/sha2: add man page, install it too * https://github.com/marschap/openldap/commit/d37b3d2f3e297105f603eccbc5221b5… contrib/adremap: install man page * https://github.com/marschap/openldap/commit/e6f3ad1f035f40fd94ac90da14ac8b2… contrib/allop: install man page * https://github.com/marschap/openldap/commit/3b417c99028fb37be3f88afc3da7511… contrib/cloak: install man page * https://github.com/marschap/openldap/commit/9902b56e7830588d761c74a5a5f7b8d… contrib/lastmod: install man page * https://github.com/marschap/openldap/commit/6590fff13b591cdb481daa38c572c2d… contrib/nops: install n n page * https://github.com/marschap/openldap/commit/7f618c17e0f40764fa1590bb9dba5a9… contrib/nssov: install man page * https://github.com/marschap/openldap/commit/b07b66e36ada9c57a85180710b326ed… contrib/passwd: add man page slapd-pw-sha2.5, install it too * https://github.com/marschap/openldap/commit/ca81d5ef6245ece3609a8708376cb91… contrib/passwd/totp: add man page, install it too that change these files contrib/slapd-modules/adremap/Makefile | 14 +- contrib/slapd-modules/allop/Makefile | 14 +- contrib/slapd-modules/cloak/Makefile | 14 +- contrib/slapd-modules/lastbind/Makefile | 14 +- contrib/slapd-modules/lastmod/Makefile | 13 +- contrib/slapd-modules/nops/Makefi | 14 +- contrib/slapd-modules/nssov/Makefile | 15 +- contrib/slapd-modules/passwd/Makefile | 14 +- contrib/slapd-modules/passwd/sha2/Makefile | 14 +- contrib/slapd-modules/passwd/sha2/slapd-pw-sha2.57C7C 118 ++++++++++++++ contrib/slapd-modules/passwd/slapd-pw-radius.5 | 110 +++++++++++++ contrib/slapd-modules/passwd/totp/Makefile | 14 +- contrib/slapd-modules/passwd/totp/slapo-totp.5 | 131 ++++++++++++++++ contrib/slapd-modules/smbk5pwd/Makefile | 14 +- contrib/slapd-modules/smbk5pwd/slapo-smbk5pwd.5 | 179 ++++++++++++++++++++++ 15 files changed, 681 insertions(+), 11 deletions(-) create mode 100644 contrib/slapd-modules/passwd/sha2/slapd-pw-sha2.5 create mode 100644 contrib/slapd-modules/passwd/slapd-pw-radius.5 create mode 100644 contrib/slapd-modules/passwd/totp/slapo-totp.5 create mode 100644 contrib/slapd-modules/smbk5pwd/slapo-smbk5pwd.5 I'd appreciate if you include them into OpenLDAP. The referenced patch files are derived from OpenLDAP Software. All of the modifications to OpenLDAP Software represented in the following patch(es) were developed by Peter Marschall <peter(a)adpm.de>. I have not assigned rights and/or interest in this work to any party. The referenced modifications to OpenLDAP Software are subject to the following notice: Copyright 2015 Peter Marschall Redistribution and use in source and binary forms, with or without modification, are permitted only as authorizedy y the OpenLDAP Public License. Thanks in advance Peter

1 0

(ITS#8204) rfc2782 shuffle implementation doesn't treat equal-weight records equally
by Sergio.Gelato＠astro.su.se 25 Jul '15

25 Jul '15

Full_Name: Sergio Gelato Version: 2.4.40 OS: Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (85.225.123.9) As currently implemented (since ITS#7027, 5de85b922aaa5bfa6eb53db6000adf01ebdb0736) the algorithm to shuffle DNS SRV records of a given priority according to their weights is flawed: if all records have the same weight, the implementation is biased towards the first record and against the last. In the most extreme case of two records of weight 1, the current implementation will never swap them (whereas one would have hoped for a swap 50% of the time). The problem can be cured by changing (r <= 0) to (r < 0). (The wording of the RFC may have contributed to this error; I suspect it was written with real random deviates in mind, not integer ones. In any event, the principle that records of equal weight should have the same probability of being picked trumps the RFC since the latter only says what algorithm SHOULD be used.) I've written and tested a patch for this and found it to solve the above problem. My patch also addresses another (operationally minor, which is why I'm not reporting it separately) issue in the same piece of code: what if at least two, but not all, of the records of a given priority have weight zero? One should be prepared to switch to a Fisher-Yates shuffle if "total" becomes zero during the iteration. (Yet another potential issue is overflow of "total" on platforms where INT_MAX==32767 if the sum of the weights exceeds that value. Consider declaring it uint32_t or u_long.)

1 0

Fix in ITS#8036 is incomplete
by hyc＠openldap.org 24 Jul '15

24 Jul '15

Full_Name: Howard Chu Version: 2.4.41 OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (78.155.231.122) Submitted by: hyc The fix in ITS#8036 only corrects the situation for candidate-based searches, not for scope-based searches. In scope-based searches the "fix" treats the scopes array incorrectly and can overwrite the heap. A new fix is coming shortly.

1 0

Re: (ITS#8202) openldap assumes printf has %z
by h.b.furuseth＠usit.uio.no 22 Jul '15

22 Jul '15

On 22. juli 2015 17:54, Howard Chu wrote: > h.b.furuseth(a)usit.uio.no wrote: >> If we require C99 library features like this, then I >> think we should add a configure test for them. Strange >> breakage at runtime is rather worse than a failed build. >> >> (That's not the same as testing for a C99 compiler, since >> one can have a C99 compiler like gcc with a C90 library.) > > The fewer configure tests we need, the better. Happy to replace %zu with %llu > and forget about it. It's not worth a fuss. Right. Looks like it should be %ld and (long) though, we don't use long long either except inside HAVE_LONG_LONG etc and mdb.c -- Hallvard

1 0

Re: (ITS#8202) openldap assumes printf has %z
by hyc＠symas.com 22 Jul '15

22 Jul '15

h.b.furuseth(a)usit.uio.no wrote: > If we require C99 library features like this, then I > think we should add a configure test for them. Strange > breakage at runtime is rather worse than a failed build. > > (That's not the same as testing for a C99 compiler, since > one can have a C99 compiler like gcc with a C90 library.) The fewer configure tests we need, the better. Happy to replace %zu with %llu and forget about it. It's not worth a fuss. -- -- 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#8202) openldap assumes printf has %z
by iand＠ekit-inc.com 22 Jul '15

22 Jul '15

Hi Howard, Yes I'm well aware of the state of Solaris 9 support and we support key components of the OS ourselves. However that doesn't mean that people don't still run it, like we do on some systems yet to be upgraded. (yes we have Sun systems purchased over 15 years ago that are still happily running; the hardware is very reliable; many are well overdue for upgrade though; its a resource/priority thing just look at how many people are running WinXP still) However this issue is a portability of openldap issue, not a OS support/patch thing (the C library in this case is not broken; its doing as the man page says, which doesn't mention %z), and the %z support is only a recent thing in the lifetime of unix (well last ~15 years it started to appear... C99 I think) There will be other legacy OS's that don't support %z too; no idea what ones though. Anyway I've got an (ugly) patch for me to use now and it passes 'make check' on Solaris 9; it was hard to find the cause of the problem though. Ian D On 07/22/15 04:01, Howard Chu wrote: > Howard Chu wrote: >> iand(a)ekit-inc.com wrote: >>> Full_Name: Ian Donaldson >>> Version: 2.4.41 >>> OS: Solaris 9 >>> URL: ftp://ftp.openldap.org/incoming/ >>> Submission from: (NULL) (60.241.85.68) >>> >>> >>> Built 2.4.41 on Solaris 9; ran 'make check' which failed to start slapd with >>> the following errors: >> >> Thanks for the report. Not sure that it's worth our taking any action though. >> The last release of Solaris 9 was 10 years ago, and it has been end-of-life'd >> by Oracle. > > For reference: Solaris 9 EOL > http://www.oracle.com/technetwork/server-storage/solaris10/overview/index-1… > > In short it means Solaris 9 is no longer eligible for any Oracle updates including security updates, fixes, patches or any other changes. Solaris 9 went into sustaining support in October 2014. > > Since Oracle is no longer providing any patches for this OS, I don't see much reason for us to either. Fortunately you are free to patch and build OpenLDAP for yourself for as long as you wish. >

1 0

Re: (ITS#8202) openldap assumes printf has %z
by h.b.furuseth＠usit.uio.no 21 Jul '15

21 Jul '15

If we require C99 library features like this, then I think we should add a configure test for them. Strange breakage at runtime is rather worse than a failed build. (That's not the same as testing for a C99 compiler, since one can have a C99 compiler like gcc with a C90 library.)

1 0

Re: (ITS#8202) openldap assumes printf has %z
by hyc＠symas.com 21 Jul '15

21 Jul '15

Howard Chu wrote: > iand(a)ekit-inc.com wrote: >> Full_Name: Ian Donaldson >> Version: 2.4.41 >> OS: Solaris 9 >> URL: ftp://ftp.openldap.org/incoming/ >> Submission from: (NULL) (60.241.85.68) >> >> >> Built 2.4.41 on Solaris 9; ran 'make check' which failed to start slapd with >> the following errors: > > Thanks for the report. Not sure that it's worth our taking any action though. > The last release of Solaris 9 was 10 years ago, and it has been end-of-life'd > by Oracle. For reference: Solaris 9 EOL http://www.oracle.com/technetwork/server-storage/solaris10/overview/index-1… In short it means Solaris 9 is no longer eligible for any Oracle updates including security updates, fixes, patches or any other changes. Solaris 9 went into sustaining support in October 2014. Since Oracle is no longer providing any patches for this OS, I don't see much reason for us to either. Fortunately you are free to patch and build OpenLDAP for yourself for as long as you wish. -- -- 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#8199) Crash when modifying the first olcAttributeTypes element in olcSchemaConfig objectClass
by luca.bruno＠rocket-internet.de 19 Jul '15

19 Jul '15

On Friday 17 July 2015 16:19:16 Ryan Tandy wrote: > On Tue, Jul 14, 2015 at 11:13:56AM +0000, luca.bruno(a)rocket-internet.de wrote: > >slapd 2.4.40 realiably crashes when modifying the 0th olcAttributeTypes > >element in a olcSchemaConfig object. > > This doesn't match my experience exactly, but if you were editing the > config with some tool, it might reflect how that tool implements > modifications. For a more specific background, this was Apache Directory Studio (pre-)2 doing schema changes on the debian backports 2.4.40 on wheezy (amd64). IIRC it does in fact synthesize a batch-modify of schema entries. > This was already fixed for olcObjectClasses in ITS#5388. I've pushed a > patch doing the same for at_next, can you please verify it? > > http://www.openldap.org/devel/gitweb.cgi?p=openldap.git;a=patch;h=b48d0169d0 > 4824f83c0e0855eea4d6429740cf08 I'll try to apply that patch on top of my current setup and see if it stops crashing without any other regression. Thanks, Luca -- Luca Bruno (kaeso) Security Engineer Rocket Internet SE -> GPG: 0xBB1A3A854F3BBEBF

1 0

Re: (ITS#8202) openldap assumes printf has %z
by hyc＠symas.com 19 Jul '15

19 Jul '15

iand(a)ekit-inc.com wrote: > Full_Name: Ian Donaldson > Version: 2.4.41 > OS: Solaris 9 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (60.241.85.68) > > > Built 2.4.41 on Solaris 9; ran 'make check' which failed to start slapd with > the following errors: Thanks for the report. Not sure that it's worth our taking any action though. The last release of Solaris 9 was 10 years ago, and it has been end-of-life'd by Oracle. > 55ab70f0 config_build_entry: "olcDatabase={-1}frontend" > 55ab70f0 config_build_entry: "olcDatabase={0}config" > 55ab70f0 config_build_entry: "olcDatabase={1}bdb" > 55ab70f0 config_build_attrs: error 21 on olcDbCacheSize value #0 > 55ab70f0 config_build_entry: build "zu" failed: "" > > Eventually found this to be due to the assumption that %z format > works in printf; this is not the case on Solaris 9. (Solaris 10 has %z) > > Found the following code that makes this assumption (there may be others): > > ./libraries/liblmdb/mdb_load.c > ./libraries/liblmdb/mdb_dump.c > ./libraries/liblmdb/mdb_stat.c > ./libraries/liblmdb/mdb.c > ./servers/slapd/overlays/constraint.c > ./servers/slapd/config.c > > My workaround was to use %l instead of %z which works for me; may not > be 100% fix though. > > See http://stackoverflow.com/questions/2524611/how-to-print-size-t-variable-por… > > > I previously built 2.4.33 which has some %z'isms too but not in places > that cause 'make check' to fail. > > -- -- 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#8202) openldap assumes printf has %z
by iand＠ekit-inc.com 19 Jul '15

19 Jul '15

Full_Name: Ian Donaldson Version: 2.4.41 OS: Solaris 9 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (60.241.85.68) Built 2.4.41 on Solaris 9; ran 'make check' which failed to start slapd with the following errors: 55ab70f0 config_build_entry: "olcDatabase={-1}frontend" 55ab70f0 config_build_entry: "olcDatabase={0}config" 55ab70f0 config_build_entry: "olcDatabase={1}bdb" 55ab70f0 config_build_attrs: error 21 on olcDbCacheSize value #0 55ab70f0 config_build_entry: build "zu" failed: "" Eventually found this to be due to the assumption that %z format works in printf; this is not the case on Solaris 9. (Solaris 10 has %z) Found the following code that makes this assumption (there may be others): ./libraries/liblmdb/mdb_load.c ./libraries/liblmdb/mdb_dump.c ./libraries/liblmdb/mdb_stat.c ./libraries/liblmdb/mdb.c ./servers/slapd/overlays/constraint.c ./servers/slapd/config.c My workaround was to use %l instead of %z which works for me; may not be 100% fix though. See http://stackoverflow.com/questions/2524611/how-to-print-size-t-variable-por… I previously built 2.4.33 which has some %z'isms too but not in places that cause 'make check' to fail.

1 0

Re: (ITS#8111) Re-ordering schema attributeTypes crashes slapd
by ryan＠nardis.ca 18 Jul '15

18 Jul '15

Hi Zach, I just pushed a patch for another ITS that reminded me of this one. Assuming you can still reproduce this, would you please try the patch mentioned at the end of http://www.openldap.org/its/?findid=8199 and let us know whether it resolves your crash?

1 0

Re: (ITS#8199) Crash when modifying the first olcAttributeTypes element in olcSchemaConfig objectClass
by ryan＠nardis.ca 18 Jul '15

18 Jul '15

On Tue, Jul 14, 2015 at 11:13:56AM +0000, luca.bruno(a)rocket-internet.de wrote: >slapd 2.4.40 realiably crashes when modifying the 0th olcAttributeTypes element >in a olcSchemaConfig object. This doesn't match my experience exactly, but if you were editing the config with some tool, it might reflect how that tool implements modifications. I reproduced the crash with the following changeset: dn: cn={2}nis,cn=schema,cn=config changetype: modify replace: olcAttributeTypes olcAttributeTypes: {1}( 1.3.6.1.1.1.1.3 NAME 'homeDirectory' DESC 'The absolute path to the home directory' EQUALITY caseExactIA5Match SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 SINGLE-VALUE ) Deleting all values clears c_at_head and c_at_tail (bconfig.c:1541). Adding a specific non-zero index assumes the head is already valid. This was already fixed for olcObjectClasses in ITS#5388. I've pushed a patch doing the same for at_next, can you please verify it? http://www.openldap.org/devel/gitweb.cgi?p=openldap.git;a=patch;h=b48d0169d…

1 0

(ITS#8173)
by Adrian.Raemy＠vtg.admin.ch 17 Jul '15

17 Jul '15

Dear Howard, We didn't use back-ldap as proxy backend in the past, we had a very old ope= nldap and did use syncrepl.=20 Then we changed our IT Infrastructures and had to use ldap proxy. That was = around 3 months ago. So we tried with 2.4.26 coming from sles and there we had the problem..so w= e tried then with the latest release and with both it was the same. Thanks a lot for your FIX. Actually it looks like working fine, the slapd of the ldap proxy didn't cra= sh anymore since 24 hours. No segfaults at the moment. We will monitor it next few days and weeks and if you like we can give you = again a feedback. ITS#8173 fix SEGV after failed retry [openldap.git] / servers / slapd / back-ldap / bind.c diff --git a/servers/slapd/back-ldap/bind.c b/servers/slapd/back-ldap/bind.= c index 598dae3..20197f3 100644 (file) --- a/servers/slapd/back-ldap/bind.c +++ b/servers/slapd/back-ldap/bind.c @@ -271,6 +271,8 @@ retry:; =20 if ( ldap_back_retry( &lc, op, rs, LDAP_BACK_BIND_SERR ) ) { = =20 goto retry; } + if ( !lc ) + return( rc ); =20 } ldap_pvt_thread_mutex_lock( &li->li_counter_mutex );

1 0

(ITS#8201) Enhancement: thread stack overrun detection
by hyc＠openldap.org 16 Jul '15

16 Jul '15

Full_Name: Howard Chu Version: HEAD OS: Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (78.155.231.135) Submitted by: hyc Have been looking at some puzzling SEGVs where none of the addresses in the core dump backtrace appear to be invalid. Suspecting a thread stack overrun. Normally pthreads allocates a 1-page guard at the end of the requested thread stack. (This is a page of memory mprotect'd to deny any access, so spilling into it should cause a SEGV.) It's possible for some overruns to skip over this guard page, e.g. if they occur in a function that has a local variable larger than 1 page in size. Adding a feature to set the guard region size to be equal to the original thread stack size. (E.g., 8MB on 64 bit builds.) This should help catch the more elusive overrun cases. The feature will be enabled by setting the LDAPSTACKGUARD environment variable (to anything, the value is ignored).

1 0

Re: (ITS#8173)
by hyc＠symas.com 16 Jul '15

16 Jul '15

Adrian.Raemy(a)vtg.admin.ch wrote: > --_000_BE8E19527611BA409D68FF6EA186AF9002A2A6AABEREXMBX19ifc1i_ > Content-Type: text/plain; charset="us-ascii" > Content-Transfer-Encoding: quoted-printable > > Dear Howard, > > Below the bt full with Openldap 2.4.40 built with "-g" flag. > Let me know if you need more...hope you have a solution for the problem bec= > ause it is really a Problem for us.. If it was such a big problem, why did you not report it when you first encountered it in 2.4.26, which was released over 4 years ago? You waited this long, clearly it's not that high a priority. That makes it even less of a priority for an open source project comprised of volunteers who have their own interests to pursue. Your repeating how big a problem you perceive it to be only comes across as whining, which makes folks even less interested in helping. > slapd of backend ldap crashes 4-5 times per day. Fixed now in git master. Please test and reply back with your results. > Regards > Adrian > > warning: Could not load shared library symbols for stics. > Do you need "set solib-search-path" or "set sysroot"? > [Thread debugging using libthread_db enabled] > Using host libthread_db library "/lib64/libthread_db.so.1". > Core was generated by `/usr/lib/openldap/slapd -h ldap://0.0.0.0:389 ldap= > s://0.0.0.0:636 -f /etc/op'. > Program terminated with signal 11, Segmentation fault. > #0 0x00007fcbb60572c6 in ldap_back_bind (op=3D0x7fcbb6c0dc00, rs=3D0x7fcba= > d881a30) at bind.c:319 > 319 bind.c: No such file or directory. > (gdb) bt full > #0 0x00007fcbb60572c6 in ldap_back_bind (op=3D0x7fcbb6c0dc00, rs=3D0x7fcba= > d881a30) at bind.c:319 > li =3D 0x7fcbb6443e40 > lc =3D 0x0 > ctrls =3D 0x0 > save_o_dn =3D {bv_len =3D 0, bv_val =3D 0x0} > save_o_do_not_cache =3D 0 > rc =3D 52 > msgid =3D 2 > retrying =3D LDAP_BACK_DONTSEND > __PRETTY_FUNCTION__ =3D "ldap_back_bind" > #1 0x00007fcbb5f47fcb in fe_op_bind (op=3D0x7fcbb6c0dc00, rs=3D0x7fcbad881= > a30) at bind.c:383 > bd =3D 0x7fcbad881750 > #2 0x00007fcbb5fb66fd in overlay_op_walk (op=3D0x7fcbb6c0dc00, rs=3D0x7fcb= > ad881a30, which=3Dop_bind, oi=3D0x7fcbb6443430, on=3D0x0) at backover.c:671 > func =3D 0x7fcbb6343ad8 <slap_frontendInfo+88> > rc =3D 32768 > #3 0x00007fcbb5fb6956 in over_op_func (op=3D0x7fcbb6c0dc00, rs=3D0x7fcbad8= > 81a30, which=3Dop_bind) at backover.c:723 > oi =3D 0x7fcbb6443430 > on =3D 0x7fcbb6443610 > be =3D 0x7fcbb6343c40 <slap_frontendDB> > db =3D {bd_info =3D 0x7fcbb6343a80 <slap_frontendInfo>, bd_self =3D= > 0x7fcbb6343c40 <slap_frontendDB>, be_ctrls =3D "\000", '\001' <repeats 18 = > times>, '\000' <repeats 13 times>, > be_flags =3D 768, be_restrictops =3D 0, be_requires =3D 0, be_ssf= > _set =3D {sss_ssf =3D 112, sss_transport =3D 0, sss_tls =3D 56, sss_sasl = > =3D 0, sss_update_ssf =3D 112, sss_update_transport =3D 0, > sss_update_tls =3D 0, sss_update_sasl =3D 0, sss_simple_bind = > =3D 0}, be_suffix =3D 0x7fcbb643bd50, be_nsuffix =3D 0x7fcbb643bda0, be_sch= > emadn =3D {bv_len =3D 12, > bv_val =3D 0x7fcbb6474530 "cn=3DSubschema"}, be_schemandn =3D {= > bv_len =3D 12, bv_val =3D 0x7fcbb6474670 "cn=3Dsubschema"}, be_rootdn =3D {= > bv_len =3D 0, bv_val =3D 0x0}, be_rootndn =3D {bv_len =3D 0, > bv_val =3D 0x0}, be_rootpw =3D {bv_len =3D 0, bv_val =3D 0x0}, = > be_max_deref_depth =3D 0, be_def_limit =3D {lms_t_soft =3D 3600, lms_t_hard= > =3D 0, lms_s_soft =3D -1, lms_s_hard =3D 0, > lms_s_unchecked =3D -1, lms_s_pr =3D 0, lms_s_pr_hide =3D 0, lms= > _s_pr_total =3D 0}, be_limits =3D 0x0, be_acl =3D 0x0, be_dfltaccess =3D AC= > L_READ, be_extra_anlist =3D 0x0, be_update_ndn =3D { > bv_len =3D 0, bv_val =3D 0x0}, be_update_refs =3D 0x0, be_pendi= > ng_csn_list =3D 0x0, be_pcl_mutex =3D {__data =3D {__lock =3D 0, __count = > =3D 0, __owner =3D 0, __nusers =3D 0, __kind =3D 0, > __spins =3D 0, __list =3D {__prev =3D 0x0, __next =3D 0x0}}, = > __size =3D '\000' <repeats 39 times>, __align =3D 0}, be_syncinfo =3D 0x0, = > be_pb =3D 0x0, > be_cf_ocs =3D 0x7fcbb63355a0 <cf_ocs+448>, be_private =3D 0x0, be= > _next =3D {stqe_next =3D 0x7fcbb643fa00}} > cb =3D {sc_next =3D 0x0, sc_response =3D 0x7fcbb5fb5629 <over_back_= > response>, sc_cleanup =3D 0x0, sc_writewait =3D 0x0, sc_private =3D 0x7fcbb= > 6443430} > sc =3D 0x7fcbb6c0dc38 > rc =3D 32768 > __PRETTY_FUNCTION__ =3D "over_op_func" > #4 0x00007fcbb5fb69de in over_op_bind (op=3D0x7fcbb6c0dc00, rs=3D0x7fcbad8= > 81a30) at backover.c:738 > No locals. > #5 0x00007fcbb5f47697 in do_bind (op=3D0x7fcbb6c0dc00, rs=3D0x7fcbad881a30= > ) at bind.c:205 > ber =3D 0x7fcb8c1a9510 > version =3D 3 > method =3D 128 > mech =3D {bv_len =3D 0, bv_val =3D 0x0} > dn =3D {bv_len =3D 41, bv_val =3D 0x7fcb88344a3a "cn=3Dxxxxbnd,ou= > =3Dbind,dc=3Dxxxx,dc=3Dxxxx.xx"} > tag =3D 128 > be =3D 0x0 > #6 0x00007fcbb5f1df19 in connection_operation (ctx=3D0x7fcbad881b80, arg_v= > =3D0x7fcbb6c0dc00) at connection.c:1155 > rc =3D 80 > cancel =3D 0 > op =3D 0x7fcbb6c0dc00 > rs =3D {sr_type =3D REP_RESULT, sr_tag =3D 97, sr_msgid =3D 2, sr_e= > rr =3D 52, sr_matched =3D 0x0, sr_text =3D 0x7fcbb60e698a "Start TLS failed= > ", sr_ref =3D 0x0, sr_ctrls =3D 0x0, sr_un =3D { > sru_search =3D {r_entry =3D 0x0, r_attr_flags =3D 0, r_operatio= > nal_attrs =3D 0x0, r_attrs =3D 0x0, r_nentries =3D 0, r_v2ref =3D 0x0}, sru= > _sasl =3D {r_sasldata =3D 0x0}, sru_extended =3D { > r_rspoid =3D 0x0, r_rspdata =3D 0x0}}, sr_flags =3D 0} > tag =3D 96 > opidx =3D SLAP_OP_BIND > conn =3D 0x7fcbae0f22d0 > memctx =3D 0x7fcbb64fada0 > memctx_null =3D 0x0 > memsiz =3D 1048576 > __PRETTY_FUNCTION__ =3D "connection_operation" > #7 0x00007fcbb5f1e4e1 in connection_read_thread (ctx=3D0x7fcbad881b80, arg= > v=3D0x281) at connection.c:1291 > rc =3D 0 > cri =3D {op =3D 0x7fcbb6c0dc00, func =3D 0x0, arg =3D 0x0, ctx =3D = > 0x7fcbad881b80, nullop =3D 0} > s =3D 641 > #8 0x00007fcbb5a53c3c in ldap_int_thread_pool_wrapper (xpool=3D0x7fcbb640a= > f70) at tpool.c:688 > pool =3D 0x7fcbb640af70 > task =3D 0x7fcba8787f80 > work_list =3D 0x7fcbb640b008 > ctx =3D {ltu_id =3D 140512766469888, ltu_key =3D {{ltk_key =3D 0x7f= > cbb5f1da15 <conn_counter_init>, ltk_data =3D 0x7fcbb64fac90, ltk_free =3D 0= > x7fcbb5f1d817 <conn_counter_destroy>}, { > ltk_key =3D 0x7fcbb5f95b15 <slap_sl_mem_init>, ltk_data =3D 0= > x7fcbb64fada0, ltk_free =3D 0x7fcbb5f95944 <slap_sl_mem_destroy>}, {ltk_key= > =3D 0x7fcbb5f3991c <slap_op_free>, > ltk_data =3D 0x7fcbb6c0ce30, ltk_free =3D 0x7fcbb5f39874 <sla= > p_op_q_destroy>}, {ltk_key =3D 0x0, ltk_data =3D 0x0, ltk_free =3D 0x0} <re= > peats 29 times>}} > kctx =3D 0x0 > i =3D 32 > keyslot =3D 838 > hash =3D 2545024838 > __PRETTY_FUNCTION__ =3D "ldap_int_thread_pool_wrapper" > #9 0x00007fcbb4e6c806 in start_thread (arg=3D<optimized out>) at pthread_c= > reate.c:301 > __res =3D <optimized out> > pd =3D 0x7fcbad882700 > unwind_buf =3D {cancel_jmp_buf =3D {{jmp_buf =3D {140512766469888, = > -3966806835471793915, 140512774851584, 140512766468096, 0, 8388608, 3991395= > 584477806853, 3991451503570501893}, > mask_was_saved =3D 0}}, priv =3D {pad =3D {0x0, 0x0, 0x0, 0x0= > }, data =3D {prev =3D 0x0, cleanup =3D 0x0, canceltype =3D 0}}} > not_first_call =3D <optimized out> > robust =3D <optimized out> > freesize =3D <optimized out> > __PRETTY_FUNCTION__ =3D "start_thread" > #10 0x00007fcbb36b702d in gnu_dev_makedev (major=3D3066092544, minor=3D<opt= > imized out>) at ../sysdeps/unix/sysv/linux/makedev.c:37 > No locals. > #11 0x0000000000000000 in ?? () > No symbol table info available. -- -- 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#8173)
by Adrian.Raemy＠vtg.admin.ch 15 Jul '15

15 Jul '15

--_000_BE8E19527611BA409D68FF6EA186AF9002A2A6AABEREXMBX19ifc1i_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear Howard, Below the bt full with Openldap 2.4.40 built with "-g" flag. Let me know if you need more...hope you have a solution for the problem bec= ause it is really a Problem for us.. slapd of backend ldap crashes 4-5 times per day. Regards Adrian warning: Could not load shared library symbols for stics. Do you need "set solib-search-path" or "set sysroot"? [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib64/libthread_db.so.1". Core was generated by `/usr/lib/openldap/slapd -h ldap://0.0.0.0:389 ldap= s://0.0.0.0:636 -f /etc/op'. Program terminated with signal 11, Segmentation fault. #0 0x00007fcbb60572c6 in ldap_back_bind (op=3D0x7fcbb6c0dc00, rs=3D0x7fcba= d881a30) at bind.c:319 319 bind.c: No such file or directory. (gdb) bt full #0 0x00007fcbb60572c6 in ldap_back_bind (op=3D0x7fcbb6c0dc00, rs=3D0x7fcba= d881a30) at bind.c:319 li =3D 0x7fcbb6443e40 lc =3D 0x0 ctrls =3D 0x0 save_o_dn =3D {bv_len =3D 0, bv_val =3D 0x0} save_o_do_not_cache =3D 0 rc =3D 52 msgid =3D 2 retrying =3D LDAP_BACK_DONTSEND __PRETTY_FUNCTION__ =3D "ldap_back_bind" #1 0x00007fcbb5f47fcb in fe_op_bind (op=3D0x7fcbb6c0dc00, rs=3D0x7fcbad881= a30) at bind.c:383 bd =3D 0x7fcbad881750 #2 0x00007fcbb5fb66fd in overlay_op_walk (op=3D0x7fcbb6c0dc00, rs=3D0x7fcb= ad881a30, which=3Dop_bind, oi=3D0x7fcbb6443430, on=3D0x0) at backover.c:671 func =3D 0x7fcbb6343ad8 <slap_frontendInfo+88> rc =3D 32768 #3 0x00007fcbb5fb6956 in over_op_func (op=3D0x7fcbb6c0dc00, rs=3D0x7fcbad8= 81a30, which=3Dop_bind) at backover.c:723 oi =3D 0x7fcbb6443430 on =3D 0x7fcbb6443610 be =3D 0x7fcbb6343c40 <slap_frontendDB> db =3D {bd_info =3D 0x7fcbb6343a80 <slap_frontendInfo>, bd_self =3D= 0x7fcbb6343c40 <slap_frontendDB>, be_ctrls =3D "\000", '\001' <repeats 18 = times>, '\000' <repeats 13 times>, be_flags =3D 768, be_restrictops =3D 0, be_requires =3D 0, be_ssf= _set =3D {sss_ssf =3D 112, sss_transport =3D 0, sss_tls =3D 56, sss_sasl = =3D 0, sss_update_ssf =3D 112, sss_update_transport =3D 0, sss_update_tls =3D 0, sss_update_sasl =3D 0, sss_simple_bind = =3D 0}, be_suffix =3D 0x7fcbb643bd50, be_nsuffix =3D 0x7fcbb643bda0, be_sch= emadn =3D {bv_len =3D 12, bv_val =3D 0x7fcbb6474530 "cn=3DSubschema"}, be_schemandn =3D {= bv_len =3D 12, bv_val =3D 0x7fcbb6474670 "cn=3Dsubschema"}, be_rootdn =3D {= bv_len =3D 0, bv_val =3D 0x0}, be_rootndn =3D {bv_len =3D 0, bv_val =3D 0x0}, be_rootpw =3D {bv_len =3D 0, bv_val =3D 0x0}, = be_max_deref_depth =3D 0, be_def_limit =3D {lms_t_soft =3D 3600, lms_t_hard= =3D 0, lms_s_soft =3D -1, lms_s_hard =3D 0, lms_s_unchecked =3D -1, lms_s_pr =3D 0, lms_s_pr_hide =3D 0, lms= _s_pr_total =3D 0}, be_limits =3D 0x0, be_acl =3D 0x0, be_dfltaccess =3D AC= L_READ, be_extra_anlist =3D 0x0, be_update_ndn =3D { bv_len =3D 0, bv_val =3D 0x0}, be_update_refs =3D 0x0, be_pendi= ng_csn_list =3D 0x0, be_pcl_mutex =3D {__data =3D {__lock =3D 0, __count = =3D 0, __owner =3D 0, __nusers =3D 0, __kind =3D 0, __spins =3D 0, __list =3D {__prev =3D 0x0, __next =3D 0x0}}, = __size =3D '\000' <repeats 39 times>, __align =3D 0}, be_syncinfo =3D 0x0, = be_pb =3D 0x0, be_cf_ocs =3D 0x7fcbb63355a0 <cf_ocs+448>, be_private =3D 0x0, be= _next =3D {stqe_next =3D 0x7fcbb643fa00}} cb =3D {sc_next =3D 0x0, sc_response =3D 0x7fcbb5fb5629 <over_back_= response>, sc_cleanup =3D 0x0, sc_writewait =3D 0x0, sc_private =3D 0x7fcbb= 6443430} sc =3D 0x7fcbb6c0dc38 rc =3D 32768 __PRETTY_FUNCTION__ =3D "over_op_func" #4 0x00007fcbb5fb69de in over_op_bind (op=3D0x7fcbb6c0dc00, rs=3D0x7fcbad8= 81a30) at backover.c:738 No locals. #5 0x00007fcbb5f47697 in do_bind (op=3D0x7fcbb6c0dc00, rs=3D0x7fcbad881a30= ) at bind.c:205 ber =3D 0x7fcb8c1a9510 version =3D 3 method =3D 128 mech =3D {bv_len =3D 0, bv_val =3D 0x0} dn =3D {bv_len =3D 41, bv_val =3D 0x7fcb88344a3a "cn=3Dxxxxbnd,ou= =3Dbind,dc=3Dxxxx,dc=3Dxxxx.xx"} tag =3D 128 be =3D 0x0 #6 0x00007fcbb5f1df19 in connection_operation (ctx=3D0x7fcbad881b80, arg_v= =3D0x7fcbb6c0dc00) at connection.c:1155 rc =3D 80 cancel =3D 0 op =3D 0x7fcbb6c0dc00 rs =3D {sr_type =3D REP_RESULT, sr_tag =3D 97, sr_msgid =3D 2, sr_e= rr =3D 52, sr_matched =3D 0x0, sr_text =3D 0x7fcbb60e698a "Start TLS failed= ", sr_ref =3D 0x0, sr_ctrls =3D 0x0, sr_un =3D { sru_search =3D {r_entry =3D 0x0, r_attr_flags =3D 0, r_operatio= nal_attrs =3D 0x0, r_attrs =3D 0x0, r_nentries =3D 0, r_v2ref =3D 0x0}, sru= _sasl =3D {r_sasldata =3D 0x0}, sru_extended =3D { r_rspoid =3D 0x0, r_rspdata =3D 0x0}}, sr_flags =3D 0} tag =3D 96 opidx =3D SLAP_OP_BIND conn =3D 0x7fcbae0f22d0 memctx =3D 0x7fcbb64fada0 memctx_null =3D 0x0 memsiz =3D 1048576 __PRETTY_FUNCTION__ =3D "connection_operation" #7 0x00007fcbb5f1e4e1 in connection_read_thread (ctx=3D0x7fcbad881b80, arg= v=3D0x281) at connection.c:1291 rc =3D 0 cri =3D {op =3D 0x7fcbb6c0dc00, func =3D 0x0, arg =3D 0x0, ctx =3D = 0x7fcbad881b80, nullop =3D 0} s =3D 641 #8 0x00007fcbb5a53c3c in ldap_int_thread_pool_wrapper (xpool=3D0x7fcbb640a= f70) at tpool.c:688 pool =3D 0x7fcbb640af70 task =3D 0x7fcba8787f80 work_list =3D 0x7fcbb640b008 ctx =3D {ltu_id =3D 140512766469888, ltu_key =3D {{ltk_key =3D 0x7f= cbb5f1da15 <conn_counter_init>, ltk_data =3D 0x7fcbb64fac90, ltk_free =3D 0= x7fcbb5f1d817 <conn_counter_destroy>}, { ltk_key =3D 0x7fcbb5f95b15 <slap_sl_mem_init>, ltk_data =3D 0= x7fcbb64fada0, ltk_free =3D 0x7fcbb5f95944 <slap_sl_mem_destroy>}, {ltk_key= =3D 0x7fcbb5f3991c <slap_op_free>, ltk_data =3D 0x7fcbb6c0ce30, ltk_free =3D 0x7fcbb5f39874 <sla= p_op_q_destroy>}, {ltk_key =3D 0x0, ltk_data =3D 0x0, ltk_free =3D 0x0} <re= peats 29 times>}} kctx =3D 0x0 i =3D 32 keyslot =3D 838 hash =3D 2545024838 __PRETTY_FUNCTION__ =3D "ldap_int_thread_pool_wrapper" #9 0x00007fcbb4e6c806 in start_thread (arg=3D<optimized out>) at pthread_c= reate.c:301 __res =3D <optimized out> pd =3D 0x7fcbad882700 unwind_buf =3D {cancel_jmp_buf =3D {{jmp_buf =3D {140512766469888, = -3966806835471793915, 140512774851584, 140512766468096, 0, 8388608, 3991395= 584477806853, 3991451503570501893}, mask_was_saved =3D 0}}, priv =3D {pad =3D {0x0, 0x0, 0x0, 0x0= }, data =3D {prev =3D 0x0, cleanup =3D 0x0, canceltype =3D 0}}} not_first_call =3D <optimized out> robust =3D <optimized out> freesize =3D <optimized out> __PRETTY_FUNCTION__ =3D "start_thread" #10 0x00007fcbb36b702d in gnu_dev_makedev (major=3D3066092544, minor=3D<opt= imized out>) at ../sysdeps/unix/sysv/linux/makedev.c:37 No locals. #11 0x0000000000000000 in ?? () No symbol table info available. --_000_BE8E19527611BA409D68FF6EA186AF9002A2A6AABEREXMBX19ifc1i_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable <html xmlns:v=3D"urn:schemas-microsoft-com:vml" xmlns:o=3D"urn:schemas-micr= osoft-com:office:office" xmlns:w=3D"urn:schemas-microsoft-com:office:word" = xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" xmlns=3D"http:= //www.w3.org/TR/REC-html40"> <head> <meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Dus-ascii"= > <meta name=3D"Generator" content=3D"Microsoft Word 14 (filtered medium)"> <style></style> </head> <body lang=3D"DE-CH" link=3D"blue" vlink=3D"purple"> <div class=3D"WordSection1"> Dear Howard,<o:p></o:p><= /p> <o:p> </o:p> Below the bt full with Openldap= 2.4.40 built with “-g” flag.<o:p></o:p> <o:p> </o:p> Let me know if you need more&#8= 230;hope you have a solution for the problem because it is really a Problem= for us..<o:p></o:p> slapd of backend ldap crashes 4= -5 times per day.<o:p></o:p> <o:p> </o:p> Regards<o:p></o:p> Adrian<o:p></o:p> <o:p> </o:p> warning: Could not load shared = library symbols for stics.<o:p></o:p> Do you need "set solib-sea= rch-path" or "set sysroot"?    <o:p></o:p> [Thread debugging using libthre= ad_db enabled]          &= nbsp; <o:p></o:p> Using host libthread_db library= "/lib64/libthread_db.so.1".<o:p></o:p> Core was generated by `/usr/lib= /openldap/slapd -h  ldap://0.0.0.0:389  ldaps://0.0.0.0:636 = -f /etc/op'.<o:p></o:p> Program terminated with signal = 11, Segmentation fault.        &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;   <o:p></o:p> #0  0x00007fcbb60572c6 in = ldap_back_bind (op=3D0x7fcbb6c0dc00, rs=3D0x7fcbad881a30) at bind.c:319&nbs= p;          <o:p></o:p> 319     bin= d.c: No such file or directory.       &n= bsp;           &nbsp= ;            &n= bsp;           &nbsp= ;            &n= bsp;    <o:p></o:p> (gdb) bt full   =             &nb= sp;            =             &nb= sp;            =             &nb= sp;            =              <o:p></o:p> #0  0x00007fcbb60572c6 in = ldap_back_bind (op=3D0x7fcbb6c0dc00, rs=3D0x7fcbad881a30) at bind.c:319<o:p= ></o:p>      &= nbsp;  li =3D 0x7fcbb6443e40<o:p></o:p></span= >      &nbs= p;  lc =3D 0x0<o:p></o:p>      &nbs= p;  ctrls =3D 0x0<o:p></o:p>      &nbs= p;  save_o_dn =3D {bv_len =3D 0, bv_val = =3D 0x0}<o:p></o:p>      &= nbsp;  save_o_do_not_cache =3D 0<o:p></o:p>      &= nbsp;  rc =3D 52<o:p></o:p>      &= nbsp;  msgid =3D 2<o:p></o:p>      &= nbsp;  retrying =3D LDAP_BACK_DONTSEND<o:p></o:p>      &= nbsp;  __PRETTY_FUNCTION__ =3D "ldap_back_bind"<o:p></o:p></= span> #1  0x00007fcbb5f47fcb in = fe_op_bind (op=3D0x7fcbb6c0dc00, rs=3D0x7fcbad881a30) at bind.c:383<o:p></o= :p>      &= nbsp;  bd =3D 0x7fcbad881750<o:p></o:p> #2  0x00007fcbb5fb66fd in = overlay_op_walk (op=3D0x7fcbb6c0dc00, rs=3D0x7fcbad881a30, which=3Dop_bind,= oi=3D0x7fcbb6443430, on=3D0x0) at backover.c:671<o:p></o:p>      &= nbsp;  func =3D 0x7fcbb6343ad8 <slap_frontendInfo+88><o:p></= o:p>      &= nbsp;  rc =3D 32768<o:p></o:p> #3  0x00007fcbb5fb6956 in = over_op_func (op=3D0x7fcbb6c0dc00, rs=3D0x7fcbad881a30, which=3Dop_bind) at= backover.c:723<o:p></o:p>      &= nbsp;  oi =3D 0x7fcbb6443430<o:p></o:p>      &= nbsp;  on =3D 0x7fcbb6443610<o:p></o:p>      &= nbsp;  be =3D 0x7fcbb6343c40 <slap_frontendDB><o:p></o:p>=      &= nbsp;  db =3D {bd_info =3D 0x7fcbb6343a80 <slap_frontendInfo>, b= d_self =3D 0x7fcbb6343c40 <slap_frontendDB>, be_ctrls =3D "\000&= quot;, '\001' <repeats 18 times>, '\000' <repeats 13 times>,<o:= p></o:p>      &= nbsp;    be_flags =3D 768, be_restrictops =3D 0, be_requires= =3D 0, be_ssf_set =3D {sss_ssf =3D 112, sss_transport =3D 0, sss_tls =3D 5= 6, sss_sasl =3D 0, sss_update_ssf =3D 112, sss_update_transport =3D 0,<o:p>= </o:p>      &= nbsp;      sss_update_tls =3D 0, sss_update_sasl = =3D 0, sss_simple_bind =3D 0}, be_suffix =3D 0x7fcbb643bd50, be_nsuffix =3D= 0x7fcbb643bda0, be_schemadn =3D {bv_len =3D 12,<o:p></o:p>      &= nbsp;      bv_val =3D 0x7fcbb6474530 "cn=3DSu= bschema"}, be_schemandn =3D {bv_len =3D 12, bv_val =3D 0x7fcbb6474670 = "cn=3Dsubschema"}, be_rootdn =3D {bv_len =3D 0, bv_val =3D 0x0}, = be_rootndn =3D {bv_len =3D 0,<o:p></o:p>      &= nbsp;      bv_val =3D 0x0}, be_rootpw =3D {bv_len = =3D 0, bv_val =3D 0x0}, be_max_deref_depth =3D 0, be_def_limit =3D {lms_t_s= oft =3D 3600, lms_t_hard =3D 0, lms_s_soft =3D -1, lms_s_hard =3D 0,<o:p></= o:p>      &= nbsp;     lms_s_unchecked =3D -1, lms_s_pr =3D 0, = lms_s_pr_hide =3D 0, lms_s_pr_total =3D 0}, be_limits =3D 0x0, be_acl =3D 0= x0, be_dfltaccess =3D ACL_READ, be_extra_anlist =3D 0x0, be_update_ndn =3D = {<o:p></o:p>      &= nbsp;      bv_len =3D 0, bv_val =3D 0x0}, be_updat= e_refs =3D 0x0, be_pending_csn_list =3D 0x0, be_pcl_mutex =3D {__data =3D {= __lock =3D 0, __count =3D 0, __owner =3D 0, __nusers =3D 0, __kind =3D 0,<o= :p></o:p>      &= nbsp;        __spins =3D 0, __list =3D {= __prev =3D 0x0, __next =3D 0x0}}, __size =3D '\000' <repeats 39 times&gt= ;, __align =3D 0}, be_syncinfo =3D 0x0, be_pb =3D 0x0,<o:p></o:p></p= >      &= nbsp;    be_cf_ocs =3D 0x7fcbb63355a0 <cf_ocs+448>= , be_private =3D 0x0, be_next =3D {stqe_next =3D 0x7fcbb643fa00}}<o:p></o:p= >      &= nbsp;  cb =3D {sc_next =3D 0x0, sc_response =3D 0x7fcbb5fb5629 <ove= r_back_response>, sc_cleanup =3D 0x0, sc_writewait =3D 0x0, sc_private = =3D 0x7fcbb6443430}<o:p></o:p>      &= nbsp;  sc =3D 0x7fcbb6c0dc38<o:p></o:p>      &= nbsp;  rc =3D 32768<o:p></o:p>      &= nbsp;  __PRETTY_FUNCTION__ =3D "over_op_func"<o:p></o:p></sp= an> #4  0x00007fcbb5fb69de in = over_op_bind (op=3D0x7fcbb6c0dc00, rs=3D0x7fcbad881a30) at backover.c:738<o= :p></o:p> No locals.<o:p></o:p></p= > #5  0x00007fcbb5f47697 in = do_bind (op=3D0x7fcbb6c0dc00, rs=3D0x7fcbad881a30) at bind.c:205<o:p></o:p>=      &= nbsp;  ber =3D 0x7fcb8c1a9510<o:p></o:p>      &= nbsp;  version =3D 3<o:p></o:p>      &= nbsp;  method =3D 128<o:p></o:p>      &= nbsp;  mech =3D {bv_len =3D 0, bv_val =3D 0x0}<o:p></o:p>      &= nbsp;  dn =3D {bv_len =3D 41, bv_val =3D 0x7fcb88344a3a "cn=3Dxxx= xbnd,ou=3Dbind,dc=3Dxxxx,dc=3Dxxxx.xx"}<o:p></o:p>      &= nbsp;  tag =3D 128<o:p></o:p>      &= nbsp;  be =3D 0x0<o:p></o:p> #6  0x00007fcbb5f1df19 in = connection_operation (ctx=3D0x7fcbad881b80, arg_v=3D0x7fcbb6c0dc00) at conn= ection.c:1155<o:p></o:p>      &= nbsp;  rc =3D 80<o:p></o:p>      &= nbsp;  cancel =3D 0<o:p></o:p>      &= nbsp;  op =3D 0x7fcbb6c0dc00<o:p></o:p>      &= nbsp;  rs =3D {sr_type =3D REP_RESULT, sr_tag =3D 97, sr_msgid =3D 2, = sr_err =3D 52, sr_matched =3D 0x0, sr_text =3D 0x7fcbb60e698a "Start T= LS failed", sr_ref =3D 0x0, sr_ctrls =3D 0x0, sr_un =3D {<o:p></o:p></= span>      &= nbsp;      sru_search =3D {r_entry =3D 0x0, r_attr= _flags =3D 0, r_operational_attrs =3D 0x0, r_attrs =3D 0x0, r_nentries =3D = 0, r_v2ref =3D 0x0}, sru_sasl =3D {r_sasldata =3D 0x0}, sru_extended =3D {<= o:p></o:p>      &= nbsp;        r_rspoid =3D 0x0, r_rspdata= =3D 0x0}}, sr_flags =3D 0}<o:p></o:p>      &= nbsp;  tag =3D 96<o:p></o:p>      &= nbsp;  opidx =3D SLAP_OP_BIND<o:p></o:p>      &= nbsp;  conn =3D 0x7fcbae0f22d0<o:p></o:p>      &= nbsp;  memctx =3D 0x7fcbb64fada0<o:p></o:p>      &= nbsp;  memctx_null =3D 0x0<o:p></o:p>      &= nbsp;  memsiz =3D 1048576<o:p></o:p>      &= nbsp;  __PRETTY_FUNCTION__ =3D "connection_operation"<o:p></= o:p> #7  0x00007fcbb5f1e4e1 in = connection_read_thread (ctx=3D0x7fcbad881b80, argv=3D0x281) at connection.c= :1291<o:p></o:p>      &= nbsp;  rc =3D 0<o:p></o:p>      &= nbsp;  cri =3D {op =3D 0x7fcbb6c0dc00, func =3D 0x0, arg =3D 0x0, ctx = =3D 0x7fcbad881b80, nullop =3D 0}<o:p></o:p>      &= nbsp;  s =3D 641<o:p></o:p> #8  0x00007fcbb5a53c3c in = ldap_int_thread_pool_wrapper (xpool=3D0x7fcbb640af70) at tpool.c:688<o:p></= o:p>      &= nbsp;  pool =3D 0x7fcbb640af70<o:p></o:p>      &= nbsp;  task =3D 0x7fcba8787f80<o:p></o:p>      &= nbsp;  work_list =3D 0x7fcbb640b008<o:p></o:p>      &= nbsp;  ctx =3D {ltu_id =3D 140512766469888, ltu_key =3D {{ltk_key =3D = 0x7fcbb5f1da15 <conn_counter_init>, ltk_data =3D 0x7fcbb64fac90, ltk_= free =3D 0x7fcbb5f1d817 <conn_counter_destroy>}, {<o:p></o:p><= /p>      &= nbsp;        ltk_key =3D 0x7fcbb5f95b15 = <slap_sl_mem_init>, ltk_data =3D 0x7fcbb64fada0, ltk_free =3D 0x7fcbb= 5f95944 <slap_sl_mem_destroy>}, {ltk_key =3D 0x7fcbb5f3991c <slap_= op_free>,<o:p></o:p>      &= nbsp;        ltk_data =3D 0x7fcbb6c0ce30= , ltk_free =3D 0x7fcbb5f39874 <slap_op_q_destroy>}, {ltk_key =3D 0x0,= ltk_data =3D 0x0, ltk_free =3D 0x0} <repeats 29 times>}}<o:p></o:p><= /span>      &= nbsp;  kctx =3D 0x0<o:p></o:p>      &= nbsp;  i =3D 32<o:p></o:p>      &= nbsp;  keyslot =3D 838<o:p></o:p>      &= nbsp;  hash =3D 2545024838<o:p></o:p>      &= nbsp;  __PRETTY_FUNCTION__ =3D "ldap_int_thread_pool_wrapper&quot= ;<o:p></o:p> #9  0x00007fcbb4e6c806 in = start_thread (arg=3D<optimized out>) at pthread_create.c:301<o:p></o:= p>      &= nbsp;  __res =3D <optimized out><o:p></o:p>      &= nbsp;  pd =3D 0x7fcbad882700<o:p></o:p>      &= nbsp;  unwind_buf =3D {cancel_jmp_buf =3D {{jmp_buf =3D {1405127664698= 88, -3966806835471793915, 140512774851584, 140512766468096, 0, 8388608, 399= 1395584477806853, 3991451503570501893},<o:p></o:p>       =         mask_was_saved =3D 0}}, pri= v =3D {pad =3D {0x0, 0x0, 0x0, 0x0}, data =3D {prev =3D 0x0, cleanup =3D 0x= 0, canceltype =3D 0}}}<o:p></o:p>      &= nbsp;  not_first_call =3D <optimized out><o:p></o:p>      &= nbsp;  robust =3D <optimized out><o:p></o:p>      &= nbsp;  freesize =3D <optimized out><o:p></o:p>      &= nbsp;  __PRETTY_FUNCTION__ =3D "start_thread"<o:p></o:p></sp= an> #10 0x00007fcbb36b702d in gnu_d= ev_makedev (major=3D3066092544, minor=3D<optimized out>) at ../sysdep= s/unix/sysv/linux/makedev.c:37<o:p></o:p> No locals.<o:p></o:p> #11 0x0000000000000000 in ?? ()<o:p></o:p> No symbol table info available.= <o:p></o:p> </div> </body> </html> --_000_BE8E19527611BA409D68FF6EA186AF9002A2A6AABEREXMBX19ifc1i_--

1 0

(ITS#8200) Potential use of freed data after mdb_midl_shrink()
by h.b.furuseth＠usit.uio.no 14 Jul '15

14 Jul '15

Full_Name: Hallvard B Furuseth Version: LMDB_0.9.15 OS: URL: Submission from: (NULL) (81.191.45.5) Submitted by: hallvard This code is wrong if the realloc in mdb_midl_shrink fails: if (mdb_midl_shrink(&txn->mt_free_pgs)) env->me_free_pgs = txn->mt_free_pgs; env->me_free_pgs is left pointing as an old, freed IDL. (Freed when mt_free_pgs was originally grown.) It should be: mdb_midl_shrink(&txn->mt_free_pgs); env->me_free_pgs = txn->mt_free_pgs; So mdb_midl_shrink() can return void.

1 0

(ITS#8199) Crash when modifying the first olcAttributeTypes element in olcSchemaConfig objectClass
by luca.bruno＠rocket-internet.de 14 Jul '15

14 Jul '15

Full_Name: Luca BRUNO Version: 2.4.40 OS: Debian URL: Submission from: (NULL) (217.110.53.72) Hi, slapd 2.4.40 realiably crashes when modifying the 0th olcAttributeTypes element in a olcSchemaConfig object. This is a stacktrace captured when trying to change the "DESC" field of the "gecos" attribute in the "nis" schema (this is just an easier/dumb reproducer, the crash was first seen in production with a custom schema). Short stacktrace first: """ #0 0x00007f804d028d78 in at_next (at=at@entry=0x7f8040842318) at ../../../../servers/slapd/at.c:368 #1 0x00007f804cfd1a2a in config_generic (c=0x7f8040845650) at ../../../../servers/slapd/bconfig.c:1686 #2 0x00007f804cfd7a4b in config_set_vals (Conf=0x7f804d2d4ca0, c=0x7f8040845650) at ../../../../servers/slapd/config.c:353 #3 0x00007f804cfd846d in config_parse_add (ct=ct@entry=0x7f804d2d4ca0, c=c@entry=0x7f8040845650, valx=<optimized out>) at ../../../../servers/slapd/config.c:697 #4 0x00007f804cfcb977 in config_modify_add (ct=ct@entry=0x7f804d2d4ca0, ca=ca@entry=0x7f8040845650, i=i@entry=0, ad=<error reading variable: Unhandled dwarf expression opcode 0xfa>) at ../../../../servers/slapd/bconfig.c:5504 #5 0x00007f804cfcc86d in config_modify_internal (ca=0x7f8040845650, rs=0x7f8040847a50, op=0x7f804d2d9fc0, ce=<optimized out>) at ../../../../servers/slapd/bconfig.c:5761 #6 config_back_modify (op=0x7f804d2d9fc0, rs=0x7f8040847a50) at ../../../../servers/slapd/bconfig.c:5906 #7 0x00007f804cffa7f9 in fe_op_modify (op=0x7f80380008b0, rs=0x7f8040847a50) at ../../%2/../servers/slapd/modify.c:303 #8 0x00007f804cffc6bd in do_modify (op=0x7f80380008b0, rs=0x7f8040847a50) at ../../../../servers/slapd/modify.c:177 #9 0x00007f804cfe2d81 in connection_operation (ctx=ctx@entry=0x7f8040847ba0, arg_v=arg_v@entry=0x7f80380008b0) at ../../../../servers/slapd/connection.c:1155 #10 0x00007f804cfe30a4 in connection_read_thread (ctx=0x7f8040847ba0, argv=<optimized out>) at ../../../../servers/slapd/connection.c:1291 #11 0x00007f804cb43f83 in ldap_int_thread_pool_wrapper (opool=0x7f804dfedfd0) at ../../../../libraries/libldap_r/tpool.c:688 #12 0x00007f804af53b50 in start_thread () from /lib/x86_64-linux-gnu/libpthread.so.0 #13 0x00007f804ac9d95d in clone () from /lib/x86_64-linux-gnu/libc.so.6 #14 0x0000000000000000 in ?? ()222"" Detailed trace: """ #0 0x00007f804d028d78 in at_next (at=at@entry=0x7f8040842318) at ../../../../servers/slapd/at.c:368 __PRETTY_FUNCTION__ = "at_next" #1 0x00007f804cfd1a2a in config_generic (c=0x7f8040845650) at ../../../../servers/slapd/bconfig.c:1686 %3= <optimized out> at = 0x0 prev = 0x0 i = <optimized out> __PRETTY_FUNCTION__ = "config_generic" #2 0x00007f804cfd7a4b in config_set_vals (Conf=0x7f804d2d4ca0, c=0x7f8040845650) at ../../../../servers/slapd/config.c:353 rc = <optimized out> arg_type = <optimized out> ptr = 0x0 #3 0x00007f804cfd846d in config_parse_add (ct=ct@entry=0x7f804d2d4ca0, c=c@entry=0x7f8040845650, valx=<optimized out>) at ../../../../servers/slapd/config.c:697 rc = 0 #4 0x00007f804cfcb977 in config_modify_add (ct=ct@entry=0x7f804d2d4ca0, ca=ca@entry=0x7f8040845650, i=i@entry=0, ad=<error reading variable: Unhandled dwarf expression opcode 0xfa>) at ../../../../servers/slapd/bconfig.3A3A5504 rc = <optimized out> #5 0x00007f804cfcc86d in config_modify_internal (ca=0x7f8040845650, rs=0x7f8040847a50, op=0x7f804d2d9fc0, ce=<optimized out>) at ../../../../servers/slapd/bconfig.c:5761 e = 0x7f804e00ae18 save_attrs = 0x7f804e01fa30 a = 0x7f804e40b858 colst = 0x7f804e07f120 i = <optimized out> dels = 0x0 rc = <optimized out> oc_at = <optimized out> ct = 0x7f804d2d4ca0 nocs = 2 ptr = <optimized out> s = <optimized out> deltail = 0x7f8040846818 ml = <optimized out> #6 config_back_modify (op=0x7f804d2d9fc0, rs=0x7f8040847a50) at ../../../../servers/slapd/bconfig.c:5906 cfb = 0x7f8040847a50 ce = <optimized out> last = <optimized out> ml = <optimized out> ca = {argc = 18, argv = 0x7f804e99cfa0, argv_size = 513, line = 0x7f804e058993 "( 1.3.6.1.1.1.1.4 NAME 'loginShell' DESC 'The d to the login shell' EQUALITY caseExactIA5Match SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 SINGLE-VALUE )", tline = 0x7f804e99a340 "(", fname = 0x7f804d071961 "slapd", lineno = 0, log = "olcAttributeTypes: value #0", '\000' <repeats 4096 times>, reply = {err = 0, msg = '\000' <repeats 255 times>}, depth = 0, valx = 1, values = {v_int = 0, v_uint = 0, v_long = 0, v_ulong = 0, v_ber_t = 0, v_string = 0x0, v_bv = {bv_len = 0, bv_val = 0x0}, v_dn = {vdn_dn = { bv_len = 0, bv_val = 0x0}, vdn_ndn = {bv_len = 0, bv_val = 0x0}}, v_ad = 0x0}, rvalue_vals = 0x0, rvalue_nvals = 0x0, op = 0, type = 25, ca_op = 0x7f80380008b0, be = 0x7f804d2dbbe0, bi = 0x0, ca_entry = 0x7f804e00ae18, ca_private = 0x7f804e04f8e0, cleanup = 0, table = Cft_Schema} rdn % % {bv_len = 2, bv_val = 0x7f804e081ef0 "cn={2}nis,cn=schema,cn=config"} ptr = <optimized out> rad = 0x7f804dfeada0 do_pause = <optimized out> #7 0x00007f804cffa7f9 in fe_op_modify (op=0x7f80380008b0, rs=0x7f8040847a50) at ../../../../servers/slapd/modify.c:303 update = <optimized out> repl_user = <optimized out> op_be = <optimized out> bd = 0x7f804d2dbbe0 textbuf = "\002\000\000\000\000\000\000\000\214\311\303J\200\177\000\000\260\370\231N\200\177\000\000\345\375\377L\200\177\000\000\320\001\000\000\000\000\000\000\240\255\201N\200\177\000\000 \342\375M\200\177\000\000b\366\231N\200\177\000\000\277\000\000\000\000\000\000\000\200șN\200\177\000\000\003\000\000\000\000\000\000\000`\366\231N\200\177\000\000\001\000\000\000\000\000\000\000a\366\231N\200\177\000\000\360h\204@\200\177\000\000\031\000\000\000\000\000\000\000\000\266\005N\200\177\000\000p%\377M\200\177", '\000' <repeats 18 times>"\220, \001\000P000\000\000\000\000ߵ\377L\200\177\000\000\020\017\000\070\200\177\000\000\020\025\000\070\200\177\000\000\340i\204@\200\177\000\000pz\204@\200\177\000\000\000\001\000\000\000\000\000\000\260\b\000\070\200\177\000\000\025\000\000\000\000\000\000\000m\210\377L\200\177\000\000\000\000\000\000\000\000\000\000\020\025\000\070\200\177\000" #8 0x00007f804cffc6bd in do_modify (op=0x7f80380008b0, rs=0x7f8040847a50) at ../../../../servers/slapd/modify.c:177 dn = {bv_len = 29, bv_val = 0x7f804e99b569 "cn={2}nis,cn=schema,cn=config"} textbuf = "olcAttributeTypes\000jectClass\000amp\000%F\217\067\260\264l\221c`=\bX\302J5\347\343\001\255\064\336\002!\036\322\326L\350\304'\245\234\026\016dJ'\315:\225\034\310f\245ӌuV.\234&F\233c\324\023'\022\236\236\370\"!C\307\065\246\067\363\302\373\021\205\207k\030\037\211d݉\213\213\226\243G\324\345R\323Ӹ\277Lo\270v\031ccEc\215\227\031\244?\222\245\037.\302\303tO\210\211\250\255\ayg\316w(\317U4\210\274\372LJ\246`]\250\230\000!N\372\305\376\365\220\222\264)\004J\353\305^m\325\366\372\361\060ӝ\203Sy\341\302\026M\333\027\252\002\370\234e\370M҅;k\275\266L\200\177\000\000\000\000\000\000\000\000\000\000\b\000\000\000\022\020\204M0S\201N\200\177\000\000\341ؒL\200\177\000" tmp = 0x0 #9 0000007f804cfe8181 in connection_operation (ctx=ctx@entry=0x7f8040847ba0, arg_v=arg_v@entry=0x7f80380008b0) at ../../../../servers/slapd/connection.c:1155 rc = 80 cancel = <optimized out> op = 0x7f80380008b0 rs = {sr_type = REP_RESULT, sr_tag = 0, sr_msgid = 0, sr_err = 0, sr_matched = 0x0, sr_text = 0x0, sr_ref = 0x0, sr_ctrls = 0x0, sr_un = { sru_search = {r_entry = 0x0, r_attr_flags = 0, r_operational_attrs = 0x0, r_attrs = 0x0, r_nentries = 0, r_v2ref 0x0x0}, sru_sasl = { r_sasldata = 0x0}, sru_extended = {r_rspoid = 0x0, r_rspdata = 0x0}}, sr_flags = 0} tag = 102 opidx = SLAP_OP_MODIFY conn = 0x7f804e11a250 memctx = 0x7f8038000f10 memctx_null = 0x0 memsiz = 1048576 __PRETTY_FUNCTION__ = "connection_operation" #10 0x00007f804cfe30a4 in connection_read_thread (ctx=0x7f8040847ba0, argv=<optimized out>) at ../../../../servers/slapd/connection.c:1291 rc = <optimized out> cri = {op = 0x7f80380008b0, func = 0, arg = 0x0, ctx = <optimized out>, nullop = <optimized out>} s = <optimized out> #11 0x00007f804cb43f83 in ldap_int_thread_pool_wrapper (xpool=0x7f804dfedfd0) at ../../../../libraries/libldap_r/tpool.ch688 pool = 0x7f804dfedfd0 task = 0x7f804e3ea890 work_list = <optimized out> ctx = {ltu_id = 140188814968576, ltu_key = {{ltk_key = 0x7f804cfe0ec0, ltk_data = 0x7f8038000e00, ltk_free = 0x7f804cfe0f90 <conn_counter_destroy>}, {ltk_key = 0x7f804d03a760, ltk_data = 0x7f8038000f10, ltk_free = 0x7f804d03a780 <slap_sl_mem_destroy>}, {ltk_key = 0x7f804cff6cb0, ltk_data = 0x0, ltk_free = 0x7f804cff6c10 <slap_op_q_destroy>}, {ltk_key = 0x7f804e3e65d0, ltk_data = 0x7f804e81aab0, ltk_free = 0x7f8047be4540 <bdb_reader_free>}, {ltk_key = 0x0, ltk_data = 0x0, ltk_free = 0} <repeats 28 times>}} kctx = <optimized out> keyslot = <optimized out> hash = <optimized out> __PRETTY_FUNCTION__ = "ldap_int_thread_pool_wrapper" #12 0x00007f804af53b50 in start_thread () from /lib/x86_64-linux-gnu/libpthread.so.0 No symbol table info available. #13 0x00007f804ac9d95d in clone () from /lib/x86_64-linux-gnu/libc.so.6 No symbol table info available. #14 0x0000000000000000 in ?? () No symbol table info available. """

1 0

Re: (ITS#8181) LMDB page leaks etc when treating DBs as data
by h.b.furuseth＠usit.uio.no 13 Jul '15

13 Jul '15

Added the error checks after all, plus documentation, after chatting about it.

1 0

(ITS#8198) pw-pbkdf2: optionally use libnettle for crypto
by luca.bruno＠rocket-internet.de 13 Jul '15

13 Jul '15

Full_Name: Luca BRUNO Version: git:master OS: Debian URL: https://github.com/lucab/openldap/commits/lucab/pbkdf2-nettle Submission from: (NULL) (78.55.218.166) This is a followup to ITS#7977. Here below are two patches against the pw-pbkdf2 contrib module to: 1) fix an always-true check 2) optionally make use of libnettle Corresponding patches are available online: 1) https://github.com/lucab/openldap/commit/f9e42bc1ce85a8c2bc7f3daa06a553b0f7… 2) https://github.com/lucab/openldap/commit/b98457fbb009e92d394e0d99851fc720df… Those have been already reviewed by Tsukasa HAMANO: * https://github.com/hamano/openldap-pbkdf2/pull/3 * https://github.com/hamano/openldap-pbkdf2/pull/4 IPR statement follows: """ The attached patch is derived from OpenLDAP Software. All of the modifications to OpenLDAP Software represented in the following patch(es) were developed by Luca BRUNO, on balalf of "Rocket Internet SE". By virtue of my employment agreement with "Rocket Internet SE", I have assigned my rights and interest in this work to "Rocket Internet SE". "Rocket Internet AG" has not assigned rights and/or interest in this work to any party. I, Luca BRUNO, am authorized by "Rocket Internet SE", my employer, to release this work under the following terms. "Rocket Internet SE" hereby places 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. """

1 0

(ITS#8197) slapo-constraint and delold=0
by michael＠stroeder.com 12 Jul '15

12 Jul '15

Full_Name: Version: OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (79.223.44.49) I thought about this: http://www.openldap.org/lists/openldap-technical/201507/msg00035.html => slapo-constraint should not trigger the constraint if the old and valid RDN value is not changed with MODRDN operation with delold=0 when moving the entry beneath a new superior.

1 0

Re: (ITS#8195) Regression: wrong conversion specifier for "port" in "ldap_domain2hostlist"
by hyc＠symas.com 12 Jul '15

12 Jul '15

Sergio.Gelato(a)astro.su.se wrote: > Full_Name: Sergio Gelato > Version: 2.4.40 > OS: Linux > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (85.225.123.131) > > > Commit 5de85b922aaa5bfa6eb53db6000adf01ebdb0736 has undone the fix for > ITS#6644. Thanks for the report. Fixed in master. > > As a consequence, if one has a record > _ldap._tcp.example.org IN SRV 0 0 38900 ldap.example.org > ldap_domain2hostlist("example.org",&result) returns > ldap.example.org:-26636 > as the value of the result string. > > -- -- 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

PRNG from ITS#7027 (shuffling DNS SRV records) is poorly seeded
by Sergio.Gelato＠astro.su.se 12 Jul '15

12 Jul '15

Full_Name: Sergio Gelato Version: 2.4.40 OS: Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (85.225.123.131) As part of ITS#7027, a simple PRNG was added to libraries/libldap/dnssrv.c in order to implement shuffling of SRV RRs as per RFC2782. I see two shortcomings with the way this generator is being seeded. (1) The seed is a very slowly varying function of time: (float)time(NULL) / (2**32-1). The mantissa of an IEEE754 float has 24 bits, so one only gets a new seed every 2**7 seconds with the current seeding method. (2) At any given time, all clients areikikely to use the same seed and therefore pick the same SRV record. This means the load on individual servers will fluctuate a lot more than if the clients picked records in an uncorrelated fashion. To fix (1) I think we need to hash the seed so that it is much more sensitive to the least significant bit of the current time value. (2) can be addressed by mixing in some value that varies from client to client; maybe the 16-bit DNS query ID is most readily available (as the first two bytes of the reply buffer; I hope all implementations of res_query() return it). Come to think of it, shifting the query ID up by 15 bits and XORing with the current time might be good enough.

1 0

(ITS#8195) Regression: wrong conversion specifier for "port" in "ldap_domain2hostlist"
by Sergio.Gelato＠astro.su.se 11 Jul '15

11 Jul '15

Full_Name: Sergio Gelato Version: 2.4.40 OS: Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (85.225.123.131) Commit 5de85b922aaa5bfa6eb53db6000adf01ebdb0736 has undone the fix for ITS#6644. As a consequence, if one has a record _ldap._tcp.example.org IN SRV 0 0 38900 ldap.example.org ldap_domain2hostlist("example.org",&result) returns ldap.example.org:-26636 as the value of the result string.

1 0

RE: (ITS#8194) Service slapd falldown in a search with client ldapsearch
by ludovic.brochard＠cgi.com 10 Jul '15

10 Jul '15

SGVsbG8sIHRoaXMgaXMgdGhlIGZ1bGwgc3RhY2t0cmFjZSA6DQoNCihnZGIpIGJ0IGZ1bGwNCiMw ICAweDAwMDAwMDAwMDA0OWUyNTEgaW4gbWRiX2hhc1N1Ym9yZGluYXRlcyAob3A9MHg3ZjYxYTE0 MGQ0NjAsIGU9PHZhbHVlIG9wdGltaXplZCBvdXQ+LCBoYXNTdWJvcmRpbmF0ZXM9MHg3ZjYxYTA5 MGUwMTApIGF0IG9wZXJhdGlvbmFsLmM6NzgNCiAgICAgICAgbWRiID0gPHZhbHVlIG9wdGltaXpl ZCBvdXQ+DQogICAgICAgIHJ0eG4gPSA8dmFsdWUgb3B0aW1pemVkIG91dD4NCiAgICAgICAgb3Bp bmZvID0ge21vaV9vZSA9IHtvZV9uZXh0ID0ge3NsZV9uZXh0ID0gMHg3MzZ9LCBvZV9rZXkgPSAw eDdmNjE5ODAwMTkyOH0sIG1vaV90eG4gPSAweDgsIG1vaV9yZWYgPSAtMTc0NDgyNTcyMCwgbW9p X2ZsYWcgPSA5NyAnYSd9DQogICAgICAgIG1vaSA9IDB4N2Y2MTk4MTAyNTgwDQogICAgICAgIHJj ID0gLTE1OTEyMjU1NjgNCiAgICAgICAgX19QUkVUVFlfRlVOQ1RJT05fXyA9ICJtZGJfaGFzU3Vi b3JkaW5hdGVzIg0KIzEgIDB4MDAwMDAwMDAwMDRhMDhhYyBpbiBtZGJfc2VhcmNoIChvcD0weDdm NjFhMTQwZWEzMCwgcnM9PHZhbHVlIG9wdGltaXplZCBvdXQ+KSBhdCBzZWFyY2guYzo5NTANCiAg ICAgICAgc2NvcGVvayA9IDx2YWx1ZSBvcHRpbWl6ZWQgb3V0Pg0KICAgICAgICBlZGF0YSA9IHtt dl9zaXplID0gODE4NywgbXZfZGF0YSA9IDB4N2Y4YzNiZWNmMTIyfQ0KICAgICAgICBtZGIgPSA8 dmFsdWUgb3B0aW1pemVkIG91dD4NCiAgICAgICAgaWQgPSAxNDAwNTcyOTM5MzU4NTYNCiAgICAg ICAgY3Vyc29yID0gODE5Mg0KICAgICAgICBuc3VicyA9IDE0MDA4MzcxMTU3NDc1Mg0KICAgICAg ICBuY2FuZCA9IDE0MDA1NzEzOTc1MDI3Mg0KICAgICAgICBjc2NvcGUgPSAwDQogICAgICAgIGxh c3RpZCA9IDg0OA0KICAgICAgICBjYW5kaWRhdGVzID0gezE4NDQ2NzQ0MDczNzA5NTUxNjE1LCAx LCAxNzgyMDg2LCAzMiwgMCwgMjcwMzc0MzE5MiwgMjcwMzc0MzQyNCwgMTQwMDU3MjkyMjk3NTIw LCAxODQ0Njc0NDA3MzcwOTU1MTYxNSwgMTQwMDU3MjkyMjk4NjU2LCAwLCAwLCAyNzAzNzQzNTMy LCAxNDAwNTcyOTIyOTg1MjAsIA0KICAgICAgICAgIDI3MDM3NDMxOTEsIDE0MDA1NzI5MjI5ODI3 MiwgMTAwLCAwLCAxMDA2MTE3NTc1LCAyNDc5LCAwLCAwLCAxNDAwNTQ1ODg1NTUyNjQsIDg1ODk5 MzQ1OTIsIDE4NDQ2NzQ0MDczNzA5NTUxNjE1LCAxNDAwNTg4ODM1MjI1NTksIDAsIDE0MDA1NzI5 MjI5ODUyMCwgNDg4MTc3Nzc5LCAwLCA1Mjk3NTE4LCANCiAgICAgICAgICAyNzAzNzQyNzUyLCAw LCAyMjk4MDgwMCwgMTE2MTI0ODk0MTEwNTc5MTUyNTksIDQyOTQ5Njc1NDM5LCAwLCA0NzkyMDQy LCAxNDAwNTcyOTIyOTg2NDcsIDg1ODk5MzQ1OTIsIDE4NTg3Nzc2LCAxNDAwNTcyOTIyOTg2NDcs IDIwNjE1ODQzMDIyNCwgMTQwMDU3MjkyMjk4NjQ4LCANCiAgICAgICAgICAxNDAwNTcyOTIyOTc4 MjgsIDAsIDU0MDU4NzAsIDIyOTgwNjU2LCAwLCAyLCAxNDAwNTcyOTIyOTgyNTYsIDE1NTg4NjQ0 ODE2LCAyNzAzNzQyNTY2LCAwLCAzNzYwNTY1MjgyMzgzODQ0OTQ0LCAxNDAyNDAyNzc1Mzc0ODYs IDE0MDI0MDI4MDU4MDgzMiwgMTQwMDU3MjkyMjk4MjIzLCAxODU4Nzc3NiwgDQogICAgICAgICAg MTQwMDU3MjkyMjk3NzQ0LCAyMDYxNTg0MzAyMjQsIDIsIDE0MDA1NzI5MjI5ODM1MiwgMTM4OTAy ODU4NTgsIDI3MDM3NDI2NjIsIDE0MDA1NDU4ODU1NTI2NCwgMzc2MDU2NTI4MjM4Mzg0NTA0MCwg MTQwMDU3MjkyMjk3OTI2LCAxNDAyNDAyODA1ODA4MzIsIDE0MDA1NzI5MjI5ODMxOSwgDQogICAg ICAgICAgMTg1ODc3NzYsIDE0MDA1NzI5MjI5Nzg0MCwgMjA2MTU4NDMwMjI0LCAxNDAwNTcyOTIy OTgzMzYsIDE0MDA1NzI5MjI5ODE0NCwgMTQwMjQwMjc3NTM3NDg2LCAxNDAwNTcxMzk3NTE0MzYs IDE0MDA1NzEzOTc1MTQzNiwgMTQwMjQwMjgwNTgyODQ4LCA3LCA4MTg3LCAyLCAxNDAwNTcyOTIy OTg1MTIsIA0KICAgICAgICAgIDEyODg0OTAxODg4LCA1NjI4ODI1MDE1NjkwMiwgMTQwMjM5Mjcy MTQ4OTkyLCAzNzYwNTY1MjgyMzgzODQ1MjAwLCAxNDAwNTcyOTIyOTgwODYsIDE0MDI0MDI4MDU4 MDgzMiwgMTQwMDU3MjkyMjk4NDc5LCAxODU4Nzc3NiwgMTQwMDU3MjkyMjk4MDAwLCAyMDYxNTg0 MzAyMjQsIA0KICAgICAgICAgIDE0MDA1NzI5MjI5ODQ5NiwgMTQwMDU3MjkyMjk4MzA0LCAxNDAw NTQ1ODg1NTUyNjQsIDE0MDA1NzI5MjI5ODIyOSwgMTQwMjM5MjcyMTQ4OTkyLCAyNzAzNzQyOTY1 LCAxNDAyNDAyNzc1Mzc0ODYsIDIwNjE1ODQzMDIyNCwgMTQwMDU3MjkyMjk4ODE2LCAxNDAwNTcy OTIyOTg2MjQsIA0KICAgICAgICAgIDE0MDA1NzEzOTc1MTQwOCwgNTYyODU1NDY0MTQxODEsIDIs IDE0MDA1NzI5MjI5ODcwNCwgMTM4OTEwMTk0NTksIDE0MDA1NzI5MjI5ODI3OCwgMTQwMDU0NTg4 NTU1MjY0LCAzNzYwNTY1MjgyMzgzODQ1MzkyLCAxNDAyNDAyNzc1Mzc0ODYsIDE0MDI0MDI4MDU4 MDgzMiwgMTQwMDU3MjkyMjk4NjcxLCANCiAgICAgICAgICAxODU4Nzc3NiwgMTQwMDU3MjkyMjk4 MTkyLCAyMDYxNTg0MzAyMjQsIDIsIDE0MDA1NzI5MjI5ODgwMCwgMTQwMjQwMjc3NTM3NDg2LCAy MDg4NjIxNzMzMTgsIDE0MDA1NDU4ODU1NTI2NCwgMzc2MDU2NTI4MjM4Mzg0NTQ4OCwgMTQwMDU3 MjkyMjk4Mzc0LCAxNDAyNDAyODA1ODA4MzIsIDIsIA0KICAgICAgICAgIDE0MDA1NzI5MjI5ODg2 NCwgMTU1ODg2NDQ5MTIsIDIwODg2MjE3MzM4MiwgMTQwMDU0NTg4NTU1MjY0LCAzNzYwNTY1Mjgy MzgzODQ1NTUyLCAxNDAwNTcyOTIyOTg0MzgsIDE0MDI0MDI4MDU4MDgzMiwgMTQwMDU3MjkyMjk4 ODMxLCAxODU4Nzc3NiwgMTQwMDU3MjkyMjk4MzUyLCANCiAgICAgICAgICAyMDYxNTg0MzAyMjQs IDE0MDA1NzI5MjI5ODg0OCwgMTQwMDU3MjkyMjk4NjU2LCAxNDAwNTQ1ODg1NTUyNjQsIDU2Mjg4 MjUwMTU3Mzk3LCAyLCAxNDAwNTcyOTIyOTg5OTIsIDEzODkxMDE5NDU5LCAxNDAwNTcyOTIyOTg1 NjYsIDE0MDA1NDU4ODU1NTI2NCwgMzc2MDU2NTI4MjM4Mzg0NTY4MCwgDQogICAgICAgICAgMTQw MDU3MjkyMjk4NTY2LCA1NjI4NjU1NDg0NTkyMCwgMTQwMDU3MjkyMjk4OTU5LCAxODU4Nzc3Niwg MTQwMjQwMjc4MjY2NTYzLCAxNDAwNTcxMzk3NTE0MzYsIDE0MDA1NzEzOTc1MTQzNiwgMTQwMjQw MjgwNTgyODQ4LCA3LCA3ODc3NzkyLCAxOTI2NTI2NCwgMTA5OTUyODQ3MDc4NCwgDQogICAgICAg ICAgMjgxNDc5Mjg4NDU1MTY5LCAyNTYsIDAsIDEsIDIzMTIsIDAsIDAsIDAsIDAsIDAsIDAsIDAs IDE4ODkxMzEyLCAxOTI1OTM5MiwgMCwgMCwgMCwgMCwgMzEsIDE5MjY2MjA4LCAzMSwgMTkyNTk1 MjAsIDAsIDAsIDE1NDYxODgyMjY1NjE1LCAyMTQ3NDgzNjQ4MDAwLCANCiAgICAgICAgICAxODQ0 Njc0NDA2OTQxNDU4NDMyMCwgMCwgMCwgMCwgMCwgNSwgMCwgMCwgMCwgMCwgMjE5MzEzNjAsIDAs IDAsIDAsIDAuLi59DQogICAgICAgIGlzY29wZXMgPSB7MCA8cmVwZWF0cyA2NTUzNiB0aW1lcz59 DQogICAgICAgIHNjb3BlcyA9IDB4N2Y2MWEwOTBlMDEwDQogICAgICAgIGUgPSAweDdmNjE5ODAw MGU0OA0KICAgICAgICBiYXNlID0gMHgyOQ0KICAgICAgICBtYXRjaGVkID0gMHg3ZjYxOTgwMDEy NTANCiAgICAgICAgYXR0cnMgPSA8dmFsdWUgb3B0aW1pemVkIG91dD4NCiAgICAgICAgbWFzayA9 IDx2YWx1ZSBvcHRpbWl6ZWQgb3V0Pg0KICAgICAgICBzdG9wdGltZSA9IDE0MDA1NzEzOTc5MTA3 Mw0KICAgICAgICBtYW5hZ2VEU0FpdCA9IDx2YWx1ZSBvcHRpbWl6ZWQgb3V0Pg0KICAgICAgICB0 ZW50cmllcyA9IDE3ODIwODYNCiAgICAgICAgaXNjID0ge210ID0gMHg3ZjYxOTgxMDJjMDAsIG1j ID0gMHg3ZjYxOTgxMDQ4ODAsIGlkID0gMTY2NDY0NCwgc2NvcGVzID0gMHg3ZjYxYTA5MGUwMTAs IG51bXJkbnMgPSAtMTgyODcyMDYyNCwgbnNjb3BlID0gMzI2MDksIG9zY29wZSA9IDEsIHJkbnMg PSB7e2J2X2xlbiA9IDIsIA0KICAgICAgICAgICAgICBidl92YWwgPSAweGUgPEFkZHJlc3MgMHhl IG91dCBvZiBib3VuZHM+fSwge2J2X2xlbiA9IDE0MDA4MDUwNjU2Njc2OSwgYnZfdmFsID0gMHgw fSwge2J2X2xlbiA9IDAsIGJ2X3ZhbCA9IDB4MH0gPHJlcGVhdHMgMTQ0IHRpbWVzPiwge2J2X2xl biA9IDE0MDA1NzEzOTc0Mjk5MiwgDQogICAgICAgICAgICAgIGJ2X3ZhbCA9IDB4N2Y2MTk4MTAy NDIwICJcYiJ9LCB7YnZfbGVuID0gMCwgYnZfdmFsID0gMHg3ZjYxYTA5MGUwMTAgIm1cMzM1XHIi fSwge2J2X2xlbiA9IDE0MDA1NzA1NDgwMTkzNiwgYnZfdmFsID0gMHgwfSwge2J2X2xlbiA9IDEs IGJ2X3ZhbCA9IDB4MH0sIHtidl9sZW4gPSAwLCANCiAgICAgICAgICAgICAgYnZfdmFsID0gMHgw fSA8cmVwZWF0cyAxODk4IHRpbWVzPn0sIG5yZG5zID0ge3tidl9sZW4gPSAwLCBidl92YWwgPSAw eGUgPEFkZHJlc3MgMHhlIG91dCBvZiBib3VuZHM+fSwge2J2X2xlbiA9IDE0MDA4MDUwNjU2Njc1 NCwgYnZfdmFsID0gMHgwfSwge2J2X2xlbiA9IDAsIA0KICAgICAgICAgICAgICBidl92YWwgPSAw eDB9IDxyZXBlYXRzIDE2NTQgdGltZXM+LCB7YnZfbGVuID0gMTQwMDU3MTM5NzUxMjMyLCBidl92 YWwgPSAweDdmNjFhMTQwYzJjMCAiXDAyMCAifSwge2J2X2xlbiA9IDYsIGJ2X3ZhbCA9IDB4N2Y2 MWExNDBjMmQwICJcMDIwICJ9LCB7DQogICAgICAgICAgICAgIGJ2X2xlbiA9IDE0MDI0MDI3ODI2 NjU2OSwgYnZfdmFsID0gMHg3ZjhjM2JlNmY0NjcgPEFkZHJlc3MgMHg3ZjhjM2JlNmY0Njcgb3V0 IG9mIGJvdW5kcz59LCB7YnZfbGVuID0gMTQwMjQwMjc4MjY2NTcwLCBidl92YWwgPSAweDEgPEFk ZHJlc3MgMHgxIG91dCBvZiBib3VuZHM+fSwgew0KICAgICAgICAgICAgICBidl9sZW4gPSAxLCBi dl92YWwgPSAweDB9LCB7YnZfbGVuID0gMCwgYnZfdmFsID0gMHgwfSwge2J2X2xlbiA9IDAsIGJ2 X3ZhbCA9IDB4MH0sIHtidl9sZW4gPSAxNDAwNTcyOTM5MzA5MjgsIGJ2X3ZhbCA9IDB4MH0sIHti dl9sZW4gPSAxNDAyNDAyNzgyNjY1NjYsIGJ2X3ZhbCA9IDB4MH0sIHsNCiAgICAgICAgICAgICAg YnZfbGVuID0gMCwgYnZfdmFsID0gMHgwfSwge2J2X2xlbiA9IDE0MDA1NzI5MzkzMTAzNiwgYnZf dmFsID0gMHg3ZjYxYTE0MGMyMzggIlwyMTRFXDAyMFwyMzBhXDE3NyJ9LCB7YnZfbGVuID0gMCwg YnZfdmFsID0gMHg3ZjYxYTE0MGMyNTggIlwiXDM2MVwzNTQ7XDIxNFwxNzcifSwgew0KICAgICAg ICAgICAgICBidl9sZW4gPSAwLCBidl92YWwgPSAweDB9LCB7YnZfbGVuID0gMCwgYnZfdmFsID0g MHg3ZjhjM2JlOWY5NWUgPEFkZHJlc3MgMHg3ZjhjM2JlOWY5NWUgb3V0IG9mIGJvdW5kcz59LCB7 YnZfbGVuID0gMTQwMDU3MTM5NzUxMjMyLCANCiAgICAgICAgICAgICAgYnZfdmFsID0gMHg3ZjYx YTE0MGMzYTAgIlwyNjBcMzA0QFwyNDFhXDE3NyJ9LCB7YnZfbGVuID0gMjQsIGJ2X3ZhbCA9IDB4 N2Y2MWExNDBjNGIwICJcMDA2In0sIHtidl9sZW4gPSA1NDI5ODk1LCANCiAgICAgICAgICAgICAg YnZfdmFsID0gMHg3ZjhjM2JlNmY0NjcgPEFkZHJlc3MgMHg3ZjhjM2JlNmY0Njcgb3V0IG9mIGJv dW5kcz59LCB7YnZfbGVuID0gNTQyOTg5NiwgYnZfdmFsID0gMHgxIDxBZGRyZXNzIDB4MSBvdXQg b2YgYm91bmRzPn0sIHtidl9sZW4gPSAxLCANCiAgICAgICAgICAgICAgYnZfdmFsID0gMHg3ZjYx YTE0MGMxODggIlwwMjZcMzAyQFwyNDFhXDE3NyJ9LCB7YnZfbGVuID0gMCwgYnZfdmFsID0gMHgy MCA8QWRkcmVzcyAweDIwIG91dCBvZiBib3VuZHM+fSwge2J2X2xlbiA9IDAsIGJ2X3ZhbCA9IDB4 MH0sIHtidl9sZW4gPSAxNDAwNTcyOTM5MzExNTIsIA0KICAgICAgICAgICAgICBidl92YWwgPSAw eGEwMDAwMDlhZiA8QWRkcmVzcyAweGEwMDAwMDlhZiBvdXQgb2YgYm91bmRzPn0sIHtidl9sZW4g PSA1NDI5ODY5LCBidl92YWwgPSAweDB9LCB7YnZfbGVuID0gMTQwMDU3MjkzOTMwODgzLCBidl92 YWwgPSAweDB9LCB7YnZfbGVuID0gMTQwMDU3MjkzOTMxMjYwLCANCiAgICAgICAgICAgICAgYnZf dmFsID0gMHg3ZjYxYTE0MGMzMTggIlwzMjVtXDM1MjtcMjE0XDE3NyJ9LCB7YnZfbGVuID0gMCwg YnZfdmFsID0gMHg3ZjYxYTE0MGMzMzggIkApXDAyMFwyMzAifSwge2J2X2xlbiA9IDAsIGJ2X3Zh bCA9IDB4MH0sIHtidl9sZW4gPSAxNDAyNDAyNzgyNjY1NjcsIGJ2X3ZhbCA9IDB4MH0sIA0KICAg ICAgICAgICAge2J2X2xlbiA9IDAsIGJ2X3ZhbCA9IDB4YjAwMDAwMDAwIDxBZGRyZXNzIDB4YjAw MDAwMDAwIG91dCBvZiBib3VuZHM+fSwge2J2X2xlbiA9IDExNjE5NTAwNzg2MjUzMjk5NzEyLCBi dl92YWwgPSAweDdmNjFhMTQwYmU4MCAiIn0sIHtidl9sZW4gPSAxODQ0Njc0NDA3MzcwOTU1MTYx NSwgDQogICAgICAgICAgICAgIGJ2X3ZhbCA9IDB4N2Y2MWExNDBjMmYwICIgIn0sIHtidl9sZW4g PSAwLCBidl92YWwgPSAweDB9LCB7YnZfbGVuID0gMCwgYnZfdmFsID0gMHg3ZjYxYTE0MGMyNjgg IiJ9LCB7YnZfbGVuID0gMCwgYnZfdmFsID0gMHgyMCA8QWRkcmVzcyAweDIwIG91dCBvZiBib3Vu ZHM+fSwgew0KICAgICAgICAgICAgICBidl9sZW4gPSAwLCBidl92YWwgPSAweDB9LCB7YnZfbGVu ID0gMTE2MTk1MDA3OTA1NDgyNjcwMDgsIGJ2X3ZhbCA9IDB4MTAwMDAwMDlhZiA8QWRkcmVzcyAw eDEwMDAwMDA5YWYgb3V0IG9mIGJvdW5kcz59LCB7YnZfbGVuID0gNCwgYnZfdmFsID0gMHgwfSwg ew0KICAgICAgICAgICAgICBidl9sZW4gPSAxNDAwNTcyOTM5MzExMTEsIGJ2X3ZhbCA9IDB4MH0s IHtidl9sZW4gPSAwLCBidl92YWwgPSAweDdmNjFhMTQwYzI2NyAiNCJ9LCB7YnZfbGVuID0gMCwg YnZfdmFsID0gMHg3ZjYxYTE0MGMyNjggIiJ9LCB7YnZfbGVuID0gMTIwLCBidl92YWwgPSAweDB9 LCB7DQogICAgICAgICAgICAgIGJ2X2xlbiA9IDU0Mjk4OTIsIGJ2X3ZhbCA9IDB4MH0sIHtidl9s ZW4gPSAwLCBidl92YWwgPSAweGIwMDAwMDAwMCA8QWRkcmVzcyAweGIwMDAwMDAwMCBvdXQgb2Yg Ym91bmRzPn0sIHtidl9sZW4gPSAwLCBidl92YWwgPSAweDB9IDxyZXBlYXRzIDM0IHRpbWVzPiwg e2J2X2xlbiA9IDAsIA0KICAgICAgICAgICAgICBidl92YWwgPSAweDQ4ZWI0ZSAiXDMyMEhcMjEx XDMwN1wzNTBxTFwzNjdcMzc3SFwyMDVcMzMzSFwyMTFcMzMwdVwyNjdJXDMwN1wwMDYifSwge2J2 X2xlbiA9IDAsIGJ2X3ZhbCA9IDB4MH0sIHtidl9sZW4gPSA0NzgyMjg4LCANCiAgICAgICAgICAg ICAgYnZfdmFsID0gMHg3ZjYxYTE0MGMwZTAgIlwzNDBcMDIzLlwwMDEifSwge2J2X2xlbiA9IDg1 ODk5MzQ1OTIsIGJ2X3ZhbCA9IDB4N2Y2MWExNDBjMTRjICIifSwge2J2X2xlbiA9IDE5Nzk2OTYw LCBidl92YWwgPSAweDB9LCB7YnZfbGVuID0gMCwgDQogICAgICAgICAgICAgIGJ2X3ZhbCA9IDB4 N2Y2MWExNDBjMzcwICJcdiJ9LCB7YnZfbGVuID0gMSwgYnZfdmFsID0gMHg3ZjYxYTE0MGMxNDAg IiJ9LCB7YnZfbGVuID0gMCwgYnZfdmFsID0gMHgwfSwge2J2X2xlbiA9IDAsIA0KICAgICAgICAg ICAgICBidl92YWwgPSAweDdmOGMzYmVkMDJjZSA8QWRkcmVzcyAweDdmOGMzYmVkMDJjZSBvdXQg b2YgYm91bmRzPn0sIHtidl9sZW4gPSAwLCBidl92YWwgPSAweDEzZTE1ZDAgIlwwMDQifSwge2J2 X2xlbiA9IDE0MDA4MDU3MDM1NTcxMiwgYnZfdmFsID0gMHgwfSwge2J2X2xlbiA9IDAsIA0KICAg ICAgICAgICAgICBidl92YWwgPSAweDIgPEFkZHJlc3MgMHgyIG91dCBvZiBib3VuZHM+fSwge2J2 X2xlbiA9IDE0MDA1NzI5MzkzMTQ1NiwgYnZfdmFsID0gMHgzMDEzZTE1ZDAgPEFkZHJlc3MgMHgz MDEzZTE1ZDAgb3V0IG9mIGJvdW5kcz59LCB7YnZfbGVuID0gMjcwNTM3NTc2NiwgDQogICAgICAg ICAgICAgIGJ2X3ZhbCA9IDB4N2Y2MTAwMDAwMDAwIDxBZGRyZXNzIDB4N2Y2MTAwMDAwMDAwIG91 dCBvZiBib3VuZHM+fSwge2J2X2xlbiA9IDM3NjA1NjUyODIzODU0NzgxNDQsIGJ2X3ZhbCA9IDB4 N2Y2MWExNDBjMjE2ICIifSwge2J2X2xlbiA9IDE0MDI0MDI4MDU4MDgzMiwgDQogICAgICAgICAg ICAgIGJ2X3ZhbCA9IDB4N2Y2MWExNDBjMzlmICJcMzc3XDI2MFwzMDRAXDI0MWFcMTc3In0sIHti dl9sZW4gPSAxODU4Nzc3NiwgYnZfdmFsID0gMHg3ZjYxYTE0MGMxYzAgIlwzNjBcMzAyQFwyNDFh XDE3NyJ9LCB7YnZfbGVuID0gMjA2MTU4NDMwMjI0LCANCiAgICAgICAgICAgICAgYnZfdmFsID0g MHg3ZjYxYTE0MGMzYjAgIlwwMDIifSwge2J2X2xlbiA9IDE0MDA1NzI5MzkzMTI0OCwgYnZfdmFs ID0gMHgwfSwge2J2X2xlbiA9IDAsIGJ2X3ZhbCA9IDB4MH0sIHtidl9sZW4gPSAwLCBidl92YWwg PSAweDB9LCB7YnZfbGVuID0gMCwgYnZfdmFsID0gMHgwfSwgew0KICAgICAgICAgICAgICBidl9s ZW4gPSAxNDAwNTcyOTM5NDAxOTIsIGJ2X3ZhbCA9IDB4NDhlYjRlICJcMzIwSFwyMTFcMzA3XDM1 MHFMXDM2N1wzNzdIXDIwNVwzMzNIXDIxMVwzMzB1XDI2N0lcMzA3XDAwNiJ9LCB7YnZfbGVuID0g NTczOTM2NDc5NzY0NDgsIA0KICAgICAgICAgICAgICBidl92YWwgPSAweDdmNjcxNzZmM2ZlOCA8 QWRkcmVzcyAweDdmNjcxNzZmM2ZlOCBvdXQgb2YgYm91bmRzPn0sIHtidl9sZW4gPSA0Nzc4MzUy LCBidl92YWwgPSAweDdmOGMzYmY4MjJjMyA8QWRkcmVzcyAweDdmOGMzYmY4MjJjMyBvdXQgb2Yg Ym91bmRzPn0sIHsNCiAgICAgICAgICAgICAgYnZfbGVuID0gMTQwMDU3MTM5NzU4NDc2LCBidl92 YWwgPSAweDdmNjE5ODEwNDU4YyAiIn0sIHtidl9sZW4gPSAxNDAyNDAyODA1ODI4NDgsIGJ2X3Zh bCA9IDB4NyA8QWRkcmVzcyAweDcgb3V0IG9mIGJvdW5kcz59LCB7YnZfbGVuID0gODE4NywgDQog ICAgICAgICAgICAgIGJ2X3ZhbCA9IDB4N2Y4YzNiZWNmMTIyIDxBZGRyZXNzIDB4N2Y4YzNiZWNm MTIyIG91dCBvZiBib3VuZHM+fSwge2J2X2xlbiA9IDM3NDY5OTQ4ODk5NzIyNjA4NjQsIGJ2X3Zh bCA9IDB4N2Y2MTAwMDAwMDAwIDxBZGRyZXNzIDB4N2Y2MTAwMDAwMDAwIG91dCBvZiBib3VuZHM+ fSwgew0KICAgICAgICAgICAgICBidl9sZW4gPSAxNDAwNTcyOTM5MzEzMzMsIGJ2X3ZhbCA9IDB4 N2Y4YzAwMDAwMDAwIDxBZGRyZXNzIDB4N2Y4YzAwMDAwMDAwIG91dCBvZiBib3VuZHM+fSwge2J2 X2xlbiA9IDI3MDUzNzYwNjksIA0KICAgICAgICAgICAgICBidl92YWwgPSAweDEwMDAwMDAwMSA8 QWRkcmVzcyAweDEwMDAwMDAwMSBvdXQgb2YgYm91bmRzPn0sIHtidl9sZW4gPSAyMDYxNTg0MzAy MjQsIGJ2X3ZhbCA9IDB4N2Y2MWExNDBjNTkwICJcMDAxIn0sIHtidl9sZW4gPSAxNDAwNTcyOTM5 MzE3MjgsIA0KICAgICAgICAgICAgICBidl92YWwgPSAweDdmNjE5ODEwNDU3MCAiIn0sIHtidl9s ZW4gPSA4NSwgYnZfdmFsID0gMHg3ZjYxOTgwMDAwMjAgIiJ9LCB7YnZfbGVuID0gODIwOCwgYnZf dmFsID0gMHg3ZjYxOTgxMDY1ODAgIiJ9LCB7YnZfbGVuID0gODIwOCwgDQogICAgICAgICAgICAg IGJ2X3ZhbCA9IDB4N2Y4YzNiZWE2YTBlIDxBZGRyZXNzIDB4N2Y4YzNiZWE2YTBlIG91dCBvZiBi b3VuZHM+fSwge2J2X2xlbiA9IDE0MDA1NzI5MzkzMTI0OCwgYnZfdmFsID0gMHgxZmY0IDxBZGRy ZXNzIDB4MWZmNCBvdXQgb2YgYm91bmRzPn0sIHtidl9sZW4gPSAxNDAwNTcxMzg2OTIxMjgsIA0K ICAgICAgICAgICAgICBidl92YWwgPSAweDdmNjE5ODEwNDU4MCAiIn0sIHtidl9sZW4gPSA2MSwg YnZfdmFsID0gMHg3ZjYxOTgxMDQ1NzAgIiJ9LCB7YnZfbGVuID0gODAsIGJ2X3ZhbCA9IDB4N2Y4 YzNiZWE2ZGQ1IDxBZGRyZXNzIDB4N2Y4YzNiZWE2ZGQ1IG91dCBvZiBib3VuZHM+fSwgew0KICAg ICAgICAgICAgICBidl9sZW4gPSAxNDAyNDAyODA1OTYwOTYsIGJ2X3ZhbCA9IDB4OGEgPEFkZHJl c3MgMHg4YSBvdXQgb2YgYm91bmRzPn0sIHtidl9sZW4gPSAwLCBidl92YWwgPSAweDk4MTAyOTQw IDxBZGRyZXNzIDB4OTgxMDI5NDAgb3V0IG9mIGJvdW5kcz59LCB7YnZfbGVuID0gMTQwMDU3Mjkz OTMxNjE2LCANCiAgICAgICAgICAgICAgYnZfdmFsID0gMHhmZmZmZmZmZiA8QWRkcmVzcyAweGZm ZmZmZmZmIG91dCBvZiBib3VuZHM+fSwge2J2X2xlbiA9IDExLCBidl92YWwgPSAweDk4MTAyOTQw IDxBZGRyZXNzIDB4OTgxMDI5NDAgb3V0IG9mIGJvdW5kcz59LCB7YnZfbGVuID0gMCwgDQogICAg ICAgICAgICAgIGJ2X3ZhbCA9IDB4ZmZmZmZmZmYgPEFkZHJlc3MgMHhmZmZmZmZmZiBvdXQgb2Yg Ym91bmRzPn0sIHtidl9sZW4gPSAxMSwgYnZfdmFsID0gMHg3ZjYxOTgxMDI5NDAgIngifSwge2J2 X2xlbiA9IDIxLCANCiAgICAgICAgICAgICAgYnZfdmFsID0gMHhmZmZmZmZmZiA8QWRkcmVzcyAw eGZmZmZmZmZmIG91dCBvZiBib3VuZHM+fSwge2J2X2xlbiA9IDExLCBidl92YWwgPSAweGZmZmZm ZmZmZmZmZmZmYTggPEFkZHJlc3MgMHhmZmZmZmZmZmZmZmZmZmE4IG91dCBvZiBib3VuZHM+fSwg ew0KICAgICAgICAgICAgICBidl9sZW4gPSAxNDAwNTcyOTM5MzE2OTYsIGJ2X3ZhbCA9IDB4N2Y4 YzNiZjBmZWFkIDxBZGRyZXNzIDB4N2Y4YzNiZjBmZWFkIG91dCBvZiBib3VuZHM+fSwge2J2X2xl biA9IDQyOTUwMzI4MzQsIA0KICAgICAgICAgICAgICBidl92YWwgPSAweDUyZGE2ZCAiJ3JlcVJl ZmVycmFsJyBERVNDICdSZWZlcnJhbHMgcmV0dXJuZWQgZm9yIHJlcXVlc3QnIFNVUCBsYWJlbGVk VVJJICkifSwge2J2X2xlbiA9IDE0NjAyODg4ODA5OCwgDQogICAgICAgICAgICAgIGJ2X3ZhbCA9 IDB4OTAwMDAwMDBmIDxBZGRyZXNzIDB4OTAwMDAwMDBmIG91dCBvZiBib3VuZHM+fSwge2J2X2xl biA9IDQ5MzkyMTIzOTA0NiwgYnZfdmFsID0gMHhiZDAwMDAwMDA0IDxBZGRyZXNzIDB4YmQwMDAw MDAwNCBvdXQgb2YgYm91bmRzPn0sIHtidl9sZW4gPSAxLCANCiAgICAgICAgICAgICAgYnZfdmFs ID0gMHgxYzIwIDxBZGRyZXNzIDB4MWMyMCBvdXQgb2YgYm91bmRzPn0sIHtidl9sZW4gPSAxODU4 Nzc3NiwgYnZfdmFsID0gMHgwfSwge2J2X2xlbiA9IDAsIGJ2X3ZhbCA9IDB4MH0sIHtidl9sZW4g PSAwLCBidl92YWwgPSAweDB9LCB7YnZfbGVuID0gMCwgYnZfdmFsID0gMHgwfSwgew0KICAgICAg ICAgICAgICBidl9sZW4gPSAwLCBidl92YWwgPSAweDB9LCB7YnZfbGVuID0gMTQwMDU3MTM5NzU4 NDY0LCBidl92YWwgPSAweDB9LCB7YnZfbGVuID0gMCwgYnZfdmFsID0gMHgzYyA8QWRkcmVzcyAw eDNjIG91dCBvZiBib3VuZHM+fSwge2J2X2xlbiA9IDE0MDA1NzEzOTc1ODQ2NCwgDQogICAgICAg ICAgICAgIGJ2X3ZhbCA9IDB4NTU5ZTc4NmEgPEFkZHJlc3MgMHg1NTllNzg2YSBvdXQgb2YgYm91 bmRzPn0sIHtidl9sZW4gPSA0MiwgYnZfdmFsID0gMHg3ZjYxYTE0MGU2NzAgIlwzMjBcMzUwQFwy NDFhXDE3NyJ9LCB7YnZfbGVuID0gMTQwMDU3MTM4Njk1NDI0LCANCiAgICAgICAgICAgICAgYnZf dmFsID0gMHhiIDxBZGRyZXNzIDB4YiBvdXQgb2YgYm91bmRzPn0sIHtidl9sZW4gPSAxNDAwNTcx Mzg2OTU0MjQsIGJ2X3ZhbCA9IDB4N2Y2MTk4MDAwY2EwICI5In0sIHtidl9sZW4gPSAxNDAwNTcx Mzk3NTEyMzIsIGJ2X3ZhbCA9IDB4N2Y2MWExNDBjYjkwICJcMDIwICJ9LCB7DQogICAgICAgICAg ICAgIGJ2X2xlbiA9IDYsIGJ2X3ZhbCA9IDB4N2Y2MWExNDBjYmEwICJcMDIwICJ9LCB7YnZfbGVu ID0gMTQwMjQwMjc4MjY2NTY5LCBidl92YWwgPSAweDdmOGMzYmU2ZjQ2NyA8QWRkcmVzcyAweDdm OGMzYmU2ZjQ2NyBvdXQgb2YgYm91bmRzPn0sIHtidl9sZW4gPSAxNDAyNDAyNzgyNjY1NzAsIA0K ICAgICAgICAgICAgICBidl92YWwgPSAweDEgPEFkZHJlc3MgMHgxIG91dCBvZiBib3VuZHM+fSwg e2J2X2xlbiA9IDEsIGJ2X3ZhbCA9IDB4MH0sIHtidl9sZW4gPSAwLCBidl92YWwgPSAweDB9LCB7 YnZfbGVuID0gNDgsIA0KICAgICAgICAgICAgICBidl92YWwgPSAweDEwY2EyZGM5MiA8QWRkcmVz cyAweDEwY2EyZGM5MiBvdXQgb2YgYm91bmRzPn0sIHtidl9sZW4gPSAxNDAwNTcyOTM5MzMxODQs IGJ2X3ZhbCA9IDB4N2Y2MTk4MTA0NWUwICIifSwge2J2X2xlbiA9IDE0MDI0MDI3ODI2NjU2Niwg DQogICAgICAgICAgICAgIGJ2X3ZhbCA9IDB4N2Y2MWExNDBlNWUwICJcMjAwXDI0MFwwMzNcMDAx In0sIHtidl9sZW4gPSAxNDAwNTcxMzg2OTU0MjQsIGJ2X3ZhbCA9IDB4MH0sIHtidl9sZW4gPSAx NDAwNTcyOTM5MzMyOTIsIGJ2X3ZhbCA9IDB4N2Y2MWExNDBjYjA4ICJcMjI2XDMxM0BcMjQxYVwx NzcifSwgew0KICAgICAgICAgICAgICBidl9sZW4gPSAxNDAwNTcxMzk3NTEyMzIsIGJ2X3ZhbCA9 IDB4N2Y2MWExNDBjYzQwICJQXDMzMUBcMjQxYVwxNzcifSwge2J2X2xlbiA9IDYsIGJ2X3ZhbCA9 IDB4N2Y2MWExNDBjYzUwICI4XDMzMUBcMjQxYVwxNzcifSwge2J2X2xlbiA9IDE0MDI0MDI3ODI2 NjU2OSwgDQogICAgICAgICAgICAgIGJ2X3ZhbCA9IDB4N2Y4YzNiZTZmNDY3IDxBZGRyZXNzIDB4 N2Y4YzNiZTZmNDY3IG91dCBvZiBib3VuZHM+fSwge2J2X2xlbiA9IDE0MDI0MDI3ODI2NjU3MCwg YnZfdmFsID0gMHgxIDxBZGRyZXNzIDB4MSBvdXQgb2YgYm91bmRzPn0sIHtidl9sZW4gPSAxLCAN CiAgICAgICAgICAgICAgYnZfdmFsID0gMHg3ZjYxYTE0MGNkODAgIiAifSwge2J2X2xlbiA9IDUz MDc2MDMsIGJ2X3ZhbCA9IDB4N2Y4YzNiZTZmNDY3IDxBZGRyZXNzIDB4N2Y4YzNiZTZmNDY3IG91 dCBvZiBib3VuZHM+fSwge2J2X2xlbiA9IDUzMDc2MDQsIA0KICAgICAgICAgICAgICBidl92YWwg PSAweDEgPEFkZHJlc3MgMHgxIG91dCBvZiBib3VuZHM+fSwge2J2X2xlbiA9IDE0MDA1NzI5Mzkz MzM2MCwgYnZfdmFsID0gMHg3ZjYxYTE0MGNhNTggIlwzNDZcMzEyQFwyNDFhXDE3NyJ9LCB7YnZf bGVuID0gMTQwMjQwMjc4MjY2NTY2LCANCiAgICAgICAgICAgICAgYnZfdmFsID0gMHgyMCA8QWRk cmVzcyAweDIwIG91dCBvZiBib3VuZHM+fSwge2J2X2xlbiA9IDAsIGJ2X3ZhbCA9IDB4MH0sIHti dl9sZW4gPSAxNDAwNTcyOTM5MzM0NjgsIGJ2X3ZhbCA9IDB4N2Y2MWExNDBjYmI4ICIhVk0ifSwg e2J2X2xlbiA9IDUzMDc1NzksIA0KICAgICAgICAgICAgICBidl92YWwgPSAweDdmNjFhMTQwY2Jk OCAiXDMyNFwzNjJFIn0sIHtidl9sZW4gPSAxNDAwNTcyOTM5MzMwNTYsIGJ2X3ZhbCA9IDB4MH0s IHtidl9sZW4gPSAxNDAwNTcyOTM5MzM1MTYsIA0KICAgICAgICAgICAgICBidl92YWwgPSAweDdm OGMzYmU5Zjk1ZSA8QWRkcmVzcyAweDdmOGMzYmU5Zjk1ZSBvdXQgb2YgYm91bmRzPn0sIHtidl9s ZW4gPSAxNDAwNTcxMzk3NTEyMzIsIGJ2X3ZhbCA9IDB4N2Y2MWExNDBjZDIwICIwXDMxNkBcMjQx YVwxNzcifSwge2J2X2xlbiA9IDU5LCANCiAgICAgICAgICAgICAgYnZfdmFsID0gMHg3ZjYxYTE0 MGNlMzAgIigifSwge2J2X2xlbiA9IDUzMDk2MDIsIGJ2X3ZhbCA9IDB4N2Y4YzNiZTZmNDY3IDxB ZGRyZXNzIDB4N2Y4YzNiZTZmNDY3IG91dCBvZiBib3VuZHM+fSwge2J2X2xlbiA9IDUzMDk2MDMs IA0KICAgICAgICAgICAgICBidl92YWwgPSAweDEgPEFkZHJlc3MgMHgxIG91dCBvZiBib3VuZHM+ fSwge2J2X2xlbiA9IDEsIGJ2X3ZhbCA9IDB4N2Y2MWExNDBjYjA4ICJcMjI2XDMxM0BcMjQxYVwx NzcifSwge2J2X2xlbiA9IDAsIA0KICAgICAgICAgICAgICBidl92YWwgPSAweDdmNjEwMDAwMDAy MCA8QWRkcmVzcyAweDdmNjEwMDAwMDAyMCBvdXQgb2YgYm91bmRzPn0sIHtidl9sZW4gPSAwLCBi dl92YWwgPSAweDB9LCB7YnZfbGVuID0gMTQwMDU3MjkzOTMzNTg0LCANCiAgICAgICAgICAgICAg YnZfdmFsID0gMHhhMDAwMDA5YWYgPEFkZHJlc3MgMHhhMDAwMDA5YWYgb3V0IG9mIGJvdW5kcz59 LCB7YnZfbGVuID0gNTMwOTU2MCwgYnZfdmFsID0gMHgyMCA8QWRkcmVzcyAweDIwIG91dCBvZiBi b3VuZHM+fSwge2J2X2xlbiA9IDE0MDA1NzI5MzkzMzMxNSwgYnZfdmFsID0gMHgwfSwgew0KICAg ICAgICAgICAgICBidl9sZW4gPSAxNDAwNTcyOTM5MzM2OTIsIGJ2X3ZhbCA9IDB4N2Y2MWExNDBj Yzk4ICIhVk0ifSwge2J2X2xlbiA9IDAsIGJ2X3ZhbCA9IDB4N2Y2MWExNDBjY2I4ICJcMzI0XDM2 MkUifSwge2J2X2xlbiA9IDE0MDA1NDU4ODU1NTI2NCwgYnZfdmFsID0gMHgwfSwgew0KICAgICAg ICAgICAgICBidl9sZW4gPSAxNDAyNDAyNzgyNjY1NjcsIGJ2X3ZhbCA9IDB4ZmZmZmZmZmYgPEFk ZHJlc3MgMHhmZmZmZmZmZiBvdXQgb2YgYm91bmRzPn0sIHtidl9sZW4gPSAwLCBidl92YWwgPSAw eGJhMTQwY2IzOCA8QWRkcmVzcyAweGJhMTQwY2IzOCBvdXQgb2YgYm91bmRzPn0sIHsNCiAgICAg ICAgICAgICAgYnZfbGVuID0gMTE1LCBidl92YWwgPSAweDdmNjFhMTQwYzgwMCAiIn0sIHtidl9s ZW4gPSAxODQ0Njc0NDA3MzcwOTU1MTYxNSwgYnZfdmFsID0gMHg3ZjYxYTE0MGNjNzAgIiAifSwg e2J2X2xlbiA9IDAsIA0KICAgICAgICAgICAgICBidl92YWwgPSAweGIwMDAwMDAwMCA8QWRkcmVz cyAweGIwMDAwMDAwMCBvdXQgb2YgYm91bmRzPn0sIHtidl9sZW4gPSAwLCBidl92YWwgPSAweDdm NjFhMTQwY2JlOCAiXDMxNFwzMzJFIn0sIHtidl9sZW4gPSAwLCBidl92YWwgPSAweDIwIDxBZGRy ZXNzIDB4MjAgb3V0IG9mIGJvdW5kcz59LCB7DQogICAgICAgICAgICAgIGJ2X2xlbiA9IDAsIGJ2 X3ZhbCA9IDB4MH0sIHtidl9sZW4gPSAwLCBidl92YWwgPSAweDlhZiA8QWRkcmVzcyAweDlhZiBv dXQgb2YgYm91bmRzPn0sIHtidl9sZW4gPSAwLCBidl92YWwgPSAweDB9LCB7YnZfbGVuID0gMTQw MDU0NTg4NTU1MjY0LCANCiAgICAgICAgICAgICAgYnZfdmFsID0gMHgyMDAwMDAwMDAgPEFkZHJl c3MgMHgyMDAwMDAwMDAgb3V0IG9mIGJvdW5kcz59LCB7YnZfbGVuID0gMCwgYnZfdmFsID0gMHg3 ZjYxZmZmZmZmZmYgPEFkZHJlc3MgMHg3ZjYxZmZmZmZmZmYgb3V0IG9mIGJvdW5kcz59LCB7YnZf bGVuID0gMCwgDQogICAgICAgICAgICAgIGJ2X3ZhbCA9IDB4N2Y2MWExNDBjYmU4ICJcMzE0XDMz MkUifSwge2J2X2xlbiA9IDExNSwgYnZfdmFsID0gMHgwfSwge2J2X2xlbiA9IDUzMDk1ODQsIGJ2 X3ZhbCA9IDB4MH0sIHtidl9sZW4gPSAwLCANCiAgICAgICAgICAgICAgYnZfdmFsID0gMHhiMDAw MDAwMDAgPEFkZHJlc3MgMHhiMDAwMDAwMDAgb3V0IG9mIGJvdW5kcz59LCB7YnZfbGVuID0gMCwg YnZfdmFsID0gMHgwfSA8cmVwZWF0cyAxMiB0aW1lcz4sIHtidl9sZW4gPSAyNCwgYnZfdmFsID0g MHg3ZjYxYTE0MGM5NDAgIiJ9LCB7DQogICAgICAgICAgICAgIGJ2X2xlbiA9IDE0MDA1NzI5Mzkz Mjc4NCwgYnZfdmFsID0gMHgwfSwge2J2X2xlbiA9IDI0LCBidl92YWwgPSAweDdmNjFhMTQwYzk2 MCAiIn0sIHtidl9sZW4gPSAxNDAwNTcyOTM5MzI4MTYsIGJ2X3ZhbCA9IDB4MH0sIHtidl9sZW4g PSAxNDAyMzk4NzYyNTI3NTIsIGJ2X3ZhbCA9IDB4MH0sIHsNCiAgICAgICAgICAgICAgYnZfbGVu ID0gMCwgYnZfdmFsID0gMHgwfSwge2J2X2xlbiA9IDIwNTAsIGJ2X3ZhbCA9IDB4MTMgPEFkZHJl c3MgMHgxMyBvdXQgb2YgYm91bmRzPn0uLi59fQ0KICAgICAgICBtY2kgPSAweDdmOGMzYmY4MjJj Mw0KICAgICAgICBtY2QgPSAweDMwMDAwMDAwMTANCiAgICAgICAgb3BpbmZvID0ge21vaV9vZSA9 IHtvZV9uZXh0ID0ge3NsZV9uZXh0ID0gMHg3ZjYxOTgwMDIwNjh9LCBvZV9rZXkgPSAweDB9LCBt b2lfdHhuID0gMHgwLCBtb2lfcmVmID0gMCwgbW9pX2ZsYWcgPSAwICdcMDAwJ30NCiAgICAgICAg bW9pID0gMHgxMDAwMDAwMDENCiAgICAgICAgbHRpZCA9IDx2YWx1ZSBvcHRpbWl6ZWQgb3V0Pg0K IzIgIDB4MDAwMDAwMDAwMDAwMDAwMCBpbiA/PyAoKQ0KTm8gc3ltYm9sIHRhYmxlIGluZm8gYXZh aWxhYmxlLg0KDQotLS0tLU1lc3NhZ2UgZCdvcmlnaW5lLS0tLS0NCkRlwqA6IExBUlJJRVUtTUFO QU4sIFJpY2hhcmQgDQpFbnZvecOpwqA6IHZlbmRyZWRpIDEwIGp1aWxsZXQgMjAxNSAxMTozOQ0K w4DCoDogSG93YXJkIENodTsgb3BlbmxkYXAtaXRzQE9wZW5MREFQLm9yZw0KQ2PCoDogQnJvY2hh cmQsIEx1ZG92aWM7IFZBU1NBVVgsIFBhc2NhbA0KT2JqZXTCoDogUkU6IChJVFMjODE5NCkgU2Vy dmljZSBzbGFwZCBmYWxsZG93biBpbiBhIHNlYXJjaCB3aXRoIGNsaWVudCBsZGFwc2VhcmNoDQoN CkhlbGxvLA0KDQpCZWxvdyB0aGUgY29yZSBkdW1wIGxvZ3MgOg0KQ29yZSB3YXMgZ2VuZXJhdGVk IGJ5IGAvb3B0L29wZW5sZGFwL2xpYmV4ZWMvc2xhcGQgLWggbGRhcDovLzAuMC4wLjA6Mzg5IGxk YXBpOi8vJTJmdmFyJTJmcnVuJTJmc2xhcGQlJy4NClByb2dyYW0gdGVybWluYXRlZCB3aXRoIHNp Z25hbCAxMSwgU2VnbWVudGF0aW9uIGZhdWx0Lg0KIzAgIDB4MDAwMDAwMDAwMDQ5ZTI1MSBpbiBt ZGJfaGFzU3Vib3JkaW5hdGVzIChvcD0weDdmNjFhMTQwZDQ2MCwgZT08dmFsdWUgb3B0aW1pemVk IG91dD4sIGhhc1N1Ym9yZGluYXRlcz0weDdmNjFhMDkwZTAxMCkgYXQgb3BlcmF0aW9uYWwuYzo3 OA0KNzggICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgTERBUF9TTElT VF9SRU1PVkUoICZvcC0+b19leHRyYSwgJm1vaS0+bW9pX29lLCBPcEV4dHJhLCBvZV9uZXh0ICk7 DQooZ2RiKSBidA0KIzAgIDB4MDAwMDAwMDAwMDQ5ZTI1MSBpbiBtZGJfaGFzU3Vib3JkaW5hdGVz IChvcD0weDdmNjFhMTQwZDQ2MCwgZT08dmFsdWUgb3B0aW1pemVkIG91dD4sIGhhc1N1Ym9yZGlu YXRlcz0weDdmNjFhMDkwZTAxMCkgYXQgb3BlcmF0aW9uYWwuYzo3OA0KIzEgIDB4MDAwMDAwMDAw MDRhMDhhYyBpbiBtZGJfc2VhcmNoIChvcD0weDdmNjFhMTQwZWEzMCwgcnM9PHZhbHVlIG9wdGlt aXplZCBvdXQ+KSBhdCBzZWFyY2guYzo5NTANCiMyICAweDAwMDAwMDAwMDAwMDAwMDAgaW4gPz8g KCkNCg0KQmVsb3cgc2xhcGQuY29uZiBmaWxlIDoNCiMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMj IyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMj DQojIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMj IyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIw0KIyBDb25maWd1cmF0aW9uIGNvbW11bmUNCg0K IyBTY2hlbWEgYW5kIG9iamVjdENsYXNzIGRlZmluaXRpb25zDQppbmNsdWRlICAgICAgICAgL2Fw cGxpL2xkYXAvY29uZi9zY2hlbWEvY29yZS5zY2hlbWENCmluY2x1ZGUgICAgICAgICAvYXBwbGkv bGRhcC9jb25mL3NjaGVtYS9jb3NpbmUuc2NoZW1hDQppbmNsdWRlICAgICAgICAgL2FwcGxpL2xk YXAvY29uZi9zY2hlbWEvbmlzLnNjaGVtYQ0KaW5jbHVkZSAgICAgICAgIC9hcHBsaS9sZGFwL2Nv bmYvc2NoZW1hL2luZXRvcmdwZXJzb24uc2NoZW1hDQoNCiMgU2NoZW1hIGRlIGwgYW5udWFpcmUg ZGVmaW5pIGRhbnMgbGUgU0RFVCBkZXMgRU5UDQppbmNsdWRlICAgICAgICAgL2FwcGxpL2xkYXAv Y29uZi9zY2hlbWEvc2RldC5zY2hlbWENCmluY2x1ZGUgICAgICAgICAvYXBwbGkvbGRhcC9jb25m L3NjaGVtYS9lbnQuc2NoZW1hDQoNCiMgV2hlcmUgdGhlIHBpZCBmaWxlIGlzIHB1dC4gVGhlIGlu aXQuZCBzY3JpcHQgIyB3aWxsIG5vdCBzdG9wIHRoZSBzZXJ2ZXIgaWYgeW91IGNoYW5nZSB0aGlz Lg0KcGlkZmlsZSAgICAgICAgIC9hcHBsaS9sZGFwL3RtcC9zbGFwZC5waWQNCg0KIyBMaXN0IG9m IGFyZ3VtZW50cyB0aGF0IHdlcmUgcGFzc2VkIHRvIHRoZSBzZXJ2ZXINCmFyZ3NmaWxlICAgICAg ICAvYXBwbGkvbGRhcC90bXAvc2xhcGQuYXJncw0KDQojIFJlYWQgc2xhcGQuY29uZig1KSBmb3Ig cG9zc2libGUgdmFsdWVzDQpsb2dsZXZlbAlzdGF0cyBzeW5jDQpsb2dmaWxlICAgICAgICAgL2Fw cGxpL2xkYXAvbG9ncy9zbGRhcC5sb2cNCg0KIyBXaGVyZSB0aGUgZHluYW1pY2FsbHkgbG9hZGVk IG1vZHVsZXMgYXJlIHN0b3JlZCAjIE5vIG1vZHVsZSBpcyBuZWVkZWQgOiB0aGVyZSBhcmUgc3Rh dGljYWxseSBsb2FkZWQNCg0KU2VydmVySUQJMDAxDQoNCiMgVGhlIHRvb2wtdGhyZWFkcyBwYXJh bWV0ZXIgc2V0cyB0aGUgYWN0dWFsIGFtb3VudCBvZiBjcHUncyB0aGF0IGlzIHVzZWQgZm9yIGlu ZGV4aW5nLg0KdG9vbC10aHJlYWRzIDMNCnRocmVhZHMgMTYNCmNvbmN1cnJlbmN5IDE2DQoNCiNj b25uX21heF9wZW5kaW5nIDEwMDANCiNjb25uX21heF9wZW5kaW5nX2F1dGggMTAwMDANCg0KYmFj a2VuZCAgICAgICAgIG1kYg0KDQojIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMj IyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIw0KIyBDb25maWd1 cmF0aW9uIGR1IGJhY2stZW5kDQojIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMj IyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIw0KIyBEYXRhYmFz ZSBFTlQgDQpkYXRhYmFzZSAgICAgICAgbWRiDQoNCiMgVGhlIGJhc2Ugb2YgeW91ciBkaXJlY3Rv cnkgaW4gZGF0YWJhc2UgIzENCnN1ZmZpeCAgICAgICAgICAiZGM9ZW50LGRjPWZyIg0KZGlyZWN0 b3J5ICAgICAgIC9hcHBsaS9sZGFwL2RhdGEvc2xhcGQNCnJvb3RkbiAgICAgICAgICAiY249YWRt aW4sb3U9c3lzdGVtLGRjPWVudCxkYz1mciINCnJvb3RwdwkJe01ENX1YWmtTSUtCK1pldDZ1RlEw RnBIS2ZRPT0NCnBhc3N3b3JkLWhhc2ggICB7TUQ1fQ0KDQojIFBhcmFtZXRyZXMgTURCDQptYXhy ZWFkZXJzIDEyNg0KbW9kZSAwNjAwDQojIFNob3VsZCBiZSBtb3JlIHRoYW4gZW5vdWdoLi4uDQpz ZWFyY2hzdGFjayAxNg0KIzMyIEdiIHNob3VsZCBiZSBlbm91Z2guLi4NCiMgU2V0IHRvIDMyIEdv DQptYXhzaXplIDE2MTA2MTI3MzYwMA0KIyBkZWZhdWx0IHZhbHVlcw0KbGFzdG1vZCBUUlVFDQpt YXhkZXJlZmRlcHRoIDE1DQpyZWFkb25seSBGQUxTRQ0Kc3luY191c2Vfc3ViZW50cnkgRkFMU0UN Cg0KIyBBdCBzb21lIHBvaW50LCB0byBnZXQgc29tZSBzdGF0cywgaXQgY291bGQgYmUgaW50ZXJl c3RlZCB0byB0dXJuIHRoaXMgb24gbW9uaXRvcmluZyBGQUxTRQ0KDQojIGVjcml0dXJlIGRpZmbD qXLDqWUNCmRibm9zeW5jIFRSVUUNCiMgZWNyaXR1cmUgdG91cyBsZXMgMTUgbWludXRlcw0KY2hl Y2twb2ludCAwIDE1DQoNCiMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMj IyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjDQojIENvbmZpZ3VyYXRpb24g SU5ERVgNCiMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMj IyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjDQoNCiNHbG9iYXV4DQppbmRleAlvYmplY3RD bGFzcwkJCQkJCWVxDQppbmRleAlhY3RpdmUJCQkJCQkJZXENCmluZGV4CW91CQkJCQkJCWVxDQpp bmRleAljbix1aWQJCQkJCQkJZXENCmluZGV4CXNuCQkJCQkJCXByZXMsc3ViLGVxDQppbmRleAll bnRyeUNTTixlbnRyeVVVSUQgCQkJCQllcQ0KI1BlcnNvbm5lcw0KaW5kZXgJRU5UUGVyc29uSm9p bnR1cmUJCQkJCXN1YixlcQ0KaW5kZXgJRU5UUGVyc29uTG9naW4JCQkJCQllcQ0KaW5kZXgJbWFp bAkJCQkJCQllcQ0KaW5kZXgJc25Ob3JtYWxpc2UJCQkJCQlwcmVzLHN1YixlcQ0KaW5kZXgJRU5U UGVyc29ubmVETgkJCQkJCWVxLHByZXMNCmluZGV4CUVOVFBlcnNvblByb2ZpbHMJCQkJCWVxDQpp bmRleAlFTlRQZXJzb25BbGlhcwkJCQkJCWVxDQppbmRleAlnaXZlbk5hbWVOb3JtYWxpc2UJCQkJ CXN1YixlcQ0KaW5kZXgJRU5UQ29kZUFjdGl2YXRpb25QYXJlbnQJCQkJCWVxDQppbmRleAljbk5v cm1hbGlzZQkJCQkJCXByZXMsc3ViLGVxDQppbmRleAlFTlRBdXhQZXJzb25Jbml0CQkJCQllcQ0K aW5kZXgJRU5URWxldmVTdHJ1Y3RSYXR0YWNoSWQJCQkJCWVxDQppbmRleAlFTlRBdXhQZXJzb25D b21wdGVBQUYJCQkJCWVxDQppbmRleAlFTlRBdXhQZXJzUmVsRWxldmVFbGV2ZQkJCQkJZXENCmlu ZGV4CUVOVFBlcnNvblN0cnVjdFJhdHRhY2gJCQkJCWVxDQppbmRleAlFTlRBdXhPdGhlckV0YWIJ CQkJCQllcQ0KaW5kZXgJRU5UUGVyc29uQ29kZVBvc3RhbAkJCQkJZXENCmluZGV4CUVOVENvZGVB Y3RpdmF0aW9uRWxldmUJCQkJCWVxDQppbmRleAlFTlRBdXhQZXJzb25EZWxldGVEYXRlCQkJCQlw cmVzLGVxDQppbmRleAlFTlRFbGV2ZUNsYXNzZXMJCQkJCQllcQ0KaW5kZXgJRU5URWxldmVNRUYJ CQkJCQllcQ0KaW5kZXgJRU5UR3JvdXBlQW5udWFpcmVGaWxpZXJlCQkJCWVxDQppbmRleAl1c2Vy UGFzc3dvcmQJCQkJCQllcQ0KI2luZGV4CUVOVFBlcnNvbk5vbVBhdHJvCQkJCQllcQ0KaW5kZXgJ Z2l2ZW5OYW1lCQkJCQkJcHJlcyxzdWIsZXENCmluZGV4ICAgRU5URWxldmVSZWxhdGlvblZhbGlk ZWUgICAgICAgICAgICAgCQkJZXEgDQoNCiNTdHJ1Y3R1cmVzDQppbmRleAlFTlRTdHJ1Y3R1cmVK b2ludHVyZQkJCQkJZXENCmluZGV4CUVOVFBvcnRldXJDb2RlCQkJCQkJZXENCmluZGV4CUVOVEV0 YWJsaXNzZW1lbnRTdHJ1Y3RSYXR0YWNoRmN0bAkJCWVxDQppbmRleAlFTlRTdHJ1Y3R1cmVOb21D b3VyYW50CQkJCQlwcmVzLHN1YixlcQ0KaW5kZXggICBFTlRTdHJ1Y3R1cmVVQUkJCQkJCQllcSAN CiNHcm91cGVzDQppbmRleAlkZXNjcmlwdGlvbgkJCQkJCXByZXMsc3ViLGVxDQppbmRleAlkZXNj cmlwdGlvbk5vcm1hbGlzZQkJCQkJcHJlcyxzdWIsZXENCmluZGV4CUVOVEdyb3VwZUFubnVhaXJl VGl0cmVOb3JtYWxpc2UJCQkJcHJlcyxzdWIsZXENCmluZGV4CW1lbWJlcgkJCQkJCQlwcmVzLGVx DQppbmRleAlvd25lcgkJCQkJCQllcQ0KaW5kZXgJRU5UR3JvdXBlQWRtaW5Mb2NhbAkJCQkJZXEN CmluZGV4CUVOVFByb2ZpbEROCQkJCQkJcHJlcyxlcQ0KaW5kZXgJRU5UUmVmZXJlbnRpZWxDb2Rl CQkJCQllcQ0KaW5kZXgJRU5UR3JvdXBlQW5udWFpcmVGb25jdGlvbgkJCQlwcmVzLGVxDQppbmRl eAlFTlRHcm91cGVBbm51YWlyZUNsYXNzZUlkCQkJCWVxDQppbmRleAlFTlRHcm91cGVBbm51YWly ZVR5cGUJCQkJCWVxDQppbmRleAlFTlRHcm91cGVBbm51YWlyZU1lZklkCQkJCQllcQ0KaW5kZXgJ RU5UR3JvdXBlQW5udWFpcmVGaWxpZXJlSWQJCQkJZXENCmluZGV4CUVOVERpc2NpcGxpbmVETgkJ CQkJCWVxDQppbmRleAlFTlRHcm91cGVBZG1pblBlcmUJCQkJCWVxDQppbmRleAlFTlRGb25jdGlv bkROCQkJCQkJZXENCmluZGV4CUVOVENsYXNzZUROCQkJCQkJZXENCmluZGV4CUVOVEdyb3VwZUFu bnVhaXJlQ2xhc3NlCQkJCQlwcmVzLGVxDQppbmRleAlFTlRBZG1pbkxvY2FsRXRhYgkJCQkJZXEN CiNTeW5jaHJvIHBvcnRhaWwNCmluZGV4ICAgRU5UU3VpdmlTeW5jaHJvRWZmZWN0dWVlCQkJCWVx IA0KIyBOZXcgQU1FVSAyMDEzMDgyNw0KaW5kZXggICBFTlRHcm91cGVBZG1pbkxpZW5Hcm91cGVB bm51YWlyZVBhcnRlbmFyaWF0ICAgICAgICAgICAgIGVxDQppbmRleCAgIEVOVFBlcnNvbkZvbmN0 aW9ucyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgZXENCmluZGV4ICAgRU5U R3JvdXBlQW5udWFpcmVHcm91cGVFbnNlaWduZW1lbnQgICAgICAgICAgICAgICAgICAgICBlcQ0K aW5kZXggICBFTlRQZXJzb25Ob21QYXRybyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgIHByZXMsc3ViLGVxDQppbmRleCAgIEVOVFN0cnVjdHVyZUFjYWRlbWllICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgZXENCmluZGV4ICAgRU5UU3RydWN0dXJlQ29tbXVu ZSAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBlcQ0KaW5kZXggICBFTlRHcm91 cGVBZG1pbkxpZW5Hcm91cGVBbm51YWlyZSAgICAgICAgICAgICAgICAgICAgICAgIGVxDQojIE5l dyBSTEFSIDIwMTMwOTA0DQppbmRleCAgIEVOVEdyb3VwZUFubnVhaXJlRm9uY3Rpb25JZCAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgZXENCiMgTmV3IDIwMTMwOTE0IMOgIDIwaDAwDQppbmRl eAlFTlRBdXhQZXJzb25FdGFiQWNjZXMgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg IGVxDQojIE5ldyAyMDEzMDkxNyDDoCAxN2gzOCBjb25mY2FsbCBTZXJnZXMgQmFyYm9zYSAvIFBy b2PDqGR1cmUgZXhwb3J0IGRlIGpldSBkZSBkb25uw6llcw0KaW5kZXggICBtb2RpZnlUaW1lc3Rh bXAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIGVxDQoNCiMgVE1BLTg1 ODUgMDQvMTEvMjAxMw0KaW5kZXggICBFTlRHcm91cGVBbm51YWlyZU1lZiAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgIGVxDQppbmRleCAgIEVOVENvZGVBY3RpdmF0aW9uQ29kZSAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgZXENCmluZGV4ICAgRU5URWxldmVQYXJl bnRzICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBlcQ0KDQojMi4xLjFS QzQNCmluZGV4ICAgRU5UQWRtaW5Mb2NhbENyZWF0ZXVyICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICBlcQ0KDQoNCiMgU2F2ZSB0aGUgdGltZSB0aGF0IHRoZSBlbnRyeSBnZXRzIG1v ZGlmaWVkLCBmb3IgZGF0YWJhc2UgIzENCmxhc3Rtb2QgICAgICAgICBvbg0KDQojIFRoZSBhZG1p biBkbiBoYXMgZnVsbCB3cml0ZSBhY2Nlc3MsIGV2ZXJ5b25lIGVsc2UgIyBjYW4gcmVhZCBldmVy eXRoaW5nLg0KYWNjZXNzIHRvICoNCiAgICAgICAgYnkgKiByZWFkDQoNCiMjIyMjIyMjIyMjIyMj IyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMj IyMjIyMjIyMNCiMgQ29uZmlndXJhdGlvbiBTWU5DSFJPDQojIyMjIyMjIyMjIyMjIyMjIyMjIyMj IyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMj Iw0KDQojIE1VTFRJIE1BU1RFUiBFTiBTRSBTWU5DSFJPTklTQU5UIEFWRUMgTEUgTERBUDAyIFRQ ICMgc3luY3JlcGwgcmlkPTIwMQ0KCXByb3ZpZGVyPWxkYXA6Ly9sZGFwcDAyOjM4OQ0KCXR5cGU9 cmVmcmVzaEFuZFBlcnNpc3QNCglyZXRyeT0iNSA1IDMwMCArIg0KCXNlYXJjaGJhc2U9ImRjPWVu dCxkYz1mciINCglhdHRycz0iKiwrIg0KCWJpbmRtZXRob2Q9c2ltcGxlDQoJYmluZGRuPSJjbj1h ZG1pbixvdT1zeXN0ZW0sZGM9ZW50LGRjPWZyIg0KCWNyZWRlbnRpYWxzPWp1bmdsZQ0KCWxvZ2Jh c2U9ImNuPWRlbHRhLXN5bmMiDQoJbG9nZmlsdGVyPSIoJihvYmplY3RDbGFzcz1hdWRpdFdyaXRl T2JqZWN0KShyZXFSZXN1bHQ9MCkpIg0KCXN5bmNkYXRhPWFjY2Vzc2xvZw0KDQptaXJyb3Jtb2Rl IG9uDQoNCiMgT3ZlcmxheSBjb25maWd1cmF0aW9uIHNob3VsZCBiZSBhZGRlZCBhZnRlciB0aGUg ZGF0YWJhc2UgY29uZmlndXJhdGlvbiAjIETDqWZpbml0aW9uIGRlIGwnb3ZlcmxheSBsacOpIMOg IGxhIHLDqXBsaWNhdGlvbiBtYWl0cmUgb3ZlcmxheSBzeW5jcHJvdg0KDQpzeW5jcHJvdi1jaGVj a3BvaW50IDEwMCAxMA0KIyBEw6lmaW5pdGlvbiBkZSBsJ292ZXJsYXkgbGnDqSDDoCBsYSByw6lw bGljYXRpb24gbWFpdHJlIGVuIGRlbHRhLXN5bmMgb3ZlcmxheSBhY2Nlc3Nsb2cgbG9nZGIgImNu PWRlbHRhLXN5bmMiDQpsb2dvcHMgd3JpdGVzDQpsb2dzdWNjZXNzIFRSVUUNCmxvZ3B1cmdlIDMr MDA6MDAgMSswMDowMA0KDQojIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMj IyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIw0KIyBDb25maWd1cmF0aW9u IGRlIGzigJlhY2Nlc3Nsb2cNCiMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMj IyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjDQojIERhdGFiYXNlIGRl bHRhLXN5bmMgOg0KZGF0YWJhc2UgbWRiDQpzdWZmaXggImNuPWRlbHRhLXN5bmMiDQpkaXJlY3Rv cnkgL2FwcGxpL2xkYXAvZGF0YS9jbj1kZWx0YS1zeW5jIHJvb3RkbiAiY249YWRtaW4sb3U9c3lz dGVtLGRjPWVudCxkYz1mciINCg0KI1NvbWUgb3B0aW9ucyB0byBvcHRpbWl6ZSBhY2Nlc2xvZyA6 DQppbmRleCBkZWZhdWx0LHJlcUROIGVxDQppbmRleCBlbnRyeUNTTixvYmplY3RDbGFzcyxyZXFF bmQscmVxUmVzdWx0LHJlcVN0YXJ0IGVxDQoNCiNQYXJhbWV0cmVzIE1EQg0KbWF4cmVhZGVycyAx MjYNCm1vZGUgMDYwMA0Kc2VhcmNoc3RhY2sgMTYNCiMgc2V0IHRvIDEwIEdvDQptYXhzaXplIDIx NDc0ODM2NDgwDQpsYXN0bW9kIFRSVUUNCm1heGRlcmVmZGVwdGggMTUNCnJlYWRvbmx5IEZBTFNF DQpkYm5vc3luYyBUUlVFDQpjaGVja3BvaW50IDAgMTUNCg0Kb3ZlcmxheSBzeW5jcHJvdg0Kc3lu Y3Byb3Ytbm9wcmVzZW50IFRSVUUNCnN5bmNwcm92LXJlbG9hZGhpbnQgVFJVRQ0KDQoNCi0tLS0t TWVzc2FnZSBkJ29yaWdpbmUtLS0tLQ0KRGXCoDogSG93YXJkIENodSBbbWFpbHRvOmh5Y0BzeW1h cy5jb21dDQpFbnZvecOpwqA6IGpldWRpIDkganVpbGxldCAyMDE1IDE3OjEzDQrDgMKgOiBMQVJS SUVVLU1BTkFOLCBSaWNoYXJkOyBvcGVubGRhcC1pdHNAT3BlbkxEQVAub3JnIE9iamV0wqA6IFJl OiAoSVRTIzgxOTQpIFNlcnZpY2Ugc2xhcGQgZmFsbGRvd24gaW4gYSBzZWFyY2ggd2l0aCBjbGll bnQgbGRhcHNlYXJjaA0KDQpyaWNoYXJkLmxhcnJpZXUtbWFuYW5AY2dpLmNvbSB3cm90ZToNCj4g RnVsbF9OYW1lOiBDR0kgLSBSaWNoYXJkIExhcnJpZXUtTWFuYW4NCj4gVmVyc2lvbjogMi40LjQx DQo+IE9TOiBSZWQgSGF0IDQuNC43LTQNCj4gVVJMOiBmdHA6Ly9mdHAub3BlbmxkYXAub3JnL2lu Y29taW5nL0NHSV8yMDE1MDcwOS5jb3JlLjMzNjA0LnRneg0KPiBTdWJtaXNzaW9uIGZyb206IChO VUxMKSAoMTk1LjYuMTI3LjEwOCkNCj4NCj4NCj4gSGVsbG8sDQo+DQo+IFdoZW4gc2VhcmNoaW5n IGluIHRoZSBkaXJlY3RvcnkgbGRhcCAyLjQuNDEgd2l0aCBsZGFwc2VhcmNoIGNsaWVudCwgMSAN Cj4gb3V0IG9mIDQgbGRhcCBzZXJ2aWNlIGZhbGxkb3duLiBTbyBJIGhhdmUgcHJvdmlkZWQgeW91 IGEgY29yZSBkdW1wDQo+IChmdHA6Ly9mdHAub3BlbmxkYXAub3JnL2luY29taW5nL0NHSV8yMDE1 MDcwOS5jb3JlLjMzNjA0LnRneikgZHVyaW5nIA0KPiB0aGUgYnVnLiBJbg0KPiAyLjQuMzggdmVy c2lvbiBvZiB0aGUgcHJvYmxlbSBkb2VzIG5vdCBhcmlzZS4NCg0KVGhhbmtzIGZvciB0aGUgcmVw b3J0IGJ1dCB3ZSBjYW5ub3QgdXNlIHlvdXIgY29yZSBmaWxlLiBQbGVhc2Ugc2VuZCB5b3VyIHNs YXBkIGNvbmZpZ3VyYXRpb24gYW5kIHRoZSBzdGFjayB0cmFjZSBmcm9tIHRoZSBjb3JlLg0KDQpo dHRwOi8vd3d3Lm9wZW5sZGFwLm9yZy9mYXEvZGF0YS9jYWNoZS81OS5odG1sDQoNCi0tIA0KICAg LS0gSG93YXJkIENodQ0KICAgQ1RPLCBTeW1hcyBDb3JwLiAgICAgICAgICAgaHR0cDovL3d3dy5z eW1hcy5jb20NCiAgIERpcmVjdG9yLCBIaWdobGFuZCBTdW4gICAgIGh0dHA6Ly9oaWdobGFuZHN1 bi5jb20vaHljLw0KICAgQ2hpZWYgQXJjaGl0ZWN0LCBPcGVuTERBUCAgaHR0cDovL3d3dy5vcGVu bGRhcC5vcmcvcHJvamVjdC8NCg==

1 0

RE: (ITS#8194) Service slapd falldown in a search with client ldapsearch
by richard.larrieu-manan＠cgi.com 10 Jul '15

10 Jul '15

Ok. Here is the command line to do the research with the client ldapsearch : /opt/openldap/bin/ldapsearch -xLLL -h ldapp02 -p 389 -D cn=3Dadmin,ou=3Dsys= tem,dc=3Dent,dc=3Dfr -b ou=3Dsupp,ou=3Dpersonnes,ou=3DCRRA,dc=3Dent,dc=3Dfr= -w jungle dn | wc -l After 1 or 2 search the slapd server goes. Thx. -----Message d'origine----- De=A0: Michael Str=F6der [mailto:michael@stroeder.com]=20 Envoy=E9=A0: vendredi 10 juillet 2015 12:35 =C0=A0: LARRIEU-MANAN, Richard; openldap-its(a)OpenLDAP.org Objet=A0: Re: (ITS#8194) Service slapd falldown in a search with client lda= psearch Maybe I missed something but I can't which search requests are causing this= . Could you please also add some information about your ldapsearch commands? Ciao, Michael.

1 0

Re: (ITS#8194) Service slapd falldown in a search with client ldapsearch
by michael＠stroeder.com 10 Jul '15

10 Jul '15

Maybe I missed something but I can't which search requests are causing this. Could you please also add some information about your ldapsearch commands? Ciao, Michael.

1 0

RE: (ITS#8194) Service slapd falldown in a search with client ldapsearch
by richard.larrieu-manan＠cgi.com 10 Jul '15

10 Jul '15

Hello, Below the core dump logs : Core was generated by `/opt/openldap/libexec/slapd -h ldap://0.0.0.0:389 ld= api://%2fvar%2frun%2fslapd%'. Program terminated with signal 11, Segmentation fault. #0 0x000000000049e251 in mdb_hasSubordinates (op=3D0x7f61a140d460, e=3D<va= lue optimized out>, hasSubordinates=3D0x7f61a090e010) at operational.c:78 78 LDAP_SLIST_REMOVE( &op->o_extr= a, &moi->moi_oe, OpExtra, oe_next ); (gdb) bt #0 0x000000000049e251 in mdb_hasSubordinates (op=3D0x7f61a140d460, e=3D<va= lue optimized out>, hasSubordinates=3D0x7f61a090e010) at operational.c:78 #1 0x00000000004a08ac in mdb_search (op=3D0x7f61a140ea30, rs=3D<value opti= mized out>) at search.c:950 #2 0x0000000000000000 in ?? () Below slapd.conf file : ###########################################################################= ######## ###########################################################################= ######## # Configuration commune # Schema and objectClass definitions include /appli/ldap/conf/schema/core.schema include /appli/ldap/conf/schema/cosine.schema include /appli/ldap/conf/schema/nis.schema include /appli/ldap/conf/schema/inetorgperson.schema # Schema de l annuaire defini dans le SDET des ENT include /appli/ldap/conf/schema/sdet.schema include /appli/ldap/conf/schema/ent.schema # Where the pid file is put. The init.d script # will not stop the server if you change this. pidfile /appli/ldap/tmp/slapd.pid # List of arguments that were passed to the server argsfile /appli/ldap/tmp/slapd.args # Read slapd.conf(5) for possible values loglevel stats sync logfile /appli/ldap/logs/sldap.log # Where the dynamically loaded modules are stored # No module is needed : there are statically loaded ServerID 001 # The tool-threads parameter sets the actual amount of cpu's that is used f= or indexing. tool-threads 3 threads 16 concurrency 16 #conn_max_pending 1000 #conn_max_pending_auth 10000 backend mdb ###########################################################################= ######## # Configuration du back-end=20 ###########################################################################= ######## # Database ENT=20 database mdb # The base of your directory in database #1 suffix "dc=3Dent,dc=3Dfr" directory /appli/ldap/data/slapd rootdn "cn=3Dadmin,ou=3Dsystem,dc=3Dent,dc=3Dfr" rootpw {MD5}XZkSIKB+Zet6uFQ0FpHKfQ=3D=3D password-hash {MD5} # Parametres MDB maxreaders 126 mode 0600 # Should be more than enough... searchstack 16 #32 Gb should be enough... # Set to 32 Go maxsize 161061273600 # default values lastmod TRUE maxderefdepth 15 readonly FALSE sync_use_subentry FALSE # At some point, to get some stats, it could be interested to turn this on monitoring FALSE # ecriture diff=E9r=E9e dbnosync TRUE # ecriture tous les 15 minutes checkpoint 0 15 ###########################################################################= ##### # Configuration INDEX ###########################################################################= ##### #Globaux index objectClass eq index active eq index ou eq index cn,uid eq index sn pres,sub,eq index entryCSN,entryUUID eq #Personnes index ENTPersonJointure sub,eq index ENTPersonLogin eq index mail eq index snNormalise pres,sub,eq index ENTPersonneDN eq,pres index ENTPersonProfils eq index ENTPersonAlias eq index givenNameNormalise sub,eq index ENTCodeActivationParent eq index cnNormalise pres,sub,eq index ENTAuxPersonInit eq index ENTEleveStructRattachId eq index ENTAuxPersonCompteAAF eq index ENTAuxPersRelEleveEleve eq index ENTPersonStructRattach eq index ENTAuxOtherEtab eq index ENTPersonCodePostal eq index ENTCodeActivationEleve eq index ENTAuxPersonDeleteDate pres,eq index ENTEleveClasses eq index ENTEleveMEF eq index ENTGroupeAnnuaireFiliere eq index userPassword eq #index ENTPersonNomPatro eq index givenName pres,sub,eq index ENTEleveRelationValidee eq=20 #Structures index ENTStructureJointure eq index ENTPorteurCode eq index ENTEtablissementStructRattachFctl eq index ENTStructureNomCourant pres,sub,eq index ENTStructureUAI eq=20 #Groupes index description pres,sub,eq index descriptionNormalise pres,sub,eq index ENTGroupeAnnuaireTitreNormalise pres,sub,eq index member pres,eq index owner eq index ENTGroupeAdminLocal eq index ENTProfilDN pres,eq index ENTReferentielCode eq index ENTGroupeAnnuaireFonction pres,eq index ENTGroupeAnnuaireClasseId eq index ENTGroupeAnnuaireType eq index ENTGroupeAnnuaireMefId eq index ENTGroupeAnnuaireFiliereId eq index ENTDisciplineDN eq index ENTGroupeAdminPere eq index ENTFonctionDN eq index ENTClasseDN eq index ENTGroupeAnnuaireClasse pres,eq index ENTAdminLocalEtab eq #Synchro portail index ENTSuiviSynchroEffectuee eq=20 # New AMEU 20130827 index ENTGroupeAdminLienGroupeAnnuairePartenariat eq index ENTPersonFonctions eq index ENTGroupeAnnuaireGroupeEnseignement eq index ENTPersonNomPatro pres,sub,eq index ENTStructureAcademie eq index ENTStructureCommune eq index ENTGroupeAdminLienGroupeAnnuaire eq # New RLAR 20130904 index ENTGroupeAnnuaireFonctionId eq # New 20130914 =E0 20h00 index ENTAuxPersonEtabAcces eq # New 20130917 =E0 17h38 confcall Serges Barbosa / Proc=E8dure export de je= u de donn=E9es index modifyTimestamp eq # TMA-8585 04/11/2013 index ENTGroupeAnnuaireMef eq index ENTCodeActivationCode eq index ENTEleveParents eq #2.1.1RC4 index ENTAdminLocalCreateur eq # Save the time that the entry gets modified, for database #1 lastmod on # The admin dn has full write access, everyone else # can read everything. access to * by * read ###########################################################################= #### # Configuration SYNCHRO ###########################################################################= ##### # MULTI MASTER EN SE SYNCHRONISANT AVEC LE LDAP02 TP # syncrepl rid=3D201 provider=3Dldap://ldapp02:389 type=3DrefreshAndPersist retry=3D"5 5 300 +" searchbase=3D"dc=3Dent,dc=3Dfr" attrs=3D"*,+" bindmethod=3Dsimple binddn=3D"cn=3Dadmin,ou=3Dsystem,dc=3Dent,dc=3Dfr" credentials=3Djungle logbase=3D"cn=3Ddelta-sync" logfilter=3D"(&(objectClass=3DauditWriteObject)(reqResult=3D0))" syncdata=3Daccesslog mirrormode on # Overlay configuration should be added after the database configuration # D=E9finition de l'overlay li=E9 =E0 la r=E9plication maitre overlay syncprov syncprov-checkpoint 100 10 # D=E9finition de l'overlay li=E9 =E0 la r=E9plication maitre en delta-sync overlay accesslog logdb "cn=3Ddelta-sync" logops writes logsuccess TRUE logpurge 3+00:00 1+00:00 ###########################################################################= ##### # Configuration de l'accesslog ###########################################################################= ##### # Database delta-sync : database mdb suffix "cn=3Ddelta-sync" directory /appli/ldap/data/cn=3Ddelta-sync rootdn "cn=3Dadmin,ou=3Dsystem,dc=3Dent,dc=3Dfr" #Some options to optimize acceslog : index default,reqDN eq index entryCSN,objectClass,reqEnd,reqResult,reqStart eq #Parametres MDB maxreaders 126 mode 0600 searchstack 16 # set to 10 Go maxsize 21474836480 lastmod TRUE maxderefdepth 15 readonly FALSE dbnosync TRUE checkpoint 0 15 overlay syncprov syncprov-nopresent TRUE syncprov-reloadhint TRUE -----Message d'origine----- De=A0: Howard Chu [mailto:hyc@symas.com]=20 Envoy=E9=A0: jeudi 9 juillet 2015 17:13 =C0=A0: LARRIEU-MANAN, Richard; openldap-its(a)OpenLDAP.org Objet=A0: Re: (ITS#8194) Service slapd falldown in a search with client lda= psearch richard.larrieu-manan(a)cgi.com wrote: > Full_Name: CGI - Richard Larrieu-Manan > Version: 2.4.41 > OS: Red Hat 4.4.7-4 > URL: ftp://ftp.openldap.org/incoming/CGI_20150709.core.33604.tgz > Submission from: (NULL) (195.6.127.108) > > > Hello, > > When searching in the directory ldap 2.4.41 with ldapsearch client, 1=20 > out of 4 ldap service falldown. So I have provided you a core dump > (ftp://ftp.openldap.org/incoming/CGI_20150709.core.33604.tgz) during=20 > the bug. In > 2.4.38 version of the problem does not arise. Thanks for the report but we cannot use your core file. Please send your sl= apd configuration and the stack trace from the core. http://www.openldap.org/faq/data/cache/59.html --=20 -- 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#8173)
by Adrian.Raemy＠vtg.admin.ch 10 Jul '15

10 Jul '15

--_000_BE8E19527611BA409D68FF6EA186AF9002A27F6FBEREXMBX19ifc1i_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Here the full backtrace #0 0x00007f756ab792c6 in ldap_back_bind () (gdb) bt full #0 0x00007f756ab792c6 in ldap_back_bind () No symbol table info available. #1 0x00007f756aa69fcb in fe_op_bind () No symbol table info available. #2 0x00007f756aad86fd in overlay_op_walk () No symbol table info available. #3 0x00007f756aad8956 in over_op_func () No symbol table info available. #4 0x00007f756aad89de in over_op_bind () No symbol table info available. #5 0x00007f756aa69697 in do_bind () No symbol table info available. #6 0x00007f756aa3ff19 in connection_operation () No symbol table info available. #7 0x00007f756aa404e1 in connection_read_thread () No symbol table info available. #8 0x00007f756a575c3c in ldap_int_thread_pool_wrapper () from /usr/lib64/l= ibldap_r-2.4.so.2 No symbol table info available. #9 0x00007f756998e806 in start_thread (arg=3D<optimized out>) at pthread_c= reate.c:301 __res =3D <optimized out> pd =3D 0x7f75527fc700 unwind_buf =3D {cancel_jmp_buf =3D {{jmp_buf =3D {140141872006912, = 3828700323369096852, 140142144269328, 140141872005120, 0, 8388608, -3762508= 621752658284, -3762593002521979244}, mask_was_saved =3D 0}}, priv =3D {pad =3D {0x0, 0x0, 0x0, 0x0= }, data =3D {prev =3D 0x0, cleanup =3D 0x0, canceltype =3D 0}}} not_first_call =3D <optimized out> robust =3D <optimized out> freesize =3D <optimized out> __PRETTY_FUNCTION__ =3D "start_thread" #10 0x00007f75681d902d in gnu_dev_makedev (major=3D1803453360, minor=3D<opt= imized out>) at ../sysdeps/unix/sysv/linux/makedev.c:37 No locals. #11 0x0000000000000000 in ?? () No symbol table info available. (gdb) --_000_BE8E19527611BA409D68FF6EA186AF9002A27F6FBEREXMBX19ifc1i_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable <html xmlns:v=3D"urn:schemas-microsoft-com:vml" xmlns:o=3D"urn:schemas-micr= osoft-com:office:office" xmlns:w=3D"urn:schemas-microsoft-com:office:word" = xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" xmlns=3D"http:= //www.w3.org/TR/REC-html40"> <head> <meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Dus-ascii"= > <meta name=3D"Generator" content=3D"Microsoft Word 14 (filtered medium)"> <style></style> </head> <body lang=3D"DE-CH" link=3D"blue" vlink=3D"purple"> <div class=3D"WordSection1"> Here the full backtrace<o:p></o:p> <o:p> </o:p> #0  0x00007f756ab792c6 in ldap_back_bind ()<o:p= ></o:p> (gdb) bt full<o:p></o:p>= #0  0x00007f756ab792c6 in = ldap_back_bind ()<o:p></o:p> No symbol table info available.= <o:p></o:p> #1  0x00007f756aa69fcb in fe_op_bind ()<o:p></o= :p> No symbol table info available.= <o:p></o:p> #2  0x00007f756aad86fd in = overlay_op_walk ()<o:p></o:p> No symbol table info available.= <o:p></o:p> #3  0x00007f756aad8956 in = over_op_func ()<o:p></o:p> No symbol table info available.= <o:p></o:p> #4  0x00007f756aad89de in = over_op_bind ()<o:p></o:p> No symbol table info available.= <o:p></o:p> #5  0x00007f756aa69697 in = do_bind ()<o:p></o:p> No symbol table info available.= <o:p></o:p> #6  0x00007f756aa3ff19 in = connection_operation ()<o:p></o:p> No symbol table info available.= <o:p></o:p> #7  0x00007f756aa404e1 in = connection_read_thread ()<o:p></o:p> No symbol table info available.= <o:p></o:p> #8  0x00007f756a575c3c in = ldap_int_thread_pool_wrapper () from /usr/lib64/libldap_r-2.4.so.2<o:p></o:= p> No symbol table info available.= <o:p></o:p> #9  0x00007f756998e806 in = start_thread (arg=3D<optimized out>) at pthread_create.c:301<o:p></o:= p>       =   __res =3D <optimized out><o:p></o:p>      &= nbsp;  pd =3D 0x7f75527fc700<o:p></o:p>      &= nbsp;  unwind_buf =3D {cancel_jmp_buf =3D {{jmp_buf =3D {1401418720069= 12, 3828700323369096852, 140142144269328, 140141872005120, 0, 8388608, -376= 2508621752658284, -3762593002521979244},<o:p></o:p>      &= nbsp;        mask_was_saved =3D 0}}, pri= v =3D {pad =3D {0x0, 0x0, 0x0, 0x0}, data =3D {prev =3D 0x0, cleanup =3D 0x= 0, canceltype =3D 0}}}<o:p></o:p>      &= nbsp;  not_first_call =3D <optimized out><o:p></o:p>      &= nbsp;  robust =3D <optimized out><o:p></o:p>      &= nbsp;  freesize =3D <optimized out><o:p></o:p>      &= nbsp;  __PRETTY_FUNCTION__ =3D "start_thread"<o:p></o:p></sp= an> #10 0x00007f75681d902d in gnu_d= ev_makedev (major=3D1803453360, minor=3D<optimized out>) at ../sysdep= s/unix/sysv/linux/makedev.c:37<o:p></o:p> No locals.<o:p></o:p></p= > #11 0x0000000000000000 in ?? ()= <o:p></o:p> No symbol table info available.= <o:p></o:p> (gdb)<o:p></o:p> <o:p> </o:p> </div> </body> </html> --_000_BE8E19527611BA409D68FF6EA186AF9002A27F6FBEREXMBX19ifc1i_--

1 0

Re: (ITS#6924) www.openldap.org and git.openldap.org serve different repositories
by ryan＠openldap.org 09 Jul '15

09 Jul '15

Since the last follow-up, this seems to have been resolved. Today the http and git URLs are returning the same repository content as far as I can tell.

1 0

Re: (ITS#8193) error in ldap logs
by quanah＠zimbra.com 09 Jul '15

09 Jul '15

--On Thursday, July 09, 2015 9:51 AM +0000 JB0035697(a)techmahindra.com wrote: > Full_Name: Bourguignon J-L > Version: 2.4.35 > OS: Sun OS 5.10 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (195.89.32.88) > > > Hi all, > > I've searched on the web for this kind of error but I've not find any > relevant answer. > > Is someone can explain what does means this following error : > > slapd(58): setsockopt(SO_KEEPALIVE) failed errno=22 (Invalid argument) > > It seems that when it appears, the process is still running but slapd > process doesn't answer to queries anymore. > > The only way to solve it, it's to restart the process. It would appear you have keepalive settings in your configuration, which are only valid for Linux, as noted in the man page. I will make a SWAG that they were added because you have a firewall breaking connections between clients and the server. As per the ldap_get_option(3) man page: Mainly intended for use with Linux, they may not be portable. --Quanah -- Quanah Gibson-Mount Platform Architect Zimbra, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#8194) Service slapd falldown in a search with client ldapsearch
by hyc＠symas.com 09 Jul '15

09 Jul '15

richard.larrieu-manan(a)cgi.com wrote: > Full_Name: CGI - Richard Larrieu-Manan > Version: 2.4.41 > OS: Red Hat 4.4.7-4 > URL: ftp://ftp.openldap.org/incoming/CGI_20150709.core.33604.tgz > Submission from: (NULL) (195.6.127.108) > > > Hello, > > When searching in the directory ldap 2.4.41 with ldapsearch client, 1 out of 4 > ldap service falldown. So I have provided you a core dump > (ftp://ftp.openldap.org/incoming/CGI_20150709.core.33604.tgz) during the bug. In > 2.4.38 version of the problem does not arise. Thanks for the report but we cannot use your core file. Please send your slapd configuration and the stack trace from the core. http://www.openldap.org/faq/data/cache/59.html -- -- 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#8194) Service slapd falldown in a search with client ldapsearch
by richard.larrieu-manan＠cgi.com 09 Jul '15

09 Jul '15

Full_Name: CGI - Richard Larrieu-Manan Version: 2.4.41 OS: Red Hat 4.4.7-4 URL: ftp://ftp.openldap.org/incoming/CGI_20150709.core.33604.tgz Submission from: (NULL) (195.6.127.108) Hello, When searching in the directory ldap 2.4.41 with ldapsearch client, 1 out of 4 ldap service falldown. So I have provided you a core dump (ftp://ftp.openldap.org/incoming/CGI_20150709.core.33604.tgz) during the bug. In 2.4.38 version of the problem does not arise. Thank you to consider this anomaly.

1 0

(ITS#8173)
by Adrian.Raemy＠vtg.admin.ch 09 Jul '15

09 Jul '15

--_000_BE8E19527611BA409D68FF6EA186AF9002A27CB3BEREXMBX19ifc1i_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear Howard, I could now install the missing debug pakages and below you find the output= of gdb. I did check 6 Dumps where the slapd crashed and always I had the same outpu= t. Now you can see where it crashes. Let me know if you need more...hope you can localize the problem and give a= s a fix. Regards Adrian Reading symbols from /usr/lib/openldap/slapd...Reading symbols from /usr/li= b/debug/usr/lib/slapd.debug...done. done. [New LWP 11777] [New LWP 11778] [New LWP 11823] [New LWP 11821] [New LWP 11970] [New LWP 11826] [New LWP 11824] [New LWP 11775] [New LWP 11971] [New LWP 11776] [New LWP 11785] [New LWP 11820] [New LWP 11825] [New LWP 11822] [New LWP 11827] [New LWP 11828] [New LWP 11972] [New LWP 11788] warning: Could not load shared library symbols for stics. Do you need "set solib-search-path" or "set sysroot"? [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib64/libthread_db.so.1". Core was generated by `/usr/lib/openldap/slapd -h ldap://0.0.0.0:389 ldap= s://0.0.0.0:636 -f /etc/op'. Program terminated with signal 11, Segmentation fault. #0 0x00007fcbb60572c6 in ldap_back_bind () (gdb) where #0 0x00007fcbb60572c6 in ldap_back_bind () #1 0x00007fcbb5f47fcb in fe_op_bind () #2 0x00007fcbb5fb66fd in overlay_op_walk () #3 0x00007fcbb5fb6956 in over_op_func () #4 0x00007fcbb5fb69de in over_op_bind () #5 0x00007fcbb5f47697 in do_bind () #6 0x00007fcbb5f1df19 in connection_operation () #7 0x00007fcbb5f1e4e1 in connection_read_thread () #8 0x00007fcbb5a53c3c in ldap_int_thread_pool_wrapper () from /usr/lib64/l= ibldap_r-2.4.so.2 #9 0x00007fcbb4e6c806 in start_thread (arg=3D<optimized out>) at pthread_c= reate.c:301 #10 0x00007fcbb36b702d in gnu_dev_makedev (major=3D3066092544, minor=3D<opt= imized out>) at ../sysdeps/unix/sysv/linux/makedev.c:37 #11 0x0000000000000000 in ?? () (gdb) --_000_BE8E19527611BA409D68FF6EA186AF9002A27CB3BEREXMBX19ifc1i_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable <html xmlns:v=3D"urn:schemas-microsoft-com:vml" xmlns:o=3D"urn:schemas-micr= osoft-com:office:office" xmlns:w=3D"urn:schemas-microsoft-com:office:word" = xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" xmlns=3D"http:= //www.w3.org/TR/REC-html40"> <head> <meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Dus-ascii"= > <meta name=3D"Generator" content=3D"Microsoft Word 14 (filtered medium)"> <style></style> </head> <body lang=3D"DE-CH" link=3D"blue" vlink=3D"purple"> <div class=3D"WordSection1"> Dear Howard,<o:p></o:p><= /p> <o:p> </o:p> I could now install the missing= debug pakages and below you find the output of gdb.<o:p></o:p> I did check 6 Dumps where the s= lapd crashed and always I had the same output. <o:p></o:p> Now you can see where it crashe= s.<o:p></o:p> <o:p> </o:p> Let me know if you need more&#8= 230;hope you can localize the problem and give as a fix.<o:p></o:p><= /p> <o:p> </o:p> Regards<o:p></o:p> Adrian<o:p></o:p> <o:p> </o:p> Reading symbols from /usr/lib/o= penldap/slapd...Reading symbols from /usr/lib/debug/usr/lib/slapd.debug...d= one.<o:p></o:p> done.<o:p></o:p> [New LWP 11777]<o:p></o:p></spa= n> [New LWP 11778]<o:p></o:p></spa= n> [New LWP 11823]<o:p></o:p></spa= n> [New LWP 11821]<o:p></o:p></spa= n> [New LWP 11970]<o:p></o:p></spa= n> [New LWP 11826]<o:p></o:p></spa= n> [New LWP 11824]<o:p></o:p></spa= n> [New LWP 11775]<o:p></o:p></spa= n> [New LWP 11971]<o:p></o:p></spa= n> [New LWP 11776]<o:p></o:p></spa= n> [New LWP 11785]<o:p></o:p></spa= n> [New LWP 11820]<o:p></o:p></spa= n> [New LWP 11825]<o:p></o:p></spa= n> [New LWP 11822]<o:p></o:p></spa= n> [New LWP 11827]<o:p></o:p> [New LWP 11828]<o:p></o:p></spa= n> [New LWP 11972]<o:p></o:p></spa= n> [New LWP 11788]<o:p></o:p></spa= n> <o:p> </o:p> warning: Could not load shared = library symbols for stics.<o:p></o:p> Do you need "set solib-sea= rch-path" or "set sysroot"?<o:p></o:p> [Thread debugging using libthre= ad_db enabled]<o:p></o:p> Using host libthread_db library= "/lib64/libthread_db.so.1".<o:p></o:p> Core was generated by `/usr/lib= /openldap/slapd -h  ldap://0.0.0.0:389  ldaps://0.0.0.0:636 = -f /etc/op'.<o:p></o:p> Program terminated with signal = 11, Segmentation fault.<o:p></o:p> #0  0x00007fcbb60572c6 in = ldap_back_bind ()<o:p></o:p> (gdb) where<o:p></o:p></= p> #0  0x00007fcbb60572c6 in = ldap_back_bind ()<o:p></o:p> #1  0x00007fcbb5f47fcb in fe_op_bind ()<o:p></o= :p> #2  0x00007fcbb5fb66fd in = overlay_op_walk ()<o:p></o:p> #3  0x00007fcbb5fb6956 in = over_op_func ()<o:p></o:p> #4  0x00007fcbb5fb69de in = over_op_bind ()<o:p></o:p> #5  0x00007fcbb5f47697 in = do_bind ()<o:p></o:p> #6  0x00007fcbb5f1df19 in = connection_operation ()<o:p></o:p> #7  0x00007fcbb5f1e4e1 in = connection_read_thread ()<o:p></o:p> #8  0x00007fcbb5a53c3c in = ldap_int_thread_pool_wrapper () from /usr/lib64/libldap_r-2.4.so.2<o:p></o:= p> #9  0x00007fcbb4e6c806 in = start_thread (arg=3D<optimized out>) at pthread_create.c:301<o:p></o:= p> #10 0x00007fcbb36b702d in gnu_d= ev_makedev (major=3D3066092544, minor=3D<optimized out>) at ../sysdep= s/unix/sysv/linux/makedev.c:37<o:p></o:p> #11 0x0000000000000000 in ?? ()<o:p></o:p> (gdb)<o:p></o:p> <o:p> </o:p> <o:p> </o:p> </div> </body> </html> --_000_BE8E19527611BA409D68FF6EA186AF9002A27CB3BEREXMBX19ifc1i_--

1 0

(ITS#8193) error in ldap logs
by JB0035697＠techmahindra.com 09 Jul '15

09 Jul '15

Full_Name: Bourguignon J-L Version: 2.4.35 OS: Sun OS 5.10 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (195.89.32.88) Hi all, I've searched on the web for this kind of error but I've not find any relevant answer. Is someone can explain what does means this following error : slapd(58): setsockopt(SO_KEEPALIVE) failed errno=22 (Invalid argument) It seems that when it appears, the process is still running but slapd process doesn't answer to queries anymore. The only way to solve it, it's to restart the process. Thx in advance for help. Brgds, Jean-Luc.

1 0

Re: (ITS#8188) unable to see the users on client after importing the TLS certificate
by quanah＠zimbra.com 08 Jul '15

08 Jul '15

--On Friday, July 03, 2015 2:53 PM +0000 vijeshkrishna(a)yahoo.com wrote: > Full_Name: Vijesh > Version: 2.4 > OS: RHEL 6.0 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (15.219.201.69) > > > Hello Team, Hello, The ITS system is for reporting bugs, not asking usage questions. Please direct your questions to the openldap-technical(a)openldap.org email list. This ITS will be closed. --Quanah -- Quanah Gibson-Mount Platform Architect Zimbra, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#8192) liblmdb confuses Windows error code with errno values
by h.b.furuseth＠usit.uio.no 08 Jul '15

08 Jul '15

Typo in original report: > #define MDB_FILE_NEW (MDB_LAST_ERRCODE + 9) > (above instead of MDB_NO_ROOT for easier cherry-picking.) "above instead of below MDB_NO_ROOT". On 08/07/15 22:36, Howard Chu wrote: > When there is a platform-specific error code that describes the > situation, we should use it. In particular, if the error code comes from > an underlying system call and accurately describes that failure, we > should pass it through. Yes. I only meant to talk about where mdb.c explicitly picks errno codes, like it does with EIO/ENOSPC. (And where it compares codes from system calls with errno codes.) > If the failure is LMDB-specific, and not related > to any particular system call, then we should define an MDB_* code for it.

1 0

Re: (ITS#8192) liblmdb confuses Windows error code with errno values
by hyc＠symas.com 08 Jul '15

08 Jul '15

h.b.furuseth(a)usit.uio.no wrote: > On 08/07/15 20:29, h.b.furuseth(a)usit.uio.no wrote: >> Finally, I suggest we replace the explicit EIO/ENOSPC returns >> with either a new MDB code or #define MDB_EIO EIO on Unix >> and something else on Windows. > > I mean, without waiting for LMDB-1.*. They are fairly > obscure errors, I doubt anyone is testing for them. When there is a platform-specific error code that describes the situation, we should use it. In particular, if the error code comes from an underlying system call and accurately describes that failure, we should pass it through. If the failure is LMDB-specific, and not related to any particular system call, then we should define an MDB_* code for it. -- -- 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#8192) liblmdb confuses Windows error code with errno values
by h.b.furuseth＠usit.uio.no 08 Jul '15

08 Jul '15

On 08/07/15 20:29, h.b.furuseth(a)usit.uio.no wrote: > Finally, I suggest we replace the explicit EIO/ENOSPC returns > with either a new MDB code or #define MDB_EIO EIO on Unix > and something else on Windows. I mean, without waiting for LMDB-1.*. They are fairly obscure errors, I doubt anyone is testing for them.

1 0

(ITS#8192) liblmdb confuses Windows error code with errno values
by h.b.furuseth＠usit.uio.no 08 Jul '15

08 Jul '15

Full_Name: Hallvard B Furuseth Version: LMDB_0.9.15 OS: Windows 7 with cygwin URL: Submission from: (NULL) (81.191.45.5) Submitted by: hallvard mdb_env_write_meta() loops to retry_write if ErrCode() == EINTR. That's ERROR_TOO_MANY_OPEN_FILES = 4 on Windows. New in 0.9.15. == This one is older, in mdb_env_setup_locks(). Also wrong on Windows: rc = ErrCode(); if (rc && rc != EACCES && rc != EAGAIN) I don't know what that code is doing. I think that belongs under if ((rc = mdb_env_excl_lock(env, excl))) goto fail; where it would read as if (*excl <= 0 && (rc = ErrCode()) && rc != EACCES && rc != EAGAIN) ==D%D ENOENT confusion: mdb_env_read_header() can explicitly return ENOENT, but only as an internal code. So mdb_strerror() should drop ENOENT. We can rename/renumber it to avoid confusion: /* Internal result codes, not exposed outside liblmdb */ #define MDB_FILE_NEW (MDB_LAST_ERRCODE + 9) (above instead of MDB_NO_ROOT for easier cherry-picking.) OTOH lmdb.h lists "ENOENT - the directory specified by the path parameter doesn't exist." That's not related to the above. It should be "ENOENT (Unix) or ERROR_PATH_NOT_FOUND (Windows) - ..." Or maybe the doc for this code should say something more general, or simply be omitted. I found the Windows code by testing @ Windows. Reading Windows doc did not help. == Finally, I suggest we replace the explicit EIO/ENOSPC returns with either a new MDB code or #define MDB_EIO EIO on Unix and something else on Windows. (I think ENOSPC should be EIO too, there could be other reasons for a short write.) Then we can drop those from mdb_strerror() too.

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs