openldap-bugs

openldap-bugs@openldap.org

1 participants
20966 discussions

Re: (ITS#8106) Retry pwrite operations in case of EINTR
by milinevskyy＠gmail.com 17 Apr '15

17 Apr '15

--f46d04426b642829070513e7a46a Content-Type: text/plain; charset=UTF-8 Proposed patch in message body as issue tracker doesn't recognizes attachments: commit c9857a7c0df4448a14a2aa9f55850df5e830069e Author: Dmytro Milinevskyy <milinevskyy(a)gmail.com> Date: Fri Apr 17 10:41:26 2015 +0200 libmdb: retry write operation in case of interrupted system diff --git a/libraries/liblmdb/mdb.c b/libraries/liblmdb/mdb.c index a95c7cd..ed7f370 100644 --- a/libraries/liblmdb/mdb.c +++ b/libraries/liblmdb/mdb.c @@ -3236,6 +3236,7 @@ mdb_page_flush(MDB_txn *txn, int keep) /* Write up to MDB_COMMIT_PAGES dirty pages at a time. */ if (pos!=next_pos || n==MDB_COMMIT_PAGES || wsize+size>MAX_WRITE) { if (n) { + retry_write: /* Write previous page(s) */ #ifdef MDB_USE_PWRITEV wres = pwritev(env->me_fd, iov, n, wpos); @@ -3243,8 +3244,10 @@ mdb_page_flush(MDB_txn *txn, int keep) if (n == 1) { wres = pwrite(env->me_fd, iov[0].iov_base, wsize, wpos); } else { + retry_seek: if (lseek(env->me_fd, wpos, SEEK_SET) == -1) { rc = ErrCode(); + if (EINTR == rc) goto retry_seek; DPRINTF(("lseek: %s", strerror(rc))); return rc; } @@ -3254,6 +3257,7 @@ mdb_page_flush(MDB_txn *txn, int keep) if (wres != wsize) { if (wres < 0) { rc = ErrCode(); + if (EINTR == rc) goto retry_write; DPRINTF(("Write error: %s", strerror(rc))); } else { rc = EIO; /* TODO: Use which error code? */ @@ -3627,7 +3631,8 @@ mdb_env_init_meta(MDB_env *env, MDB_meta *meta) int len; #define DO_PWRITE(rc, fd, ptr, size, len, pos) do { \ len = pwrite(fd, ptr, size, pos); \ - rc = (len >= 0); } while(0) + if (len == -1 && EINVAL == ErrCode()) continue; \ + rc = (len >= 0); break; } while(1) #endif DPUTS("writing new meta page"); @@ -3735,6 +3740,7 @@ mdb_env_write_meta(MDB_txn *txn) /* Write to the SYNC fd */ mfd = (flags & (MDB_NOSYNC|MDB_NOMETASYNC)) ? env->me_fd : env->me_mfd; +retry_write: #ifdef _WIN32 { memset(&ov, 0, sizeof(ov)); @@ -3747,6 +3753,7 @@ mdb_env_write_meta(MDB_txn *txn) #endif if (rc != len) { rc = rc < 0 ? ErrCode() : EIO; + if (EINTR == rc) goto retry_write; DPUTS("write failed, disk error?"); /* On a failure, the pagecache still contains the new data. * Write some old data back, to prevent it from being used. On Fri, Apr 17, 2015 at 10:46 AM, Dmytro Milinevskyy <milinevskyy(a)gmail.com> wrote: > Proposed patch in attachment. > > On Fri, Apr 17, 2015 at 10:43 AM, <openldap-its(a)openldap.org> wrote: > >> >> *** THIS IS AN AUTOMATICALLY GENERATED REPLY *** >> >> Thanks for your report to the OpenLDAP Issue Tracking System. Your >> report has been assigned the tracking number ITS#8106. >> >> One of our support engineers will look at your report in due course. >> Note that this may take some time because our support engineers >> are volunteers. They only work on OpenLDAP when they have spare >> time. >> >> If you need to provide additional information in regards to your >> issue report, you may do so by replying to this message. Note that >> any mail sent to openldap-its(a)openldap.org with (ITS#8106) >> in the subject will automatically be attached to the issue report. >> >> mailto:openldap-its@openldap.org?subject=(ITS#8106) >> >> You may follow the progress of this report by loading the following >> URL in a web browser: >> http://www.OpenLDAP.org/its/index.cgi?findid=8106 >> >> Please remember to retain your issue tracking number (ITS#8106) >> on any further messages you send to us regarding this report. If >> you don't then you'll just waste our time and yours because we >> won't be able to properly track the report. >> >> Please note that the Issue Tracking System is not intended to >> be used to seek help in the proper use of OpenLDAP Software. >> Such requests will be closed. >> >> OpenLDAP Software is user supported. >> http://www.OpenLDAP.org/support/ >> >> -------------- >> Copyright 1998-2007 The OpenLDAP Foundation, All Rights Reserved. >> >> > --f46d04426b642829070513e7a46a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: base64 PGRpdiBkaXI9Imx0ciI+UHJvcG9zZWQgcGF0Y2ggaW4gbWVzc2FnZSBib2R5IGFzIGlzc3VlIHRy YWNrZXIgZG9lc24mIzM5O3QgcmVjb2duaXplcyBhdHRhY2htZW50czo8YnI+PGJyPmNvbW1pdCBj OTg1N2E3YzBkZjQ0NDhhMTRhMmFhOWY1NTg1MGRmNWU4MzAwNjllPGJyPkF1dGhvcjogRG15dHJv IE1pbGluZXZza3l5ICZsdDs8YSBocmVmPSJtYWlsdG86bWlsaW5ldnNreXlAZ21haWwuY29tIj5t aWxpbmV2c2t5eUBnbWFpbC5jb208L2E+Jmd0Ozxicj5EYXRlOsKgwqAgRnJpIEFwciAxNyAxMDo0 MToyNiAyMDE1ICswMjAwPGJyPjxicj7CoMKgwqAgbGlibWRiOiByZXRyeSB3cml0ZSBvcGVyYXRp b24gaW4gY2FzZSBvZiBpbnRlcnJ1cHRlZCBzeXN0ZW08YnI+PGJyPmRpZmYgLS1naXQgYS9saWJy YXJpZXMvbGlibG1kYi9tZGIuYyBiL2xpYnJhcmllcy9saWJsbWRiL21kYi5jPGJyPmluZGV4IGE5 NWM3Y2QuLmVkN2YzNzAgMTAwNjQ0PGJyPi0tLSBhL2xpYnJhcmllcy9saWJsbWRiL21kYi5jPGJy PisrKyBiL2xpYnJhcmllcy9saWJsbWRiL21kYi5jPGJyPkBAIC0zMjM2LDYgKzMyMzYsNyBAQCBt ZGJfcGFnZV9mbHVzaChNREJfdHhuICp0eG4sIGludCBrZWVwKTxicj7CoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqAgLyogV3JpdGUgdXAgdG8gTURCX0NPTU1JVF9QQUdFUyBkaXJ0eSBwYWdl cyBhdCBhIHRpbWUuICovPGJyPsKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCBpZiAocG9z IT1uZXh0X3BvcyB8fCBuPT1NREJfQ09NTUlUX1BBR0VTIHx8IHdzaXplK3NpemUmZ3Q7TUFYX1dS SVRFKSB7PGJyPsKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAg aWYgKG4pIHs8YnI+K8KgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgIHJldHJ5X3dyaXRlOjxicj7C oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoCAvKiBXcml0ZSBwcmV2aW91cyBwYWdlKHMpICovPGJyPsKgI2lmZGVmIE1EQl9VU0VfUFdS SVRFVjxicj7CoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoCB3cmVzID0gcHdyaXRldihlbnYtJmd0O21lX2ZkLCBpb3YsIG4sIHdwb3Mp Ozxicj5AQCAtMzI0Myw4ICszMjQ0LDEwIEBAIG1kYl9wYWdlX2ZsdXNoKE1EQl90eG4gKnR4biwg aW50IGtlZXApPGJyPsKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgIGlmIChuID09IDEpIHs8YnI+wqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg IHdyZXMgPSBwd3JpdGUoZW52LSZndDttZV9mZCwgaW92WzBdLmlvdl9iYXNlLCB3c2l6ZSwgd3Bv cyk7PGJyPsKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgIH0gZWxzZSB7PGJyPivCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgIHJldHJ5X3NlZWs6PGJyPsKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoCBpZiAobHNlZWsoZW52LSZndDttZV9mZCwgd3BvcywgU0VFS19TRVQpID09 IC0xKSB7PGJyPsKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAgcmMgPSBFcnJD b2RlKCk7PGJyPivCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCBpZiAoRUlOVFIg PT0gcmMpIGdvdG8gcmV0cnlfc2Vlazs8YnI+wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoCBEUFJJTlRGKCgmcXVvdDtsc2VlazogJXMmcXVvdDssIHN0cmVycm9yKHJjKSkpOzxi cj7CoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgIHJldHVybiByYzs8YnI+wqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgIH08YnI+QEAgLTMyNTQsNiArMzI1Nyw3IEBAIG1kYl9wYWdlX2Zs dXNoKE1EQl90eG4gKnR4biwgaW50IGtlZXApPGJyPsKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgIGlmICh3cmVzICE9IHdzaXplKSB7 PGJyPsKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCBpZiAod3JlcyAmbHQ7IDApIHs8YnI+wqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCByYyA9IEVyckNvZGUoKTs8YnI+K8KgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgIGlmIChFSU5UUiA9PSByYykgZ290byByZXRyeV93 cml0ZTs8YnI+wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCBEUFJJTlRGKCgm cXVvdDtXcml0ZSBlcnJvcjogJXMmcXVvdDssIHN0cmVycm9yKHJjKSkpOzxicj7CoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqAgfSBlbHNlIHs8YnI+wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoCByYyA9IEVJTzsgLyogVE9ETzogVXNlIHdoaWNoIGVycm9yIGNvZGU/ICovPGJyPkBAIC0z NjI3LDcgKzM2MzEsOCBAQCBtZGJfZW52X2luaXRfbWV0YShNREJfZW52ICplbnYsIE1EQl9tZXRh ICptZXRhKTxicj7CoMKgwqDCoMKgwqDCoCBpbnQgbGVuOzxicj7CoCNkZWZpbmUgRE9fUFdSSVRF KHJjLCBmZCwgcHRyLCBzaXplLCBsZW4sIHBvcykgZG8geyBcPGJyPsKgwqDCoMKgwqDCoMKgIGxl biA9IHB3cml0ZShmZCwgcHRyLCBzaXplLCBwb3MpO8KgwqDCoMKgwqDCoCBcPGJyPi3CoMKgwqDC oMKgwqAgcmMgPSAobGVuICZndDs9IDApOyB9IHdoaWxlKDApPGJyPivCoMKgwqDCoMKgwqAgaWYg KGxlbiA9PSAtMSAmYW1wOyZhbXA7IEVJTlZBTCA9PSBFcnJDb2RlKCkpIGNvbnRpbnVlOyBcPGJy PivCoMKgwqDCoMKgwqAgcmMgPSAobGVuICZndDs9IDApOyBicmVhazsgfSB3aGlsZSgxKTxicj7C oCNlbmRpZjxicj48YnI+wqDCoMKgwqDCoMKgwqAgRFBVVFMoJnF1b3Q7d3JpdGluZyBuZXcgbWV0 YSBwYWdlJnF1b3Q7KTs8YnI+QEAgLTM3MzUsNiArMzc0MCw3IEBAIG1kYl9lbnZfd3JpdGVfbWV0 YShNREJfdHhuICp0eG4pPGJyPjxicj7CoMKgwqDCoMKgwqDCoCAvKiBXcml0ZSB0byB0aGUgU1lO QyBmZCAqLzxicj7CoMKgwqDCoMKgwqDCoCBtZmQgPSAoZmxhZ3MgJmFtcDsgKE1EQl9OT1NZTkN8 TURCX05PTUVUQVNZTkMpKSA/IGVudi0mZ3Q7bWVfZmQgOiBlbnYtJmd0O21lX21mZDs8YnI+K3Jl dHJ5X3dyaXRlOjxicj7CoCNpZmRlZiBfV0lOMzI8YnI+wqDCoMKgwqDCoMKgwqAgezxicj7CoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAgbWVtc2V0KCZhbXA7b3YsIDAsIHNpemVvZihvdikp Ozxicj5AQCAtMzc0Nyw2ICszNzUzLDcgQEAgbWRiX2Vudl93cml0ZV9tZXRhKE1EQl90eG4gKnR4 bik8YnI+wqAjZW5kaWY8YnI+wqDCoMKgwqDCoMKgwqAgaWYgKHJjICE9IGxlbikgezxicj7CoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAgcmMgPSByYyAmbHQ7IDAgPyBFcnJDb2RlKCkgOiBF SU87PGJyPivCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgIGlmIChFSU5UUiA9PSByYykgZ290 byByZXRyeV93cml0ZTs8YnI+wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgIERQVVRTKCZx dW90O3dyaXRlIGZhaWxlZCwgZGlzayBlcnJvcj8mcXVvdDspOzxicj7CoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqAgLyogT24gYSBmYWlsdXJlLCB0aGUgcGFnZWNhY2hlIHN0aWxsIGNvbnRh aW5zIHRoZSBuZXcgZGF0YS48YnI+wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAgKiBX cml0ZSBzb21lIG9sZCBkYXRhIGJhY2ssIHRvIHByZXZlbnQgaXQgZnJvbSBiZWluZyB1c2VkLjxi cj48L2Rpdj48ZGl2IGNsYXNzPSJnbWFpbF9leHRyYSI+PGJyPjxkaXYgY2xhc3M9ImdtYWlsX3F1 b3RlIj5PbiBGcmksIEFwciAxNywgMjAxNSBhdCAxMDo0NiBBTSwgRG15dHJvIE1pbGluZXZza3l5 IDxzcGFuIGRpcj0ibHRyIj4mbHQ7PGEgaHJlZj0ibWFpbHRvOm1pbGluZXZza3l5QGdtYWlsLmNv bSIgdGFyZ2V0PSJfYmxhbmsiPm1pbGluZXZza3l5QGdtYWlsLmNvbTwvYT4mZ3Q7PC9zcGFuPiB3 cm90ZTo8YnI+PGJsb2NrcXVvdGUgY2xhc3M9ImdtYWlsX3F1b3RlIiBzdHlsZT0ibWFyZ2luOjAg MCAwIC44ZXg7Ym9yZGVyLWxlZnQ6MXB4ICNjY2Mgc29saWQ7cGFkZGluZy1sZWZ0OjFleCI+PGRp diBkaXI9Imx0ciI+UHJvcG9zZWQgcGF0Y2ggaW4gYXR0YWNobWVudC48YnI+PC9kaXY+PGRpdiBj bGFzcz0iSE9FblpiIj48ZGl2IGNsYXNzPSJoNSI+PGRpdiBjbGFzcz0iZ21haWxfZXh0cmEiPjxi cj48ZGl2IGNsYXNzPSJnbWFpbF9xdW90ZSI+T24gRnJpLCBBcHIgMTcsIDIwMTUgYXQgMTA6NDMg QU0sICA8c3BhbiBkaXI9Imx0ciI+Jmx0OzxhIGhyZWY9Im1haWx0bzpvcGVubGRhcC1pdHNAb3Bl bmxkYXAub3JnIiB0YXJnZXQ9Il9ibGFuayI+b3BlbmxkYXAtaXRzQG9wZW5sZGFwLm9yZzwvYT4m Z3Q7PC9zcGFuPiB3cm90ZTo8YnI+PGJsb2NrcXVvdGUgY2xhc3M9ImdtYWlsX3F1b3RlIiBzdHls ZT0ibWFyZ2luOjAgMCAwIC44ZXg7Ym9yZGVyLWxlZnQ6MXB4ICNjY2Mgc29saWQ7cGFkZGluZy1s ZWZ0OjFleCI+PGJyPg0KKioqIFRISVMgSVMgQU4gQVVUT01BVElDQUxMWSBHRU5FUkFURUQgUkVQ TFkgKioqPGJyPg0KPGJyPg0KVGhhbmtzIGZvciB5b3VyIHJlcG9ydCB0byB0aGUgT3BlbkxEQVAg SXNzdWUgVHJhY2tpbmcgU3lzdGVtLsKgIFlvdXI8YnI+DQpyZXBvcnQgaGFzIGJlZW4gYXNzaWdu ZWQgdGhlIHRyYWNraW5nIG51bWJlciBJVFMjODEwNi48YnI+DQo8YnI+DQpPbmUgb2Ygb3VyIHN1 cHBvcnQgZW5naW5lZXJzIHdpbGwgbG9vayBhdCB5b3VyIHJlcG9ydCBpbiBkdWUgY291cnNlLjxi cj4NCk5vdGUgdGhhdCB0aGlzIG1heSB0YWtlIHNvbWUgdGltZSBiZWNhdXNlIG91ciBzdXBwb3J0 IGVuZ2luZWVyczxicj4NCmFyZSB2b2x1bnRlZXJzLsKgIFRoZXkgb25seSB3b3JrIG9uIE9wZW5M REFQIHdoZW4gdGhleSBoYXZlIHNwYXJlPGJyPg0KdGltZS48YnI+DQo8YnI+DQpJZiB5b3UgbmVl ZCB0byBwcm92aWRlIGFkZGl0aW9uYWwgaW5mb3JtYXRpb24gaW4gcmVnYXJkcyB0byB5b3VyPGJy Pg0KaXNzdWUgcmVwb3J0LCB5b3UgbWF5IGRvIHNvIGJ5IHJlcGx5aW5nIHRvIHRoaXMgbWVzc2Fn ZS7CoCBOb3RlIHRoYXQ8YnI+DQphbnkgbWFpbCBzZW50IHRvIDxhIGhyZWY9Im1haWx0bzpvcGVu bGRhcC1pdHNAb3BlbmxkYXAub3JnIiB0YXJnZXQ9Il9ibGFuayI+b3BlbmxkYXAtaXRzQG9wZW5s ZGFwLm9yZzwvYT4gd2l0aCAoSVRTIzgxMDYpPGJyPg0KaW4gdGhlIHN1YmplY3Qgd2lsbCBhdXRv bWF0aWNhbGx5IGJlIGF0dGFjaGVkIHRvIHRoZSBpc3N1ZSByZXBvcnQuPGJyPg0KPGJyPg0KwqAg wqAgwqAgwqAgbWFpbHRvOjxhIGhyZWY9Im1haWx0bzpvcGVubGRhcC1pdHNAb3BlbmxkYXAub3Jn IiB0YXJnZXQ9Il9ibGFuayI+b3BlbmxkYXAtaXRzQG9wZW5sZGFwLm9yZzwvYT4/c3ViamVjdD0o SVRTIzgxMDYpPGJyPg0KPGJyPg0KWW91IG1heSBmb2xsb3cgdGhlIHByb2dyZXNzIG9mIHRoaXMg cmVwb3J0IGJ5IGxvYWRpbmcgdGhlIGZvbGxvd2luZzxicj4NClVSTCBpbiBhIHdlYiBicm93c2Vy Ojxicj4NCsKgIMKgIDxhIGhyZWY9Imh0dHA6Ly93d3cuT3BlbkxEQVAub3JnL2l0cy9pbmRleC5j Z2k/ZmluZGlkPTgxMDYiIHRhcmdldD0iX2JsYW5rIj5odHRwOi8vd3d3Lk9wZW5MREFQLm9yZy9p dHMvaW5kZXguY2dpP2ZpbmRpZD04MTA2PC9hPjxicj4NCjxicj4NClBsZWFzZSByZW1lbWJlciB0 byByZXRhaW4geW91ciBpc3N1ZSB0cmFja2luZyBudW1iZXIgKElUUyM4MTA2KTxicj4NCm9uIGFu eSBmdXJ0aGVyIG1lc3NhZ2VzIHlvdSBzZW5kIHRvIHVzIHJlZ2FyZGluZyB0aGlzIHJlcG9ydC7C oCBJZjxicj4NCnlvdSBkb24mIzM5O3QgdGhlbiB5b3UmIzM5O2xsIGp1c3Qgd2FzdGUgb3VyIHRp bWUgYW5kIHlvdXJzIGJlY2F1c2Ugd2U8YnI+DQp3b24mIzM5O3QgYmUgYWJsZSB0byBwcm9wZXJs eSB0cmFjayB0aGUgcmVwb3J0Ljxicj4NCjxicj4NClBsZWFzZSBub3RlIHRoYXQgdGhlIElzc3Vl IFRyYWNraW5nIFN5c3RlbSBpcyBub3QgaW50ZW5kZWQgdG88YnI+DQpiZSB1c2VkIHRvIHNlZWsg aGVscCBpbiB0aGUgcHJvcGVyIHVzZSBvZiBPcGVuTERBUCBTb2Z0d2FyZS48YnI+DQpTdWNoIHJl cXVlc3RzIHdpbGwgYmUgY2xvc2VkLjxicj4NCjxicj4NCk9wZW5MREFQIFNvZnR3YXJlIGlzIHVz ZXIgc3VwcG9ydGVkLjxicj4NCsKgIMKgIMKgIMKgIDxhIGhyZWY9Imh0dHA6Ly93d3cuT3BlbkxE QVAub3JnL3N1cHBvcnQvIiB0YXJnZXQ9Il9ibGFuayI+aHR0cDovL3d3dy5PcGVuTERBUC5vcmcv c3VwcG9ydC88L2E+PGJyPg0KPGJyPg0KLS0tLS0tLS0tLS0tLS08YnI+DQpDb3B5cmlnaHQgMTk5 OC0yMDA3IFRoZSBPcGVuTERBUCBGb3VuZGF0aW9uLCBBbGwgUmlnaHRzIFJlc2VydmVkLjxicj4N Cjxicj4NCjwvYmxvY2txdW90ZT48L2Rpdj48YnI+PC9kaXY+DQo8L2Rpdj48L2Rpdj48L2Jsb2Nr cXVvdGU+PC9kaXY+PGJyPjwvZGl2Pg0K --f46d04426b642829070513e7a46a--

1 0

Re: (ITS#8106) Retry pwrite operations in case of EINTR
by milinevskyy＠gmail.com 17 Apr '15

17 Apr '15

--089e013d0c3883937b0513e79d1c Content-Type: multipart/alternative; boundary=089e013d0c3883936f0513e79d1a --089e013d0c3883936f0513e79d1a Content-Type: text/plain; charset=UTF-8 Proposed patch in attachment. On Fri, Apr 17, 2015 at 10:43 AM, <openldap-its(a)openldap.org> wrote: > > *** THIS IS AN AUTOMATICALLY GENERATED REPLY *** > > Thanks for your report to the OpenLDAP Issue Tracking System. Your > report has been assigned the tracking number ITS#8106. > > One of our support engineers will look at your report in due course. > Note that this may take some time because our support engineers > are volunteers. They only work on OpenLDAP when they have spare > time. > > If you need to provide additional information in regards to your > issue report, you may do so by replying to this message. Note that > any mail sent to openldap-its(a)openldap.org with (ITS#8106) > in the subject will automatically be attached to the issue report. > > mailto:openldap-its@openldap.org?subject=(ITS#8106) > > You may follow the progress of this report by loading the following > URL in a web browser: > http://www.OpenLDAP.org/its/index.cgi?findid=8106 > > Please remember to retain your issue tracking number (ITS#8106) > on any further messages you send to us regarding this report. If > you don't then you'll just waste our time and yours because we > won't be able to properly track the report. > > Please note that the Issue Tracking System is not intended to > be used to seek help in the proper use of OpenLDAP Software. > Such requests will be closed. > > OpenLDAP Software is user supported. > http://www.OpenLDAP.org/support/ > > -------------- > Copyright 1998-2007 The OpenLDAP Foundation, All Rights Reserved. > > --089e013d0c3883936f0513e79d1a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr">Proposed patch in attachment. </div><div class=3D"gmail= _extra"> <div class=3D"gmail_quote">On Fri, Apr 17, 2015 at 10:43 AM, <= span dir=3D"ltr"><<a href=3D"mailto:openldap-its@openldap.org" target=3D= "_blank">openldap-its(a)openldap.org</a>> wrote: <blockquote cla= ss=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;pa= dding-left:1ex"> *** THIS IS AN AUTOMATICALLY GENERATED REPLY *** Thanks for your report to the OpenLDAP Issue Tracking System.=C2=A0 Your<br= > report has been assigned the tracking number ITS#8106. One of our support engineers will look at your report in due course. Note that this may take some time because our support engineers are volunteers.=C2=A0 They only work on OpenLDAP when they have spare time. If you need to provide additional information in regards to your issue report, you may do so by replying to this message.=C2=A0 Note that<br= > any mail sent to <a href=3D"mailto:openldap-its@openldap.org">openldap-its@= openldap.org</a> with (ITS#8106) in the subject will automatically be attached to the issue report. =C2=A0 =C2=A0 =C2=A0 =C2=A0 mailto:<a href=3D"mailto:openldap-its@openldap.= org">openldap-its(a)openldap.org</a>?subject=3D(ITS#8106) You may follow the progress of this report by loading the following URL in a web browser: =C2=A0 =C2=A0 <a href=3D"http://www.OpenLDAP.org/its/index.cgi?findid=3D810= 6" target=3D"_blank">http://www.OpenLDAP.org/its/index.cgi?findid=3D8106</a= > Please remember to retain your issue tracking number (ITS#8106) on any further messages you send to us regarding this report.=C2=A0 If you don't then you'll just waste our time and yours because we won't be able to properly track the report. Please note that the Issue Tracking System is not intended to be used to seek help in the proper use of OpenLDAP Software. Such requests will be closed. OpenLDAP Software is user supported. =C2=A0 =C2=A0 =C2=A0 =C2=A0 <a href=3D"http://www.OpenLDAP.org/support/" ta= rget=3D"_blank">http://www.OpenLDAP.org/support/</a> -------------- Copyright 1998-2007 The OpenLDAP Foundation, All Rights Reserved. </blockquote></div> </div> --089e013d0c3883936f0513e79d1a-- --089e013d0c3883937b0513e79d1c Content-Type: text/x-patch; charset=US-ASCII; name="0001-libmdb-retry-write-operation-in-case-of-interrupted-.patch" Content-Disposition: attachment; filename="0001-libmdb-retry-write-operation-in-case-of-interrupted-.patch" Content-Transfer-Encoding: base64 X-Attachment-Id: f_i8lcpk680 RnJvbSBjOTg1N2E3YzBkZjQ0NDhhMTRhMmFhOWY1NTg1MGRmNWU4MzAwNjllIE1vbiBTZXAgMTcg MDA6MDA6MDAgMjAwMQpGcm9tOiBEbXl0cm8gTWlsaW5ldnNreXkgPG1pbGluZXZza3l5QGdtYWls LmNvbT4KRGF0ZTogRnJpLCAxNyBBcHIgMjAxNSAxMDo0MToyNiArMDIwMApTdWJqZWN0OiBbUEFU Q0hdIGxpYm1kYjogcmV0cnkgd3JpdGUgb3BlcmF0aW9uIGluIGNhc2Ugb2YgaW50ZXJydXB0ZWQg c3lzdGVtCgotLS0KIGxpYnJhcmllcy9saWJsbWRiL21kYi5jIHwgOSArKysrKysrKy0KIDEgZmls ZSBjaGFuZ2VkLCA4IGluc2VydGlvbnMoKyksIDEgZGVsZXRpb24oLSkKCmRpZmYgLS1naXQgYS9s aWJyYXJpZXMvbGlibG1kYi9tZGIuYyBiL2xpYnJhcmllcy9saWJsbWRiL21kYi5jCmluZGV4IGE5 NWM3Y2QuLmVkN2YzNzAgMTAwNjQ0Ci0tLSBhL2xpYnJhcmllcy9saWJsbWRiL21kYi5jCisrKyBi L2xpYnJhcmllcy9saWJsbWRiL21kYi5jCkBAIC0zMjM2LDYgKzMyMzYsNyBAQCBtZGJfcGFnZV9m bHVzaChNREJfdHhuICp0eG4sIGludCBrZWVwKQogCQkvKiBXcml0ZSB1cCB0byBNREJfQ09NTUlU X1BBR0VTIGRpcnR5IHBhZ2VzIGF0IGEgdGltZS4gKi8KIAkJaWYgKHBvcyE9bmV4dF9wb3MgfHwg bj09TURCX0NPTU1JVF9QQUdFUyB8fCB3c2l6ZStzaXplPk1BWF9XUklURSkgewogCQkJaWYgKG4p IHsKKyAgICAgICAgICAgICAgcmV0cnlfd3JpdGU6CiAJCQkJLyogV3JpdGUgcHJldmlvdXMgcGFn ZShzKSAqLwogI2lmZGVmIE1EQl9VU0VfUFdSSVRFVgogCQkJCXdyZXMgPSBwd3JpdGV2KGVudi0+ bWVfZmQsIGlvdiwgbiwgd3Bvcyk7CkBAIC0zMjQzLDggKzMyNDQsMTAgQEAgbWRiX3BhZ2VfZmx1 c2goTURCX3R4biAqdHhuLCBpbnQga2VlcCkKIAkJCQlpZiAobiA9PSAxKSB7CiAJCQkJCXdyZXMg PSBwd3JpdGUoZW52LT5tZV9mZCwgaW92WzBdLmlvdl9iYXNlLCB3c2l6ZSwgd3Bvcyk7CiAJCQkJ fSBlbHNlIHsKKwkJCQkgIHJldHJ5X3NlZWs6CiAJCQkJCWlmIChsc2VlayhlbnYtPm1lX2ZkLCB3 cG9zLCBTRUVLX1NFVCkgPT0gLTEpIHsKIAkJCQkJCXJjID0gRXJyQ29kZSgpOworCQkJCQkJaWYg KEVJTlRSID09IHJjKSBnb3RvIHJldHJ5X3NlZWs7CiAJCQkJCQlEUFJJTlRGKCgibHNlZWs6ICVz Iiwgc3RyZXJyb3IocmMpKSk7CiAJCQkJCQlyZXR1cm4gcmM7CiAJCQkJCX0KQEAgLTMyNTQsNiAr MzI1Nyw3IEBAIG1kYl9wYWdlX2ZsdXNoKE1EQl90eG4gKnR4biwgaW50IGtlZXApCiAJCQkJaWYg KHdyZXMgIT0gd3NpemUpIHsKIAkJCQkJaWYgKHdyZXMgPCAwKSB7CiAJCQkJCQlyYyA9IEVyckNv ZGUoKTsKKwkJCQkJCWlmIChFSU5UUiA9PSByYykgZ290byByZXRyeV93cml0ZTsKIAkJCQkJCURQ UklOVEYoKCJXcml0ZSBlcnJvcjogJXMiLCBzdHJlcnJvcihyYykpKTsKIAkJCQkJfSBlbHNlIHsK IAkJCQkJCXJjID0gRUlPOyAvKiBUT0RPOiBVc2Ugd2hpY2ggZXJyb3IgY29kZT8gKi8KQEAgLTM2 MjcsNyArMzYzMSw4IEBAIG1kYl9lbnZfaW5pdF9tZXRhKE1EQl9lbnYgKmVudiwgTURCX21ldGEg Km1ldGEpCiAJaW50IGxlbjsKICNkZWZpbmUgRE9fUFdSSVRFKHJjLCBmZCwgcHRyLCBzaXplLCBs ZW4sIHBvcykJZG8geyBcCiAJbGVuID0gcHdyaXRlKGZkLCBwdHIsIHNpemUsIHBvcyk7CVwKLQly YyA9IChsZW4gPj0gMCk7IH0gd2hpbGUoMCkKKwlpZiAobGVuID09IC0xICYmIEVJTlZBTCA9PSBF cnJDb2RlKCkpIGNvbnRpbnVlOyBcCisJcmMgPSAobGVuID49IDApOyBicmVhazsgfSB3aGlsZSgx KQogI2VuZGlmCiAKIAlEUFVUUygid3JpdGluZyBuZXcgbWV0YSBwYWdlIik7CkBAIC0zNzM1LDYg KzM3NDAsNyBAQCBtZGJfZW52X3dyaXRlX21ldGEoTURCX3R4biAqdHhuKQogCiAJLyogV3JpdGUg dG8gdGhlIFNZTkMgZmQgKi8KIAltZmQgPSAoZmxhZ3MgJiAoTURCX05PU1lOQ3xNREJfTk9NRVRB U1lOQykpID8gZW52LT5tZV9mZCA6IGVudi0+bWVfbWZkOworcmV0cnlfd3JpdGU6CiAjaWZkZWYg X1dJTjMyCiAJewogCQltZW1zZXQoJm92LCAwLCBzaXplb2Yob3YpKTsKQEAgLTM3NDcsNiArMzc1 Myw3IEBAIG1kYl9lbnZfd3JpdGVfbWV0YShNREJfdHhuICp0eG4pCiAjZW5kaWYKIAlpZiAocmMg IT0gbGVuKSB7CiAJCXJjID0gcmMgPCAwID8gRXJyQ29kZSgpIDogRUlPOworCQlpZiAoRUlOVFIg PT0gcmMpIGdvdG8gcmV0cnlfd3JpdGU7CiAJCURQVVRTKCJ3cml0ZSBmYWlsZWQsIGRpc2sgZXJy b3I/Iik7CiAJCS8qIE9uIGEgZmFpbHVyZSwgdGhlIHBhZ2VjYWNoZSBzdGlsbCBjb250YWlucyB0 aGUgbmV3IGRhdGEuCiAJCSAqIFdyaXRlIHNvbWUgb2xkIGRhdGEgYmFjaywgdG8gcHJldmVudCBp dCBmcm9tIGJlaW5nIHVzZWQuCi0tIAoyLjMuNQoK --089e013d0c3883937b0513e79d1c--

1 0

(ITS#8106) Retry pwrite operations in case of EINTR
by milinevskyy＠gmail.com 17 Apr '15

17 Apr '15

Full_Name: Dmytro Milinevskyy Version: OS: Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (92.132.131.166) On linux systems it's common to have system calls interrupted and restarted. LMDB should retry pwrites to avoid "false" failures.

1 0

Re: (ITS#8097) update nssov to nss-pam-ldapd 0.9.4
by hyc＠symas.com 15 Apr '15

15 Apr '15

ryan(a)nardis.ca wrote: > Full_Name: Ryan Tandy > Version: master, 2.4 > OS: Debian > URL: > Submission from: (NULL) (24.68.37.4) > Thanks, pushed to git master. > updating the copied nss-pam-ldapd files: > > ftp://ftp.openldap.org/incoming/20150405_rtandy_nssov-update-nss-pam-ldapd-… > > updating nssov for those changes, see commit msg for details: > > ftp://ftp.openldap.org/incoming/20150405_rtandy_nssov-update-to-protocol-ve… > > while I'm in the code anyway, cleaning up a few compiler warnings (that were > already there, I didn't introduce them :P). Cosmetic stuff: unused variables, > return-type (void/non-void) mismatches, a couple of undeclared prototypes. > > ftp://ftp.openldap.org/incoming/20150405_rtandy_nssov-clean-up-some-compile… > > Please note, the protocol change breaks backwards compat with older versions of > the client libraries (per nss-pam-ldapd/README). > > Tested on Linux. No idea about Solaris etc, sorry. > > The DN field was removed from the pam protocol, so uid lookup happens on every > connection now. I couldn't think of a safe way to avoid that; suggestions > welcome. > > -- > > (the following statements apply to patches 2 and 3 only; patch 1 is copied from > work by Arthur de Jong, licensed LGPLv2.1) > > The attached patch files are derived from OpenLDAP Software. All of the > modifications to OpenLDAP Software represented in the preceding patches were > developed by Ryan Tandy <ryan(a)nardis.ca>. I have not assigned rights and/or > interest in this work to any party. > > I, Ryan Tandy, hereby place the preceding 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

Re: (ITS#8095) Patch
by hyc＠symas.com 15 Apr '15

15 Apr '15

rouzier(a)gmail.com wrote: > Full_Name: James Rouzier > Version: > OS: > URL: ftp://ftp.openldap.org/incoming/james-rouzier-150331.patch > Submission from: (NULL) (192.222.129.11) > > > I am working on a proof of concept of a simple key value store service using > lmdb as the back end. > I am using sendfile to avoid an extra copy. > I accomplished this by creating function to extract get the mmap ptr from the > env so I can calculate the offset of data. I'm quite reluctant to return the mmap pointer. In a WRITEMAP environment that invites all manner of undetectable/unpreventable corruptions. Have you actually measured the performance difference between using sendfile() here and plain write() or send()? The kernel doesn't physically copy the written data from user space to kernel space, it just maps in a particular page. Since LMDB data is already mmap'd, the kernel has very little work to do since the relevant pages are already present in the kernel's page tables. Ultimately sending data over TCP involves byte-by-byte iteration anyway, since TCP checksums must be computed on all outgoing data. Doesn't seem to me like sendfile can be a very significant optimization here. > > I figured that function might be useful to the bigger community. > > If it does not fit in the bigger vision of lmdb it is fine not to include it. > > > I, James Rouzier, 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

Re: (ITS#8089) LMDB hangs on mdb_txn_renew0 if MDB_NOSYNC flag is used
by hyc＠symas.com 15 Apr '15

15 Apr '15

pk(a)dbic.pro wrote: > Full_Name: Pavel Kraynyukhov > Version: only LMDB from git and lmdb-0.9.14 > OS: Gentoo Linux > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (37.99.47.171) > > > Hello there, I have ran into an issue with LMDB, which I can reproduce at will, > but it seems a specific one. The git commit is > 3368d1f5e243225cba4d730fba19ff600798ebe3 > And this commit and my issue seems to be related. > > 1. I use MDB_NOTLS flag on environment open. > 2. if I use MDB_NOSYNC flag for LMDB environment, the writer thread is stuck > after several transactions (writer thread backtrace): > P.S. tested against system provided lmdb version 0.9.14 and result is the same. > So this maybe not related to latest commit in git. If you're having this problem in 0.9.14 then it is certainly not related to 3368d1f5e243225cba4d730fba19ff600798ebe3. You confirm that the issue does not occur in 0.9.13? Can you upload a test case demonstrating the problem? -- -- 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#8105) [PATCH] slaptest doesn't convert perlModuleConfig lines
by hyc＠symas.com 15 Apr '15

15 Apr '15

jsynacek(a)redhat.com wrote: > Full_Name: Jan Synacek > Version: master > OS: GNU/Linux > URL: https://jsynacek.fedorapeople.org/openldap/jsynacek-20150415-back-perl-corr… > Submission from: (NULL) (213.175.37.10) > > > When using the perl backend, slaptest doesn't convert perlModuleConfig lines > from slapd.conf to slapd.d. > > A simple reproducer can be found at > https://jsynacek.fedorapeople.org/openldap/back-perl.sh > > Thanks, added to git master -- -- 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#8062) Assertion 'IS_LEAF(mp)' failed in mdb_cursor_next()
by hyc＠symas.com 15 Apr '15

15 Apr '15

This is a multi-part message in MIME format. --------------030305070307090003010905 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Gawen ARAB wrote: > Thanks for the report. Unfortunately, it appears the DB was > constructed incorrectly at some time in the past, so even updating > to later revisions of the code won't avoid the crash. It's more > important now to find the sequence of steps that recreates the > invalid DB in the first place, or verify that the same sequence > doesn't crash using the 0.9.15 release candidate. > > > OK. I'll try to reproduce the steps. I reproduced an occurrence of this assert using the attached test program. This particular bug is now fixed in git, but since we never had a test case for your original situation it's still unconfirmed whether this fix addresses your issue. Were you able to do any further testing? -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/ --------------030305070307090003010905 Content-Type: text/x-csrc; name="its8062.c" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="its8062.c" /* mtest.c - memory-mapped database tester/toy */ /* * Copyright 2011-2015 Howard Chu, Symas Corp. * All rights reserved. * * Redistribution and use in source and binary forms, with or without * modification, are permitted only as authorized by the OpenLDAP * Public License. * * A copy of this license is available in the file LICENSE in the * top-level directory of the distribution or, alternatively, at * <http://www.OpenLDAP.org/license.html>. */ #include <stdio.h> #include <stdlib.h> #include <string.h> #include "lmdb.h" #define E(expr) CHECK((rc = (expr)) == MDB_SUCCESS, #expr) #define RES(err, expr) ((rc = expr) == (err) || (CHECK(!rc, #expr), 0)) #define CHECK(test, msg) ((test) ? (void)0 : ((void)fprintf(stderr, \ "%s:%d: %s: %s\n", __FILE__, __LINE__, msg, mdb_strerror(rc)), abort())) /* Write an 8 byte integer in big-endian order */ void L2B(unsigned long l, char *c) { int i; for (i=7; i>=0; i--) { c[i] = l & 0xff; l >>= 8; } } int main(int argc,char * argv[]) { int i = 0, j = 0, rc; MDB_env *env; MDB_dbi dbi; MDB_val headkey1, headkey2, headkey3, TERMINATOR; MDB_val key, data; MDB_txn *txn; MDB_cursor *cursor; int count = 1024; char ck1[24], ck2[24], ck3[24], ckx[32], cterm[511]; char cvar[1024]; E(mdb_env_create(&env)); E(mdb_env_set_mapsize(env, 1024*1024*1024)); E(mdb_env_set_maxdbs(env, 2)); E(mdb_env_open(env, "./testdb", MDB_NOSYNC, 0664)); E(mdb_txn_begin(env, NULL, 0, &txn)); E(mdb_dbi_open(txn, "test", MDB_CREATE, &dbi)); E(mdb_txn_commit(txn)); /* set up 3 partitions of data */ headkey1.mv_size = 24; headkey1.mv_data = ck1; headkey2.mv_size = 24; headkey2.mv_data = ck2; headkey3.mv_size = 24; headkey3.mv_data = ck3; /* and a final record */ TERMINATOR.mv_size = sizeof(cterm); TERMINATOR.mv_data = cterm; memset(cterm, 255, sizeof(cterm)); memset(ck1, 0, 24); memset(ck2, 0, 24); memset(ck3, 0, 24); memset(ckx, 0, 24); /* Assign the 3 partition keys */ L2B(1, ck1); L2B(-1, ck2); L2B(0, ck3); E(mdb_txn_begin(env, NULL, 0, &txn)); /* Terminator data is a single NUL byte */ data.mv_size = 1; data.mv_data = cvar; cvar[0] = 0; E(mdb_put(txn, dbi, &TERMINATOR, &data, 0)); /* Partition data is 24 NUL bytes */ memset(cvar, 0, 24); data.mv_size = 24; E(mdb_put(txn, dbi, &headkey1, &data, 0)); E(mdb_put(txn, dbi, &headkey2, &data, 0)); E(mdb_put(txn, dbi, &headkey3, &data, 0)); /* Main data is 35 NUL bytes, keys are 32 bytes */ memset(cvar, 0, 35); data.mv_size = 35; key.mv_data = ckx; key.mv_size = 32; for (i=1; i<=count; i++) { L2B(i, ckx+24); memcpy(ckx, headkey1.mv_data, 24); E(mdb_put(txn, dbi, &key, &data, 0)); memcpy(ckx, headkey2.mv_data, 24); E(mdb_put(txn, dbi, &key, &data, 0)); memcpy(ckx, headkey3.mv_data, 24); E(mdb_put(txn, dbi, &key, &data, 0)); } /* Delete from 1st partition */ E(mdb_cursor_open(txn, dbi, &cursor)); E(mdb_cursor_get(cursor, &headkey1, &data, MDB_SET)); for (i=0; i<count; i++) { E(mdb_cursor_del(cursor, 0)); E(mdb_cursor_get(cursor, &key, &data, MDB_NEXT)); } mdb_cursor_close(cursor); /* Delete from 2nd partition - assert happens here */ E(mdb_cursor_open(txn, dbi, &cursor)); E(mdb_cursor_get(cursor, &headkey2, &data, MDB_SET)); for (i=0; i<count; i++) { E(mdb_cursor_del(cursor, 0)); E(mdb_cursor_get(cursor, &key, &data, MDB_NEXT)); } mdb_cursor_close(cursor); /* Delete from 3rd partition - not reached */ E(mdb_cursor_open(txn, dbi, &cursor)); E(mdb_cursor_get(cursor, &headkey3, &data, MDB_SET)); for (i=0; i<count; i++) { E(mdb_cursor_del(cursor, 0)); E(mdb_cursor_get(cursor, &key, &data, MDB_NEXT)); } mdb_cursor_close(cursor); E(mdb_txn_commit(txn)); mdb_dbi_close(env, dbi); mdb_env_close(env); return 0; } --------------030305070307090003010905--

1 0

(ITS#8105) [PATCH] slaptest doesn't convert perlModuleConfig lines
by jsynacek＠redhat.com 15 Apr '15

15 Apr '15

Full_Name: Jan Synacek Version: master OS: GNU/Linux URL: https://jsynacek.fedorapeople.org/openldap/jsynacek-20150415-back-perl-corr… Submission from: (NULL) (213.175.37.10) When using the perl backend, slaptest doesn't convert perlModuleConfig lines from slapd.conf to slapd.d. A simple reproducer can be found at https://jsynacek.fedorapeople.org/openldap/back-perl.sh

1 0

(ITS#8104) Admin Guide 2.4 pdf
by it＠kotoc.cat 14 Apr '15

14 Apr '15

Full_Name: Ricard Valero Version: 2.4 OS: Debian/Ubuntu URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (81.35.55.43) Hi, Admins Guide 2.4 PDF lacks images, i know it's a minor issue but I like to have it on pdf, i'm new to LDAP and I would like to print it so i can write notes on it. Thanks

1 0

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs