- openldap-bugs - openldap.org

Re: (ITS#7682) LMDB: [PATCH] mdb_env_copy should retry open() if O_DIRECT fails
by h.b.furuseth＠usit.uio.no 31 Aug '16

31 Aug '16

Sorry, looks like I dropped this message. Yes, #ifdef F_NOCACHE / #elif defined O_DIRECT / #endif seems better. Included in branch "mdb/fopen" in my repo at UiO. On 24. des. 2013 18:18, Howard Chu wrote: > h.b.furuseth(a)usit.uio.no wrote: >> This was fixed in LMDB 0.9.9, except: If both O_DIRECT and >> F_NOCACHE are #defined, both are used. Looks a bit strange. >> Maybe just one should be used in that case. (Which?) Also I'm >> still wondering if env_open needs to fail if F_NOCACHE fails. >> >> Anyway, maybe it should be something like this. The "else {}" >> is in case O_DIRECT is an unsupported dummy definiton: > > Isn't that in the wrong order then? What you suggest here will use O_DIRECT > even if it's a dummy. > > I don't see any reason to fail the operation. They just want to make a > copy/backup; even if the optimization of avoiding pollution of the buffer > cache can't be done, they still want the copy to happen. > >> #ifdef O_DIRECT >> if ((rc = fcntl(newfd, F_GETFL)) != -1) >> (void) fcntl(newfd, F_SETFL, rc | O_DIRECT); >> else >> #endif >> { >> #ifdef F_NOCACHE /* __APPLE__ */ >> (void) fcntl(newfd, F_NOCACHE, 1); >> #endif >> } -- Hallvard

1 0

Re: (ITS#8488) OpenSSL 1.1.0
by hyc＠symas.com 30 Aug '16

30 Aug '16

norm.green(a)gemtalksystems.com wrote: > Full_Name: Norm Green > Version: 2.4.43 > OS: Linux > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (50.240.19.49) > > > Please support OpenSSL 1.1.0. Current versions of OpenLDAP will not build with > OpenSSL 1.1.0 due to OpenSSL API changes. > > Already supported in git master. Closing this ITS. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

(ITS#8488) OpenSSL 1.1.0
by norm.green＠gemtalksystems.com 30 Aug '16

30 Aug '16

Full_Name: Norm Green Version: 2.4.43 OS: Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (50.240.19.49) Please support OpenSSL 1.1.0. Current versions of OpenLDAP will not build with OpenSSL 1.1.0 due to OpenSSL API changes.

1 0

Re: (ITS#8487) Properly handle realloc() failures
by hyc＠symas.com 30 Aug '16

30 Aug '16

cissp(a)bryongloden.com wrote: > Full_Name: Bryon Gloden, CISSP. > Version: > OS: > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (161.133.194.55) > > > Greetings. On line numbers 123 and 134 of liblmdb/midl.c > (https://github.com/LMDB/lmdb/blob/mdb.master/libraries/liblmdb/midl.c) there > are two common realloc() mistakes. Passing one pointer into realloc() and > assigning the result directly into that same pointer variable can cause a memory > leak if the reallocation fails, because the original allocation will still > exist. The correct way to do this is to use a temporary pointer variable. > > Credit: http://stackoverflow.com/a/11548901 > > Found by https://github.com/bryongloden/cppcheck > > This is all false. On line number 123 we are shrinking the memory region - this will never fail. At worst it can only return the original pointer unchanged. On line number 134 we are leaving the original pointer unchanged on failure, it is not leaked. The caller can free it if it wants to. Closing this ITS. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

(ITS#8487) Properly handle realloc() failures
by cissp＠bryongloden.com 30 Aug '16

30 Aug '16

Full_Name: Bryon Gloden, CISSP. Version: OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (161.133.194.55) Greetings. On line numbers 123 and 134 of liblmdb/midl.c (https://github.com/LMDB/lmdb/blob/mdb.master/libraries/liblmdb/midl.c) there are two common realloc() mistakes. Passing one pointer into realloc() and assigning the result directly into that same pointer variable can cause a memory leak if the reallocation fails, because the original allocation will still exist. The correct way to do this is to use a temporary pointer variable. Credit: http://stackoverflow.com/a/11548901 Found by https://github.com/bryongloden/cppcheck

1 0

(ITS#8486) Syncprov sessionlog is inefficient, kills perf
by quanah＠openldap.org 29 Aug '16

29 Aug '16

Full_Name: Quanah Gibson-Mount Version: 2.4.44 OS: Linux 2.6 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (75.111.52.177) After setting the sessionlog for syncprov to a large size so as to avoid ITS#8125. However, due to the sessionlog being a linear linked list, it can be vastly inefficient to iterate, and slows down the master to the point that searches can time out. Howard suggests converting it into a tree instead to help obviate the load this currently induces.

1 0

(ITS#8485) [PATCH] Adding support for encrypted server private keys
by ahnolds＠gmail.com 29 Aug '16

29 Aug '16

Full_Name: Alec Cooper Version: HEAD of master branch OS: Ubuntu Linux 16.04 URL: ftp://ftp.openldap.org/incoming/Alec-Cooper-160827.patch Submission from: (NULL) (73.134.243.211) Adding support for encrypted server private keys. The meat of this patch is changes to tls2.c, tls_g.c, tls_m.c, and tls_o.c to send a password to the underlying TLS library. Changes to ldap.h, init.c and ldap-int.h expose the new LDAP_OPT_X_TLS_KEYPASSWORD in the main API. Changes in the contrib/ldapc++ directory expose the corresponding TlsOptions::KEYPASSWORD option in the C++ API. Changes in the servers directory expose equivalent options for servers as configuration file entries or environment variables. Changes in the doc directory add documentation about the new options and remove statements that indicated that encrypted keyfiles are not supported. New files in the test directory are for testing TLS connections, both in general and with encrypted keyfiles. Tests pass for OpenSSL and GnuTLS using PEM formatted certs and keys, and for MozNSS using cert/key databases. The new unit test (test065-tls) has been written to detect when using NSS, and use the cert/key databases in this case. I have been unable to get a working version of libnsspem, so I cannot test MozNSS with (or without) encrypted keyfiles - testing for this case would be welcome! Notice of origin: The attached patch file is derived from OpenLDAP Software. All of the modifications to OpenLDAP Software represented in the following patch were developed by Alec Cooper ahnolds(a)gmail.com. I have not assigned rights and/or interest in this work to any party. Rights statement: I, Alec Cooper, hereby place the following modifications to OpenLDAP Software (and only these modifications) into the public domain. Hence, these modifications may be freely used and/or redistributed for any purpose with or without attribution and/or other notice. The patch has been uploaded to the OpenLDAP FTP server and can be found at ftp://ftp.openldap.org/incoming/Alec-Cooper-160827.patch

1 0

Re: (ITS#7992) lmdb: Windows: assume file paths are UTF-8, encode to UTF-16 for WinAPI and enable compiling when UNICODE is defined
by h.b.furuseth＠usit.uio.no 27 Aug '16

27 Aug '16

Seems the test for MultiByteToWideChar() == 0xFFFD can be dropped. The MultiByteToWideChar doc mentions U+FFFD under Return Value. But when I test bad UTF-8 characters, it inserts 0xFFFD for the bad character(s) in the output string. It doesn't return 0xFFFD. Or if we pass the MB_ERR_INVALID_CHARS flag, it returns 0 and sets GetLastError() as usual. (I wonder if I had a hand in this code - looks like my kind of thing to write a draft from the Windows doc but leave the Windows testing to someone else:-)

1 0

(ITS#8484) tlsm_register_shutdown_callonce needs to be reinitialized
by soohoon.lee＠f5.com 23 Aug '16

23 Aug '16

Full_Name: soohoon lee Version: HEAD OS: linux 7.2 URL: ftp://ftp.openldap.org/incoming/soohoon-lee-160823.patch Submission from: (NULL) (50.205.70.164) When there's a persistent daemon for auth and it sets LDAP_OPT_X_TLS_NEWCTX, it fails to auth at third login. 1. everything is good and destroyed after use but tlsm_register_shutdown_callonce.initialized=1. 2. still good but because tlsm_register_shutdown_callonce.initialized==1, it fails to register shutdown function. so pem_module is not destroyed at the end. 3. pem_module is not NULL so it's not initialized again and not added to modules list. And Login fails.

1 0

Re: (ITS#8483) CMake buildsystem support for LMDB
by hyc＠symas.com 20 Aug '16

20 Aug '16

Ivan Shapovalov wrote: > On 2016-08-20 at 03:32 +0100, Howard Chu wrote: >> intelfx(a)intelfx.name wrote: >>> >>> Full_Name: Ivan Shapovalov >>> Version: LMDB 0.9.18 >>> OS: GNU/Linux >>> URL: ftp://ftp.openldap.org/incoming/ivan-shapovalov-160820.patch >>> Submission from: (NULL) (77.41.63.43) >>> >>> >>> This patch adds a CMake buildsystem for LMDB, side-by-side with >>> existing >>> Makefile. >>> It builds the same targets except coverage tests. >> >> I am not a fan of CMake. Using it requires learning a whole new set >> of >> documentation in addition to knowing the rules of Make. It comes with >> a huge >> footprint of dependencies, and most people using it are misusing it. > > Mastering CMake is a lot easier than just learning to use Make... > If you don't like CMake out of personal motives, please just say so I have said so, right up front: "I am not a fan of CMake." > and don't cover it with made-up reasons. I don't need to make up reasons. I've spent a lot of time working with CMake already. When setting up a new build environment, it is ridiculously hard to debug a broken setup. Crucial information is hidden, and debug/verbose settings and log files don't reveal it. Been there, done that, no thanks. >> If you need to integrate LMDB into a particular CMake-based project, >> it's a >> lot simpler than this. E.g., >> https://github.com/LMDB/bitmonero/blob/master/external/db_drivers/lib >> lmdb/CMakeLists.txt >> >> There's no reason to duplicate the entire Makefile when you're >> embedding LMDB >> into some other project. This also shows the correct way to use CMake >> and >> propagate threads dependencies. > This file does not cover packaging and exporting targets, which is > crucial when building multiple dependent projects in a staging tree (e. > g. cross-compiling stuff). You see, it is easier to have a single > correct build script in the upstream repo than to have many ad-hoc > build scripts in each project, each deficient in its own regard. There is no such thing as a single correct upstream CMake script since different projects have different requirements for how they intend to use their dependencies. Most projects won't need install targets for the utility commands or manpages. Most projects don't need packaging of intermediate dependencies. There's nothing to argue here. This project doesn't use CMake and we won't maintain files for tools we don't use. -- -- 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#8483) CMake buildsystem support for LMDB
by intelfx＠intelfx.name 20 Aug '16

20 Aug '16

--=-Nq65m7sM2GaofoKVHHN0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On 2016-08-20 at 03:32 +0100, Howard Chu wrote: > intelfx(a)intelfx.name wrote: > >=20 > > Full_Name: Ivan Shapovalov > > Version: LMDB 0.9.18 > > OS: GNU/Linux > > URL: ftp://ftp.openldap.org/incoming/ivan-shapovalov-160820.patch > > Submission from: (NULL) (77.41.63.43) > >=20 > >=20 > > This patch adds a CMake buildsystem for LMDB, side-by-side with > > existing > > Makefile. > > It builds the same targets except coverage tests. >=20 > I am not a fan of CMake. Using it requires learning a whole new set > of=C2=A0 > documentation in addition to knowing the rules of Make. It comes with > a huge=C2=A0 > footprint of dependencies, and most people using it are misusing it. Mastering CMake is a lot easier than just learning to use Make... >=20 > >=20 > > Rationale for this change: CMake simplifies building of LMDB with > > non-standard > > toolchains > > such as Android NDK which only support their custom buildsystem and > > CMake (via > > a > > provided CMake toolchain configuration file). >=20 > Building for Android is trivial using e.g. agcc > https://gist.github.com/angad/1033321 This "agcc" has all flags hard-coded and simply does not work with third-party NDKs such as CrystaX NDK, which is exactly the point I'm trying to make. >=20 > >=20 > > This way, one does not need to extract required compiler flags > > manually. > > Moreover, this simplifies life for projects which use CMake and > > LMDB, because a > > proper CMake buildsystem allows to e. g. automatically pass > > transitive > > dependencies like pthreads to dependent projects. >=20 > Using agcc allows one to build for Android any project that simply > uses Make,=C2=A0 > which was 100% of them before CMake came along. This is false, as shown above. >=20 > Transitive dependencies like pthreads, which you have now embedded > into your=C2=A0 > CMakeLists.txt file, are actually compiler and platform dependent. > That's why=C2=A0 > the LMDB Makefile sets it in an overridable macro, that a programmer > can=C2=A0 > easily change on the commandline when invoking make on their chosen > build=C2=A0 > platform. True; this can be fixed. >=20 > Rejecting this patch and all future patches involving CMake. We will > not use=C2=A0 > this tool ourselves and we will not maintain files that it uses in > the LMDB=C2=A0 > source tree. If you don't like CMake out of personal motives, please just say so and don't cover it with made-up reasons. >=20 > If you need to integrate LMDB into a particular CMake-based project, > it's a=C2=A0 > lot simpler than this. E.g., > https://github.com/LMDB/bitmonero/blob/master/external/db_drivers/lib > lmdb/CMakeLists.txt >=20 > There's no reason to duplicate the entire Makefile when you're > embedding LMDB=C2=A0 > into some other project. This also shows the correct way to use CMake > and=C2=A0 > propagate threads dependencies. >=20 This file does not cover packaging and exporting targets, which is crucial when building multiple dependent projects in a staging tree (e. g. cross-compiling stuff). You see, it is easier to have a single correct build script in the upstream repo than to have many ad-hoc build scripts in each project, each deficient in its own regard. --=20 Ivan Shapovalov / intelfx / --=-Nq65m7sM2GaofoKVHHN0 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAABCgAGBQJXt8N1AAoJEHveF8jk4w6dxNMP/0rbPnFVC6SP7ouTI8XhSdRq YmTl5f3clANv29PV5d6VpEROrbom0Exw07oBFIo4pN01Wo8/Gc48P/2NWZhO+IIZ qvhxTjatCIIZWviZprzQqQK/1VaH4F0IPA7vDHTZGu6G6OHHw70rKIWRh00x0K46 PZfmHZCN5akfdWVniX/Uc7RplAFyOzrnZZRfulfNPPCgwtwoenJ6mO0k4zWwJtP8 Yk/ipwHpXFAkuU5UQ0ObHJfmcCSebFEt53knDfUV7u2aBg24bFTMK0IfX3RuNN1D /fAV0WuoMS6HtTEfaOiUtlemjejxiOxCHFwHbe31Q2XgO3fSOuyv3qrdJCBKwJAX 8/MUbTf2RRA5pdAgiELEZ8o3mMuf0Gjs9BYC+Who5F+cy/3v0ga44MmRZwjtRZre 7h9GeqcgInNtRj9eYOeHPmSdLh8v/6RJRm7OQ/NkeFcKQdooMqd0vsbCWSWkdpyo rb3opd+mv8iRM6rVpEOyQDfWEguVIhemUB6g5/jyjO3tAcjIhwxnImvPTJXjNB9z OmTwnoVezixG8cJ6dYZYr3tSq7okBJd3DjTyxpB5VkWcp12+59vBLfkVrhEzA7Qw fMOPItN/2FymaLsh2kYv3jVLCl3r2hQ+LP2rPD4NWTC5MLcsxRCgJLfTvrALuRp0 IJCyUdAOf+xXzd6VF53n =Ln4x -----END PGP SIGNATURE----- --=-Nq65m7sM2GaofoKVHHN0--

1 0

Re: (ITS#8483) CMake buildsystem support for LMDB
by hyc＠symas.com 20 Aug '16

20 Aug '16

intelfx(a)intelfx.name wrote: > Full_Name: Ivan Shapovalov > Version: LMDB 0.9.18 > OS: GNU/Linux > URL: ftp://ftp.openldap.org/incoming/ivan-shapovalov-160820.patch > Submission from: (NULL) (77.41.63.43) > > > This patch adds a CMake buildsystem for LMDB, side-by-side with existing > Makefile. > It builds the same targets except coverage tests. I am not a fan of CMake. Using it requires learning a whole new set of documentation in addition to knowing the rules of Make. It comes with a huge footprint of dependencies, and most people using it are misusing it. > Rationale for this change: CMake simplifies building of LMDB with non-standard > toolchains > such as Android NDK which only support their custom buildsystem and CMake (via > a > provided CMake toolchain configuration file). Building for Android is trivial using e.g. agcc https://gist.github.com/angad/1033321 > This way, one does not need to extract required compiler flags manually. > Moreover, this simplifies life for projects which use CMake and LMDB, because a > proper CMake buildsystem allows to e. g. automatically pass transitive > dependencies like pthreads to dependent projects. Using agcc allows one to build for Android any project that simply uses Make, which was 100% of them before CMake came along. Transitive dependencies like pthreads, which you have now embedded into your CMakeLists.txt file, are actually compiler and platform dependent. That's why the LMDB Makefile sets it in an overridable macro, that a programmer can easily change on the commandline when invoking make on their chosen build platform. Rejecting this patch and all future patches involving CMake. We will not use this tool ourselves and we will not maintain files that it uses in the LMDB source tree. If you need to integrate LMDB into a particular CMake-based project, it's a lot simpler than this. E.g., https://github.com/LMDB/bitmonero/blob/master/external/db_drivers/liblmdb/C… There's no reason to duplicate the entire Makefile when you're embedding LMDB into some other project. This also shows the correct way to use CMake and propagate threads dependencies. -- -- 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#8483) CMake buildsystem support for LMDB
by intelfx＠intelfx.name 20 Aug '16

20 Aug '16

Full_Name: Ivan Shapovalov Version: LMDB 0.9.18 OS: GNU/Linux URL: ftp://ftp.openldap.org/incoming/ivan-shapovalov-160820.patch Submission from: (NULL) (77.41.63.43) This patch adds a CMake buildsystem for LMDB, side-by-side with existing Makefile. It builds the same targets except coverage tests. Rationale for this change: CMake simplifies building of LMDB with non-standard toolchains such as Android NDK which only support their custom buildsystem and CMake (via a provided CMake toolchain configuration file). This way, one does not need to extract required compiler flags manually. Moreover, this simplifies life for projects which use CMake and LMDB, because a proper CMake buildsystem allows to e. g. automatically pass transitive dependencies like pthreads to dependent projects.

1 0

(ITS#8482) Assertion failed with back-meta
by hydrazine＠bergzand.net 20 Aug '16

20 Aug '16

Full_Name: Koen Zandberg Version: 2.4.44 OS: Debian Jessie URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (130.89.160.191) I'm currently deploying an openldap server (version 2.4.44 ltb-project package) with back-meta and with config in the in database format. Slapd crashes with an assertion failed error whenever I modify the suffixmassaging property in the config of one of the backends of my meta backend. What did I do: I created an olcDatabase={2}meta,cn=config with multiple backends. The intial config was converted from a slapd.conf style configfile. Openldap loads the config correct and everything works as expected. I've tried editting one of the rewriterules of the meta URI backends (olcMetaSub={0}uri,olcDatabase={2}meta,cn=config) with ldapvi. specifically the olcDbRewrite: {0}suffixmassage What did I expect: Either an updated rewriterule or an error when committing. What happens: Slapd crashes with an assertion error: slapd: config.c:59: rewrite_parse: Assertion `info != ((void *)0)' failed. Aborted It seems to happen when any rewriterule is modified, not only when modifying the suffixmassage rules If more information is required such as more debug information or specific config options I gladly provide them Regards Koen Zandberg

1 0

Re: (ITS#8481) macOS shared libraries should be .dylib not .so
by hyc＠symas.com 19 Aug '16

19 Aug '16

ilovezfs(a)icloud.com wrote: > Full_Name: ilovezfs > Version: LMDB_0.9.18 > OS: macOS > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (50.168.32.161) > > > This is in regard to the Homebrew formula for LMDB (See > https://github.com/Homebrew/homebrew-core/pull/2317). Currently, we are having > to patch the shared library extensions from .so to .dylib, which is the correct > file extension on macOS. It would be great if this patch could be removed from > the formula, which would mean upstream support for automatically setting the > extension correctly based on platform in the build system. > > This is a pretty common practice, and it would be highly appreciated as we like > to as little patching as possible to upstream code for maintainability and > fidelity. > > In particular, we're currently having to do the following replacement: > ``` > inreplace "Makefile", ".so", ".dylib" > ``` Fixed in commit c6510147cee88d182af431c14a61fad6fae18be3 > Here's a typical example of how shared libraries get named on macOS: > ``` > libiconv.2.4.0.dylib -> libiconv.2.dylib > libiconv.2.dylib > libiconv.dylib -> libiconv.2.4.0.dylib > ``` > > -- -- 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#8481) macOS shared libraries should be .dylib not .so
by ilovezfs＠icloud.com 19 Aug '16

19 Aug '16

Full_Name: ilovezfs Version: LMDB_0.9.18 OS: macOS URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (50.168.32.161) This is in regard to the Homebrew formula for LMDB (See https://github.com/Homebrew/homebrew-core/pull/2317). Currently, we are having to patch the shared library extensions from .so to .dylib, which is the correct file extension on macOS. It would be great if this patch could be removed from the formula, which would mean upstream support for automatically setting the extension correctly based on platform in the build system. This is a pretty common practice, and it would be highly appreciated as we like to as little patching as possible to upstream code for maintainability and fidelity. In particular, we're currently having to do the following replacement: ``` inreplace "Makefile", ".so", ".dylib" ``` Here's a typical example of how shared libraries get named on macOS: ``` libiconv.2.4.0.dylib -> libiconv.2.dylib libiconv.2.dylib libiconv.dylib -> libiconv.2.4.0.dylib ```

1 0

Re: (ITS#8480) running sample-mdb without ./testdb/
by hyc＠symas.com 17 Aug '16

17 Aug '16

gp.ciceri(a)gmail.com wrote: > Full_Name: gian paolo ciceri > Version: lmdb 0.9.18 > OS: OSX > URL: ftp://ftp.openldap/org/incoming > Submission from: (NULL) (5.170.1.95) > > > With lmdb (fresh git clone), if you run the standard sample-mdb.c example > program WITHOUT creating the ./testdb/ directory for the database before, you > take error 2 No such file or directory after the open. OK, but if you still > proceed to the begin the transaction, you take a segmentation fault 11: there's > what gdb says > There is no sample-mdb.c in a fresh git clone. There is a sample-mdb.txt. It is a text file, which you are expected to read, not run blindly. Closing this ITS. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

(ITS#8480) running sample-mdb without ./testdb/
by gp.ciceri＠gmail.com 17 Aug '16

17 Aug '16

Full_Name: gian paolo ciceri Version: lmdb 0.9.18 OS: OSX URL: ftp://ftp.openldap/org/incoming Submission from: (NULL) (5.170.1.95) With lmdb (fresh git clone), if you run the standard sample-mdb.c example program WITHOUT creating the ./testdb/ directory for the database before, you take error 2 No such file or directory after the open. OK, but if you still proceed to the begin the transaction, you take a segmentation fault 11: there's what gdb says sample-mdb Program received signal SIGSEGV, Segmentation fault. 0x0000000100001443 in mdb_txn_renew0 (txn=0x0) at ../mdb.c:2619 2619 MDB_env *env =xtxn->mt_env; Of course there is NO reason to begin the tnx if the open fails, but should not be better to trap this situation and comply instead of proceed and generate the segfault? Perhaps you suppose the program knows what is doing, but I (as programmer) am less sure of myself. Best regards, thanks for your attention. /gp

1 0

(ITS#8479) overlay unique + mdb: loop and OOM kill, 2 URS as olcUniqueURI value
by william.b.clay＠acm.org 15 Aug '16

15 Aug '16

Full_Name: Bill Clay Version: 2.4.44 OS: Debian/GNU Linux 7.8 (Wheezy) URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (87.15.115.130) The below modification to an otherwise correctly-functioning slapd instance provokes an infinite loop that eventually ends with allocation of all configured virtual memory, kernel invocation of its oom-killer (generally on an innocent bystander), and sometimes a kernel panic. This scenario is 100% repeatable on this installation. If I understand "man 5 slapo-unique" correctly, an instance of overlay unique may specify more than one olcUniqueURI attribute, each of which may specify more than one space-separated (?) URI. In this case, I am replacing two initially-configured olcUniqueURI attributes whose values comprise a single URI each (and which seem to work correctly) by one olcUniqueURI attribute with two URIs. bill@fuji:~$ sudo ldapmodify -YEXTERNAL -Hldapi:// SASL/EXTERNAL authentication started SASL username: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth SASL SSF: 0 dn:olcOverlay={2}unique,olcDatabase={3}mdb,cn=config changetype: modify replace: olcUniqueURI olcUniqueURI: ldap:///ou=gruppi,dc=test?gidNumber?one ldap:///ou=gruppi,dc=test?owner?one modifying entry "olcOverlay={2}unique,olcDatabase={3}mdb,cn=config" ldap_result: Can't contact LDAP server (-1) bill@fuji:~$ This slapd is the following custom build on an otherwise fairly stock Debian Wheezy system. cd /usr/local/src/openldap-2.4.44 ./configure --sysconfdir=/etc --localstatedir=/ \ --disable-backends --enable-mdb --enable-monitor --enable-crypt \ --with-cyrus-sasl --enable-spasswd --enable-syslog --enable-local \ --disable-overlays --enable-memberof --enable-refint --enable-unique \ --disable-modules --with-cyrus-sasl --with-tls --with-threads --with-gnu-ld # if --enable-shell, avoid --with threads I have uploaded files bill-clay-160815-<type>.txt to ftp://ftp.openldap.org/incoming/ for the following <types>: log: console log of slapd running foreground with -d1 (serial console at 57600 bps, allowing prompt manual termination via kill -KILL) cnf1-cnf3: slapadd specification of (1) the rootDSE, (2) {2}mdb's tree dc=epici,dc=it, and (3) {3}mdb's tree dc=test (subject of the failed ldapmodify). As is probably obvious from these files, I am an LDAP newbie, so there may be a configuration error here that's painfully obvious to the experienced practictioner.

1 0

Re: (ITS#8478) Master/Slave Replication not catching up if syncrepl config is defined before the replication user exist
by hyc＠symas.com 12 Aug '16

12 Aug '16

elecharny(a)apache.org wrote: > Full_Name: Emmanuel L.charny > Version: 2.4.42 > OS: linux > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (86.247.10.144) > > > When configuring syncrepl using slapd.d on a slave, if the replicator user does > not exist beforehand, replication won't catch with entries that were updated > prior the creation of the replicator user on the slave. OTOH, if we create this > replicator user *before* setting the replication configuration on the slave, > every updated entries on the master are replicated, even those created before > the configuration modification. Please provide a sample config that demonstrates the issue. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

(ITS#8478)
by elecharny＠gmail.com 12 Aug '16

12 Aug '16

IMO, it's a different issue. Ther ei no timing issue, it's reproductible in any case. FTR, I tested it on 2.4.44 (even if the original issue was seen on 2.4.42) The key here is really to create the replicator user before or after configuring syncrepl on the slave : if the user is created first, then all the entries get replicated from the master, and if teh user is created after the syncrepl configuration, no entry older than the moment the replicator user is added are read from the master.

1 0

Re: (ITS#8478) Master/Slave Replication not catching up if syncrepl config is defined before the replication user exist
by quanah＠zimbra.com 12 Aug '16

12 Aug '16

--On Friday, August 12, 2016 4:42 PM +0000 elecharny(a)apache.org wrote: > Full_Name: Emmanuel L.charny > Version: 2.4.42 > OS: linux > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (86.247.10.144) > > > When configuring syncrepl using slapd.d on a slave, if the replicator > user does not exist beforehand, replication won't catch with entries that > were updated prior the creation of the replicator user on the slave. > OTOH, if we create this replicator user *before* setting the replication > configuration on the slave, every updated entries on the master are > replicated, even those created before the configuration modification. Is this any different from ITS#8281, ITS#8365? It sounds quite similar. Have you tested on a current release, which is general best practices before filing an ITS? --Quanah -- Quanah Gibson-Mount

1 0

(ITS#8478) Master/Slave Replication not catching up if syncrepl config is defined before the replication user exist
by elecharny＠apache.org 12 Aug '16

12 Aug '16

Full_Name: Emmanuel L.charny Version: 2.4.42 OS: linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (86.247.10.144) When configuring syncrepl using slapd.d on a slave, if the replicator user does not exist beforehand, replication won't catch with entries that were updated prior the creation of the replicator user on the slave. OTOH, if we create this replicator user *before* setting the replication configuration on the slave, every updated entries on the master are replicated, even those created before the configuration modification.

1 0

Re: (ITS#8477) OpenLDAP.org has a broken TLS certificate
by demiobenour＠gmail.com 11 Aug '16

11 Aug '16

On Wed, 2016-08-10 at 21:13 +0100, Howard Chu wrote: > demiobenour(a)gmail.com wrote: > > > > Full_Name: Demi Obenour > > Version: N/A > > OS: N/A > > URL: ftp://ftp.openldap.org/incoming/ > > Submission from: (NULL) (2601:840:8100:6720:2ae3:47ff:fe02:d99e) > > > > > > OpenLDAP.org has an expired self-signed TLS certificate, > > This is intentional. > > > > > which makes it > > impossible to securely access the Git repositories over HTTPS. > > The repos are only intended to be used via git: and http: anyway. > > This needs to be > > > > fixed to avoid man-in-the-middle attacks, which would allow > > arbitrary code > > execution on the developer's machine. > > When I discussed this with Kurt, we decided to leave things as-is. > Replacing > an expired self-signed cert with a non-expired self-signed cert > wouldn't > change anything, you still need to set an explicit exception in your > client to > trust the cert. > Why are the repos only intended to be used via git: and http: ? Is there some reason? This makes them unusable for anyone who cares about security. In the past http:// and https:// used an old dumb protocol that was slow, but that has long since been fixed in Git. Also, why the self-signed certificate at all? Let's Encrypt is providing free certificates.

1 0

Re: (ITS#8477) OpenLDAP.org has a broken TLS certificate
by michael＠stroeder.com 10 Aug '16

10 Aug '16

hyc(a)symas.com wrote: > When I discussed this with Kurt, we decided to leave things as-is. Replacing > an expired self-signed cert with a non-expired self-signed cert wouldn't > change anything, you still need to set an explicit exception in your client to > trust the cert. Hmm, but browsers will likely not allow adding an exception anymore in the near future. And e.g. using Let's Encrypt isn't that hard (even without installing the bloated standard client on the system). Ciao, Michael.

1 0

Re: (ITS#8477) OpenLDAP.org has a broken TLS certificate
by hyc＠symas.com 10 Aug '16

10 Aug '16

demiobenour(a)gmail.com wrote: > Full_Name: Demi Obenour > Version: N/A > OS: N/A > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (2601:840:8100:6720:2ae3:47ff:fe02:d99e) > > > OpenLDAP.org has an expired self-signed TLS certificate, This is intentional. > which makes it > impossible to securely access the Git repositories over HTTPS. The repos are only intended to be used via git: and http: anyway. This needs to be > fixed to avoid man-in-the-middle attacks, which would allow arbitrary code > execution on the developer's machine. When I discussed this with Kurt, we decided to leave things as-is. Replacing an expired self-signed cert with a non-expired self-signed cert wouldn't change anything, you still need to set an explicit exception in your client to trust the cert. -- -- 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#8477) OpenLDAP.org has a broken TLS certificate
by demiobenour＠gmail.com 10 Aug '16

10 Aug '16

Full_Name: Demi Obenour Version: N/A OS: N/A URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (2601:840:8100:6720:2ae3:47ff:fe02:d99e) OpenLDAP.org has an expired self-signed TLS certificate, which makes it impossible to securely access the Git repositories over HTTPS. This needs to be fixed to avoid man-in-the-middle attacks, which would allow arbitrary code execution on the developer's machine.

1 0

Re: (ITS#8475) Feature request: MDB low durability transactions
by bentrask＠comcast.net 10 Aug '16

10 Aug '16

Okay, thanks for taking the time to discuss, and of course for all your work on MDB! Ben On 08/10/2016 08:50 AM, Hallvard Breien Furuseth wrote: > Nope, you're as confused as I was originally:-) LDMB doesn't know or > care when a page was written. A page can be reused when the snapshot > which _freed_ it is known to be durable and there are no older readers. > (We could improve that by tracking page history better. Maybe later.) > > "Known to be durable" = sync datapages, write metapage, sync metapage, > note that the metapage was synced. (We implicitly note that when > writing next txn's metapage, since we must have synced first.) From > a data safety point of view, txns which do all that are the real txns. > Anything else is fluff, like no-sync txns if we implement them. Their > metapages must go somewhere they *won't* be confused with durable ones. > > Think of such a fluffy commit as saving an intermediate stage of a > real txn. That's irrelevant to a later write-txn wanting to not touch > the last two durable snapshots. It's only relevant vs. oldest reader. > > So. 3rd metapage and variants - I've tried and Howard pointed out > the flaws, Howard tried and I said here we go again. We do not need > another round, but it's just as well to have it summarized here. > > (This discussion ignores MDB_NOSYNC and partly MDB_NOLOCK - if the > user enables either, it's his responsibility to compensate.) >

1 0

Re: (ITS#8475) Feature request: MDB low durability transactions
by h.b.furuseth＠usit.uio.no 10 Aug '16

10 Aug '16

Nope, you're as confused as I was originally:-) LDMB doesn't know or care when a page was written. A page can be reused when the snapshot which _freed_ it is known to be durable and there are no older readers. (We could improve that by tracking page history better. Maybe later.) "Known to be durable" = sync datapages, write metapage, sync metapage, note that the metapage was synced. (We implicitly note that when writing next txn's metapage, since we must have synced first.) From a data safety point of view, txns which do all that are the real txns. Anything else is fluff, like no-sync txns if we implement them. Their metapages must go somewhere they *won't* be confused with durable ones. Think of such a fluffy commit as saving an intermediate stage of a real txn. That's irrelevant to a later write-txn wanting to not touch the last two durable snapshots. It's only relevant vs. oldest reader. So. 3rd metapage and variants - I've tried and Howard pointed out the flaws, Howard tried and I said here we go again. We do not need another round, but it's just as well to have it summarized here. (This discussion ignores MDB_NOSYNC and partly MDB_NOLOCK - if the user enables either, it's his responsibility to compensate.) -- Hallvard

1 0

Re: (ITS#8474) Securely Erase BerElement Buffer After Use
by alcronin＠cisco.com 09 Aug '16

09 Aug '16

SGksDQoNCkkgY2FuIHRha2UgYSBsb29rIGF0IHRoZSBzbGFwZCBzaWRlIGFuZCB0aG9zZSBvdGhl ciByZXF1ZXN0cyBhbmQgaW1wbGVtZW50IHRoZSBmaXggdGhlcmUgYXMgd2VsbC4gSWYgdGhlcmUg YXJlIGFueSBvdGhlciBhcmVhcyBsZXQgbWUga25vdyBhbmQgSSBjYW4gYWRkcmVzcyB0aGVtIHRv LiBJIHdpbGwgdXBkYXRlIHRoZSBwYXRjaCB3aGVuIEkgaGF2ZSB0aG9zZSBjaGFuZ2VzIHJlYWR5 Lg0KDQpUaGUgY29tcGlsZXJzIHdpbGwgdHJlYXQgdGhhdCAobWVtc2V0IGJlaGF2aW91cikgYXMg YW4gb3B0aW1pemF0aW9uIGFuZCB3b3VsZCBiZSBoZXNpdGFudCB0byBjaGFuZ2UgaXQuIFRoaXMg aXMgbW9zdGx5IHNlZW4gaW4gR0NDIGFuZCBhbnkgdmFyaWFudHMuIFRoZXJlIGFyZSBvdGhlciBv cHRpbWlzYXRpb25zIHN1Y2ggYXMgcmVtb3ZpbmcgdGhlIGNhbGwgdG8gdGhlIG1ldGhvZCBlbnRp cmVseSBpZiB0aGUgbmV4dCBvcGVyYXRpb24gaXMgYSBmcmVlIGFzIHRoaXMgd291bGQgYmUgc2Vl biBieSB0aGUgY29tcGlsZXIgYXMgYSBuby1vcC4gUmVtb3Zpbmcgb3B0aW1pc2F0aW9ucyBpcyBu b3QgaWRlYWwgYXMgaXQgY2FuIGFmZmVjdCBtb3JlIHRoYW4ganVzdCB0aGUgc2VjdGlvbiBvZiB0 aGUgY29kZSBhbmQgaXMgbm90IGEgY3Jvc3MgcGxhdGZvcm0gc29sdXRpb24uDQoNClRoYW5rcywN CkFsYW4NCg0KT24gMDgvMDgvMjAxNiwgMjE6MzcsICJIb3dhcmQgQ2h1IiA8aHljQHN5bWFzLmNv bT4gd3JvdGU6DQoNCiAgICBBbGFuIENyb25pbiAoYWxjcm9uaW4pIHdyb3RlOg0KICAgID4gSGkg SG93YXJkLA0KICAgID4NCiAgICA+IEkgY2FuIGNoYW5nZSB0aGUgY29kZSBzbyB0aGF0IGl0IG92 ZXJ3cml0ZXMgdGhlIG1lbW9yeSBmcm9tDQogICAgbGRhcF9mcmVlX3JlcXVlc3RfaW50KCkgaW5z dGVhZC4gVGhpcyB3aWxsIGNvdmVyIHRoZSBleGVjdXRpb24gdXNpbmcgYSBiaW5kDQogICAgKGJv dGggc3luY2hyb25vdXMgYW5kIGFzeW5jaHJvbm91cykuIElzIHRoZXJlIGFueSBvdGhlciBwbGFj ZXMgd2hlcmUgdGhlDQogICAgcGFzc3dvcmQgd291bGQgYmUgaW4gdGhlIGJ1ZmZlciB0aGF0IG5l ZWRzIHRvIGJlIGNsZWFyZWQ/IFRoZSByZWFzb24gZm9yDQogICAgaW5zZXJ0aW5nIGl0IGludG8g YmVyX2ZyZWVfYnVmKCkgd2FzIHRoYXQgaXQgd291bGQgY2xlYXIgYWxsIHBsYWNlcy4NCiAgICAN CiAgICBJIHNlZSwgeW91J3JlIGxvb2tpbmcgYXQgdGhlIGNsaWVudCBzaWRlLiBXaGF0IGFib3V0 IHRoZSBzbGFwZCBzaWRlPw0KICAgIA0KICAgIFRoZXJlIGFyZSAyIG1haW4gcGxhY2VzIHdoZXJl IHBhc3N3b3JkcyBvY2N1ciAtIEJpbmQsIGFuZCBQYXNzd29yZE1vZGlmeSBleG9wLiANCiAgICBU aGV5IG1pZ2h0IGFsc28gb2NjdXIgaW4gQWRkIGFuZCBNb2RpZnkgcmVxdWVzdHMuIEFkZCBpcyBu b3Qgc28gdW51c3VhbCwgDQogICAgTW9kaWZ5IHNob3VsZCBub3QgaGFwcGVuIHNpbmNlIGNsaWVu dHMgc2hvdWxkIHVzZSBQYXNzd29yZE1vZGlmeSBpbnN0ZWFkLg0KICAgIA0KICAgID4gU29tZSBj b21waWxlcnMgd2lsbCBvcHRpbWl6ZSBjYWxscyB0byBtZW1zZXQoKSBzbyB0aGF0IG9ubHkgdGhl IGZpcnN0DQogICAgY2hhcmFjdGVyIHdpbGwgYmUgY2hhbmdlZC4gTGVhdmluZyB0aGUgcmVzdCBv ZiB0aGUgc3RyaW5nIGludGFjdC4NCiAgICANCiAgICBUaGF0J3MgY2xlYXJseSBhIGNvbXBpbGVy IGJ1ZyB0aGVuLiBJZiB5b3UgaGF2ZSBleGFtcGxlcyBvZiBzdWNoIHNpdHVhdGlvbnMgDQogICAg eW91IHNob3VsZCByZXBvcnQgdGhhdCB0byB0aGUgcmVzcGVjdGl2ZSBjb21waWxlciBtYWludGFp bmVycy4NCiAgICANCiAgICA+IFRoaXMgaXMgd2h5DQogICAgdGhlIGl0ZXJhdGlvbiBpcyBpbiBw bGFjZS4NCiAgICA+DQogICAgPiBUaGFua3MgZm9yIGxvb2tpbmcgaW50byB0aGlzIHBhdGNoLg0K ICAgID4NCiAgICA+IEFsYW4NCiAgICA+DQogICAgPiBPbiAwNS8wOC8yMDE2LCAxOTo1MCwgIkhv d2FyZCBDaHUiIDxoeWNAc3ltYXMuY29tPiB3cm90ZToNCiAgICA+DQogICAgPiAgICAgIGFsY3Jv bmluQGNpc2NvLmNvbSB3cm90ZToNCiAgICA+ICAgICAgPiBGdWxsX05hbWU6IEFsYW4gQ3Jvbmlu DQogICAgPiAgICAgID4gVmVyc2lvbjogMi40LjQ0DQogICAgPiAgICAgID4gT1M6IFdpbmRvd3Mg OC4xDQogICAgPiAgICAgID4gVVJMOiBodHRwczovL2RsLmRyb3Bib3h1c2VyY29udGVudC5jb20v dS84MjM0MzQ3NS9TZWN1cmVseUVyYXNlQnVmZmVyLmRpZmYNCiAgICA+ICAgICAgPiBTdWJtaXNz aW9uIGZyb206IChOVUxMKSAoMjAwMTo0MjA6NDA0MToyMDAzOmY5NDI6NTlhNTo1NDVmOmIzMzQp DQogICAgPiAgICAgID4NCiAgICA+ICAgICAgPg0KICAgID4gICAgICA+IFRoZSBmb2xsb3dpbmcg cGF0Y2ggaXMgYSBtb2RpZmljYXRpb24gdG8gdGhlIE9wZW5MREFQIEJlckVsZW1lbnQgYnVmZmVy LiBUaGUNCiAgICA+ICAgICAgPiBidWZmZXIgY2FuIGJlIHVzZWQgdG8gY29udGFpbiB0aGUgTERB UCByZXF1ZXN0IGluY2x1ZGluZyB0aGUgcGFzc3dvcmQgZm9yDQogICAgPiAgICAgID4gYXV0aGVu dGljYXRpb24uIFdoaWxlIHRoaXMgaXMgZnJlZSdkIHdoZW4gaXQgaXMgbm8gbG9uZ2VyIG5lZWRl ZCwgdGhlIGNvbnRlbnRzDQogICAgPiAgICAgID4gb2YgdGhlIGJ1ZmZlciBpcyBub3Qgb3Zlcndy aXR0ZW4gZnJvbSBtZW1vcnkuIFRoaXMgY2FuIGxlYWQgdG8gc29tZW9uZSByZWFkaW5nDQogICAg PiAgICAgID4gdGhlIG1lbW9yeSBvZiB0aGUgcHJvY2VzcyBhbmQgZGV0ZXJtaW5pbmcgd2hhdCB0 aGUgcGFzc3dvcmQgaXMuIFRoZSBjaGFuZ2UNCiAgICA+ICAgICAgPiBpbmNsdWRlZCBpbiB0aGlz IHBhdGNoIHdpbGwgaXRlcmF0ZSBvdmVyIHRoZSBtZW1vcnkgYW5kIGNsZWFyIGl0LiBUaGlzIHdp bGwNCiAgICA+ICAgICAgPiByZW1vdmUgYW55IHRyYWNlIG9mIHRoZSBwYXNzd29yZCBieSB0aGUg dGltZSBleGVjdXRpb24gaXMgaGFuZGVkIGJhY2sgdG8gdGhlDQogICAgPiAgICAgID4gY2FsbGVy Lg0KICAgID4NCiAgICA+ICAgICAgV2h5IHdvdWxkIHlvdSBpbnNlcnQgYSBwZXJmb3JtYW5jZSBw ZXNzaW1pemF0aW9uIGludG8gZXZlcnkgdXNlIG9mIHRoZSBMQkVSDQogICAgPiAgICAgIGxpYnJh cnksIHJhdGhlciB0aGFuIGp1c3QgZXJhc2luZyB0aGUgcGFzc3dvcmQgZnJvbSBhIEJpbmQgcmVx dWVzdD8NCiAgICA+DQogICAgPiAgICAgIFdoeSB3b3VsZCB5b3UgdXNlIGFuIGV4cGxpY2l0bHkg Y29kZWQgbG9vcCBzZXR0aW5nIG9uZSBjaGFyYWN0ZXIgYXQgYSB0aW1lLA0KICAgID4gICAgICBp bnN0ZWFkIG9mIHVzaW5nIGxpYmMncyBtZW1zZXQoKSB3aGljaCBoYXMgcHJvYmFibHkgYmVlbiB3 ZWxsIG9wdGltaXplZD8NCiAgICA+DQogICAgPiAgICAgID4gVGhlIGF0dGFjaGVkIHBhdGNoIGZp bGUgaXMgZGVyaXZlZCBmcm9tIE9wZW5MREFQIFNvZnR3YXJlLiBBbGwgb2YgdGhlDQogICAgPiAg ICAgID4gbW9kaWZpY2F0aW9ucyB0byBPcGVuTERBUCBTb2Z0d2FyZSByZXByZXNlbnRlZCBpbiB0 aGUgZm9sbG93aW5nIHBhdGNoKGVzKSB3ZXJlDQogICAgPiAgICAgID4gZGV2ZWxvcGVkIGJ5IEFs YW4gQ3JvbmluIGFsY3JvbmluQGNpc2NvLmNvbS4gSSBoYXZlIG5vdCBhc3NpZ25lZCByaWdodHMg YW5kL29yDQogICAgPiAgICAgID4gaW50ZXJlc3QgaW4gdGhpcyB3b3JrIHRvIGFueSBwYXJ0eS4N CiAgICA+ICAgICAgPiBUaGUgYXR0YWNoZWQgZmlsZSBpcyBkZXJpdmVkIGZyb20gT3BlbkxEQVAg U29mdHdhcmUuIEFsbCBvZiB0aGUgbW9kaWZpY2F0aW9ucyB0bw0KICAgID4gICAgICA+IE9wZW5M REFQIFNvZnR3YXJlIHJlcHJlc2VudGVkIGluIHRoZSBmb2xsb3dpbmcgcGF0Y2goZXMpIHdlcmUg ZGV2ZWxvcGVkIGJ5IENpc2NvDQogICAgPiAgICAgID4gU3lzdGVtcywgSW5jLi4gQ2lzY28gU3lz dGVtcywgSW5jLiBoYXMgbm90IGFzc2lnbmVkIHJpZ2h0cyBhbmQvb3IgaW50ZXJlc3QgaW4NCiAg ICA+ICAgICAgPiB0aGlzIHdvcmsgdG8gYW55IHBhcnR5LiBJLCBBbGFuIENyb25pbiBhbSBhdXRo b3JpemVkIGJ5IENpc2NvIFN5c3RlbXMsIEluYy4sIG15DQogICAgPiAgICAgID4gZW1wbG95ZXIs IHRvIHJlbGVhc2UgdGhpcyB3b3JrIHVuZGVyIHRoZSBmb2xsb3dpbmcgdGVybXMuDQogICAgPiAg ICAgID4gQ2lzY28gU3lzdGVtcywgSW5jLiBoZXJlYnkgcGxhY2UgdGhlIGZvbGxvd2luZyBtb2Rp ZmljYXRpb25zIHRvIE9wZW5MREFQDQogICAgPiAgICAgID4gU29mdHdhcmUgKGFuZCBvbmx5IHRo ZXNlIG1vZGlmaWNhdGlvbnMpIGludG8gdGhlIHB1YmxpYyBkb21haW4uIEhlbmNlLCB0aGVzZQ0K ICAgID4gICAgICA+IG1vZGlmaWNhdGlvbnMgbWF5IGJlIGZyZWVseSB1c2VkIGFuZC9vciByZWRp c3RyaWJ1dGVkIGZvciBhbnkgcHVycG9zZSB3aXRoIG9yDQogICAgPiAgICAgID4gd2l0aG91dCBh dHRyaWJ1dGlvbiBhbmQvb3Igb3RoZXIgbm90aWNlLg0KICAgID4gICAgICA+DQogICAgPiAgICAg ID4NCiAgICA+DQogICAgPg0KICAgID4gICAgICAtLQ0KICAgID4gICAgICAgICAtLSBIb3dhcmQg Q2h1DQogICAgPiAgICAgICAgIENUTywgU3ltYXMgQ29ycC4gICAgICAgICAgIGh0dHA6Ly93d3cu c3ltYXMuY29tDQogICAgPiAgICAgICAgIERpcmVjdG9yLCBIaWdobGFuZCBTdW4gICAgIGh0dHA6 Ly9oaWdobGFuZHN1bi5jb20vaHljLw0KICAgID4gICAgICAgICBDaGllZiBBcmNoaXRlY3QsIE9w ZW5MREFQICBodHRwOi8vd3d3Lm9wZW5sZGFwLm9yZy9wcm9qZWN0Lw0KICAgID4NCiAgICA+DQog ICAgDQogICAgDQogICAgLS0gDQogICAgICAgLS0gSG93YXJkIENodQ0KICAgICAgIENUTywgU3lt YXMgQ29ycC4gICAgICAgICAgIGh0dHA6Ly93d3cuc3ltYXMuY29tDQogICAgICAgRGlyZWN0b3Is IEhpZ2hsYW5kIFN1biAgICAgaHR0cDovL2hpZ2hsYW5kc3VuLmNvbS9oeWMvDQogICAgICAgQ2hp ZWYgQXJjaGl0ZWN0LCBPcGVuTERBUCAgaHR0cDovL3d3dy5vcGVubGRhcC5vcmcvcHJvamVjdC8N CiAgICANCg0K

1 0

Re: (ITS#8474) Securely Erase BerElement Buffer After Use
by hyc＠symas.com 08 Aug '16

08 Aug '16

Alan Cronin (alcronin) wrote: > Hi Howard, > > I can change the code so that it overwrites the memory from ldap_free_request_int() instead. This will cover the execution using a bind (both synchronous and asynchronous). Is there any other places where the password would be in the buffer that needs to be cleared? The reason for inserting it into ber_free_buf() was that it would clear all places. I see, you're looking at the client side. What about the slapd side? There are 2 main places where passwords occur - Bind, and PasswordModify exop. They might also occur in Add and Modify requests. Add is not so unusual, Modify should not happen since clients should use PasswordModify instead. > Some compilers will optimize calls to memset() so that only the first character will be changed. Leaving the rest of the string intact. That's clearly a compiler bug then. If you have examples of such situations you should report that to the respective compiler maintainers. > This is why the iteration is in place. > > Thanks for looking into this patch. > > Alan > > On 05/08/2016, 19:50, "Howard Chu" <hyc(a)symas.com> wrote: > > alcronin(a)cisco.com wrote: > > Full_Name: Alan Cronin > > Version: 2.4.44 > > OS: Windows 8.1 > > URL: https://dl.dropboxusercontent.com/u/82343475/SecurelyEraseBuffer.diff > > Submission from: (NULL) (2001:420:4041:2003:f942:59a5:545f:b334) > > > > > > The following patch is a modification to the OpenLDAP BerElement buffer. The > > buffer can be used to contain the LDAP request including the password for > > authentication. While this is free'd when it is no longer needed, the contents > > of the buffer is not overwritten from memory. This can lead to someone reading > > the memory of the process and determining what the password is. The change > > included in this patch will iterate over the memory and clear it. This will > > remove any trace of the password by the time execution is handed back to the > > caller. > > Why would you insert a performance pessimization into every use of the LBER > library, rather than just erasing the password from a Bind request? > > Why would you use an explicitly coded loop setting one character at a time, > instead of using libc's memset() which has probably been well optimized? > > > The attached patch file is derived from OpenLDAP Software. All of the > > modifications to OpenLDAP Software represented in the following patch(es) were > > developed by Alan Cronin alcronin(a)cisco.com. I have not assigned rights and/or > > interest in this work to any party. > > The attached file is derived from OpenLDAP Software. All of the modifications to > > OpenLDAP Software represented in the following patch(es) were developed by Cisco > > Systems, Inc.. Cisco Systems, Inc. has not assigned rights and/or interest in > > this work to any party. I, Alan Cronin am authorized by Cisco Systems, Inc., my > > employer, to release this work under the following terms. > > Cisco Systems, Inc. hereby place the following modifications to OpenLDAP > > Software (and only these modifications) into the public domain. Hence, these > > modifications may be freely used and/or redistributed for any purpose with or > > without attribution and/or other notice. > > > > > > > -- > -- Howard Chu > CTO, Symas Corp. http://www.symas.com > Director, Highland Sun http://highlandsun.com/hyc/ > Chief Architect, OpenLDAP http://www.openldap.org/project/ > > -- -- 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#8475) Feature request: MDB low durability transactions
by bentrask＠comcast.net 08 Aug '16

08 Aug '16

On 08/08/2016 05:41 AM, Hallvard Breien Furuseth wrote: > A transaction must not reuse data pages visible in the last snapshot > known to be durable, since that's how far back LDMB may need to revert > after abnormal termination. Like a crash after MDB_NOMETASYNC may do. > > Sync the data pages from a txn, write the metapage, eventually sync > that metapage, wait out any older read-only transactions, and *then* > you can reuse the pages the txn freed. Not before. So when you don't > sync, or a read-only txn won't die, LMDB degenerates to append-only. > > ...except if you sync the metapage and exit, next LMDB run may not > know you synced it and must assume the metapage isn't yet durable. > So it might not reuse pages visible to the _previous_ durable > metapage, until it syncs. I'm rather losing track at this point, > but I think it may mean twice as may not-yet-usable pages as one > might expect. Concretely: say the current write transaction is number 10, and a long-lived reader is on number 7. Currently, MDB will be unable to reuse any pages used in transactions 7+ until the reader ends. Now say a 3rd, durable root is added. For the sake of argument, no checksums are used and in the event of a crash, only the last durable state is recovered. Say the durable transaction is number 2. Pages used in transaction 2 need to be preserved, obviously. 7+ still need to be preserved for the slow reader. But pages from transactions 3-6 can be reused. Note that the last durable transaction is controlled purely by the single writer, so tracking it is actually easier than tracking which readers are where. If a crash happens before a durable root is fully synced, then there should be a second, older durable root that hasn't been reused yet. In that case MDB recovers the way it does currently. Does this make sense? Thanks for bearing with me.

1 0

Re: (ITS#8474) Securely Erase BerElement Buffer After Use
by alcronin＠cisco.com 08 Aug '16

08 Aug '16

SGkgSG93YXJkLA0KDQpJIGNhbiBjaGFuZ2UgdGhlIGNvZGUgc28gdGhhdCBpdCBvdmVyd3JpdGVz IHRoZSBtZW1vcnkgZnJvbSBsZGFwX2ZyZWVfcmVxdWVzdF9pbnQoKSBpbnN0ZWFkLiBUaGlzIHdp bGwgY292ZXIgdGhlIGV4ZWN1dGlvbiB1c2luZyBhIGJpbmQgKGJvdGggc3luY2hyb25vdXMgYW5k IGFzeW5jaHJvbm91cykuIElzIHRoZXJlIGFueSBvdGhlciBwbGFjZXMgd2hlcmUgdGhlIHBhc3N3 b3JkIHdvdWxkIGJlIGluIHRoZSBidWZmZXIgdGhhdCBuZWVkcyB0byBiZSBjbGVhcmVkPyBUaGUg cmVhc29uIGZvciBpbnNlcnRpbmcgaXQgaW50byBiZXJfZnJlZV9idWYoKSB3YXMgdGhhdCBpdCB3 b3VsZCBjbGVhciBhbGwgcGxhY2VzLg0KDQpTb21lIGNvbXBpbGVycyB3aWxsIG9wdGltaXplIGNh bGxzIHRvIG1lbXNldCgpIHNvIHRoYXQgb25seSB0aGUgZmlyc3QgY2hhcmFjdGVyIHdpbGwgYmUg Y2hhbmdlZC4gTGVhdmluZyB0aGUgcmVzdCBvZiB0aGUgc3RyaW5nIGludGFjdC4gVGhpcyBpcyB3 aHkgdGhlIGl0ZXJhdGlvbiBpcyBpbiBwbGFjZS4NCg0KVGhhbmtzIGZvciBsb29raW5nIGludG8g dGhpcyBwYXRjaC4NCg0KQWxhbg0KDQpPbiAwNS8wOC8yMDE2LCAxOTo1MCwgIkhvd2FyZCBDaHUi IDxoeWNAc3ltYXMuY29tPiB3cm90ZToNCg0KICAgIGFsY3JvbmluQGNpc2NvLmNvbSB3cm90ZToN CiAgICA+IEZ1bGxfTmFtZTogQWxhbiBDcm9uaW4NCiAgICA+IFZlcnNpb246IDIuNC40NA0KICAg ID4gT1M6IFdpbmRvd3MgOC4xDQogICAgPiBVUkw6IGh0dHBzOi8vZGwuZHJvcGJveHVzZXJjb250 ZW50LmNvbS91LzgyMzQzNDc1L1NlY3VyZWx5RXJhc2VCdWZmZXIuZGlmZg0KICAgID4gU3VibWlz c2lvbiBmcm9tOiAoTlVMTCkgKDIwMDE6NDIwOjQwNDE6MjAwMzpmOTQyOjU5YTU6NTQ1ZjpiMzM0 KQ0KICAgID4NCiAgICA+DQogICAgPiBUaGUgZm9sbG93aW5nIHBhdGNoIGlzIGEgbW9kaWZpY2F0 aW9uIHRvIHRoZSBPcGVuTERBUCBCZXJFbGVtZW50IGJ1ZmZlci4gVGhlDQogICAgPiBidWZmZXIg Y2FuIGJlIHVzZWQgdG8gY29udGFpbiB0aGUgTERBUCByZXF1ZXN0IGluY2x1ZGluZyB0aGUgcGFz c3dvcmQgZm9yDQogICAgPiBhdXRoZW50aWNhdGlvbi4gV2hpbGUgdGhpcyBpcyBmcmVlJ2Qgd2hl biBpdCBpcyBubyBsb25nZXIgbmVlZGVkLCB0aGUgY29udGVudHMNCiAgICA+IG9mIHRoZSBidWZm ZXIgaXMgbm90IG92ZXJ3cml0dGVuIGZyb20gbWVtb3J5LiBUaGlzIGNhbiBsZWFkIHRvIHNvbWVv bmUgcmVhZGluZw0KICAgID4gdGhlIG1lbW9yeSBvZiB0aGUgcHJvY2VzcyBhbmQgZGV0ZXJtaW5p bmcgd2hhdCB0aGUgcGFzc3dvcmQgaXMuIFRoZSBjaGFuZ2UNCiAgICA+IGluY2x1ZGVkIGluIHRo aXMgcGF0Y2ggd2lsbCBpdGVyYXRlIG92ZXIgdGhlIG1lbW9yeSBhbmQgY2xlYXIgaXQuIFRoaXMg d2lsbA0KICAgID4gcmVtb3ZlIGFueSB0cmFjZSBvZiB0aGUgcGFzc3dvcmQgYnkgdGhlIHRpbWUg ZXhlY3V0aW9uIGlzIGhhbmRlZCBiYWNrIHRvIHRoZQ0KICAgID4gY2FsbGVyLg0KICAgIA0KICAg IFdoeSB3b3VsZCB5b3UgaW5zZXJ0IGEgcGVyZm9ybWFuY2UgcGVzc2ltaXphdGlvbiBpbnRvIGV2 ZXJ5IHVzZSBvZiB0aGUgTEJFUiANCiAgICBsaWJyYXJ5LCByYXRoZXIgdGhhbiBqdXN0IGVyYXNp bmcgdGhlIHBhc3N3b3JkIGZyb20gYSBCaW5kIHJlcXVlc3Q/DQogICAgDQogICAgV2h5IHdvdWxk IHlvdSB1c2UgYW4gZXhwbGljaXRseSBjb2RlZCBsb29wIHNldHRpbmcgb25lIGNoYXJhY3RlciBh dCBhIHRpbWUsIA0KICAgIGluc3RlYWQgb2YgdXNpbmcgbGliYydzIG1lbXNldCgpIHdoaWNoIGhh cyBwcm9iYWJseSBiZWVuIHdlbGwgb3B0aW1pemVkPw0KICAgIA0KICAgID4gVGhlIGF0dGFjaGVk IHBhdGNoIGZpbGUgaXMgZGVyaXZlZCBmcm9tIE9wZW5MREFQIFNvZnR3YXJlLiBBbGwgb2YgdGhl DQogICAgPiBtb2RpZmljYXRpb25zIHRvIE9wZW5MREFQIFNvZnR3YXJlIHJlcHJlc2VudGVkIGlu IHRoZSBmb2xsb3dpbmcgcGF0Y2goZXMpIHdlcmUNCiAgICA+IGRldmVsb3BlZCBieSBBbGFuIENy b25pbiBhbGNyb25pbkBjaXNjby5jb20uIEkgaGF2ZSBub3QgYXNzaWduZWQgcmlnaHRzIGFuZC9v cg0KICAgID4gaW50ZXJlc3QgaW4gdGhpcyB3b3JrIHRvIGFueSBwYXJ0eS4NCiAgICA+IFRoZSBh dHRhY2hlZCBmaWxlIGlzIGRlcml2ZWQgZnJvbSBPcGVuTERBUCBTb2Z0d2FyZS4gQWxsIG9mIHRo ZSBtb2RpZmljYXRpb25zIHRvDQogICAgPiBPcGVuTERBUCBTb2Z0d2FyZSByZXByZXNlbnRlZCBp biB0aGUgZm9sbG93aW5nIHBhdGNoKGVzKSB3ZXJlIGRldmVsb3BlZCBieSBDaXNjbw0KICAgID4g U3lzdGVtcywgSW5jLi4gQ2lzY28gU3lzdGVtcywgSW5jLiBoYXMgbm90IGFzc2lnbmVkIHJpZ2h0 cyBhbmQvb3IgaW50ZXJlc3QgaW4NCiAgICA+IHRoaXMgd29yayB0byBhbnkgcGFydHkuIEksIEFs YW4gQ3JvbmluIGFtIGF1dGhvcml6ZWQgYnkgQ2lzY28gU3lzdGVtcywgSW5jLiwgbXkNCiAgICA+ IGVtcGxveWVyLCB0byByZWxlYXNlIHRoaXMgd29yayB1bmRlciB0aGUgZm9sbG93aW5nIHRlcm1z Lg0KICAgID4gQ2lzY28gU3lzdGVtcywgSW5jLiBoZXJlYnkgcGxhY2UgdGhlIGZvbGxvd2luZyBt b2RpZmljYXRpb25zIHRvIE9wZW5MREFQDQogICAgPiBTb2Z0d2FyZSAoYW5kIG9ubHkgdGhlc2Ug bW9kaWZpY2F0aW9ucykgaW50byB0aGUgcHVibGljIGRvbWFpbi4gSGVuY2UsIHRoZXNlDQogICAg PiBtb2RpZmljYXRpb25zIG1heSBiZSBmcmVlbHkgdXNlZCBhbmQvb3IgcmVkaXN0cmlidXRlZCBm b3IgYW55IHB1cnBvc2Ugd2l0aCBvcg0KICAgID4gd2l0aG91dCBhdHRyaWJ1dGlvbiBhbmQvb3Ig b3RoZXIgbm90aWNlLg0KICAgID4NCiAgICA+DQogICAgDQogICAgDQogICAgLS0gDQogICAgICAg LS0gSG93YXJkIENodQ0KICAgICAgIENUTywgU3ltYXMgQ29ycC4gICAgICAgICAgIGh0dHA6Ly93 d3cuc3ltYXMuY29tDQogICAgICAgRGlyZWN0b3IsIEhpZ2hsYW5kIFN1biAgICAgaHR0cDovL2hp Z2hsYW5kc3VuLmNvbS9oeWMvDQogICAgICAgQ2hpZWYgQXJjaGl0ZWN0LCBPcGVuTERBUCAgaHR0 cDovL3d3dy5vcGVubGRhcC5vcmcvcHJvamVjdC8NCiAgICANCg0K

1 0

Re: (ITS#8475) Feature request: MDB low durability transactions
by h.b.furuseth＠usit.uio.no 08 Aug '16

08 Aug '16

On 08/08/16 03:51, bentrask(a)comcast.net wrote: > The idea was that the two "floating" roots would reuse pages the way MDB > does now. The 3rd durable root would have its pages preserved > separately. I can see why this would cause up to a ~2X storage increase > as the two sets diverged, but I don't see why it would need to grow > unbounded. Apologies for this stupid question. A transaction must not reuse data pages visible in the last snapshot known to be durable, since that's how far back LDMB may need to revert after abnormal termination. Like a crash after MDB_NOMETASYNC may do. Sync the data pages from a txn, write the metapage, eventually sync that metapage, wait out any older read-only transactions, and *then* you can reuse the pages the txn freed. Not before. So when you don't sync, or a read-only txn won't die, LMDB degenerates to append-only. ...except if you sync the metapage and exit, next LMDB run may not know you synced it and must assume the metapage isn't yet durable. So it might not reuse pages visible to the _previous_ durable metapage, until it syncs. I'm rather losing track at this point, but I think it may mean twice as may not-yet-usable pages as one might expect.

1 0

Re: (ITS#8475) Feature request: MDB low durability transactions
by bentrask＠comcast.net 08 Aug '16

08 Aug '16

On 08/07/2016 09:29 PM, Howard Chu wrote: > Knowing whether or not the root pages are pristine still doesn't tell > you anything about whether the data pages are intact. The only way to > make any of these schemes work is to avoid overwriting/reusing any data > pages for the last N transactions. I.e., reverting to append-only > behavior. So the underlying question (which we have wrestled with > internally for quite some time) which you haven't asked or answered - > how many of these non-durable transactions will you support at any given > time? The idea was that the two "floating" roots would reuse pages the way MDB does now. The 3rd durable root would have its pages preserved separately. I can see why this would cause up to a ~2X storage increase as the two sets diverged, but I don't see why it would need to grow unbounded. Apologies for this stupid question.

1 0

Re: (ITS#8475) Feature request: MDB low durability transactions
by hyc＠symas.com 08 Aug '16

08 Aug '16

Ben Trask wrote: > On 08/07/2016 05:44 PM, Howard Chu wrote: >> The only way to guarantee integrity is with ordered writes. All SCSI >> devices support this feature, but e.g. the Linux kernel does not (and >> neither does SATA, and no idea about PCIe SSDs...). >> >> Lacking a portable mechanism for ordered writes, you have two choices >> for preserving integrity - append-only operation (which forces ordered >> writes anyway) or at least one synchronous write somewhere. >> >> Whenever you decide to reuse existing pages rather than operating as >> append-only, you create the possibility of overwriting some required >> data before it was safe to do so. Your 3-root checksum scheme *might* >> let you detect that the DB is corrupted, but it *won't* let you recover >> to a clean state. Given that writes occur in unpredictable order, >> without fsyncs there is no way you can guarantee that anything sane is >> on the disk. > > Consider three roots without any checksums. Each root has a simple flag > indicating whether it was written durably (fsync write barrier). During > recovery, non-durable roots are simply ignored/discarded. This is equivalent > to Hallvard's suggestion for volatile meta-pages. I think it's pretty clear > this is workable. > > From there, checksums just give you slightly stronger guarantees, although > they might not be worth the overhead (CPU/storage) and recovery complexity. Knowing whether or not the root pages are pristine still doesn't tell you anything about whether the data pages are intact. The only way to make any of these schemes work is to avoid overwriting/reusing any data pages for the last N transactions. I.e., reverting to append-only behavior. So the underlying question (which we have wrestled with internally for quite some time) which you haven't asked or answered - how many of these non-durable transactions will you support at any given time? -- -- 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#8475) Feature request: MDB low durability transactions
by bentrask＠comcast.net 08 Aug '16

08 Aug '16

On 08/07/2016 05:44 PM, Howard Chu wrote: > The only way to guarantee integrity is with ordered writes. All SCSI > devices support this feature, but e.g. the Linux kernel does not (and > neither does SATA, and no idea about PCIe SSDs...). > > Lacking a portable mechanism for ordered writes, you have two choices > for preserving integrity - append-only operation (which forces ordered > writes anyway) or at least one synchronous write somewhere. > > Whenever you decide to reuse existing pages rather than operating as > append-only, you create the possibility of overwriting some required > data before it was safe to do so. Your 3-root checksum scheme *might* > let you detect that the DB is corrupted, but it *won't* let you recover > to a clean state. Given that writes occur in unpredictable order, > without fsyncs there is no way you can guarantee that anything sane is > on the disk. Consider three roots without any checksums. Each root has a simple flag indicating whether it was written durably (fsync write barrier). During recovery, non-durable roots are simply ignored/discarded. This is equivalent to Hallvard's suggestion for volatile meta-pages. I think it's pretty clear this is workable. From there, checksums just give you slightly stronger guarantees, although they might not be worth the overhead (CPU/storage) and recovery complexity.

1 0

Re: (ITS#8475) Feature request: MDB low durability transactions
by hyc＠symas.com 07 Aug '16

07 Aug '16

bentrask(a)comcast.net wrote: > Thanks for the replies, Hallvard and Howard! > > I was mistaken in thinking that NOMETASYNC didn't guarantee integrity. > However, my proposal would allow fsync to be omitted entirely. > > I think my approach with three roots is better than a WAL because it > keeps the read and write paths simpler and more uniform. It also doesn't > force periodic fsyncs when the log wraps, or consume unbounded space. In > fact it's very similar to the basic design of MDB. > > You're right that you'd actually need to record the page's checksum in > the parent, rather than in the page itself. I guess this would hurt the > branching factor. And then it's turtles all the way down. What you're suggesting won't work. Trust me when I say we have spent far more time thinking about this question than you have. The only way to guarantee integrity is with ordered writes. All SCSI devices support this feature, but e.g. the Linux kernel does not (and neither does SATA, and no idea about PCIe SSDs...). Lacking a portable mechanism for ordered writes, you have two choices for preserving integrity - append-only operation (which forces ordered writes anyway) or at least one synchronous write somewhere. Whenever you decide to reuse existing pages rather than operating as append-only, you create the possibility of overwriting some required data before it was safe to do so. Your 3-root checksum scheme *might* let you detect that the DB is corrupted, but it *won't* let you recover to a clean state. Given that writes occur in unpredictable order, without fsyncs there is no way you can guarantee that anything sane is on the disk. -- -- 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#8475) Feature request: MDB low durability transactions
by bentrask＠comcast.net 07 Aug '16

07 Aug '16

Thanks for the replies, Hallvard and Howard! I was mistaken in thinking that NOMETASYNC didn't guarantee integrity. However, my proposal would allow fsync to be omitted entirely. I think my approach with three roots is better than a WAL because it keeps the read and write paths simpler and more uniform. It also doesn't force periodic fsyncs when the log wraps, or consume unbounded space. In fact it's very similar to the basic design of MDB. You're right that you'd actually need to record the page's checksum in the parent, rather than in the page itself. I guess this would hurt the branching factor. Thanks again, Ben On 08/06/2016 12:42 PM, Hallvard Breien Furuseth wrote: > On 06. aug. 2016 17:38, bentrask(a)comcast.net wrote: >> Transaction commits are one of the few bottlenecks in MDB, because it >> has to >> fsync twice, sequentially. >> >> I think MDB could support mixed low and high durability transactions >> in the same >> database by adding per-page checksums and a third root page. The idea >> is that >> when committing a low-durability transaction, no fsyncs are performed. >> (...) > > Yesno. We can get rid of fsyncs, but not that way. Checksumming each > page isn't enough. We must know it's the right version of the page and > not e.g. a similar page from a previous aborted transaction. To commit > a branch or meta page, we'd need to scan its children and checksum the > page headers (thus including their checksum) of each. Expensive. > > IIRC there are three things we can do: > > - Use and fsync a WAL (write-ahead log) instead of the database pages. > That can be cheaper because it writes one contiguous region instead > of a lot of random-access pages. Requires recovery after a crash. > > - Volatile metapages which mdb_env_open() _always_ throws away if no > other environment is already open. They are lost of the application > crashes/exits without doing a final checkpoint. > > - Improve that a bit: Put them in a shared memory region, since that > won't survive a system crash (unlike if we put them in the lockfile). > That way they'll survive application crash provided something does > a checkpoint before next system crash. > > We've discussed these sometimes and there are caveats for some of them, > I don't quite remember. One issue is that a "system crash" isn't the > only thing which can lose unsynced pages. Another is unmounting and > re-mounting the disk (i.e. an USB disk). >

1 0

(ITS#8476) slapo-constraint: info per constraint_attribute
by michael＠stroeder.com 07 Aug '16

07 Aug '16

Full_Name: Version: OS: URL: Submission from: (NULL) (213.240.180.113) If your configuration has lots of overlapping constraints affecting the same attributes finding out which constraint was violated can be hard for the user. Therefore it would be nice if one could add a specific message to a constraint_attribute directive to be returned as LDAP diagnosticMessage if a specific constraint is violated. Ahem. Personally I'd add there what I have in the comments above the constraint_attribute directive. So this could also be handy for dynamic configuration with cn=config. ;-)

1 0

Re: (ITS#8475) Feature request: MDB low durability transactions
by h.b.furuseth＠usit.uio.no 06 Aug '16

06 Aug '16

On 06/08/16 18:56, hyc(a)symas.com wrote: > We already have low durability transactions, that's what MDB_NOMETASYNC is > for. It only does one fsync per commit instead of two. Haha, I didn't notice that since this reminded me of other discussions. The stuff I was talking about was for fewer fsyncs than one per commit.

1 0

Re: (ITS#8475) Feature request: MDB low durability transactions
by hyc＠symas.com 06 Aug '16

06 Aug '16

bentrask(a)comcast.net wrote: > Full_Name: Ben Trask > Version: > OS: > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (192.241.251.11) > > > Hi, > > Transaction commits are one of the few bottlenecks in MDB, because it has to > fsync twice, sequentially. > > I think MDB could support mixed low and high durability transactions in the same We already have low durability transactions, that's what MDB_NOMETASYNC is for. It only does one fsync per commit instead of two. -- -- 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#8475) Feature request: MDB low durability transactions
by h.b.furuseth＠usit.uio.no 06 Aug '16

06 Aug '16

On 06. aug. 2016 17:38, bentrask(a)comcast.net wrote: > Transaction commits are one of the few bottlenecks in MDB, because it has to > fsync twice, sequentially. > > I think MDB could support mixed low and high durability transactions in the same > database by adding per-page checksums and a third root page. The idea is that > when committing a low-durability transaction, no fsyncs are performed. (...) Yesno. We can get rid of fsyncs, but not that way. Checksumming each page isn't enough. We must know it's the right version of the page and not e.g. a similar page from a previous aborted transaction. To commit a branch or meta page, we'd need to scan its children and checksum the page headers (thus including their checksum) of each. Expensive. IIRC there are three things we can do: - Use and fsync a WAL (write-ahead log) instead of the database pages. That can be cheaper because it writes one contiguous region instead of a lot of random-access pages. Requires recovery after a crash. - Volatile metapages which mdb_env_open() _always_ throws away if no other environment is already open. They are lost of the application crashes/exits without doing a final checkpoint. - Improve that a bit: Put them in a shared memory region, since that won't survive a system crash (unlike if we put them in the lockfile). That way they'll survive application crash provided something does a checkpoint before next system crash. We've discussed these sometimes and there are caveats for some of them, I don't quite remember. One issue is that a "system crash" isn't the only thing which can lose unsynced pages. Another is unmounting and re-mounting the disk (i.e. an USB disk). -- Hallvard

1 0

(ITS#8475) Feature request: MDB low durability transactions
by bentrask＠comcast.net 06 Aug '16

06 Aug '16

Full_Name: Ben Trask Version: OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (192.241.251.11) Hi, Transaction commits are one of the few bottlenecks in MDB, because it has to fsync twice, sequentially. I think MDB could support mixed low and high durability transactions in the same database by adding per-page checksums and a third root page. The idea is that when committing a low-durability transaction, no fsyncs are performed. One of the two other roots is always consistent on-disk to serve as a "backstop" in the event of power loss/kernel panic. The two other pages are allowed to alternate, with consistency only ensured by checksums. During a restore after a crash, the non-durable roots (if any) get compared against the third durable root. Any new pages get checksum'd to ensure integrity. In the worst case, the durable root is used.

1 0

Re: (ITS#8474) Securely Erase BerElement Buffer After Use
by hyc＠symas.com 05 Aug '16

05 Aug '16

alcronin(a)cisco.com wrote: > Full_Name: Alan Cronin > Version: 2.4.44 > OS: Windows 8.1 > URL: https://dl.dropboxusercontent.com/u/82343475/SecurelyEraseBuffer.diff > Submission from: (NULL) (2001:420:4041:2003:f942:59a5:545f:b334) > > > The following patch is a modification to the OpenLDAP BerElement buffer. The > buffer can be used to contain the LDAP request including the password for > authentication. While this is free'd when it is no longer needed, the contents > of the buffer is not overwritten from memory. This can lead to someone reading > the memory of the process and determining what the password is. The change > included in this patch will iterate over the memory and clear it. This will > remove any trace of the password by the time execution is handed back to the > caller. Why would you insert a performance pessimization into every use of the LBER library, rather than just erasing the password from a Bind request? Why would you use an explicitly coded loop setting one character at a time, instead of using libc's memset() which has probably been well optimized? > The attached patch file is derived from OpenLDAP Software. All of the > modifications to OpenLDAP Software represented in the following patch(es) were > developed by Alan Cronin alcronin(a)cisco.com. I have not assigned rights and/or > interest in this work to any party. > The attached file is derived from OpenLDAP Software. All of the modifications to > OpenLDAP Software represented in the following patch(es) were developed by Cisco > Systems, Inc.. Cisco Systems, Inc. has not assigned rights and/or interest in > this work to any party. I, Alan Cronin am authorized by Cisco Systems, Inc., my > employer, to release this work under the following terms. > Cisco Systems, Inc. hereby place the following modifications to OpenLDAP > Software (and only these modifications) into the public domain. Hence, these > modifications may be freely used and/or redistributed for any purpose with or > without attribution and/or other notice. > > -- -- 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#8474) Securely Erase BerElement Buffer After Use
by alcronin＠cisco.com 05 Aug '16

05 Aug '16

Full_Name: Alan Cronin Version: 2.4.44 OS: Windows 8.1 URL: https://dl.dropboxusercontent.com/u/82343475/SecurelyEraseBuffer.diff Submission from: (NULL) (2001:420:4041:2003:f942:59a5:545f:b334) The following patch is a modification to the OpenLDAP BerElement buffer. The buffer can be used to contain the LDAP request including the password for authentication. While this is free'd when it is no longer needed, the contents of the buffer is not overwritten from memory. This can lead to someone reading the memory of the process and determining what the password is. The change included in this patch will iterate over the memory and clear it. This will remove any trace of the password by the time execution is handed back to the caller. The attached patch file is derived from OpenLDAP Software. All of the modifications to OpenLDAP Software represented in the following patch(es) were developed by Alan Cronin alcronin(a)cisco.com. I have not assigned rights and/or interest in this work to any party. The attached file is derived from OpenLDAP Software. All of the modifications to OpenLDAP Software represented in the following patch(es) were developed by Cisco Systems, Inc.. Cisco Systems, Inc. has not assigned rights and/or interest in this work to any party. I, Alan Cronin am authorized by Cisco Systems, Inc., my employer, to release this work under the following terms. Cisco Systems, Inc. hereby place the following modifications to OpenLDAP Software (and only these modifications) into the public domain. Hence, these modifications may be freely used and/or redistributed for any purpose with or without attribution and/or other notice.

1 0

(ITS#8473) unkown plugin type {0} preoperation
by dominik.spychalski＠googlemail.com 02 Aug '16

02 Aug '16

Full_Name: Dominik Spychalski Version: 2.4.44 OS: Ubuntu 14.04 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (141.12.66.96) After the configuration of a self written slapi-plugin in slapd.conf >plugin preoperation /../plugin.so plugin_init I'm converting the konfiguration File to the configuration directory structure >slaptest -F /etc/openldap/slapd.d -f /etc/openldap/slapd.conf When restarting slapd the Error "...unknown plugin type {0} preoperation..." occours. Line in /etc/openldap/slapd.d/cn=config/olcDatabase={-1}frontend.ldif: >olcPlugin: {0} preoperation /../plugin.so plugin_init When I modify the line above to "olcPlugin: preoperation /../plugin.so plugin_init" and recalculate the crc32 checksum everthing works fine.

1 0

(ITS#8472) slapd killed after ldapadd
by dominik.spychalski＠googlemail.com 02 Aug '16

02 Aug '16

Full_Name: Dominik Spychalski Version: 2.4.44 OS: Ubuntu 14.04 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (141.12.66.96) When trying to delete the olcDbIndex-Entry (to add it afterwards with additional indexes) in olcDatabase={1}mdb,cn=config: dn: olcDatabase={1}mdb,cn=config changeType: modify delete: olcDbIndex ldapadd -x -D cn=config -w *** -f del.ldif the slapd process gets killed with the error message: 57a08182 ch_calloc of 1 elems of 0 bytes failed slapd: ch_malloc.c:107: ch_calloc: Assertion `0' failed. If I try to add an additional olcDbIndex with other values, everything works fine.

1 0

Re: (ITS#8460) Invalid pointer free
by quanah＠zimbra.com 29 Jul '16

29 Jul '16

--On Friday, July 29, 2016 12:43 AM +0100 Howard Chu <hyc(a)symas.com> wrote: > Howard Chu wrote: >> Anyway, we know the bad patch was >> 2d5996ac603391ddbd618425f88eb13e5e0e2cc0 so this should be easy to fix. >> > Fixed in master. Should fix ITS8462 as well. --Quanah -- Quanah Gibson-Mount Platform Architect Manager, Systems Team Zimbra, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration A division of Synacor, Inc

1 0

Re: (ITS#8462) Assertion in accesslog.c during replication
by quanah＠zimbra.com 29 Jul '16

29 Jul '16

--On Friday, July 08, 2016 5:37 PM +0000 quanah(a)openldap.org wrote: > Full_Name: Quanah Gibson-Mount > Version: 2.4.44+ITS8432 > OS: Linux > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (75.111.52.177) Full backtrace, since the ITS system lost it via the web form: Thread 10 (Thread 0x7f35cf140700 (LWP 26952)): #0 pthread_cond_wait@@GLIBC_2.3.2 () at=20 ../nptl/sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:185 No locals. #1 0x00007f5dd686fa82 in ldap_pvt_thread_cond_wait (cond=3D0x16ca038,=20 mutex=3D0x16ca010) at thr_posix.c:277 No locals. #2 0x00007f5dd686e315 in ldap_int_thread_pool_wrapper (xpool=3D0x16ca000) = at=20 tpool.c:938 pq =3D 0x16ca000 pool =3D 0x1892240 task =3D 0x0 work_list =3D 0x16ca070 ctx =3D {ltu_pq =3D 0x16ca000, ltu_id =3D 139869084190464, ltu_key = =3D=20 {{ltk_key =3D 0x4ac6bb <slap_sl_mem_init>, ltk_data =3D 0x3d0a4c0, ltk_free = =3D=20 0x4ac4e0 <slap_sl_mem_destroy>}, {ltk_key =3D 0x439b53 <conn_counter_init>, ltk_data =3D 0x189d700, ltk_free =3D 0x4399a5=20 <conn_counter_destroy>}, {ltk_key =3D 0x189ad00, ltk_data =3D 0x4044200,=20 ltk_free =3D 0x7f5dd17c6ea5 <mdb_reader_free>}, {ltk_key =3D 0x7f5dd17bc109 = <search_stack>, ltk_data =3D 0x91ac000, ltk_free =3D 0x7f5dd17bc0e6 <search_stack_free>}, {ltk_key = =3D=20 0x7f5dd17b8cad <scope_chunk_get>, ltk_data =3D 0x8eac000, ltk_free =3D=20 0x7f5dd17b8c65 <scope_chunk_free>}, {ltk_key =3D 0x4548c9 <slap_op_free>,=20 ltk_data =3D 0xe66ba40, ltk_free =3D 0x45481c <slap_op_q_destroy>}, {ltk_key =3D=20 0x189b400, ltk_data =3D 0x1c32800, ltk_free =3D 0x7f5dd17c6ea5=20 <mdb_reader_free>}, {ltk_key =3D 0x0, ltk_data =3D 0xe6ff200, ltk_free =3D = 0x0},=20 {ltk_key =3D 0x0, ltk_data =3D 0x0, ltk_free =3D 0x0} <repeats 24 times>}} kctx =3D 0x0 i =3D 32 keyslot =3D 318 hash =3D 1328570686 pool_lock =3D 0 freeme =3D 0 __PRETTY_FUNCTION__ =3D "ldap_int_thread_pool_wrapper" #3 0x00007f5dd52dfdc5 in start_thread (arg=3D0x7f35cf140700) at=20 pthread_create.c:308 __res =3D <optimized out> pd =3D 0x7f35cf140700 now =3D <optimized out> unwind_buf =3D {cancel_jmp_buf =3D {{jmp_buf =3D {139869084190464,=20 9196993683121098082, 0, 139869084191168, 139869084190464, 0,=20 -9094501435400139422, -9144027579543728798}, mask_was_saved =3D 0}}, priv = =3D=20 {pad =3D {0x0, 0x0, 0x0, 0x0}, data =3D {prev =3D 0x0, cleanup =3D 0x0, canceltype =3D 0}}} not_first_call =3D <optimized out> pagesize_m1 =3D <optimized out> sp =3D <optimized out> freesize =3D <optimized out> #4 0x00007f5dd500cced in clone () at=20 ../sysdeps/unix/sysv/linux/x86_64/clone.S:113 No locals. Thread 9 (Thread 0x7f35d0142700 (LWP 26950)): #0 pthread_cond_wait@@GLIBC_2.3.2 () at=20 ../nptl/sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:185 No locals. #1 0x00007f5dd686fa82 in ldap_pvt_thread_cond_wait (cond=3D0x16ca038,=20 mutex=3D0x16ca010) at thr_posix.c:277 No locals. #2 0x00007f5dd686e315 in ldap_int_thread_pool_wrapper (xpool=3D0x16ca000) = at=20 tpool.c:938 pq =3D 0x16ca000 pool =3D 0x1892240 task =3D 0x0 work_list =3D 0x16ca070 ctx =3D {ltu_pq =3D 0x16ca000, ltu_id =3D 139869100975872, ltu_key = =3D=20 {{ltk_key =3D 0x4ac6bb <slap_sl_mem_init>, ltk_data =3D 0x3d0a440, ltk_free = =3D=20 0x4ac4e0 <slap_sl_mem_destroy>}, {ltk_key =3D 0x189b400, ltk_data =3D=20 0x3d02200, ltk_free =3D 0x7f5dd17c6ea5 <mdb_reader_free>}, {ltk_key =3D=20 0x189ad00, ltk_data =3D 0x4040e00, ltk_free =3D 0x7f5dd17c6ea5=20 <mdb_reader_free>}, {ltk_key =3D 0x439b53 <conn_counter_init>, ltk_data =3D = 0x189a900, ltk_free =3D 0x4399a5 <conn_counter_destroy>}, {ltk_key =3D=20 0x7f5dd17bc109 <search_stack>, ltk_data =3D 0x7eac000, ltk_free =3D=20 0x7f5dd17bc0e6 <search_stack_free>}, {ltk_key =3D 0x7f5dd17b8cad=20 <scope_chunk_get>, ltk_data =3D 0x7bac000, ltk_free =3D 0x7f5dd17b8c65=20 <scope_chunk_free>}, {ltk_key =3D 0x4548c9 <slap_op_free>, ltk_data =3D=20 0x1e6f0c0, ltk_free =3D 0x45481c <slap_op_q_destroy>}, {ltk_key =3D 0x0,=20 ltk_data =3D 0xe6e6800, ltk_free =3D 0x0}, {ltk_key =3D 0x0, ltk_data =3D 0x0, = ltk_free =3D=20 0x0} <repeats 24 times>}} kctx =3D 0x0 i =3D 32 keyslot =3D 607 hash =3D 3999935071 pool_lock =3D 0 freeme =3D 0 __PRETTY_FUNCTION__ =3D "ldap_int_thread_pool_wrapper" #3 0x00007f5dd52dfdc5 in start_thread (arg=3D0x7f35d0142700) at=20 pthread_create.c:308 __res =3D <optimized out> pd =3D 0x7f35d0142700 now =3D <optimized out> unwind_buf =3D {cancel_jmp_buf =3D {{jmp_buf =3D {139869100975872,=20 9196993683121098082, 0, 139869100976576, 139869100975872, 0,=20 -9094481585135039134, -9144027579543728798}, mask_was_saved =3D 0}}, priv = =3D=20 {pad =3D {0x0, 0x0, 0x0, 0x0}, data =3D {prev =3D 0x0, cleanup =3D 0x0, canceltype =3D 0}}} not_first_call =3D <optimized out> pagesize_m1 =3D <optimized out> sp =3D <optimized out> freesize =3D <optimized out> #4 0x00007f5dd500cced in clone () at=20 ../sysdeps/unix/sysv/linux/x86_64/clone.S:113 No locals. Thread 8 (Thread 0x7f35cf941700 (LWP 26951)): #0 pthread_cond_wait@@GLIBC_2.3.2 () at=20 ../nptl/sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:185 No locals. #1 0x00007f5dd686fa82 in ldap_pvt_thread_cond_wait (cond=3D0x16ca038,=20 mutex=3D0x16ca010) at thr_posix.c:277 No locals. #2 0x00007f5dd686e315 in ldap_int_thread_pool_wrapper (xpool=3D0x16ca000) = at=20 tpool.c:938 pq =3D 0x16ca000 pool =3D 0x1892240 task =3D 0x0 work_list =3D 0x16ca070 ctx =3D {ltu_pq =3D 0x16ca000, ltu_id =3D 139869092583168, ltu_key = =3D=20 {{ltk_key =3D 0x4ac6bb <slap_sl_mem_init>, ltk_data =3D 0x3d0a480, ltk_free = =3D=20 0x4ac4e0 <slap_sl_mem_destroy>}, {ltk_key =3D 0x189b400, ltk_data =3D=20 0x403c000, ltk_free =3D 0x7f5dd17c6ea5 <mdb_reader_free>}, {ltk_key =3D=20 0x7f5dd17bc109 <search_stack>, ltk_data =3D 0x434a000, ltk_free =3D=20 0x7f5dd17bc0e6 <search_stack_free>}, {ltk_key =3D 0x7f5dd17b8cad=20 <scope_chunk_get>, ltk_data =3D 0x404a000, ltk_free =3D 0x7f5dd17b8c65=20 <scope_chunk_free>}, {ltk_key =3D 0x439b53 <conn_counter_init>, ltk_data = =3D=20 0x189c500, ltk_free =3D 0x4399a5 <conn_counter_destroy>}, {ltk_key =3D=20 0x189ad00, ltk_data =3D 0x1c2c000, ltk_free =3D 0x7f5dd17c6ea5 <mdb_reader_free>}, {ltk_key =3D=20 0x4548c9 <slap_op_free>, ltk_data =3D 0xe66dc00, ltk_free =3D 0x45481c=20 <slap_op_q_destroy>}, {ltk_key =3D 0x0, ltk_data =3D 0xa6a1200, ltk_free = =3D=20 0x0}, {ltk_key =3D 0x0, ltk_data =3D 0x0, ltk_free =3D 0x0} <repeats 24 times>}} kctx =3D 0x0 i =3D 32 keyslot =3D 206 hash =3D 4097825998 pool_lock =3D 0 freeme =3D 0 __PRETTY_FUNCTION__ =3D "ldap_int_thread_pool_wrapper" #3 0x00007f5dd52dfdc5 in start_thread (arg=3D0x7f35cf941700) at=20 pthread_create.c:308 __res =3D <optimized out> pd =3D 0x7f35cf941700 now =3D <optimized out> unwind_buf =3D {cancel_jmp_buf =3D {{jmp_buf =3D {139869092583168,=20 9196993683121098082, 0, 139869092583872, 139869092583168, 0,=20 -9094502475319095966, -9144027579543728798}, mask_was_saved =3D 0}}, priv = =3D=20 {pad =3D {0x0, 0x0, 0x0, 0x0}, data =3D {prev =3D 0x0, cleanup =3D 0x0, canceltype =3D 0}}} not_first_call =3D <optimized out> pagesize_m1 =3D <optimized out> sp =3D <optimized out> freesize =3D <optimized out> #4 0x00007f5dd500cced in clone () at=20 ../sysdeps/unix/sysv/linux/x86_64/clone.S:113 No locals. Thread 7 (Thread 0x7f35cdf38700 (LWP 26955)): #0 pthread_cond_wait@@GLIBC_2.3.2 () at=20 ../nptl/sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:185 No locals. #1 0x00007f5dd686fa82 in ldap_pvt_thread_cond_wait (cond=3D0x16ca038,=20 mutex=3D0x16ca010) at thr_posix.c:277 No locals. #2 0x00007f5dd686e315 in ldap_int_thread_pool_wrapper (xpool=3D0x16ca000) = at=20 tpool.c:938 pq =3D 0x16ca000 pool =3D 0x1892240 task =3D 0x0 work_list =3D 0x16ca070 ctx =3D {ltu_pq =3D 0x16ca000, ltu_id =3D 139869065283328, ltu_key = =3D=20 {{ltk_key =3D 0x439b53 <conn_counter_init>, ltk_data =3D 0x189a600, = ltk_free =3D=20 0x4399a5 <conn_counter_destroy>}, {ltk_key =3D 0x4ac6bb <slap_sl_mem_init>, ltk_data =3D 0x3d0aac0, ltk_free =3D 0x4ac4e0=20 <slap_sl_mem_destroy>}, {ltk_key =3D 0x189ad00, ltk_data =3D 0x403f400,=20 ltk_free =3D 0x7f5dd17c6ea5 <mdb_reader_free>}, {ltk_key =3D 0x4548c9=20 <slap_op_free>, ltk_data =3D 0xe34a000, ltk_free =3D 0x45481c <slap_op_q_destroy>}, {ltk_key =3D=20 0x7f5dd17bc109 <search_stack>, ltk_data =3D 0x6bac000, ltk_free =3D=20 0x7f5dd17bc0e6 <search_stack_free>}, {ltk_key =3D 0x7f5dd17b8cad=20 <scope_chunk_get>, ltk_data =3D 0x68ac000, ltk_free =3D 0x7f5dd17b8c65 <scope_chunk_free>}, {ltk_key =3D = 0x189b400, ltk_data =3D 0x1c30e00, ltk_free =3D 0x7f5dd17c6ea5=20 <mdb_reader_free>}, {ltk_key =3D 0x0, ltk_data =3D 0xe331200, ltk_free =3D = 0x0},=20 {ltk_key =3D 0x0, ltk_data =3D 0x0, ltk_free =3D 0x0} <repeats 24 times>}} kctx =3D 0x0 i =3D 32 keyslot =3D 955 hash =3D 3207721915 pool_lock =3D 0 freeme =3D 0 __PRETTY_FUNCTION__ =3D "ldap_int_thread_pool_wrapper" #3 0x00007f5dd52dfdc5 in start_thread (arg=3D0x7f35cdf38700) at=20 pthread_create.c:308 __res =3D <optimized out> pd =3D 0x7f35cdf38700 now =3D <optimized out> unwind_buf =3D {cancel_jmp_buf =3D {{jmp_buf =3D {139869065283328,=20 9196993683121098082, 0, 139869065284032, 139869065283328, 0,=20 -9094506112619524766, -9144027579543728798}, mask_was_saved =3D 0}}, priv = =3D=20 {pad =3D {0x0, 0x0, 0x0, 0x0}, data =3D {prev =3D 0x0, cleanup =3D 0x0, canceltype =3D 0}}} not_first_call =3D <optimized out> pagesize_m1 =3D <optimized out> sp =3D <optimized out> freesize =3D <optimized out> #4 0x00007f5dd500cced in clone () at=20 ../sysdeps/unix/sysv/linux/x86_64/clone.S:113 No locals. Thread 6 (Thread 0x7f35cd737700 (LWP 27176)): #0 pthread_cond_wait@@GLIBC_2.3.2 () at=20 ../nptl/sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:185 No locals. #1 0x00007f5dd686fa82 in ldap_pvt_thread_cond_wait (cond=3D0x16ca038,=20 mutex=3D0x16ca010) at thr_posix.c:277 No locals. #2 0x00007f5dd686e315 in ldap_int_thread_pool_wrapper (xpool=3D0x16ca000) = at=20 tpool.c:938 pq =3D 0x16ca000 pool =3D 0x1892240 task =3D 0x0 work_list =3D 0x16ca070 ctx =3D {ltu_pq =3D 0x16ca000, ltu_id =3D 139869056890624, ltu_key = =3D=20 {{ltk_key =3D 0x439b53 <conn_counter_init>, ltk_data =3D 0x1efd400, = ltk_free =3D=20 0x4399a5 <conn_counter_destroy>}, {ltk_key =3D 0x4ac6bb <slap_sl_mem_init>, ltk_data =3D 0xa322e00, ltk_free =3D 0x4ac4e0=20 <slap_sl_mem_destroy>}, {ltk_key =3D 0x189ad00, ltk_data =3D 0x4042800,=20 ltk_free =3D 0x7f5dd17c6ea5 <mdb_reader_free>}, {ltk_key =3D 0x7f5dd17bc109 = <search_stack>, ltk_data =3D 0xab2a000, ltk_free =3D 0x7f5dd17bc0e6 <search_stack_free>}, {ltk_key = =3D=20 0x7f5dd17b8cad <scope_chunk_get>, ltk_data =3D 0xa82a000, ltk_free =3D=20 0x7f5dd17b8c65 <scope_chunk_free>}, {ltk_key =3D 0x4548c9 <slap_op_free>,=20 ltk_data =3D 0xe66b680, ltk_free =3D 0x45481c <slap_op_q_destroy>}, {ltk_key =3D=20 0x189b400, ltk_data =3D 0xe7b8000, ltk_free =3D 0x7f5dd17c6ea5=20 <mdb_reader_free>}, {ltk_key =3D 0x0, ltk_data =3D 0xe6e6800, ltk_free =3D = 0x0},=20 {ltk_key =3D 0x0, ltk_data =3D 0x0, ltk_free =3D 0x0} <repeats 24 times>}} kctx =3D 0x0 i =3D 32 keyslot =3D 43 hash =3D 438466603 pool_lock =3D 0 freeme =3D 0 __PRETTY_FUNCTION__ =3D "ldap_int_thread_pool_wrapper" #3 0x00007f5dd52dfdc5 in start_thread (arg=3D0x7f35cd737700) at=20 pthread_create.c:308 __res =3D <optimized out> pd =3D 0x7f35cd737700 now =3D <optimized out> unwind_buf =3D {cancel_jmp_buf =3D {{jmp_buf =3D {139869056890624,=20 9196993683121098082, 0, 139869056891328, 139869056890624, 0,=20 -9094505012571026078, -9144027579543728798}, mask_was_saved =3D 0}}, priv = =3D=20 {pad =3D {0x0, 0x0, 0x0, 0x0}, data =3D {prev =3D 0x0, cleanup =3D 0x0, canceltype =3D 0}}} not_first_call =3D <optimized out> pagesize_m1 =3D <optimized out> sp =3D <optimized out> freesize =3D <optimized out> #4 0x00007f5dd500cced in clone () at=20 ../sysdeps/unix/sysv/linux/x86_64/clone.S:113 No locals. Thread 5 (Thread 0x7f35ccf36700 (LWP 27177)): #0 pthread_cond_wait@@GLIBC_2.3.2 () at=20 ../nptl/sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:185 No locals. #1 0x00007f5dd686fa82 in ldap_pvt_thread_cond_wait (cond=3D0x16ca038,=20 mutex=3D0x16ca010) at thr_posix.c:277 No locals. #2 0x00007f5dd686e315 in ldap_int_thread_pool_wrapper (xpool=3D0x16ca000) = at=20 tpool.c:938 pq =3D 0x16ca000 pool =3D 0x1892240 task =3D 0x0 work_list =3D 0x16ca070 ctx =3D {ltu_pq =3D 0x16ca000, ltu_id =3D 139869048497920, ltu_key = =3D=20 {{ltk_key =3D 0x439b53 <conn_counter_init>, ltk_data =3D 0x1efd200, = ltk_free =3D=20 0x4399a5 <conn_counter_destroy>}, {ltk_key =3D 0x4ac6bb <slap_sl_mem_init>, ltk_data =3D 0xa3228c0, ltk_free =3D 0x4ac4e0=20 <slap_sl_mem_destroy>}, {ltk_key =3D 0x189ad00, ltk_data =3D 0x1c2da00,=20 ltk_free =3D 0x7f5dd17c6ea5 <mdb_reader_free>}, {ltk_key =3D 0x7f5dd17bc109 = <search_stack>, ltk_data =3D 0xd32a000, ltk_free =3D 0x7f5dd17bc0e6 <search_stack_free>}, {ltk_key = =3D=20 0x7f5dd17b8cad <scope_chunk_get>, ltk_data =3D 0xd02a000, ltk_free =3D=20 0x7f5dd17b8c65 <scope_chunk_free>}, {ltk_key =3D 0x4548c9 <slap_op_free>,=20 ltk_data =3D 0xe34a3c0, ltk_free =3D 0x45481c <slap_op_q_destroy>}, {ltk_key =3D=20 0x189b400, ltk_data =3D 0xe7be800, ltk_free =3D 0x7f5dd17c6ea5=20 <mdb_reader_free>}, {ltk_key =3D 0x0, ltk_data =3D 0xe6e6800, ltk_free =3D = 0x0},=20 {ltk_key =3D 0x0, ltk_data =3D 0x0, ltk_free =3D 0x0} <repeats 24 times>}} kctx =3D 0x0 i =3D 32 keyslot =3D 666 hash =3D 536357530 pool_lock =3D 0 freeme =3D 0 __PRETTY_FUNCTION__ =3D "ldap_int_thread_pool_wrapper" #3 0x00007f5dd52dfdc5 in start_thread (arg=3D0x7f35ccf36700) at=20 pthread_create.c:308 __res =3D <optimized out> pd =3D 0x7f35ccf36700 now =3D <optimized out> unwind_buf =3D {cancel_jmp_buf =3D {{jmp_buf =3D {139869048497920,=20 9196993683121098082, 0, 139869048498624, 139869048497920, 0,=20 -9094508310569038494, -9144027579543728798}, mask_was_saved =3D 0}}, priv = =3D=20 {pad =3D {0x0, 0x0, 0x0, 0x0}, data =3D {prev =3D 0x0, cleanup =3D 0x0, canceltype =3D 0}}} not_first_call =3D <optimized out> pagesize_m1 =3D <optimized out> sp =3D <optimized out> freesize =3D <optimized out> #4 0x00007f5dd500cced in clone () at=20 ../sysdeps/unix/sysv/linux/x86_64/clone.S:113 No locals. Thread 4 (Thread 0x7f35d0943700 (LWP 26949)): #0 0x00007f5dd500d2c3 in epoll_wait () at=20 ../sysdeps/unix/syscall-template.S:81 No locals. #1 0x0000000000435e73 in slapd_daemon_task (ptr=3D0x1693f20) at = daemon.c:2517 ns =3D 1 at =3D 0 nfds =3D 256 revents =3D 0x172e000 tvp =3D 0x7f35d0942e00 cat =3D {tv_sec =3D 1468252245, tv_usec =3D 0} i =3D 1 nwriters =3D 0 now =3D 1468246929 tv =3D {tv_sec =3D 5316, tv_usec =3D 0} tdelta =3D 1 rtask =3D 0x16bbd60 l =3D 3 last_idle_check =3D 1468237845 ebadf =3D 0 tid =3D 0 #2 0x00007f5dd52dfdc5 in start_thread (arg=3D0x7f35d0943700) at=20 pthread_create.c:308 __res =3D <optimized out> pd =3D 0x7f35d0943700 now =3D <optimized out> unwind_buf =3D {cancel_jmp_buf =3D {{jmp_buf =3D {139869109368576,=20 9196993683121098082, 0, 139869109369280, 139869109368576, 0,=20 -9094482685183537822, -9144027579543728798}, mask_was_saved =3D 0}}, priv = =3D=20 {pad =3D {0x0, 0x0, 0x0, 0x0}, data =3D {prev =3D 0x0, cleanup =3D 0x0, canceltype =3D 0}}} not_first_call =3D <optimized out> pagesize_m1 =3D <optimized out> sp =3D <optimized out> freesize =3D <optimized out> #3 0x00007f5dd500cced in clone () at=20 ../sysdeps/unix/sysv/linux/x86_64/clone.S:113 No locals. Thread 3 (Thread 0x7f35ce93f700 (LWP 26953)): #0 pthread_cond_wait@@GLIBC_2.3.2 () at=20 ../nptl/sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:185 No locals. #1 0x00007f5dd686fa82 in ldap_pvt_thread_cond_wait (cond=3D0x16ca038,=20 mutex=3D0x16ca010) at thr_posix.c:277 No locals. #2 0x00007f5dd686e315 in ldap_int_thread_pool_wrapper (xpool=3D0x16ca000) = at=20 tpool.c:938 pq =3D 0x16ca000 pool =3D 0x1892240 task =3D 0x0 work_list =3D 0x16ca070 ctx =3D {ltu_pq =3D 0x16ca000, ltu_id =3D 139869075797760, ltu_key = =3D=20 {{ltk_key =3D 0x439b53 <conn_counter_init>, ltk_data =3D 0x189a500, = ltk_free =3D=20 0x4399a5 <conn_counter_destroy>}, {ltk_key =3D 0x4ac6bb <slap_sl_mem_init>, ltk_data =3D 0x3d0aa00, ltk_free =3D 0x4ac4e0=20 <slap_sl_mem_destroy>}, {ltk_key =3D 0x189ad00, ltk_data =3D 0x403da00,=20 ltk_free =3D 0x7f5dd17c6ea5 <mdb_reader_free>}, {ltk_key =3D 0x4548c9=20 <slap_op_free>, ltk_data =3D 0x1e6f840, ltk_free =3D 0x45481c <slap_op_q_destroy>}, {ltk_key =3D=20 0x7f5dd17bc109 <search_stack>, ltk_data =3D 0x5792000, ltk_free =3D=20 0x7f5dd17bc0e6 <search_stack_free>}, {ltk_key =3D 0x7f5dd17b8cad=20 <scope_chunk_get>, ltk_data =3D 0x5492000, ltk_free =3D 0x7f5dd17b8c65 <scope_chunk_free>}, {ltk_key =3D = 0x189b400, ltk_data =3D 0xe7bb400, ltk_free =3D 0x7f5dd17c6ea5=20 <mdb_reader_free>}, {ltk_key =3D 0x0, ltk_data =3D 0xa44a400, ltk_free =3D = 0x0},=20 {ltk_key =3D 0x0, ltk_data =3D 0x0, ltk_free =3D 0x0} <repeats 24 times>}} kctx =3D 0x0 i =3D 32 keyslot =3D 268 hash =3D 1288693004 pool_lock =3D 0 freeme =3D 0 __PRETTY_FUNCTION__ =3D "ldap_int_thread_pool_wrapper" #3 0x00007f5dd52dfdc5 in start_thread (arg=3D0x7f35ce93f700) at=20 pthread_create.c:308 __res =3D <optimized out> pd =3D 0x7f35ce93f700 now =3D <optimized out> unwind_buf =3D {cancel_jmp_buf =3D {{jmp_buf =3D {139869075797760,=20 9196993683121098082, 0, 139869075798464, 139869075797760, 0,=20 -9094504733398151838, -9144027579543728798}, mask_was_saved =3D 0}}, priv = =3D=20 {pad =3D {0x0, 0x0, 0x0, 0x0}, data =3D {prev =3D 0x0, cleanup =3D 0x0, canceltype =3D 0}}} not_first_call =3D <optimized out> pagesize_m1 =3D <optimized out> sp =3D <optimized out> freesize =3D <optimized out> #4 0x00007f5dd500cced in clone () at=20 ../sysdeps/unix/sysv/linux/x86_64/clone.S:113 No locals. Thread 2 (Thread 0x7f5dd6f1b740 (LWP 26948)): #0 0x00007f5dd52e0ef7 in pthread_join (threadid=3D139869109368576,=20 thread_return=3D0x0) at pthread_join.c:92 _tid =3D 26949 _buffer =3D {__routine =3D 0x7f5dd52e0e30 <cleanup>, __arg =3D=20 0x7f35d0943d28, __canceltype =3D -795592960, __prev =3D 0x0} oldtype =3D 0 pd =3D 0x7f35d0943700 self =3D 0x7f5dd6f1b740 result =3D 0 #1 0x00007f5dd686f9c3 in ldap_pvt_thread_join (thread=3D139869109368576,=20 thread_return=3D0x0) at thr_posix.c:197 No locals. #2 0x0000000000437032 in slapd_daemon () at daemon.c:2910 i =3D 0 rc =3D 0 #3 0x0000000000414bfa in main (argc=3D9, argv=3D0x7ffdf9c09488) at = main.c:1017 i =3D 9 no_detach =3D 0 rc =3D 0 urls =3D 0x169a020 "ldap:/// ldapi:///" username =3D 0x1692010 "root" groupname =3D 0x0 sandbox =3D 0x0 syslogUser =3D 128 pid =3D 0 waitfds =3D {10, 11} g_argc =3D 9 g_argv =3D 0x7ffdf9c09488 configfile =3D 0x0 configdir =3D 0x169a040 "/opt/zimbra/data/ldap/config" serverName =3D 0x7ffdf9c0a69e "slapd" serverMode =3D 1 scp =3D 0x0 scp_entry =3D 0x0 debug_unknowns =3D 0x0 syslog_unknowns =3D 0x0 serverNamePrefix =3D 0x4f0048 "" l =3D 2305843479183585312 slapd_pid_file_unlink =3D 1 slapd_args_file_unlink =3D 1 firstopt =3D 0 __PRETTY_FUNCTION__ =3D "main" Thread 1 (Thread 0x7f35cc735700 (LWP 27178)): #0 0x00007f5dd4f4b5f7 in __GI_raise (sig=3Dsig@entry=3D6) at=20 ../nptl/sysdeps/unix/sysv/linux/raise.c:56 resultvar =3D 0 pid =3D 26948 selftid =3D 27178 #1 0x00007f5dd4f4cce8 in __GI_abort () at abort.c:90 save_stage =3D 2 act =3D {__sigaction_handler =3D {sa_handler =3D 0x7ffdf9c0a69e,=20 sa_sigaction =3D 0x7ffdf9c0a69e}, sa_mask =3D {__val =3D {140040982830608,=20 5298640, 310, 1, 140040981470915, 4, 139869040095104, 54969718528,=20 8390876207988696434, 139869040095536, 0, 0, 0, 21474836480, 140040982830428,=20 139869040095248}}, sa_flags =3D -688766976, sa_restorer =3D 0x7f5dd5094ce8} sigs =3D {__val =3D {32, 0 <repeats 15 times>}} #2 0x00007f5dd4f44566 in __assert_fail_base (fmt=3D0x7f5dd5094ce8=20 "%s%s%s:%u: %s%sAssertion `%s' failed.\n%n",=20 assertion=3Dassertion@entry=3D0x50da0c "0", file=3Dfile@entry=3D0x50d9d0=20 "sl_malloc.c", line=3Dline@entry=3D310, function=3Dfunction@entry=3D0x50da93 <__PRETTY_FUNCTION__.11433>=20 "slap_sl_malloc") at assert.c:92 str =3D 0xea8d7a0 " \324\250\016" total =3D 4096 #3 0x00007f5dd4f44612 in __GI___assert_fail (assertion=3D0x50da0c "0",=20 file=3D0x50d9d0 "sl_malloc.c", line=3D310, function=3D0x50da93=20 <__PRETTY_FUNCTION__.11433> "slap_sl_malloc") at assert.c:101 No locals. #4 0x00000000004acba0 in slap_sl_malloc (size=3D139869040095783, = ctx=3D0x0) at=20 sl_malloc.c:310 sh =3D 0x0 ptr =3D 0x7f35cc733249 newptr =3D 0x0 __PRETTY_FUNCTION__ =3D "slap_sl_malloc" #5 0x00000000004574eb in build_new_dn (new_dn=3D0x19f9dd0,=20 parent_dn=3D0x1da0280, newrdn=3D0x7f35cc7331f0, memctx=3D0x0) at dn.c:1154 ptr =3D 0xa45e840 "cn=3Daccesslog" #6 0x00007f5dd1163c60 in accesslog_entry (op=3D0x7f35cc734480,=20 rs=3D0x7f35cc734010, logop=3D2, op2=3D0x7f35cc733390) at accesslog.c:1325 on =3D 0x1c74760 li =3D 0x1a71de0 rdnbuf =3D = "reqStart=3D20160711142209.1000000\000\004\063s\314\065\177" nrdnbuf =3D=20 "reqStart=3D\000}\321]\177\000\000\000\060\270F7\177\000\000L3s\314\065\177\= 000\000\000\255\211\001\000\000" rdn =3D {bv_len =3D 31, bv_val =3D 0x7f35cc733240=20 "reqStart=3D20160711142209.1000000"} nrdn =3D {bv_len =3D 139869040095769, bv_val =3D 0x7f35cc733210=20 "reqStart=3D"} timestamp =3D {bv_len =3D 22, bv_val =3D 0x7f35cc733249=20 "20160711142209.1000000"} ntimestamp =3D {bv_len =3D 139869040095760, bv_val =3D = 0x7f35cc733330 ""} bv =3D {bv_len =3D 139869040095760, bv_val =3D 0x7f5dd17d1a48=20 <mdb_node_read+199> "\211E\374\203", <incomplete sequence \374>} lo =3D 0x7f5dd136b5d0 <logops+144> e =3D 0x19f9db8 #7 0x00007f5dd1164668 in accesslog_response (op=3D0x7f35cc734480,=20 rs=3D0x7f35cc734010) at accesslog.c:1528 on =3D 0x1c74760 li =3D 0x1a71de0 a =3D 0x7f35cc734480 last_attr =3D 0x7f35cc734010 m =3D 0x7f35cc7337c0 b =3D 0x7f35cc733610 uuid =3D {bv_len =3D 36, bv_val =3D 0xe5e4e50=20 "bd4b254a-9cfc-102f-8a73-ad92a9dc2877"} i =3D 0 logop =3D 2 do_graduate =3D 0 lo =3D 0x7f5dd136b5d0 <logops+144> e =3D 0x0 old =3D 0x0 e_uuid =3D 0x0 timebuf =3D "=20 \t\000\000\000\000\000\000\bT\361\016\000\000\000\000\b\000\000\000\000\000\= 000\000\b5s\314\065\177" bv =3D {bv_len =3D 63938752, bv_val =3D 0x96a772 <Address 0x96a772 = out of=20 bounds>} ptr =3D 0x7f3746b77000 <Address 0x7f3746b77000 out of bounds> vals =3D 0x7f35cc733558 op2 =3D {o_hdr =3D 0x0, o_tag =3D 0, o_time =3D 0, o_tincr =3D 0, = o_bd =3D 0x0,=20 o_req_dn =3D {bv_len =3D 0, bv_val =3D 0x0}, o_req_ndn =3D {bv_len =3D 0, = bv_val =3D=20 0x0}, o_request =3D {oq_add =3D {rs_modlist =3D 0x0, rs_e =3D 0x0}, oq_bind = =3D=20 {rb_method =3D 0, rb_cred =3D {bv_len =3D 0, bv_val =3D 0x0}, rb_edn =3D = {bv_len =3D 0,=20 bv_val =3D 0x0}, rb_ssf =3D 0, rb_mech =3D {bv_len =3D 0, bv_val =3D 0x0}}, = oq_compare =3D {rs_ava =3D 0x0}, oq_modify =3D {rs_mods =3D {rs_modlist =3D = 0x0, rs_no_opattrs =3D 0 '\000'}, rs_increment =3D 0}, oq_modrdn = =3D=20 {rs_mods =3D {rs_modlist =3D 0x0, rs_no_opattrs =3D 0 '\000'}, = rs_deleteoldrdn =3D=20 0, rs_newrdn =3D {bv_len =3D 0, bv_val =3D 0x0}, rs_nnewrdn =3D {bv_len =3D = 0, bv_val=20 =3D 0x0}, rs_newSup =3D 0x0, rs_nnewSup =3D 0x0}, oq_search =3D = {rs_scope =3D=20 0, rs_deref =3D 0, rs_slimit =3D 0, rs_tlimit =3D 0, rs_limit =3D 0x0, = rs_attrsonly=20 =3D 0, rs_attrs =3D 0x0, rs_filter =3D 0x0, rs_filterstr =3D {bv_len =3D 0, = bv_val =3D=20 0x0}}, oq_abandon =3D {rs_msgid =3D 0}, oq_cancel =3D {rs_msgid =3D = 0},=20 oq_extended =3D {rs_reqoid =3D {bv_len =3D 0, bv_val =3D 0x0}, rs_flags =3D = 0,=20 rs_reqdata =3D 0x0}, oq_pwdexop =3D {rs_extended =3D {rs_reqoid =3D {bv_len = =3D 0,=20 bv_val =3D 0x0}, rs_flags =3D 0, rs_reqdata =3D 0x0}, rs_old =3D {bv_len =3D = 0,=20 bv_val =3D 0x0}, rs_new =3D {bv_len =3D 0, bv_val =3D 0x0}, rs_mods =3D = 0x0,=20 rs_modtail =3D 0x0}}, o_abandon =3D 0, o_cancel =3D 0, o_groups =3D 0x0,=20 o_do_not_cache =3D 0 '\000', o_is_auth_check =3D 0 '\000', o_dont_replicate =3D 0 '\000',=20 o_acl_priv =3D ACL_NONE, o_nocaching =3D 0 '\000', o_delete_glue_parent =3D = 0=20 '\000', o_no_schema_check =3D 0 '\000', o_no_subordinate_glue =3D 0 '\000', o_ctrlflag =3D '\000' <repeats 31 times>, o_controls =3D 0x0, = o_authz=20 =3D {sai_method =3D 0, sai_mech =3D {bv_len =3D 0, bv_val =3D 0x0}, sai_dn = =3D {bv_len=20 =3D 0, bv_val =3D 0x0}, sai_ndn =3D {bv_len =3D 0, bv_val =3D 0x0}, sai_ssf = =3D 0, sai_transport_ssf =3D 0, sai_tls_ssf =3D 0, sai_sasl_ssf =3D = 0},=20 o_ber =3D 0x0, o_res_ber =3D 0x0, o_callback =3D 0x0, o_ctrls =3D 0x0, = o_csn =3D=20 {bv_len =3D 0, bv_val =3D 0x0}, o_private =3D 0x0, o_extra =3D {slh_first = =3D 0x0},=20 o_next =3D { stqe_next =3D 0x0}} rs2 =3D {sr_type =3D REP_RESULT, sr_tag =3D 0, sr_msgid =3D 0, = sr_err =3D 0,=20 sr_matched =3D 0x0, sr_text =3D 0x0, sr_ref =3D 0x0, sr_ctrls =3D 0x0, = sr_un =3D=20 {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=20 {r_sasldata =3D 0x0}, sru_extended =3D {r_rspoid =3D 0x0, r_rspdata =3D = 0x0}},=20 sr_flags =3D 0} #8 0x00000000004cb94c in over_back_response (op=3D0x7f35cc734480,=20 rs=3D0x7f35cc734010) at backover.c:237 oi =3D 0x1a91680 on =3D 0x1c74760 rc =3D 32768 be =3D 0x7f35cc733cf0 db =3D {bd_info =3D 0x1c74760, bd_self =3D 0x18bb400, be_ctrls =3D=20 "\000\001\001\001\000\001\000\000\001\000\000\001\001\000\001\000\000\001", = '\000' <repeats 14 times>, "\001", be_flags =3D 563464, be_restrictops =3D = 0,=20 be_requires =3D 0, be_ssf_set =3D {sss_ssf =3D 0, sss_transport =3D 0, sss_tls =3D = 0,=20 sss_sasl =3D 0, sss_update_ssf =3D 0, sss_update_transport =3D 0, = sss_update_tls=20 =3D 0, sss_update_sasl =3D 0, sss_simple_bind =3D 0}, be_suffix =3D = 0x1da1140, be_nsuffix =3D 0x1da1180, be_schemadn =3D {bv_len =3D 0, bv_val = =3D 0x0},=20 be_schemandn =3D {bv_len =3D 0, bv_val =3D 0x0}, be_rootdn =3D {bv_len =3D = 9, bv_val=20 =3D 0x1bb8c60 "cn=3Dconfig"}, be_rootndn =3D {bv_len =3D 9, bv_val =3D 0x1bb8c80 "cn=3Dconfig"}, be_rootpw =3D {bv_len =3D = 0,=20 bv_val =3D 0x0}, be_max_deref_depth =3D 15, be_def_limit =3D {lms_t_soft = =3D -1,=20 lms_t_hard =3D 0, lms_s_soft =3D -1, lms_s_hard =3D 0, lms_s_unchecked =3D = -1,=20 lms_s_pr =3D 0, lms_s_pr_hide =3D 0, lms_s_pr_total =3D 0}, be_limits =3D 0x0, = be_acl=20 =3D 0x1c22060, be_dfltaccess =3D ACL_READ, be_extra_anlist =3D 0x0, = be_update_ndn=20 =3D {bv_len =3D 0, bv_val =3D 0x0}, be_update_refs =3D 0x0, be_pending_csn_list =3D 0x36f24b0, be_pcl_mutex =3D {__data =3D = {__lock=20 =3D 0, __count =3D 0, __owner =3D 0, __nusers =3D 0, __kind =3D 0, __spins = =3D 0,=20 __list =3D {__prev =3D 0x0, __next =3D 0x0}}, __size =3D '\000' <repeats 39 = times>, __align =3D 0}, be_syncinfo =3D 0x16bf8c0, be_pb =3D 0x0, = be_cf_ocs =3D=20 0x7f5dd19ebc40 <mdbocs>, be_private =3D 0x1fda000, be_next =3D {stqe_next = =3D=20 0x0}} #9 0x000000000044f9e4 in slap_response_play (op=3D0x7f35cc734480,=20 rs=3D0x7f35cc734010) at result.c:537 sc_next =3D 0x7f35cc734080 sc_nextp =3D 0x7f35cc733cc0 rc =3D 32768 sc =3D 0xbb2a0a8 scp =3D 0xbb2a0a8 #10 0x000000000044fc07 in send_ldap_response (op=3D0x7f35cc734480,=20 rs=3D0x7f35cc734010) at result.c:612 berbuf =3D { buffer =3D "@:s\314\065\177\000\000\200Ds\314\065\177", '\000'=20 <repeats 18 times>, "\200\352j\001\000\000\000\000\360<s\314\065\177",=20 '\000' <repeats 18 times>,=20 "\020\071s\314\065\177\000\000\326.{\321]\177\000\000\320\070s\314\000\000\0= 00\000\000\347j\001\000\000\000\000@\347j\001\000\000\000\000\374z|\321]\177= \000\000p9s\314\065\177\000\000P9s\314\065\177\000\000@:s\314\065\177\000\00= 0\200Ds\314\065\177\000\000\000\240\375\001\000\000\000\000\000\000\000\000\= 005\000\000\000=E4=95=B6F7\177\000\000\000\000\000\000\000\000\000\000\060\0= 71s\314\065\177\000\000\000\000\000\000\000\000\000\000\300Ys\314\065\177\00= 0\000\253F"...,=20 ialign =3D -864863680, lalign =3D 139869040097856, falign =3D -63760640, dalign =3D 6.9104487629142434e-310, palign =3D 0x7f35cc733a40 ""} ber =3D 0x7f35cc733850 rc =3D 0 bytes =3D 0 __PRETTY_FUNCTION__ =3D "send_ldap_response" #11 0x0000000000450b0a in slap_send_ldap_result (op=3D0x7f35cc734480,=20 rs=3D0x7f35cc734010) at result.c:891 tmp =3D 0x0 otext =3D 0x0 oref =3D 0x0 __PRETTY_FUNCTION__ =3D "slap_send_ldap_result" #12 0x00007f5dd17b57e7 in mdb_modify (op=3D0x7f35cc734480, = rs=3D0x7f35cc734010)=20 at modify.c:708 mdb =3D 0x1fda000 e =3D 0xbb2a160 manageDSAit =3D 2 textbuf =3D '\000' <repeats 16 times>, = "X;s\314\065\177\000\000\017",=20 '\000' <repeats 15 times>,=20 "\377\377\377\377\377\377\377\377\200\026\251\001", '\000' <repeats 12=20 times>,=20 "p;s\314\065\177\000\000\000\000\000\000\000\000\000\000\300Ys\314\065\177\0= 00\000\000Ws\314\065\177\000\000\000\000\000\000\000\000\000\000\227\353L\00= 0\000\000\000\000p;s\314\065\177\000\000\310Es\314\065\177\000\000\003\000\0= 00\000\000\000\000\000^\240\262\v\000\000\000\000\260\000\000\000\000\000\00= 0\000a\240\262\v\000\000\000\000^\240\262\v\000\000\000\000\260\000\000\000\= 003\000\000\000\060<s\314\065\177\000\000\221O7\321]\177\000\000\020@s\314\0= 65\177\000\000"... textlen =3D 256 txn =3D 0x0 opinfo =3D {moi_oe =3D {oe_next =3D {sle_next =3D 0x0}, oe_key =3D = 0x0},=20 moi_txn =3D 0x1cfc000, moi_ref =3D 1, moi_flag =3D 0 '\000'} moi =3D 0x7f35cc733aa0 dummy =3D {e_id =3D 0, e_name =3D {bv_len =3D 0, bv_val =3D = 0xa2c3890 ""},=20 e_nname =3D {bv_len =3D 0, bv_val =3D 0xbb2a500 ""}, e_attrs =3D 0xa3d9ea8, = e_ocflags =3D 82208, e_bv =3D {bv_len =3D 0, bv_val =3D 0x0}, e_private =3D = 0xbb2a160} preread_ctrl =3D 0x0 postread_ctrl =3D 0x0 ctrls =3D {0x0, 0x7f5dd0d51c42 <unique_modify+619>, 0x0,=20 0x7f35cc733a30, 0x7f35cc734010, 0x7f35cc734480} num_ctrls =3D 0 numads =3D 1174 #13 0x00000000004cc7ed in overlay_op_walk (op=3D0x7f35cc734480,=20 rs=3D0x7f35cc734010, which=3Dop_modify, oi=3D0x1a91680, on=3D0x0) at = backover.c:677 func =3D 0x7f5dd19ebf38 <bi+88> rc =3D 32768 #14 0x00000000004cca11 in over_op_func (op=3D0x7f35cc734480,=20 rs=3D0x7f35cc734010, which=3Dop_modify) at backover.c:730 oi =3D 0x1a91680 on =3D 0x1a90b40 be =3D 0x18bb400 db =3D {bd_info =3D 0x7f5dd19ebee0 <bi>, bd_self =3D 0x18bb400, = be_ctrls=20 =3D=20 "\000\001\001\001\000\001\000\000\001\000\000\001\001\000\001\000\000\001", = '\000' <repeats 14 times>, "\001", be_flags =3D 563464, be_restrictops =3D = 0, be_requires =3D 0, be_ssf_set =3D {sss_ssf =3D 0, sss_transport = =3D 0,=20 sss_tls =3D 0, sss_sasl =3D 0, sss_update_ssf =3D 0, sss_update_transport = =3D 0,=20 sss_update_tls =3D 0, sss_update_sasl =3D 0, sss_simple_bind =3D 0}, = be_suffix =3D=20 0x1da1140, be_nsuffix =3D 0x1da1180, be_schemadn =3D {bv_len =3D 0, bv_val = =3D 0x0},=20 be_schemandn =3D {bv_len =3D 0, bv_val =3D 0x0}, be_rootdn =3D {bv_len =3D = 9, bv_val=20 =3D 0x1bb8c60 "cn=3Dconfig"}, be_rootndn =3D {bv_len =3D 9, bv_val =3D 0x1bb8c80 "cn=3Dconfig"}, be_rootpw =3D {bv_len =3D = 0,=20 bv_val =3D 0x0}, be_max_deref_depth =3D 15, be_def_limit =3D {lms_t_soft = =3D -1,=20 lms_t_hard =3D 0, lms_s_soft =3D -1, lms_s_hard =3D 0, lms_s_unchecked =3D = -1,=20 lms_s_pr =3D 0, lms_s_pr_hide =3D 0, lms_s_pr_total =3D 0}, be_limits =3D 0x0, = be_acl=20 =3D 0x1c22060, be_dfltaccess =3D ACL_READ, be_extra_anlist =3D 0x0, = be_update_ndn=20 =3D {bv_len =3D 0, bv_val =3D 0x0}, be_update_refs =3D 0x0, be_pending_csn_list =3D 0x36f24b0, be_pcl_mutex =3D {__data =3D = {__lock=20 =3D 0, __count =3D 0, __owner =3D 0, __nusers =3D 0, __kind =3D 0, __spins = =3D 0,=20 __list =3D {__prev =3D 0x0, __next =3D 0x0}}, __size =3D '\000' <repeats 39 = times>, __align =3D 0}, be_syncinfo =3D 0x16bf8c0, be_pb =3D 0x0, = be_cf_ocs =3D=20 0x7f5dd19ebc40 <mdbocs>, be_private =3D 0x1fda000, be_next =3D {stqe_next = =3D=20 0x0}} cb =3D {sc_next =3D 0x7f35cc734080, sc_response =3D 0x4cb874=20 <over_back_response>, sc_cleanup =3D 0x0, sc_writewait =3D 0x0, sc_private = =3D=20 0x1a91680} sc =3D 0x4ce698 <slap_queue_csn+414> rc =3D 32768 __PRETTY_FUNCTION__ =3D "over_op_func" #15 0x00000000004ccb45 in over_op_modify (op=3D0x7f35cc734480,=20 rs=3D0x7f35cc734010) at backover.c:769 No locals. #16 0x00000000004bf7a7 in syncrepl_updateCookie (si=3D0x16c0ec0,=20 op=3D0x7f35cc734480, syncCookie=3D0x7f35cc7342c0) at syncrepl.c:3934 be =3D 0x18bb400 mod =3D {sml_mod =3D {sm_desc =3D 0x16aea80, sm_values =3D = 0xa5d1c00,=20 sm_nvalues =3D 0x0, sm_numvals =3D 5, sm_op =3D 2, sm_flags =3D 1, sm_type = =3D=20 {bv_len =3D 10, bv_val =3D 0x1697370 "contextCSN"}}, sml_next =3D 0x0} first =3D {bv_len =3D 40, bv_val =3D 0xe7d6ae0=20 "20160711142209.998656Z#000000#003#000000"} sc =3D {ctxcsn =3D 0xa5d1c00, sids =3D 0xa41da60, numcsns =3D 5, = rid =3D 0,=20 octet_str =3D {bv_len =3D 0, bv_val =3D 0x0}, sid =3D 0, sc_next =3D = {stqe_next =3D=20 0x0}} syn =3D 0x18ad980 rc =3D 0 i =3D 1 j =3D 3 changed =3D 1 len =3D 40 cb =3D {sc_next =3D 0xbb2a078, sc_response =3D 0x4c128e = <null_callback>,=20 sc_cleanup =3D 0x0, sc_writewait =3D 0x0, sc_private =3D 0x16c0ec0} rs_modify =3D {sr_type =3D REP_RESULT, sr_tag =3D 103, sr_msgid =3D = 0,=20 sr_err =3D 0, sr_matched =3D 0x0, sr_text =3D 0x0, sr_ref =3D 0x0, sr_ctrls = =3D 0x0,=20 sr_un =3D {sru_search =3D {r_entry =3D 0x0, r_attr_flags =3D 0, = r_operational_attrs=20 =3D 0x0, r_attrs =3D 0x0, r_nentries =3D 0, r_v2ref =3D 0x0}, sru_sasl = =3D=20 {r_sasldata =3D 0x0}, sru_extended =3D {r_rspoid =3D 0x0, r_rspdata =3D = 0x0}},=20 sr_flags =3D 0} __PRETTY_FUNCTION__ =3D "syncrepl_updateCookie" #17 0x00000000004b53f2 in do_syncrep2 (op=3D0x7f35cc734480, si=3D0x16c0ec0) = at=20 syncrepl.c:1017 match =3D 0 syncUUID =3D {{bv_len =3D 16, bv_val =3D 0x36df567 "\231=20 \253R=DB=BE\020\065\223F\371\233\300\266/?"}, {bv_len =3D 0, bv_val =3D = 0x0}} cookie =3D {bv_len =3D 60, bv_val =3D 0x36df579=20 "rid=3D003,sid=3D003,csn=3D20160711142209.998656Z#000000#003#000000"} rctrls =3D 0xa4116a0 rctrlp =3D 0xe77d340 bdn =3D {bv_len =3D 44, bv_val =3D 0xa38d989=20 "reqStart=3D20160711142209.998570Z,cn=3Daccesslog"} si_tag =3D 139869040100480 entry =3D 0x0 punlock =3D 0 syncstate =3D 1 retdata =3D 0x0 retoid =3D 0x7f35cc734330 "\265\365m\003" syncUUIDs =3D 0xe7b6580 len =3D 60 berbuf =3D { buffer =3D "\002\000\001", '\000' <repeats 29 times>,=20 "`\365m\003\000\000\000\000\265\365m\003\000\000\000\000\265\365m\003",=20 '\000' <repeats 28 times>,=20 "\030\000\000\000\060\000\000\000\000Js\314\065\177\000\000@Is\314\065\177",= =20 '\000' <repeats 19 times>, "\240\262\v", '\000' <repeats 28 times>,=20 "\t\373\206\326]\177\000\000\000Ws\314\065\177\000\000@cu\000\000\000\000\00= 0\340Cs\314\065\177\000\000\t\373\206\326]\177\000\000\230Ds\314\001\000\000= \000"..., ialign =3D 65538, lalign =3D 65538, falign =3D 9.18382988e-41, = dalign =3D=20 3.2380074297143616e-319, palign =3D 0x10002 <Address 0x10002 out of = bounds>} ber =3D 0x7f35cc734300 msg =3D 0xe4b8a80 syncCookie =3D {ctxcsn =3D 0xe77b700, sids =3D 0xa4871e8, numcsns = =3D 1,=20 rid =3D 3, octet_str =3D {bv_len =3D 60, bv_val =3D 0xe9586c0=20 "rid=3D003,sid=3D003,csn=3D20160711142209.998656Z#000000#003#000000"}, sid = =3D 3,=20 sc_next =3D {stqe_next =3D 0x0}} syncCookie_req =3D {ctxcsn =3D 0xa5d10c0, sids =3D 0xe98c320, = numcsns =3D=20 5, rid =3D 3, octet_str =3D {bv_len =3D 0, bv_val =3D 0x0}, sid =3D 2, = sc_next =3D=20 {stqe_next =3D 0x0}} rc =3D 0 err =3D 0 modlist =3D 0x0 m =3D 0 tout_p =3D 0x7f35cc734250 tout =3D {tv_sec =3D 0, tv_usec =3D 0} refreshDeletes =3D 0 empty =3D "empty" __PRETTY_FUNCTION__ =3D "do_syncrep2" #18 0x00000000004b74f4 in do_syncrepl (ctx=3D0x7f35cc734bb0, = arg=3D0x16bbea0)=20 at syncrepl.c:1565 rtask =3D 0x16bbea0 si =3D 0x16c0ec0 conn =3D {c_struct_state =3D SLAP_C_UNINITIALIZED, c_conn_state =3D = SLAP_C_INVALID, c_conn_idx =3D -1, c_sd =3D 0, c_close_reason =3D 0x0, = c_mutex =3D=20 {__data =3D {__lock =3D 0, __count =3D 0, __owner =3D 0, __nusers =3D 0, = __kind =3D 0,=20 __spins =3D 0, __list =3D {__prev =3D 0x0, __next =3D 0x0}}, __size =3D = '\000'=20 <repeats 39 times>, __align =3D 0}, c_sb =3D 0x0, c_starttime =3D 0,=20 c_activitytime =3D 0, c_connid =3D 18446744073709551615, c_peer_domain =3D=20 {bv_len =3D 0, bv_val =3D 0x4f05b0 ""}, c_peer_name =3D {bv_len =3D 0, bv_val = =3D=20 0x4f05b0 ""}, c_listener =3D 0x4f8740 <dummy_list>, c_sasl_bind_mech =3D=20 {bv_len =3D 0, bv_val =3D 0x0}, c_sasl_dn =3D {bv_len =3D 0, bv_val =3D = 0x0},=20 c_sasl_authz_dn =3D { bv_len =3D 0, bv_val =3D 0x0}, c_authz_backend =3D 0x0,=20 c_authz_cookie =3D 0x0, c_authz =3D {sai_method =3D 0, sai_mech =3D {bv_len = =3D 0,=20 bv_val =3D 0x0}, sai_dn =3D {bv_len =3D 0, bv_val =3D 0x0}, sai_ndn =3D = {bv_len =3D 0,=20 bv_val =3D 0x0}, sai_ssf =3D 0, sai_transport_ssf =3D 0, sai_tls_ssf =3D 0,=20 sai_sasl_ssf =3D 0}, c_protocol =3D 0, c_ops =3D {stqh_first =3D 0x0, = stqh_last =3D=20 0x0}, c_pending_ops =3D {stqh_first =3D 0x0, stqh_last =3D 0x0}, = c_write1_mutex =3D=20 {__data =3D { __lock =3D 0, __count =3D 0, __owner =3D 0, __nusers =3D 0, = __kind =3D=20 0, __spins =3D 0, __list =3D {__prev =3D 0x0, __next =3D 0x0}}, __size =3D = '\000'=20 <repeats 39 times>, __align =3D 0}, c_write1_cv =3D {__data =3D {__lock =3D = 0,=20 __futex =3D 0, __total_seq =3D 0, __wakeup_seq =3D 0, __woken_seq =3D 0, = __mutex =3D=20 0x0, __nwaiters =3D 0, __broadcast_seq =3D 0}, __size =3D '\000' <repeats = 47=20 times>, __align =3D 0}, c_write2_mutex =3D {__data =3D {__lock =3D 0, = __count =3D 0,=20 __owner =3D 0, __nusers =3D 0, __kind =3D 0, __spins =3D 0, __list =3D = {__prev =3D=20 0x0, __next =3D 0x0}}, __size =3D '\000' <repeats 39 times>, __align =3D = 0},=20 c_write2_cv =3D {__data =3D {__lock =3D 0, __futex =3D 0, __total_seq =3D = 0,=20 __wakeup_seq =3D 0, __woken_seq =3D 0, __mutex =3D 0x0, __nwaiters =3D 0,=20 __broadcast_seq =3D 0}, __size =3D '\000' <repeats 47 times>, __align =3D = 0},=20 c_currentber =3D 0x0, c_writers =3D 0, c_writing =3D 0 '\000',=20 c_sasl_bind_in_progress =3D 0 '\000', c_writewaiter =3D 0 '\000', c_is_tls =3D 0 '\000', = c_needs_tls_accept=20 =3D 0 '\000', c_sasl_layers =3D 0 '\000', c_sasl_done =3D 0 '\000',=20 c_sasl_authctx =3D 0x0, c_sasl_sockctx =3D 0x0, c_sasl_extra =3D 0x0,=20 c_sasl_bindop =3D 0x0, c_pagedresults_state =3D {ps_be =3D 0x0, ps_size =3D 0, ps_count = =3D 0,=20 ps_cookie =3D 0, ps_cookieval =3D {bv_len =3D 0, bv_val =3D 0x0}}, = c_n_ops_received=20 =3D 0, c_n_ops_executing =3D 0, c_n_ops_pending =3D 0, c_n_ops_completed = =3D 0,=20 c_n_get =3D 0, c_n_read =3D 0, c_n_write =3D 0, c_extensions =3D 0x0, = c_clientfunc =3D=20 0x0, c_clientarg =3D 0x0, c_send_ldap_result =3D 0x4506fe=20 <slap_send_ldap_result>, c_send_search_entry =3D 0x451575=20 <slap_send_search_entry>, c_send_search_reference =3D 0x453527 = <slap_send_search_reference>,=20 c_send_ldap_extended =3D 0x45105e <slap_send_ldap_extended>,=20 c_send_ldap_intermediate =3D 0x451360 <slap_send_ldap_intermediate>} opbuf =3D {ob_op =3D {o_hdr =3D 0x7f35cc7345f0, o_tag =3D 102, = o_time =3D=20 1468246929, o_tincr =3D 1000000, o_bd =3D 0x7f35cc733620, o_req_dn =3D = {bv_len =3D=20 0, bv_val =3D 0x1693048 ""}, o_req_ndn =3D {bv_len =3D 0, bv_val =3D = 0x1693048 ""}, o_request =3D {oq_add =3D {rs_modlist =3D 0x7f35cc734100, rs_e = =3D=20 0x1}, oq_bind =3D {rb_method =3D -864861952, rb_cred =3D {bv_len =3D 1, = bv_val =3D=20 0x0}, rb_edn =3D {bv_len =3D 0, bv_val =3D 0x0}, rb_ssf =3D 0, rb_mech =3D = {bv_len =3D=20 0, bv_val =3D 0x0}}, oq_compare =3D {rs_ava =3D = 0x7f35cc734100},=20 oq_modify =3D {rs_mods =3D {rs_modlist =3D 0x7f35cc734100, rs_no_opattrs = =3D 1=20 '\001'}, rs_increment =3D 0}, oq_modrdn =3D {rs_mods =3D {rs_modlist =3D=20 0x7f35cc734100, rs_no_opattrs =3D 1 '\001'}, rs_deleteoldrdn =3D 0, = rs_newrdn=20 =3D {bv_len =3D 0, bv_val =3D 0x0}, rs_nnewrdn =3D {bv_len =3D 0, bv_val = =3D 0x0},=20 rs_newSup =3D 0x0, rs_nnewSup =3D 0x0}, oq_search =3D {rs_scope =3D = -864861952, rs_deref =3D 32565, rs_slimit =3D 1, rs_tlimit =3D 0, = rs_limit =3D=20 0x0, rs_attrsonly =3D 0, rs_attrs =3D 0x0, rs_filter =3D 0x0, rs_filterstr = =3D=20 {bv_len =3D 0, bv_val =3D 0x0}}, oq_abandon =3D {rs_msgid =3D -864861952},=20 oq_cancel =3D { rs_msgid =3D -864861952}, oq_extended =3D {rs_reqoid =3D = {bv_len=20 =3D 139869040099584, bv_val =3D 0x1 <Address 0x1 out of bounds>}, rs_flags = =3D 0,=20 rs_reqdata =3D 0x0}, oq_pwdexop =3D {rs_extended =3D {rs_reqoid =3D { bv_len =3D 139869040099584, bv_val =3D 0x1 <Address 0x1 = out=20 of bounds>}, rs_flags =3D 0, rs_reqdata =3D 0x0}, rs_old =3D {bv_len =3D 0, = bv_val=20 =3D 0x0}, rs_new =3D {bv_len =3D 0, bv_val =3D 0x0}, rs_mods =3D 0x0, = rs_modtail =3D=20 0x0}}, o_abandon =3D 0, o_cancel =3D 0, o_groups =3D 0x0, = o_do_not_cache =3D 0=20 '\000', o_is_auth_check =3D 0 '\000', o_dont_replicate =3D 1 '\001', = o_acl_priv=20 =3D ACL_NONE, o_nocaching =3D 0 '\000', o_delete_glue_parent =3D 0 '\000', o_no_schema_check =3D 1 '\001', o_no_subordinate_glue =3D 0 = '\000',=20 o_ctrlflag =3D '\000' <repeats 14 times>, "\002", '\000' <repeats 16 = times>,=20 o_controls =3D 0x7f35cc734738, o_authz =3D {sai_method =3D 0, sai_mech =3D = {bv_len=20 =3D 0, bv_val =3D 0x0}, sai_dn =3D {bv_len =3D 9, bv_val =3D = 0x1bb8c60=20 "cn=3Dconfig"}, sai_ndn =3D {bv_len =3D 9, bv_val =3D 0x1bb8c80 = "cn=3Dconfig"},=20 sai_ssf =3D 0, sai_transport_ssf =3D 0, sai_tls_ssf =3D 0, sai_sasl_ssf =3D = 0},=20 o_ber =3D 0x0, o_res_ber =3D 0x0, o_callback =3D 0x7f35cc733cc0, o_ctrls =3D = 0x0,=20 o_csn =3D {bv_len =3D 40, bv_val =3D 0xbb2a040=20 "20160711142209.998656Z#000000#003#000000"}, o_private =3D 0x0, o_extra =3D = {slh_first =3D 0x0}, o_next =3D {stqe_next =3D 0x0}}, ob_hdr =3D {oh_opid =3D 0, oh_connid =3D 3, oh_conn =3D = 0x7f35cc734840,=20 oh_msgid =3D 0, oh_protocol =3D 0, oh_tid =3D 139869040105216, oh_threadctx = =3D=20 0x7f35cc734bb0, oh_tmpmemctx =3D 0xa322d80, oh_tmpmfuncs =3D 0x7543c0=20 <slap_sl_mfuncs>, oh_counters =3D 0x7578c0 <slap_counters>, oh_log_prefix =3D=20 "conn=3D-1 op=3D0", '\000' <repeats 243 times>}, ob_controls =3D {0x0 = <repeats 17=20 times>, 0x7f35cc7342c0, 0x0 <repeats 14 times>}} op =3D 0x7f35cc734480 rc =3D 0 dostop =3D 0 s =3D 11 i =3D 0 defer =3D 1 fail =3D 0 freeinfo =3D 0 be =3D 0x18bb400 #19 0x000000000043a59d in connection_read_thread (ctx=3D0x7f35cc734bb0,=20 argv=3D0xb) at connection.c:1273 rc =3D 0 cri =3D {op =3D 0x0, func =3D 0x4b6fd7 <do_syncrepl>, arg =3D = 0x16bbea0,=20 ctx =3D 0x7f35cc734bb0, nullop =3D 0} s =3D 11 #20 0x00007f5dd686e3ea in ldap_int_thread_pool_wrapper (xpool=3D0x16ca000) = at=20 tpool.c:956 pq =3D 0x16ca000 pool =3D 0x1892240 task =3D 0x3d10060 work_list =3D 0x16ca070 ctx =3D {ltu_pq =3D 0x16ca000, ltu_id =3D 139869040105216, ltu_key = =3D=20 {{ltk_key =3D 0x439b53 <conn_counter_init>, ltk_data =3D 0x1efd300, = ltk_free =3D=20 0x4399a5 <conn_counter_destroy>}, {ltk_key =3D 0x4ac6bb <slap_sl_mem_init>, ltk_data =3D 0xa322d80, ltk_free =3D 0x4ac4e0=20 <slap_sl_mem_destroy>}, {ltk_key =3D 0x189ad00, ltk_data =3D 0x1c2f400,=20 ltk_free =3D 0x7f5dd17c6ea5 <mdb_reader_free>}, {ltk_key =3D 0x7f5dd17bc109 = <search_stack>, ltk_data =3D 0xbf2a000, ltk_free =3D 0x7f5dd17bc0e6 <search_stack_free>}, {ltk_key = =3D=20 0x7f5dd17b8cad <scope_chunk_get>, ltk_data =3D 0xbc2a000, ltk_free =3D=20 0x7f5dd17b8c65 <scope_chunk_free>}, {ltk_key =3D 0x4548c9 <slap_op_free>,=20 ltk_data =3D 0xe7b6580, ltk_free =3D 0x45481c <slap_op_q_destroy>}, {ltk_key =3D=20 0x189b400, ltk_data =3D 0xe7bce00, ltk_free =3D 0x7f5dd17c6ea5=20 <mdb_reader_free>}, {ltk_key =3D 0x0, ltk_data =3D 0xe3ba800, ltk_free =3D = 0x0},=20 {ltk_key =3D 0x0, ltk_data =3D 0x0, ltk_free =3D 0x0} <repeats 24 times>}} kctx =3D 0x0 i =3D 32 keyslot =3D 778 hash =3D 2062069514 pool_lock =3D 0 freeme =3D 0 __PRETTY_FUNCTION__ =3D "ldap_int_thread_pool_wrapper" #21 0x00007f5dd52dfdc5 in start_thread (arg=3D0x7f35cc735700) at=20 pthread_create.c:308 __res =3D <optimized out> pd =3D 0x7f35cc735700 now =3D <optimized out> unwind_buf =3D {cancel_jmp_buf =3D {{jmp_buf =3D {139869040105216,=20 9196993683121098082, 0, 139869040105920, 139869040105216, 0,=20 -9094507210520539806, -9144027579543728798}, mask_was_saved =3D 0}}, priv = =3D=20 {pad =3D {0x0, 0x0, 0x0, 0x0}, data =3D {prev =3D 0x0, cleanup =3D 0x0, canceltype =3D 0}}} not_first_call =3D <optimized out> pagesize_m1 =3D <optimized out> sp =3D <optimized out> freesize =3D <optimized out> #22 0x00007f5dd500cced in clone () at=20 ../sysdeps/unix/sysv/linux/x86_64/clone.S:113 No locals. --Quanah -- Quanah Gibson-Mount Platform Architect Manager, Systems Team Zimbra, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration A division of Synacor, Inc

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs