- openldap-bugs - openldap.org

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