- openldap-bugs - openldap.org

Re: (ITS#8278) slapd fails to start when built with --enable-slp on freebsd
by ryan＠nardis.ca 20 Oct '15

20 Oct '15

On Mon, Oct 19, 2015 at 10:28:40PM +0000, quanah(a)openldap.org wrote: >OS: FreeBSD 10.1 FTR, this is not FreeBSD specific. I reproduced it easily on Linux (Debian unstable). Only happens when using OpenSLP 2.0.0, not with 1.2.1. Have not figured out whether it's an OpenSLP bug or a change we need to adapt to.

1 0

(ITS#8279) back-mdb maxsize should accept suffixes
by matthieu.cerda＠normation.com 20 Oct '15

20 Oct '15

Full_Name: Matthieu CERDA Version: 2.4.31 OS: Debian 7.8 URL: http://www.openldap.org/doc/admin24/backends.html Submission from: (NULL) (91.223.73.146) Hello, Would it be possible (without too much hassle and without interfering with OpenLDAP configuration and coding standards) to make the maxsize / olcDbMaxSize configuration parameter able to handle K / M / G suffixes ? Regards, -- Matthieu CERDA

1 0

Re: (ITS#8270) win32: fix conversion error
by nacho.resa＠gmail.com 20 Oct '15

20 Oct '15

--047d7bb03a5ac118d20522842ead Content-Type: text/plain; charset=UTF-8 So I took another closer look at this issue and I went for this possible solution: https://github.com/nice-software/lmdb/commit/03987789735141dc68ae8b2d0e5ad5… Basically it errors out because MSVC needs stdcall on that method. Cheers. On Mon, Oct 19, 2015 at 2:55 PM, Ignacio Casal Quinteiro < nacho.resa(a)gmail.com> wrote: > Sorry! I did indeed meant to change just the windows part, for some reason > I thought it was already ifdeffed that part. > > https://github.com/nice-software/lmdb/commit/42577fe173923c1166f8382a53523a… > > This is the right patch. > > On Mon, Oct 19, 2015 at 1:43 PM, Hallvard Breien Furuseth < > h.b.furuseth(a)usit.uio.no> wrote: > >> On 19. okt. 2015 08:57, nacho.resa(a)gmail.com wrote: >> >>> I do not understand, I tested also with mingw64 (...) >>> >> >> There's no LPTHREAD_START_ROUTINE type on non-Windows machines. >> You could replace 'start' with '(LPTHREAD_START_ROUTINE)(start)' >> in the _WIN32 variant of '#define THREAD_CREATE...'. >> >> However, it's still wrong to call a function via another prototype. >> Maybe that'd fall on 32-bit Windows or something, I don't know >> how LPTHREAD_START_ROUTINE is defined. The safe way would be to >> give mdb_env_copythr() a prototype which does not need a cast. >> There is some code for that already. Maybe it can be improved. >> >> -- >> Hallvard >> > > > > -- > Ignacio Casal Quinteiro > -- Ignacio Casal Quinteiro --047d7bb03a5ac118d20522842ead Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr"><div><div>So I took another closer look at this issue and = I went for this possible solution:<br><a href=3D"https://github.com/nice-so= ftware/lmdb/commit/03987789735141dc68ae8b2d0e5ad52d82cc80d0">https://github= .com/nice-software/lmdb/commit/03987789735141dc68ae8b2d0e5ad52d82cc80d0</a>= <br><br></div>Basically it errors out because MSVC needs stdcall on that me= thod.<br><br></div>Cheers.<br></div><div class=3D"gmail_extra"><br><div cla= ss=3D"gmail_quote">On Mon, Oct 19, 2015 at 2:55 PM, Ignacio Casal Quinteiro= <span dir=3D"ltr"><<a href=3D"mailto:nacho.resa@gmail.com" target=3D"_b= lank">nacho.resa(a)gmail.com</a>></span> wrote:<br><blockquote class=3D"gm= ail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-le= ft:1ex"><div dir=3D"ltr"><div>Sorry! I did indeed meant to change just the = windows part, for some reason I thought it was already ifdeffed that part.<= br><a href=3D"https://github.com/nice-software/lmdb/commit/42577fe173923c11= 66f8382a53523a31479f9d43" target=3D"_blank">https://github.com/nice-softwar= e/lmdb/commit/42577fe173923c1166f8382a53523a31479f9d43</a><br><br></div>Thi= s is the right patch.<br></div><div class=3D"gmail_extra"><div><div class= =3D"h5"><br><div class=3D"gmail_quote">On Mon, Oct 19, 2015 at 1:43 PM, Hal= lvard Breien Furuseth <span dir=3D"ltr"><<a href=3D"mailto:h.b.furuseth@= usit.uio.no" target=3D"_blank">h.b.furuseth(a)usit.uio.no</a>></span> wrot= e:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-l= eft:1px #ccc solid;padding-left:1ex">On 19. okt. 2015 08:57, <a href=3D"mai= lto:nacho.resa@gmail.com" target=3D"_blank">nacho.resa(a)gmail.com</a> wrote:= <br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex"> I do not understand, I tested also with mingw64 (...)<br> </blockquote> <br> There's no LPTHREAD_START_ROUTINE type on non-Windows machines.<br> You could replace 'start' with '(LPTHREAD_START_ROUTINE)(start)= '<br> in the _WIN32 variant of '#define THREAD_CREATE...'.<br> <br> However, it's still wrong to call a function via another prototype.<br> Maybe that'd fall on 32-bit Windows or something, I don't know<br> how LPTHREAD_START_ROUTINE is defined.=C2=A0 The safe way would be to<br> give mdb_env_copythr() a prototype which does not need a cast.<br> There is some code for that already. Maybe it can be improved.<span><font c= olor=3D"#888888"><br> <br> -- <br> Hallvard<br> </font></span></blockquote></div><br><br clear=3D"all"><br></div></div><spa= n class=3D"HOEnZb"><font color=3D"#888888">-- <br><div>Ignacio Casal Quinte= iro</div> </font></span></div> </blockquote></div><br><br clear=3D"all"><br>-- <br><div class=3D"gmail_sig= nature">Ignacio Casal Quinteiro</div> </div> --047d7bb03a5ac118d20522842ead--

1 0

(ITS#8278) slapd fails to start when built with --enable-slp on freebsd
by quanah＠openldap.org 20 Oct '15

20 Oct '15

Full_Name: Quanah Gibson-Mount Version: 2.4.42 OS: FreeBSD 10.1 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (75.111.52.177) slapd will not start, exits with "slap_schema_init: Error registering matching rule ( 2.5.13.28 NAME 'generalizedTimeOrderingMatch' SYNTAX 1.3.6.1.4.1.1466.115.121.1.24 )"

1 0

(ITS#8277) test049 crashes
by hyc＠openldap.org 19 Oct '15

19 Oct '15

Full_Name: Howard Chu Version: 2.4 OS: Win32 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (78.155.231.14) Submitted by: hyc After "replacing syncrepl on provider" the consumer crashes. Stack trace shows a do_syncrepl thread trying to lock a syncinfo mutex that is no longer valid, i.e., the syncinfo has been freed. This happens when the consumer receives the syncrepl config change - it deletes the existing config (thus freeing it) and creates a new one. Something funny is going on here since the config change itself is being processed in the consumer, and no other thread should have been started for this syncrepl instance.

1 0

(ITS#8276) [PATCH 2/2] Add an application context pointer into user-defined key compare and dupsort functions
by pmedvedev＠gmail.com 19 Oct '15

19 Oct '15

Full_Name: Pavel Medvedev Version: OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (217.25.225.40) This allows to use application context in user-defined compare functions. --- libraries/liblmdb/lmdb.h | 14 ++++++++++---- libraries/liblmdb/mdb.c | 40 ++++++++++++++++"B2B+++++----------------- 2 files changed, 33 insertions(+), 21 deletions(-) diff --git a/libraries/liblmdb/lmdb.h b/libraries/liblmdb/lmdb.h index 933a862..debdf43 100644 --- a/libraries/liblmdb/lmdb.h +++ b/libraries/liblmdb/lmdb.h @@ -251,8 +251,12 @@ typedef struct MDB_val { void *mv_data; /**< address of the data item */ } MDB_val; -/** @brief A callback function used to compare two keys in a database */ -typedef int (MDB_cmp_func)(const MDB_val *a, const MDB_val *b); +/** @brief A callback function used to compare two keys in a database +* @param[in] a The first value to compare. +* @param[in] b The second value to compare. +* @param[in] cmpctx An application-provided context, set by #mdb_set_compare() or #mdb_set_dupsort(). +*/ +typedef int (MDB_cmp_func)(const MDB_val *a, const MDB_val *b, void *cmpctx); /** @brief A callback function used to relocate a position-dependent data item * in a fixed-address database. @@ -1193,13 +1197,14 @@ int mdb_drop(MDB_txn *txn, MDB_dbi dbi, int del); * @param[in] txn A transaction handle returned by #mdb_txn_begin() * @param[in] dbi A database handle returned by #mdb_dbi_open() * @param[in] cmp A #MDB_cmp_func function + * @param[in] cmpctx An arbitrary pointer for whatever the application needs. * @return A non-zero error value on failure and 0 on success. Some possible * errors are: * <ul> * <li>EINVAL - an invalid parameter was specified. * </ul> */ -int mdb_set_compare(MDB_txn *txn, MDB_dbi dbi, MDB_cmp_func *cmp); +int mdb_set_compare(MDB_txn *txn, MDB_dbi dbi, MDB_cmp_func *cmp, void *cmpctx); /** @brief Set a custom data comparison function for a #MDB_DUPSORT database. * @@ -1216,13 +1221,14 @@ int mdb_set_compare(MDB_txn *txn, MDB_dbi dbi, MDB_cmp_func *cmp); * @param[in] txn A transaction handle returned by #mdb_txn_begin() * @param[in] dbi A database handle returned by #mdb_dbi_open() * @param[in] cmp A #MDB_cmp_func function + * @param[in] cmpctx An arbitrary pointer forhahatever the application needs. * @return A non-zero error value on failure and 0 on success. Some possible * errors are: * <ul> * <li>EINVAL - an invalid parameter was specified. * </ul> */ -int mdb_set_dupsort(MDB_txn *txn, MDB_dbi dbi, MDB_cmp_func *cmp); +int mdb_set_dupsort(MDB_txn *txn, MDB_dbi dbi, MDB_cmp_func *cmp, void *cmpctx); /** @brief Set a relocation function for a #MDB_FIXEDMAP database. * diff --git a/libraries/liblmdb/mdb.c b/libraries/liblmdb-bdb.c index a2763f8..f816a44 100644 --- a/libraries/liblmdb/mdb.c +++ b/libraries/liblmdb/mdb.c @@ -1057,7 +1057,9 @@ typedef union MDB_metabuf { typedef struct MDB_dbx { MDB_val md_name; /**< name of the database */ MDB_cmp_func9*9*md_cmp; /**< function for comparing keys */ + void *md_cmpctx; /**< user-provided context for md_cmp*/ MDB_cmp_func *md_dcmp; /**< function for comparing data items */ + void *md_dcmpctx; /**< user-provided context for md_dcmp */A A MDB_rel_func *md_rel; /**< user relocate function */ void *md_relctx; /**< user-provided context for md_rel */ } MDB_dbx; @@ -1709,7 +1711,7 @@ static void mdb_audit(MDB_txn *txn) int mdb_cmp(MDB_txn *txn, MDB_dbi dbi, const MDB_val *a, const MDB_val *b) { - return txn->mt_dbxs[dbi].md_cmp(a, b); + return txn->mt_dbxs[dbi].md_cmp(a, b, txn->mt_dbxs[dbi].md_cmpctx); } int @@ -1720,7 +1722,7 @@ mdb_dcmp(MDB_txn *txn, MDB_dbi dbi, const MDB_val *a, const MDB_val *b) if (dcmp == mdb_cmp_int && a->mv_size == sizeof(size_t)) dcmp = mdb_cmp_clong; #endif - return dcmp(a, b); + return dcmp(a, b, txn->mt_dbxs[dbi].md_dcmpctx); } /** Allocate memory for a page. @@ -5003,7 +5005,7 @@ mdb_env_close(MDB_env *env) /** Compare two items pointing at aligned size_t's */ static int -mdb_cmp_long(const MDB_val *a, const MDB_val *b) +mdb_cmp_long(const MDB_val *a, const MDB_val *b, void *cmpctx) { return (*(size_t *)a->mv_data < *(size_t *)b->mv_data) ? -1 : *(size_t *)a->mv_data > *(size_t *)b->mv_data; @@ -5015,7 +5017,7 @@ mdb_cmp_long(const MDB_val *a, const MDB_val *b) * but #mdb_cmp_clong() is called instead if the data type is size_t. */ static int -mdb_cmp_int(const MDB_val *a, const MDB_val *b) +mdb_cmp_int(const MDB_val *a, const MDB_v *b%b, void *cmpctx) { return (*(unsigned int *)a->mv_data < *(unsigned int *)b->mv_data) ? -1 : *(unsigned int *)a->mv_data > *(unsigned int *)b->mv_data; @@ -5025,7 +5027,7 @@ mdb_cmp_int(const MDB_val *a, const MDB_val *b) * Nodes and keys are guaranteed to be 2-byte aligned. */ static int -mdb_cmp_cint(const MDB_val *a, const MDB_val *b) +mdb_cmp_cint(const MDB_val *a, const MDB_val *b, void *cmpctx) { #if BYTE_ORDER == LITTLE_ENDIAN unsigned short *u, *c; @@ -5053,7 +5055,7 @@ mdb_cmp_cint(const MDB_val *a, const MDB_val *b) /** Compare two items lexically */ static int -mdb_cmp_memn(const MDB_val *a, const MDB_val *b) +mdb_cmp_memn(const MDB_val *a, const MDB_val *b, void *cmpctx) { int diff; ssize_t len_diff; @@ -5072,7 +5074,7 @@ mdb_cmp_memn(const MDB_val *a, const MDB_val *b) /** Compare two items in reverse byte order */ static int -mdb_cmp_memnr(const MDB_val *a, const MDB_val *b) +mdb_cmp_memnr(const MDB_val *a, const MDB_val *b, void *cmpctx) { const unsigned char *p1, *p2, *p1_lim; ssize_t len_diff; @@ -5113,6 +5115,7 @@ mdb_node_search(MDB_cursor *mc, MDB_val *key, int *exactp) MDB_node *node = NULL; MDB_val nodekey; MDB_cmp_func *cmp; + void *cmpctx; DKBUF; nkeys = NUMKEYS(mp); @@ -5124,6 +5127,7 @@ mdb_node_search(MDB_cursor *mc, MDB_val *key, int *exactp) low = IS_LEAF(mp) ? 0 : 1; high = nkeys - 1; cmp = mc->mc_dbx->md_cmp; + cmpctx = mc->mc_dbx->md_cmpctx; /* Branch pages have no data% so o if using integer keys, * alignment is guaranteed. Use faster mdb_cmp_int. @@ -5141,7 +5145,7 @@ mdb_node_search(MDB_cursor *mc, MDB_val *key, int *exactp) while (low <= high) { i = (low + high) >> 1; nodey.m.mv_data = LEAF2KEY(mp, i, nodekey.mv_size); - rc = cmp(key, &nodekey); + rc = cmp(key, &nodekey, cmpctx); DPRINTF(("found leaf index %u [%s], rc = %i", i, DKEY(&nodekey), rc)); if (rc == 0) @@ -5159,7 +5163,7 @@ mdb_node_search(MDB_cursor *mc, MDB_val *key, int *exactp) nodekey.mv_size = NODEKSZ(node); nodekey.mv_data = NODEKEY(node); - rc = cmp(key, &nodekey); + rc = cmp(key, &nodekey, cmpctx); #if MDB_DEBUG if (IS_LEAF(mp)) DPRINTF(("found leaf index %u [%s], rc = %i", @@ -5855,7 +5859,7 @@ mdb_cursor_set(MDB_cursor *mc, MDB_val *key, MDB_val *data, leaf = NODEPTR(mp, 0); MDB_GET_KEY2(leaf, nodekey); } - rc = mc->mc_dbx->md_cmp(key, &nodekey); + rc = mc->mc_dbx->md_cmp(key, &nodekey, mc->mc_dbx->md_cmpctx); if (rc == 0) { /* Probably happens rarely, but first node on the page * was the one we wanted. @@ -5876,7 +5880,7 @@ mdb_cursor_set(MDB_cursor *mc, MDB_val *key, MDB_val *data, leaf = NODEPTR(%2, nkeys-1); MDB_GET_KEY2(leaf, nodekey); } - rc = mc->mc_dbx->md_cmp(key, &nodekey); + rc = mc->mc_dbx->md_cmp(key, &nodekey, mc->mc_dbx->md_cmpctx); if (rc == 0) { /* last node was the one we wanted */ mc->mc_ki[mc->mc_top] D D nkeys-1; @@ -5894,7 +5898,7 @@ mdb_cursor_set(MDB_cursor *mc, MDB_val *key, MDB_val *data, leaf = NODEPTR(mp, mc->mc_ki[mc->mc_top]); MDB_GET_KEY2(leaf, nodekey); } - rc = mc->mc_dbx->md_cmp(key, &nodekey);A%A+ rc = mc->mc_dbx->md_cmp(key, &nodekey, mc->mc_dbx->md_cmpctx); if (rc == 0) { /* current node was the one we wanted */ if (exactp) @@ -5996,7 +6000,7 @@ set1: if (dcmp == mdb_cmp_int && olddata.mv_size == sizeof(size_t)) dcmp = mdb_cmp_clong; #endif - rc = dcmp(data, &olddata); + rc = dcmp(data, &olddata, mc->mc_dbx->md_dcmpctx); if (rc) { if (op == MDB_GET_BOTH || rc > 0) return MDB_NOTFOUND; @@ -6387,7 +6391,7 @@ mdb_cursor_put(MDB_cursor *mc, MDB_val *key, MDB_val *data, MDB_val k2; rc = mdb_cursor_last(mc, &k2, &d2); if (rc == 0) { - rc = mc->mc_dbx->md_cmp(key, &k2); + rc = mc->mc_dbx->md_cmp(key, &k2, mc->mc_dbx->md_cmpctx); if (rc > 0) { rc = MDB_NOTFOUND; mc->mc_k5B5Bmc->mc_top]++; @@ -6520,7 +6524,7 @@ more: dcmp = mdb_cmp_clong; #endif /* does data match? */ - if (!dcmp(data, &olddata)) { + if (!dcmp(data, &olddata, mc->mc_dbx->md_dcmpctx)) { if (flags &DMDB_NODUPDATA) return MDB_KEYEXIST; /* overwrite it */ @@ -9690,21 +9694,23 @@ leave: return rc; } -int mdb_set_compare(MDB_txn *txn, MDB_dbi dbi, MDB_cmp_func *cmp) +int mdb_set_compare(MDB_txn *txn, MDB_dbi dbi, MDB_cmp_func *cmp, void *cmpctx) { if (!TXN_DBI_EXIST(txn, dbi, DB_USRVALID)) return EINVAL; txn->mt_dbxs[dbi].md_cmp = cmp; + txn->mt_dbxs[dbi].md_cmpctx = cmpctx; return MDB_SUCCESS; } -int mdb_set_dupsort(MDB_txn *txn, MDB_dbi dbi, MDB_cmp_func *cmp) +int mdb_set_dupsort(MDB_txn *txn, MDB_dbi dbi, MDB_cmp_func *cmp, void *cmpctx) { if (!TXN_DBI_EXIST(txn, dbi, DB_USRVALID)) return EINVAL; txn->mt_dbxs[dbi].md_dcmp = cmp; + txn->mt_dbxs[dbi].md_dcmpctx = cmpctx; return MDB_SUCCESS; }

1 0

(ITS#8275) [PATCH 1/2] Add mdb_dbi_name() function to get database name from a handle
by pmedvedev＠gmail.com 19 Oct '15

19 Oct '15

Full_Name: Pavel Medvedev Version: OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (217.25.225.40) --- libraries/liblmdb/lmdb.h | 15 +++++++++++++++ libraries/liblmdb/mdb.c | 9 +++++++++ 2 files changed, 24 insertions(+) diff --git a/libraries/liblmdb/lmdb.h b/libraries/liblmdb/lmdb.h index e080e76..933a862 100644 - - a/libraries/liblmdb/lmdb.h +++ b/libraries/liblmdb/lmdb.h @@ -1136,6 +1136,21 @@ int mdb_stat(MDB_txn *txn, MDB_dbi dbi, MDB_stat *stat); */ int mdb_dbi_flags(MDB_txn *txn, MDB_dbi dbi, unsigned int *flags); + /** @brief Return the DB name that was used in #mdb_dbi_open(). + * + * @param[in] txn A transaction handle returned by #mdb_txn_begin() + * @param[in] dbi A database handle returned by #mdb_dbi_open() + * @param[out] path Address of a string pointer to contain the path. This + * is the actual string in the database, not a copy. It should not be + * altered in any way. + * @return A non-zero error value on failure and 0 on success. Some possible + * errors are: + * <ul> + * <li>EINVAL - an invalid parameter was specified. + * </ul> + */ +int mdb_dbi_name(MDB_txn *txn, MDB_dbi dbi, const char **name); + /** @brief Close a database handle. Normally unnecessary. Use with care: * * This call is not mutex protected. Handles should only be closed by diff --git a/libraries/liblmdb/mdb.c b/libraries/liblmdb/mdb.c index 8f7f3b3..a2763f8 100644 --- a/libraries/liblmdb/mdb.c +++ b/libraries/liblmdb/mdb.c @@ -9541,6 +9541,15 @@ int mdb_dbi_flags(MDB_txn *txn, MDB_dbi dbi, unsigned int *flags) return MDB_SUCCESS; } +int mdb_dbi_name(MDB_txn *txn, MDB_dbi dbi, const char **name) +{ + if (!TXN_DBI_EXIST(txn, dbi, DB_USRVALID) || !name) + return EINVAL; + /* safe since md_name is 0-terminated with strdup in mdb_dbi_open */ + *name = txn->mtbxbxs[dbi].md_name.mv_data; + return MDB_SUCCESS; +} + /** Add all the DB's pages to the free list. * @param[in] mc Cursor on the DB to free. * @param[in] subs non-Zero to check for sub-DBs in this DB.

1 0

Re: (ITS#8270) win32: fix conversion error
by nacho.resa＠gmail.com 19 Oct '15

19 Oct '15

--f46d0444813d6e6086052274a949 Content-Type: text/plain; charset=UTF-8 Sorry! I did indeed meant to change just the windows part, for some reason I thought it was already ifdeffed that part. https://github.com/nice-software/lmdb/commit/42577fe173923c1166f8382a53523a… This is the right patch. On Mon, Oct 19, 2015 at 1:43 PM, Hallvard Breien Furuseth < h.b.furuseth(a)usit.uio.no> wrote: > On 19. okt. 2015 08:57, nacho.resa(a)gmail.com wrote: > >> I do not understand, I tested also with mingw64 (...) >> > > There's no LPTHREAD_START_ROUTINE type on non-Windows machines. > You could replace 'start' with '(LPTHREAD_START_ROUTINE)(start)' > in the _WIN32 variant of '#define THREAD_CREATE...'. > > However, it's still wrong to call a function via another prototype. > Maybe that'd fall on 32-bit Windows or something, I don't know > how LPTHREAD_START_ROUTINE is defined. The safe way would be to > give mdb_env_copythr() a prototype which does not need a cast. > There is some code for that already. Maybe it can be improved. > > -- > Hallvard > -- Ignacio Casal Quinteiro --f46d0444813d6e6086052274a949 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr"><div>Sorry! I did indeed meant to change just the windows = part, for some reason I thought it was already ifdeffed that part.<br><a hr= ef=3D"https://github.com/nice-software/lmdb/commit/42577fe173923c1166f8382a= 53523a31479f9d43">https://github.com/nice-software/lmdb/commit/42577fe17392= 3c1166f8382a53523a31479f9d43</a><br><br></div>This is the right patch.<br><= /div><div class=3D"gmail_extra"><br><div class=3D"gmail_quote">On Mon, Oct = 19, 2015 at 1:43 PM, Hallvard Breien Furuseth <span dir=3D"ltr"><<a href= =3D"mailto:h.b.furuseth@usit.uio.no" target=3D"_blank">h.b.furuseth(a)usit.ui= o.no</a>></span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"ma= rgin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On 19. okt. 20= 15 08:57, <a href=3D"mailto:nacho.resa@gmail.com" target=3D"_blank">nacho.r= esa(a)gmail.com</a> wrote:<br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex"> I do not understand, I tested also with mingw64 (...)<br> </blockquote> <br> There's no LPTHREAD_START_ROUTINE type on non-Windows machines.<br> You could replace 'start' with '(LPTHREAD_START_ROUTINE)(start)= '<br> in the _WIN32 variant of '#define THREAD_CREATE...'.<br> <br> However, it's still wrong to call a function via another prototype.<br> Maybe that'd fall on 32-bit Windows or something, I don't know<br> how LPTHREAD_START_ROUTINE is defined.=C2=A0 The safe way would be to<br> give mdb_env_copythr() a prototype which does not need a cast.<br> There is some code for that already. Maybe it can be improved.<span class= =3D"HOEnZb"><font color=3D"#888888"><br> <br> -- <br> Hallvard<br> </font></span></blockquote></div><br><br clear=3D"all"><br>-- <br><div clas= s=3D"gmail_signature">Ignacio Casal Quinteiro</div> </div> --f46d0444813d6e6086052274a949--

1 0

Re: (ITS#8270) win32: fix conversion error
by h.b.furuseth＠usit.uio.no 19 Oct '15

19 Oct '15

On 19. okt. 2015 08:57, nacho.resa(a)gmail.com wrote: > I do not understand, I tested also with mingw64 (...) There's no LPTHREAD_START_ROUTINE type on non-Windows machines. You could replace 'start' with '(LPTHREAD_START_ROUTINE)(start)' in the _WIN32 variant of '#define THREAD_CREATE...'. However, it's still wrong to call a function via another prototype. Maybe that'd fall on 32-bit Windows or something, I don't know how LPTHREAD_START_ROUTINE is defined. The safe way would be to give mdb_env_copythr() a prototype which does not need a cast. There is some code for that already. Maybe it can be improved. -- Hallvard

1 0

(ITS#8274) Review lmdb cyrus-sasl backend changes
by nacho.resa＠gmail.com 19 Oct '15

19 Oct '15

Full_Name: Ignacio Casal Quinteiro Version: OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (89.202.223.30) Hi Howard Chu, since you made the backend for cyrus-sasl, any chance you could review the patches here: https://github.com/nice-software/cyrus-sasl/commits/wip/lmdb before they get upstream? Cheers.

1 0

(ITS#8273) file:// URLs broken on Windows
by hyc＠openldap.org 19 Oct '15

19 Oct '15

Full_Name: Howard Chu Version: 2.4 OS: Win32 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (78.155.231.14) Submitted by: hyc file URLs with absolute paths are parsed incorrectly on Windows. The current code expects an absolute path in Unix form: file:///etc/ldap.conf In our test suites we just concatenate "file://" with an absolute path. On Windowsn ababsolute path starts with a drive letter and a colon, so our test suite doing simple concatenation uses file://C:/some/thing This is actually invalid; the proper form would be file:///C:/some/thing but the current parser won't do the right thing for either form. It MUST be fixed to accept the latter form with 3 slashes. I'm inclined to also accept the form with 2 slashes, to avoid hacking up our test suite to handle this case.

1 0

Re: (ITS#8270) win32: fix conversion error
by nacho.resa＠gmail.com 19 Oct '15

19 Oct '15

--f46d044289f661da1905226fa6a2 Content-Type: text/plain; charset=UTF-8 I do not understand, I tested also with mingw64 and here is the result I get with my patches applied: $ make gcc -pthread -O2 -g -W -Wall -Wno-unused-parameter -Wbad-function-cast -Wuninitialized -c mdb.c mdb.c: In function 'mdb_strerror': cc1.exe: warning: function may return address of local variable [-Wreturn-local-addr] mdb.c:1453:7: note: declared here char buf[1024], *ptr = buf; ^ gcc -pthread -O2 -g -W -Wall -Wno-unused-parameter -Wbad-function-cast -Wuninitialized -c midl.c ar rs liblmdb.a mdb.o midl.o C:\msys64\mingw64\bin\ar.exe: creating liblmdb.a gcc -pthread -O2 -g -W -Wall -Wno-unused-parameter -Wbad-function-cast -Wuninitialized -fPIC -c mdb.c -o mdb.lo mdb.c:1:0: warning: -fPIC ignored for target (all code is position independent) /** @file mdb.c ^ mdb.c: In function 'mdb_strerror': cc1.exe: warning: function may return address of local variable [-Wreturn-local-addr] mdb.c:1453:7: note: declared here char buf[1024], *ptr = buf; ^ gcc -pthread -O2 -g -W -Wall -Wno-unused-parameter -Wbad-function-cast -Wuninitialized -fPIC -c midl.c -o midl.lo midl.c:1:0: warning: -fPIC ignored for target (all code is position independent) /** @file midl.c ^ gcc -pthread -shared -o liblmdb.so mdb.lo midl.lo gcc -pthread -O2 -g -W -Wall -Wno-unused-parameter -Wbad-function-cast -Wuninitialized -c mdb_stat.c gcc -pthread -O2 -g -W -Wall -Wno-unused-parameter -Wbad-function-cast -Wuninitialized mdb_stat.o liblmdb.a -o mdb_stat gcc -pthread -O2 -g -W -Wall -Wno-unused-parameter -Wbad-function-cast -Wuninitialized -c mdb_copy.c gcc -pthread -O2 -g -W -Wall -Wno-unused-parameter -Wbad-function-cast -Wuninitialized mdb_copy.o liblmdb.a -o mdb_copy gcc -pthread -O2 -g -W -Wall -Wno-unused-parameter -Wbad-function-cast -Wuninitialized -c mdb_dump.c gcc -pthread -O2 -g -W -Wall -Wno-unused-parameter -Wbad-function-cast -Wuninitialized mdb_dump.o liblmdb.a -o mdb_dump gcc -pthread -O2 -g -W -Wall -Wno-unused-parameter -Wbad-function-cast -Wuninitialized -c mdb_load.c gcc -pthread -O2 -g -W -Wall -Wno-unused-parameter -Wbad-function-cast -Wuninitialized mdb_load.o liblmdb.a -o mdb_load gcc -pthread -O2 -g -W -Wall -Wno-unused-parameter -Wbad-function-cast -Wuninitialized -c mtest.c gcc -pthread -O2 -g -W -Wall -Wno-unused-parameter -Wbad-function-cast -Wuninitialized mtest.o liblmdb.a -o mtest gcc -pthread -O2 -g -W -Wall -Wno-unused-parameter -Wbad-function-cast -Wuninitialized -c mtest2.c gcc -pthread -O2 -g -W -Wall -Wno-unused-parameter -Wbad-function-cast -Wuninitialized mtest2.o liblmdb.a -o mtest2 gcc -pthread -O2 -g -W -Wall -Wno-unused-parameter -Wbad-function-cast -Wuninitialized -c mtest3.c gcc -pthread -O2 -g -W -Wall -Wno-unused-parameter -Wbad-function-cast -Wuninitialized mtest3.o liblmdb.a -o mtest3 gcc -pthread -O2 -g -W -Wall -Wno-unused-parameter -Wbad-function-cast -Wuninitialized -c mtest4.c gcc -pthread -O2 -g -W -Wall -Wno-unused-parameter -Wbad-function-cast -Wuninitialized mtest4.o liblmdb.a -o mtest4 gcc -pthread -O2 -g -W -Wall -Wno-unused-parameter -Wbad-function-cast -Wuninitialized -c mtest5.c gcc -pthread -O2 -g -W -Wall -Wno-unused-parameter -Wbad-function-cast -Wuninitialized mtest5.o liblmdb.a -o mtest5 On Mon, Oct 19, 2015 at 8:35 AM, Howard Chu <hyc(a)symas.com> wrote: > Ignacio Casal Quinteiro wrote: > >> I am ok not fixing the MSVC warnings because it is picky even though some >> of >> them might make sense even for mingw, but in this case it is an error and >> this >> really small change enable msvc to build without errors. Can't you >> reconsider >> the change? Specially since it will build fine with mingw as well. >> > > No, since it will break Unix builds. > >> >> On Sat, Oct 17, 2015 at 7:54 PM, Howard Chu <hyc(a)symas.com >> <mailto:hyc@symas.com>> wrote: >> >> nacho.resa(a)gmail.com <mailto:nacho.resa@gmail.com> wrote: >> >> Full_Name: Ignacio Casal Quinteiro >> Version: >> OS: Windows 7 >> URL: ftp://ftp.openldap.org/incoming/ >> Submission from: (NULL) (2a01:111f:9fa:7f00:864b:f5ff:fe34:ddaa) >> >> >> >> https://github.com/nice-software/lmdb/commit/076281a2c03356667fca7cce1a898a… >> >> >> I see no error when compiling with gcc -Wall. Closing this ITS. >> >> -- >> -- Howard Chu >> CTO, Symas Corp. http://www.symas.com >> Director, Highland Sun http://highlandsun.com/hyc/ >> Chief Architect, OpenLDAP http://www.openldap.org/project/ >> >> >> >> >> -- >> Ignacio Casal Quinteiro >> > > > -- > -- Howard Chu > CTO, Symas Corp. http://www.symas.com > Director, Highland Sun http://highlandsun.com/hyc/ > Chief Architect, OpenLDAP http://www.openldap.org/project/ > -- Ignacio Casal Quinteiro --f46d044289f661da1905226fa6a2 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr">I do not understand, I tested also with mingw64 and here i= s the result I get with my patches applied:<br><br>$ make<br>gcc -pthread -= O2 -g -W -Wall -Wno-unused-parameter -Wbad-function-cast -Wuninitialized=C2= =A0=C2=A0 -c mdb.c<br>mdb.c: In function 'mdb_strerror':<br>cc1.exe= : warning: function may return address of local variable [-Wreturn-local-ad= dr]<br>mdb.c:1453:7: note: declared here<br>=C2=A0 char buf[1024], *ptr =3D= buf;<br>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 ^<br>gcc -pthread -O2 -g -W -= Wall -Wno-unused-parameter -Wbad-function-cast -Wuninitialized=C2=A0=C2=A0 = -c midl.c<br>ar rs liblmdb.a mdb.o midl.o<br>C:\msys64\mingw64\bin\ar.exe: = creating liblmdb.a<br>gcc -pthread -O2 -g -W -Wall -Wno-unused-parameter -W= bad-function-cast -Wuninitialized=C2=A0 -fPIC=C2=A0 -c mdb.c -o mdb.lo<br>m= db.c:1:0: warning: -fPIC ignored for target (all code is position independe= nt)<br>=C2=A0/** @file mdb.c<br>=C2=A0^<br>mdb.c: In function 'mdb_stre= rror':<br>cc1.exe: warning: function may return address of local variab= le [-Wreturn-local-addr]<br>mdb.c:1453:7: note: declared here<br>=C2=A0 cha= r buf[1024], *ptr =3D buf;<br>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 ^<br>gcc= -pthread -O2 -g -W -Wall -Wno-unused-parameter -Wbad-function-cast -Wunini= tialized=C2=A0 -fPIC=C2=A0 -c midl.c -o midl.lo<br>midl.c:1:0: warning: -fP= IC ignored for target (all code is position independent)<br>=C2=A0/** @file= midl.c<br>=C2=A0^<br>gcc=C2=A0 -pthread -shared -o liblmdb.so mdb.lo midl.= lo<br>gcc -pthread -O2 -g -W -Wall -Wno-unused-parameter -Wbad-function-cas= t -Wuninitialized=C2=A0=C2=A0 -c mdb_stat.c<br>gcc -pthread -O2 -g -W -Wall= -Wno-unused-parameter -Wbad-function-cast -Wuninitialized=C2=A0=C2=A0 mdb_= stat.o liblmdb.a=C2=A0 -o mdb_stat<br>gcc -pthread -O2 -g -W -Wall -Wno-unu= sed-parameter -Wbad-function-cast -Wuninitialized=C2=A0=C2=A0 -c mdb_copy.c= <br>gcc -pthread -O2 -g -W -Wall -Wno-unused-parameter -Wbad-function-cast = -Wuninitialized=C2=A0=C2=A0 mdb_copy.o liblmdb.a=C2=A0 -o mdb_copy<br>gcc -= pthread -O2 -g -W -Wall -Wno-unused-parameter -Wbad-function-cast -Wuniniti= alized=C2=A0=C2=A0 -c mdb_dump.c<br>gcc -pthread -O2 -g -W -Wall -Wno-unuse= d-parameter -Wbad-function-cast -Wuninitialized=C2=A0=C2=A0 mdb_dump.o libl= mdb.a=C2=A0 -o mdb_dump<br>gcc -pthread -O2 -g -W -Wall -Wno-unused-paramet= er -Wbad-function-cast -Wuninitialized=C2=A0=C2=A0 -c mdb_load.c<br>gcc -pt= hread -O2 -g -W -Wall -Wno-unused-parameter -Wbad-function-cast -Wuninitial= ized=C2=A0=C2=A0 mdb_load.o liblmdb.a=C2=A0 -o mdb_load<br>gcc -pthread -O2= -g -W -Wall -Wno-unused-parameter -Wbad-function-cast -Wuninitialized=C2= =A0=C2=A0 -c mtest.c<br>gcc -pthread -O2 -g -W -Wall -Wno-unused-parameter = -Wbad-function-cast -Wuninitialized=C2=A0=C2=A0 mtest.o liblmdb.a=C2=A0 -o = mtest<br>gcc -pthread -O2 -g -W -Wall -Wno-unused-parameter -Wbad-function-= cast -Wuninitialized=C2=A0=C2=A0 -c mtest2.c<br>gcc -pthread -O2 -g -W -Wal= l -Wno-unused-parameter -Wbad-function-cast -Wuninitialized=C2=A0=C2=A0 mte= st2.o liblmdb.a=C2=A0 -o mtest2<br>gcc -pthread -O2 -g -W -Wall -Wno-unused= -parameter -Wbad-function-cast -Wuninitialized=C2=A0=C2=A0 -c mtest3.c<br>g= cc -pthread -O2 -g -W -Wall -Wno-unused-parameter -Wbad-function-cast -Wuni= nitialized=C2=A0=C2=A0 mtest3.o liblmdb.a=C2=A0 -o mtest3<br>gcc -pthread -= O2 -g -W -Wall -Wno-unused-parameter -Wbad-function-cast -Wuninitialized=C2= =A0=C2=A0 -c mtest4.c<br>gcc -pthread -O2 -g -W -Wall -Wno-unused-parameter= -Wbad-function-cast -Wuninitialized=C2=A0=C2=A0 mtest4.o liblmdb.a=C2=A0 -= o mtest4<br>gcc -pthread -O2 -g -W -Wall -Wno-unused-parameter -Wbad-functi= on-cast -Wuninitialized=C2=A0=C2=A0 -c mtest5.c<br>gcc -pthread -O2 -g -W -= Wall -Wno-unused-parameter -Wbad-function-cast -Wuninitialized=C2=A0=C2=A0 = mtest5.o liblmdb.a=C2=A0 -o mtest5<br><br></div><div class=3D"gmail_extra">= <br><div class=3D"gmail_quote">On Mon, Oct 19, 2015 at 8:35 AM, Howard Chu = <span dir=3D"ltr"><<a href=3D"mailto:hyc@symas.com" target=3D"_blank">hy= c(a)symas.com</a>></span> wrote:<br><blockquote class=3D"gmail_quote" styl= e=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span c= lass=3D"">Ignacio Casal Quinteiro wrote:<br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex"> I am ok not fixing the MSVC warnings because it is picky even though some o= f<br> them might make sense even for mingw, but in this case it is an error and t= his<br> really small change enable msvc to build without errors. Can't you reco= nsider<br> the change? Specially since it will build fine with mingw as well.<br> </blockquote> <br></span> No, since it will break Unix builds.<br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex"><span class=3D""> <br> On Sat, Oct 17, 2015 at 7:54 PM, Howard Chu <<a href=3D"mailto:hyc@symas= .com" target=3D"_blank">hyc(a)symas.com</a><br></span> <mailto:<a href=3D"mailto:hyc@symas.com" target=3D"_blank">hyc(a)symas.com= </a>>> wrote:<span class=3D""><br> <br> =C2=A0 =C2=A0 <a href=3D"mailto:nacho.resa@gmail.com" target=3D"_blank">nac= ho.resa(a)gmail.com</a> <mailto:<a href=3D"mailto:nacho.resa@gmail.com" ta= rget=3D"_blank">nacho.resa(a)gmail.com</a>> wrote:<br> <br> =C2=A0 =C2=A0 =C2=A0 =C2=A0 Full_Name: Ignacio Casal Quinteiro<br> =C2=A0 =C2=A0 =C2=A0 =C2=A0 Version:<br> =C2=A0 =C2=A0 =C2=A0 =C2=A0 OS: Windows 7<br> =C2=A0 =C2=A0 =C2=A0 =C2=A0 URL: <a href=3D"ftp://ftp.openldap.org/incoming= /" rel=3D"noreferrer" target=3D"_blank">ftp://ftp.openldap.org/incoming/</a= ><br> =C2=A0 =C2=A0 =C2=A0 =C2=A0 Submission from: (NULL) (2a01:111f:9fa:7f00:864= b:f5ff:fe34:ddaa)<br> <br> <br> =C2=A0 =C2=A0 =C2=A0 =C2=A0 <a href=3D"https://github.com/nice-software/lmd= b/commit/076281a2c03356667fca7cce1a898a4f155e3dce" rel=3D"noreferrer" targe= t=3D"_blank">https://github.com/nice-software/lmdb/commit/076281a2c03356667= fca7cce1a898a4f155e3dce</a><br> <br> <br> =C2=A0 =C2=A0 I see no error when compiling with gcc -Wall. Closing this IT= S.<br> <br> =C2=A0 =C2=A0 --<br> =C2=A0 =C2=A0 =C2=A0 =C2=A0-- Howard Chu<br> =C2=A0 =C2=A0 =C2=A0 =C2=A0CTO, Symas Corp. <a href=3D"http://www.symas.com= " rel=3D"noreferrer" target=3D"_blank">http://www.symas.com</a><br> =C2=A0 =C2=A0 =C2=A0 =C2=A0Director, Highland Sun <a href=3D"http://highlan= dsun.com/hyc/" rel=3D"noreferrer" target=3D"_blank">http://highlandsun.com/= hyc/</a><br> =C2=A0 =C2=A0 =C2=A0 =C2=A0Chief Architect, OpenLDAP <a href=3D"http://www.= openldap.org/project/" rel=3D"noreferrer" target=3D"_blank">http://www.open= ldap.org/project/</a><br> <br> <br> <br> <br> --<br> Ignacio Casal Quinteiro<br> </span></blockquote><div class=3D"HOEnZb"><div class=3D"h5"> <br> <br> -- <br> =C2=A0 -- Howard Chu<br> =C2=A0 CTO, Symas Corp.=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<a href=3D"= http://www.symas.com" rel=3D"noreferrer" target=3D"_blank">http://www.symas= .com</a><br> =C2=A0 Director, Highland Sun=C2=A0 =C2=A0 =C2=A0<a href=3D"http://highland= sun.com/hyc/" rel=3D"noreferrer" target=3D"_blank">http://highlandsun.com/h= yc/</a><br> =C2=A0 Chief Architect, OpenLDAP=C2=A0 <a href=3D"http://www.openldap.org/p= roject/" rel=3D"noreferrer" target=3D"_blank">http://www.openldap.org/proje= ct/</a><br> </div></div></blockquote></div><br><br clear=3D"all"><br>-- <br><div class= =3D"gmail_signature">Ignacio Casal Quinteiro</div> </div> --f46d044289f661da1905226fa6a2--

1 0

Re: (ITS#8270) win32: fix conversion error
by hyc＠symas.com 19 Oct '15

19 Oct '15

Ignacio Casal Quinteiro wrote: > I am ok not fixing the MSVC warnings because it is picky even though some of > them might make sense even for mingw, but in this case it is an error and this > really small change enable msvc to build without errors. Can't you reconsider > the change? Specially since it will build fine with mingw as well. No, since it will break Unix builds. > > On Sat, Oct 17, 2015 at 7:54 PM, Howard Chu <hyc(a)symas.com > <mailto:hyc@symas.com>> wrote: > > nacho.resa(a)gmail.com <mailto:nacho.resa@gmail.com> wrote: > > Full_Name: Ignacio Casal Quinteiro > Version: > OS: Windows 7 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (2a01:111f:9fa:7f00:864b:f5ff:fe34:ddaa) > > > https://github.com/nice-software/lmdb/commit/076281a2c03356667fca7cce1a898a… > > > I see no error when compiling with gcc -Wall. Closing this ITS. > > -- > -- Howard Chu > CTO, Symas Corp. http://www.symas.com > Director, Highland Sun http://highlandsun.com/hyc/ > Chief Architect, OpenLDAP http://www.openldap.org/project/ > > > > > -- > Ignacio Casal Quinteiro -- -- 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#8270) win32: fix conversion error
by nacho.resa＠gmail.com 19 Oct '15

19 Oct '15

--047d7bfd0df8f33b1905226f06af Content-Type: text/plain; charset=UTF-8 I am ok not fixing the MSVC warnings because it is picky even though some of them might make sense even for mingw, but in this case it is an error and this really small change enable msvc to build without errors. Can't you reconsider the change? Specially since it will build fine with mingw as well. On Sat, Oct 17, 2015 at 7:54 PM, Howard Chu <hyc(a)symas.com> wrote: > nacho.resa(a)gmail.com wrote: > >> Full_Name: Ignacio Casal Quinteiro >> Version: >> OS: Windows 7 >> URL: ftp://ftp.openldap.org/incoming/ >> Submission from: (NULL) (2a01:111f:9fa:7f00:864b:f5ff:fe34:ddaa) >> >> >> >> https://github.com/nice-software/lmdb/commit/076281a2c03356667fca7cce1a898a… >> >> >> I see no error when compiling with gcc -Wall. Closing this ITS. > > -- > -- Howard Chu > CTO, Symas Corp. http://www.symas.com > Director, Highland Sun http://highlandsun.com/hyc/ > Chief Architect, OpenLDAP http://www.openldap.org/project/ > -- Ignacio Casal Quinteiro --047d7bfd0df8f33b1905226f06af Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr">I am ok not fixing the MSVC warnings because it is picky e= ven though some of them might make sense even for mingw, but in this case i= t is an error and this really small change enable msvc to build without err= ors. Can't you reconsider the change? Specially since it will build fin= e with mingw as well.<br></div><div class=3D"gmail_extra"><br><div class=3D= "gmail_quote">On Sat, Oct 17, 2015 at 7:54 PM, Howard Chu <span dir=3D"ltr"= ><<a href=3D"mailto:hyc@symas.com" target=3D"_blank">hyc(a)symas.com</a>&g= t;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0= .8ex;border-left:1px #ccc solid;padding-left:1ex"><a href=3D"mailto:nacho.= resa(a)gmail.com" target=3D"_blank">nacho.resa(a)gmail.com</a> wrote:<br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex"> Full_Name: Ignacio Casal Quinteiro<br> Version:<br> OS: Windows 7<br> URL: <a href=3D"ftp://ftp.openldap.org/incoming/" rel=3D"noreferrer" target= =3D"_blank">ftp://ftp.openldap.org/incoming/</a><br> Submission from: (NULL) (2a01:111f:9fa:7f00:864b:f5ff:fe34:ddaa)<br> <br> <br> <a href=3D"https://github.com/nice-software/lmdb/commit/076281a2c03356667fc= a7cce1a898a4f155e3dce" rel=3D"noreferrer" target=3D"_blank">https://github.= com/nice-software/lmdb/commit/076281a2c03356667fca7cce1a898a4f155e3dce</a><= br> <br> <br> </blockquote> I see no error when compiling with gcc -Wall. Closing this ITS.<span class= =3D"HOEnZb"><font color=3D"#888888"><br> <br> -- <br> =C2=A0 -- Howard Chu<br> =C2=A0 CTO, Symas Corp.=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<a href=3D"= http://www.symas.com" rel=3D"noreferrer" target=3D"_blank">http://www.symas= .com</a><br> =C2=A0 Director, Highland Sun=C2=A0 =C2=A0 =C2=A0<a href=3D"http://highland= sun.com/hyc/" rel=3D"noreferrer" target=3D"_blank">http://highlandsun.com/h= yc/</a><br> =C2=A0 Chief Architect, OpenLDAP=C2=A0 <a href=3D"http://www.openldap.org/p= roject/" rel=3D"noreferrer" target=3D"_blank">http://www.openldap.org/proje= ct/</a><br> </font></span></blockquote></div><br><br clear=3D"all"><br>-- <br><div clas= s=3D"gmail_signature">Ignacio Casal Quinteiro</div> </div> --047d7bfd0df8f33b1905226f06af--

1 0

Re: (ITS#8267) contributing a new overlay unicodepw
by ingo.voss＠freenet.de 18 Oct '15

18 Oct '15

Am 17.10.2015 um 20:58 schrieb Howard Chu: > ingo.voss(a)gmail.com wrote: >> Full_Name: Ingo Voss >> Version: >> OS: >> URL: ftp://ftp.openldap.org/incoming/contrib-slapd-modules-unicodepw.tar >> Submission from: (NULL) (78.53.86.212) >> >> >> Hello, >> >> I wrote a small overlay, that restricts all LDAP modification >> requests, so that >> only password changes for MS unicodePwd are possible. >> All other LDAP requests will not be observed. >> If someone needs a read-only proxy (in a e.g. dmz) for an MS Active >> Directory, >> but password changes must be possible, then unicodepw is the right >> overlay. >> For more informations, a manual page is included. > > If you want a read-only proxy, shouldn't this overlay also intercept > and deny all Add/Delete/ModDN requests? > Yes, you are right! But such overlay (denyop) exist already and it is working well. The manual page for unicodepw refers to denyop and describes the complete configuration in detail. Kindly regards Ingo

1 0

Re: (ITS#8267) contributing a new overlay unicodepw
by hyc＠symas.com 17 Oct '15

17 Oct '15

ingo.voss(a)gmail.com wrote: > Full_Name: Ingo Voss > Version: > OS: > URL: ftp://ftp.openldap.org/incoming/contrib-slapd-modules-unicodepw.tar > Submission from: (NULL) (78.53.86.212) > > > Hello, > > I wrote a small overlay, that restricts all LDAP modification requests, so that > only password changes for MS unicodePwd are possible. > All other LDAP requests will not be observed. > If someone needs a read-only proxy (in a e.g. dmz) for an MS Active Directory, > but password changes must be possible, then unicodepw is the right overlay. > For more informations, a manual page is included. If you want a read-only proxy, shouldn't this overlay also intercept and deny all Add/Delete/ModDN requests? -- -- 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#8272) Add Visual Studio Projects
by hyc＠symas.com 17 Oct '15

17 Oct '15

nacho.resa(a)gmail.com wrote: > Full_Name: Ignacio Casal Quinteiro > Version: > OS: Windows 7 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (2a01:111f:9fa:7f00:864b:f5ff:fe34:ddaa) > > > Patch can be found here: > https://github.com/nice-software/lmdb/commit/615fff21435f158b0afdb34b055aa8… > > The supported build tool is "make". Closing this ITS. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: (ITS#8270) win32: fix conversion error
by hyc＠symas.com 17 Oct '15

17 Oct '15

nacho.resa(a)gmail.com wrote: > Full_Name: Ignacio Casal Quinteiro > Version: > OS: Windows 7 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (2a01:111f:9fa:7f00:864b:f5ff:fe34:ddaa) > > > https://github.com/nice-software/lmdb/commit/076281a2c03356667fca7cce1a898a… > > I see no error when compiling with gcc -Wall. Closing this ITS. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: (ITS#8271) win32: add cast to avoid warning about LONGLONG to size_t
by hyc＠symas.com 17 Oct '15

17 Oct '15

nacho.resa(a)gmail.com wrote: > Full_Name: Ignacio Casal Quinteiro > Version: > OS: Windows 7 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (2a01:111f:9fa:7f00:864b:f5ff:fe34:ddaa) > > > Patch can be found here. > https://github.com/nice-software/lmdb/commit/2030f7dca473e66bd66ebee759ecfe… I see no warnings when compiled with gcc -Wall. Closing this ITS. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: (ITS#8269) win32: avoid warning about using strdup instead of _strdup
by hyc＠symas.com 17 Oct '15

17 Oct '15

nacho.resa(a)gmail.com wrote: > Full_Name: Ignacio Casal Quinteiro > Version: > OS: Windows 7 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (2a01:111f:9fa:7f00:864b:f5ff:fe34:ddaa) > > > You can find the patch here: > https://github.com/nice-software/lmdb/commit/67a61ed18ddb978f4e58198ca55b97… Sounds like you're using MSVC. The supported build system for LMDB uses gcc; with MinGW for Windows builds. We don't care about trivial warnings on MSVC. Add -D_CRT_NONSTDC_NO_DEPRECATE to your CFLAGS to silence this warning. Closing this ITS. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

(ITS#8272) Add Visual Studio Projects
by nacho.resa＠gmail.com 15 Oct '15

15 Oct '15

Full_Name: Ignacio Casal Quinteiro Version: OS: Windows 7 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (2a01:111f:9fa:7f00:864b:f5ff:fe34:ddaa) Patch can be found here: https://github.com/nice-software/lmdb/commit/615fff21435f158b0afdb34b055aa8…

1 0

(ITS#8271) win32: add cast to avoid warning about LONGLONG to size_t
by nacho.resa＠gmail.com 15 Oct '15

15 Oct '15

Full_Name: Ignacio Casal Quinteiro Version: OS: Windows 7 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (2a01:111f:9fa:7f00:864b:f5ff:fe34:ddaa) Patch can be found here. https://github.com/nice-software/lmdb/commit/2030f7dca473e66bd66ebee759ecfe…

1 0

(ITS#8270) win32: fix conversion error
by nacho.resa＠gmail.com 15 Oct '15

15 Oct '15

Full_Name: Ignacio Casal Quinteiro Version: OS: Windows 7 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (2a01:111f:9fa:7f00:864b:f5ff:fe34:ddaa) https://github.com/nice-software/lmdb/commit/076281a2c03356667fca7cce1a898a…

1 0

(ITS#8269) win32: avoid warning about using strdup instead of _strdup
by nacho.resa＠gmail.com 15 Oct '15

15 Oct '15

Full_Name: Ignacio Casal Quinteiro Version: OS: Windows 7 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (2a01:111f:9fa:7f00:864b:f5ff:fe34:ddaa) You can find the patch here: https://github.com/nice-software/lmdb/commit/67a61ed18ddb978f4e58198ca55b97…

1 0

Re: (ITS#7771) liblmdb cursor issues
by h.b.furuseth＠usit.uio.no 12 Oct '15

12 Oct '15

I wrote: > mdb_subcursor(MDB_cursor *mc) > (...) > if (((mc->mc_flags | subc->mc_flags) & C_INITIALIZED) && Oops. For reference, the '|' should be '&'. mdb.master has now been fixed to work without this function, though. -- Hallvard

1 0

Re: (ITS#7771) liblmdb cursor issues
by h.b.furuseth＠usit.uio.no 12 Oct '15

12 Oct '15

On 22/12/13 23:09, h.b.furuseth(a)usit.uio.no wrote: > I.e. lots more code needs something like > if ((leaf->mn_flags & (F_DUPDATA|F_SUBDATA)) == F_DUPDATA) > m2->mc_xcursor->mx_cursor.mc_pg[0] = NODEDATA(leaf); > before using an xcursor. I tried that everywhere before > using xcursors: That helped, but it was not enough. E.g. > after mdb_cursor_del() calls mdb_node_shrink(), it tracks > cursors in the same sub-page but not nearby sub-pages. Such fixups do heal this ITS's test program with current mdb.master, though. That is, perl -i -pe ' s/\b(\w+)->mc_xcursor->mx_cursor\./mdb_subcursor($1)->/gx; s/\&(\w+)->mc_xcursor->mx_cursor/mdb_subcursor($1)/gx;' mdb.c plus this function: static MDB_cursor * mdb_subcursor(MDB_cursor *mc) { MDB_xcursor *mx = mc->mc_xcursor; MDB_cursor *subc = NULL; MDB_page *mp = mc->mc_pg[mc->mc_top]; if (mx) { subc = &mx->mx_cursor; if (((mc->mc_flags | subc->mc_flags) & C_INITIALIZED) && mp && !(mp->mp_flags & (P_BRANCH|P_LEAF2|P_SUBP))) { MDB_node *leaf = NODEPTR(mp, mc->mc_ki[mc->mc_top]); if ((leaf->mn_flags & (F_SUBDATA|F_DUPDATA)) == F_DUPDATA) subc->mc_pg[0] = NODEDATA(leaf); } } return subc; }

1 0

ITS#8267
by ingo.voss＠gmail.com 11 Oct '15

11 Oct '15

Hello, after rereading, I=E2=80=99ve made a few changes in the manual page, so tha= t the old tar package can be discarded. Please use instead the old package now: ftp://ftp.openldap.org/incoming/contrib-slapd-modules-unicodepw-151011.tar Thanks, kindly regards Ingo Voss

1 0

(ITS#8268) slapd-ldap quarantine, per configuration retries fail
by nvoutsin＠gmai.com 11 Oct '15

11 Oct '15

Full_Name: Nikos Voutsinas Version: 2.4.42 OS: Solaris/Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (62.38.193.214) Hi, In a 4-nodes MMR deployment with a 2-nodes LDAP Proxy Front-ends, we have repeatedly noticed that whenever the connection recovery method falls into the quarantine code, it fails. i.e. when all the back-end ldap servers become unavailable, for some reason, slapd-ldap fails to follow the retry scheme that is dictated by olcDbQuarantine. In our case we set olcDbQuarantine to: 10,30;60,+ and when we got a temporary network timeout from all back-end ldap server this is what we saw in the slapd logs. Oct 7 21:30:58 proxy slapd[330]: conn=632725 op=0 ldap_back_retry: retrying URI="ldap://back01 ldap://back02" DN="" Oct 7 21:30:58 proxy slapd[330]: conn=632725 op=0: ldap_back_quarantine enter. Oct 7 21:31:08 proxy slapd[330]: conn=632759 op=0: ldap_back_getconn quarantine retry block #0 try #0. After that the only method to recover was either to restart the whole process or reset the value of olcDbQuarantine. Thanks, Nikos

1 0

(ITS#8267) contributing a new overlay unicodepw
by ingo.voss＠gmail.com 10 Oct '15

10 Oct '15

Full_Name: Ingo Voss Version: OS: URL: ftp://ftp.openldap.org/incoming/contrib-slapd-modules-unicodepw.tar Submission from: (NULL) (78.53.86.212) Hello, I wrote a small overlay, that restricts all LDAP modification requests, so that only password changes for MS unicodePwd are possible. All other LDAP requests will not be observed. If someone needs a read-only proxy (in a e.g. dmz) for an MS Active Directory, but password changes must be possible, then unicodepw is the right overlay. For more informations, a manual page is included. Kindly regards Ingo Voss

1 0

(ITS#8266) empty ldapmodify refused with slapo-unique
by geert＠hendrickx.be 08 Oct '15

08 Oct '15

Full_Name: Geert Hendrickx Version: 2.4.42 OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (212.123.14.2) When slapo-unique constraints are in effect, it seems empty updates are no longer allowed: $ ldapmodify -x -h localhost -D cn=Manager,dc=my-domain,dc=com -w secret dn: cn=test1,dc=my-domain,dc=com changetype: modifyA%A modifying entry "cn=test1,dc=my-domain,dc=com" ldap_modify: Invalid syntax (21) additional info: unique_modify() got null op.orm_modlist Why is this considered invalid syntax? Without slapo-unique constraint, empty updates like these are accepted.

1 0

Re: (ITS#8263) Broken cursor tracking in mdb_cursor_put()
by h.b.furuseth＠usit.uio.no 07 Oct '15

07 Oct '15

On 07/10/15 07:37, Howard Chu wrote: > Note: It's tempting to just merge the new xcursor_init2 function into > xcursor_init1 since they're very similar, but that's a bad idea. The > xcursor_init1 function really is meant for init'ing an unused cursor; > it's expected that immediately after, a full cursor-positioning action > will occur. > > xcursor_init2 is meant for xcursors that have already been positioned, > in which case their physical position is updated in order to keep their > logical position unchanged. Maybe you should document that in the code instead of in a mail message.

1 0

Re: (ITS#8263) Broken cursor tracking in mdb_cursor_put()
by hyc＠symas.com 07 Oct '15

07 Oct '15

h.b.furuseth(a)usit.uio.no wrote: > Full_Name: Hallvard B Furuseth > Version: mdb.master, 8b46dcc26d1e9897ab1da3a4a164cad4a4479a52 > OS: Linux x86_64 > URL: ftp://ftp.openldap.org/incoming/Hallvard-Furuseth-151005.c > Submission from: (NULL) (81.191.45.5) > Submitted by: hallvard > > > The test program catches several cursor tracking bugs. > It works when the DUPSORT sub-DB is created immediately: Yes, when using a fake page we init the subcursor with the fake page. When using a full sub-DB we left the subcursor pointing to the sub-DB but otherwise uninit'd. > > $ ./a.out 1500 > mn_flags = 6 <repeated 22 times> Fixed now in mdb.master. Note: It's tempting to just merge the new xcursor_init2 function into xcursor_init1 since they're very similar, but that's a bad idea. The xcursor_init1 function really is meant for init'ing an unused cursor; it's expected that immediately after, a full cursor-positioning action will occur. xcursor_init2 is meant for xcursors that have already been positioned, in which case their physical position is updated in order to keep their logical position unchanged. -- -- 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#8265) RFE: resultCode counters in cn=monitor
by michael＠stroeder.com 06 Oct '15

06 Oct '15

Full_Name: Michael Str.der Version: HEAD OS: URL: Submission from: (NULL) (84.181.161.13) It would be handy especially for security monitoring if one could observe counters for several result codes in cn=monitor. E.g. correlating the number of bind requests with 49 counter is much easier and gives better performance than extracting log lines (if those are available at all). Maybe a tree like this: cn=monitor cn=Results monitoredResultCode=0 monitoredInfo: <counter> monitoredResultCode=49 monitoredInfo: <counter> This should probably configurable because there are so many also custom result code: database monitor monitor_resultcodes 0,49

1 0

Re: (ITS#8264) LMDB mdb_del in a cursor causes data loss in certain situations
by hyc＠symas.com 06 Oct '15

06 Oct '15

hyc(a)symas.com wrote: > Unable to reproduce. Ah, the error went away if you reran with an existing DB. After deleting the DB the problem showed up. Fixed now in mdb.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#8264) LMDB mdb_del in a cursor causes data loss in certain situations
by hyc＠symas.com 06 Oct '15

06 Oct '15

malyn(a)strangeGizmo.com wrote: > Full_Name: Michael Alyn Miller > Version: LMDB 0.9.14, Git head > OS: Windows 8.1 x64, NixOS 14.12 x64 > URL: ftp://ftp.openldap.org/incoming/michael-alyn-miller-151005.c > Submission from: (NULL) (96.251.78.237) > > > I have a helper library that sits on top of LMDB and testing some of the > abstractions in that library has exposed a bug in LMDB related to deleting items > while inside of a cursor. I have reduced the repro down to a test case that > operates directly against LMDB. > > The test in question adds three groups of keys to the database (each with a > different prefix) and then deletes the third group of keys. The deletion is > done by scanning all of the keys with that prefix using a cursor. > mdb_cursor_del works correctly and deletes only the targeted keys, whereas > mdb_del causes nine extra keys (not in that group/prefix) to be deleted. > I have tested this code against LMDB 0.9.14 and Git head 8b46dcc. Please let me > know if you need any additional information. Thank you for your time! Unable to reproduce. violino:~/OD/mdb/libraries/liblmdb> gcc -g -c michael-alyn-miller-151005.c violino:~/OD/mdb/libraries/liblmdb> gcc -o mic michael-alyn-miller-151005.o -pthread liblmdb.a violino:~/OD/mdb/libraries/liblmdb> ./mic Num items after deletion using mdb_cursor_del: 44 (correct) Num items after deletion using mdb_del: 44 (correct) violino:~/OD/mdb/libraries/liblmdb> git log commit 8b46dcc26d1e9897ab1da3a4a164cad4a4479a52 Author: Howard Chu <hyc(a)openldap.org> Date: Sun Oct 4 01:56:25 2015 +0100 ITS#8258 fix rebalance/split The tree height can also increase during rebalance, not just shrink. This can happen if update_key needs to split a parent branch page. -- -- 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#8264) LMDB mdb_del in a cursor causes data loss in certain situations
by malyn＠strangeGizmo.com 06 Oct '15

06 Oct '15

Full_Name: Michael Alyn Miller Version: LMDB 0.9.14, Git head OS: Windows 8.1 x64, NixOS 14.12 x64 URL: ftp://ftp.openldap.org/incoming/michael-alyn-miller-151005.c Submission from: (NULL) (96.251.78.237) I have a helper library that sits on top of LMDB and testing some of the abstractions in that library has exposed a bug in LMDB related to deleting items while inside of a cursor. I have reduced the repro down to a test case that operates directly against LMDB. The test in question adds three groups of keys to the database (each with a different prefix) and then deletes the third group of keys. The deletion is done by scanning all of the keys with that prefix using a cursor. mdb_cursor_del works correctly and deletes only the targeted keys, whereas mdb_del causes nine extra keys (not in that group/prefix) to be deleted. Note that most of my test runs (with different test data) do not exhibit this behavior: the targeted keys, and only the targeted keys, are deleted as expected. Something about these specific keys and values triggers the bug. I assume that other keys will also trigger the bug, but these are the ones that I have converted into an LMDB-based test. The referenced test runs twice: once with mdb_cursor_del and once with mdb_del. You can mdb_dump the data before and after each deletion to see the extra keys that are being removed. The incorrectly deleted keys are all consecutive and begin with 02000000000000003a; the nine keys after and including 02...3aa4... are the ones that are incorrectly deleted. Only keys beginning with 03000000000000003a should have been deleted (so it is interesting to note that the nine keys immediately preceding the targeted keys were the ones that were incorrectly deleted). Is it valid to delete keys with mdb_del while inside of a cursor? If not, then ignore this bug report and I will modify my helper library. That said, I do expose more than just delete to my callers during cursor scans (they can mdb_put new items during a scan), which is why my library uses mdb_del and not mdb_cursor_del in this scenario. I have tested this code against LMDB 0.9.14 and Git head 8b46dcc. Please let me know if you need any additional information. Thank you for your time!

1 0

(ITS#8263) Broken cursor tracking in mdb_cursor_put()
by h.b.furuseth＠usit.uio.no 05 Oct '15

05 Oct '15

Full_Name: Hallvard B Furuseth Version: mdb.master, 8b46dcc26d1e9897ab1da3a4a164cad4a4479a52 OS: Linux x86_64 URL: ftp://ftp.openldap.org/incoming/Hallvard-Furuseth-151005.c Submission from: (NULL) (81.191.45.5) Submitted by: hallvard The test program catches several cursor tracking bugs. $ ./a.out 250 mn_flags = 0 mn_flags = 4 mn_flags = 4 a.c:36: run: Assertion `d1.mv_size == ksz && d1.mv_data == d2.mv_data' failed. Aborted $ ./a.out 500 mn_flags = 0 mn_flags = 4 mn_flags = 6 a.c:36: run: Assertion `d1.mv_size == ksz && d1.mv_data == d2.mv_data' failed. Aborted $ ./a.out 1000 mn_flags = 0 mn_flags = 6 a.c:34: mdb_cursor_get(c1, &k1, &d1, MDB_GET_CURRENT): Invalid argument Aborted It works when the DUPSORT sub-DB is created immediately: $ ./a.out 1500 mn_flags = 6 <repeated 22 times>

1 0

Re: (ITS#8258) LMDB cursor_del followed by MDB_NEXT can trigger assert crash
by hyc＠symas.com 04 Oct '15

04 Oct '15

hyc(a)symas.com wrote: > steven.lang(a)hgst.com wrote: >> Full_Name: Steven Lang >> Version: LMDB 0.9.16 >> OS: Ubuntu 14.04 >> URL: ftp://ftp.openldap.org/incoming/steven-lang-150929.c >> Submission from: (NULL) (199.255.44.5) >> >> >> While doing some testing using randomized key and data lengths and random puts >> and deletes, I found a situation in which mdb_cursor_del(...) followed by >> mdb_cursor_get(..., MDB_NEXT) causes an error: >> >> mdb.c:5726: Assertion 'IS_LEAF(mp)' failed in mdb_cursor_next() >> Aborted >> Attached is a program which fills a DB, then deletes keys until it asserts. > > Thanks for the report. Our alternate approach to solve #8221 was to check the > page fill factor including the (usually omitted) key #0 size; we didn't go > that way because it was slightly more processing. But given this bug, it seems > that's the only way to go. > Fixed now in git, thanks. -- -- 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#8260) Test "test062-config-delete" occasionally runs intosegmentation fault
by hyc＠symas.com 02 Oct '15

02 Oct '15

hguo(a)suse.com wrote: > This message is in MIME format. The first part should be readable text, > while the remaining parts are likely unreadable without MIME-aware tools. Only plaintext emails should be used here. > > ---1609925821-2101104869-1443783301=:2873 > Content-Type: text/plain; charset=UTF-8; format=flowed > Content-Transfer-Encoding: 8BIT > > Hello Michael. > > The bug can be triggered not only on master, but on the released versions 2.4.41 and 2.4.42 as well. test062 is not included in OpenLDAP 2.4. Running it against 2.4 is invalid. This is a dup of ITS#7639. Closing this ITS. > Regards, > Howard > > On Thu, 1 Oct 2015, Michael StrÃ¶der wrote: > >> Howard, >> >> hguo(a)suse.com wrote: >>> The test case "test062-config-delete" occasionally runs into segfault when >>> running with BDB backend. The chance of segfault happening is about once every >>> 200 runs. >>> >>> The version of OpenLDAP is post-2.4.42 master checked out at revision >>> 94d6581b50fa2d877cf4a1e20ca6766454094ef8, simply compiled with make. >> >> To me this revision seems to be from master branch. Are you sure you want to >> test that? Or are you rather looking for testing OPENLDAP_REL_ENG_2_4 branch? >> >> Also note that back-bdb is highly deprecated and IIRC building it will be >> disabled in OpenLDAP 2.5 (which is AFAIK what master branch is heading to). >> >> Ciao, Michael. >> . >> > ---1609925821-2101104869-1443783301=:2873-- > > > > -- -- 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#8260) Test "test062-config-delete" occasionally runs intosegmentation fault
by leo＠yuriev.ru 02 Oct '15

02 Oct '15

This issue fixed in ReOpenLDAP. https://github.com/ReOpen/ReOpenLDAP/issues/45 2015-10-02 13:55 GMT+03:00 <hguo(a)suse.com>: > This message is in MIME format. The first part should be readable text= , > while the remaining parts are likely unreadable without MIME-aware tool= s. > > ---1609925821-2101104869-1443783301=3D:2873 > Content-Type: text/plain; charset=3DUTF-8; format=3Dflowed > Content-Transfer-Encoding: 8BIT > > Hello Michael. > > The bug can be triggered not only on master, but on the released versions= 2.4.41 and 2.4.42 as well. > > Regards, > Howard > > On Thu, 1 Oct 2015, Michael Str=C3=B6der wrote: > >> Howard, >> >> hguo(a)suse.com wrote: >>> The test case "test062-config-delete" occasionally runs into segfault w= hen >>> running with BDB backend. The chance of segfault happening is about onc= e every >>> 200 runs. >>> >>> The version of OpenLDAP is post-2.4.42 master checked out at revision >>> 94d6581b50fa2d877cf4a1e20ca6766454094ef8, simply compiled with make. >> >> To me this revision seems to be from master branch. Are you sure you wan= t to >> test that? Or are you rather looking for testing OPENLDAP_REL_ENG_2_4 br= anch? >> >> Also note that back-bdb is highly deprecated and IIRC building it will b= e >> disabled in OpenLDAP 2.5 (which is AFAIK what master branch is heading t= o). >> >> Ciao, Michael. >> . >> > ---1609925821-2101104869-1443783301=3D:2873-- > > >

1 0

Re: (ITS#8260) Test "test062-config-delete" occasionally runs intosegmentation fault
by hguo＠suse.com 02 Oct '15

02 Oct '15

This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. ---1609925821-2101104869-1443783301=:2873 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8BIT Hello Michael. The bug can be triggered not only on master, but on the released versions 2.4.41 and 2.4.42 as well. Regards, Howard On Thu, 1 Oct 2015, Michael Ströder wrote: > Howard, > > hguo(a)suse.com wrote: >> The test case "test062-config-delete" occasionally runs into segfault when >> running with BDB backend. The chance of segfault happening is about once every >> 200 runs. >> >> The version of OpenLDAP is post-2.4.42 master checked out at revision >> 94d6581b50fa2d877cf4a1e20ca6766454094ef8, simply compiled with make. > > To me this revision seems to be from master branch. Are you sure you want to > test that? Or are you rather looking for testing OPENLDAP_REL_ENG_2_4 branch? > > Also note that back-bdb is highly deprecated and IIRC building it will be > disabled in OpenLDAP 2.5 (which is AFAIK what master branch is heading to). > > Ciao, Michael. > . > ---1609925821-2101104869-1443783301=:2873--

1 0

(ITS#8262) libldap API enhancement
by hyc＠openldap.org 02 Oct '15

02 Oct '15

Full_Name: Howard Chu Version: 2.4 OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (70.211.141.184) Submitted by: hyc libldap has always (since initial commit) had an ldap_build_search_request() function which constructs the ber of the request message. This ber can then be sent to a server using ldap_send_initial_request(). Corresponding build* functions are missing for all of the other request types. There doesn't appear to be a good reason for this inconsistency, and it would be useful to be able to handle all request types the same way. In particular, it's useful for a caller to know the messageID of the new request before attempting to send it over the wire. This would make a number of issues in back-ldap/back-meta easier to deal with.

1 0

(ITS#8261) sl_malloc API enhancement
by hyc＠openldap.org 02 Oct '15

02 Oct '15

Full_Name: Howard Chu Version: 2.4 OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (70.211.141.184) Submitted by: hyc The slap_sl_mem_detach() function has never been used. It's basically not useful as-is, but a more general function slap_sl_mem_setctx would be useful, and could also handle any potential use cases for _mem_detach.

1 0

Re: (ITS#8260) Test "test062-config-delete" occasionally runs into segmentation fault
by michael＠stroeder.com 01 Oct '15

01 Oct '15

Howard, hguo(a)suse.com wrote: > The test case "test062-config-delete" occasionally runs into segfault when > running with BDB backend. The chance of segfault happening is about once every > 200 runs. > > The version of OpenLDAP is post-2.4.42 master checked out at revision > 94d6581b50fa2d877cf4a1e20ca6766454094ef8, simply compiled with make. To me this revision seems to be from master branch. Are you sure you want to test that? Or are you rather looking for testing OPENLDAP_REL_ENG_2_4 branch? Also note that back-bdb is highly deprecated and IIRC building it will be disabled in OpenLDAP 2.5 (which is AFAIK what master branch is heading to). Ciao, Michael.

1 0

(ITS#8260) Test "test062-config-delete" occasionally runs into segmentation fault
by hguo＠suse.com 01 Oct '15

01 Oct '15

Full_Name: Howard Guo Version: master-94d6581b50fa2d877cf4a1e20ca6766454094ef8 OS: openSUSE URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (195.135.221.2) The test case "test062-config-delete" occasionally runs into segfault when running with BDB backend. The chance of segfault happening is about once every 200 runs. The version of OpenLDAP is post-2.4.42 master checked out at revision 94d6581b50fa2d877cf4a1e20ca6766454094ef8, simply compiled with make. The operating system is openSUSE Tumbleweed running on kernel 4.1.6. Here is the GDB conversation with a captured core dump file: Core was generated by `/home/howard/qa_test_openldap2/tests/../servers/slapd/slapd -s0 -F ./slapd.d -h'. Program terminated with signal SIGSEGV, Segmentation fault. #0 0x000055e606fed253 in syncprov_op_abandon (op=0x7f7aa15498a0, rs=0x7f7aa15496e0) at syncprov.c:1156 1156 if ( so->s_op->o_connid == op->o_connid && (gdb) l 1151 syncprov_info_t *si = on->on_bi.bi_private; 1152 syncops *so, **sop; 1153 1154 ldap_pvt_thread_mutex_lock( &si->si_ops_mutex ); 1155 for ( sop=&si->si_ops; (so = *sop); sop = &(*sop)->s_next ) { 1156 if ( so->s_op->o_connid == op->o_connid && 1157 so->s_op->o_msgid == op->orn_msgid ) { 1158 so->s_op->o_abandon = 1; 1159 *sop = so->s_next; 1160 break; (gdb) info locals on = <optimized out> si = 0x7f7a94104990 so = 0x7f7a94103f30 sop = 0x7f7a94104990 (gdb) print so->s_op->o_hdr Cannot access memory at address 0x6172757463757274 Please let me know how I may assist further with debugging.

1 0

Re: (ITS#8259) LMDB utilities print usage incorrectly
by hyc＠symas.com 30 Sep '15

30 Sep '15

jpmens(a)gmail.com wrote: > Full_Name: Jan-Piet Mens > Version: LMDB 0.9.16 > OS: OSX, Linux > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (2a02:908:b41:38e0:241a:be7c:787f:620) > > > LMDB's utilities (mdb_stat, mdb_copy, etc) incorrectly specify that dbpath > (envpath) comes before options. > > $ ./mdb_stat jp -a > usage: ./mdb_stat dbpath [-V] [-n] [-e] [-r[r]] [-f[f[f]]] [-a|-s subdb] > > $ ./mdb_stat -a jp > Status of Main DB > ... > > This also requires a documentation update in the man pages. Fixed in mdb.master and mdb.RE/0.9 -- -- 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#8259) LMDB utilities print usage incorrectly
by jpmens＠gmail.com 30 Sep '15

30 Sep '15

Full_Name: Jan-Piet Mens Version: LMDB 0.9.16 OS: OSX, Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (2a02:908:b41:38e0:241a:be7c:787f:620) LMDB's utilities (mdb_stat, mdb_copy, etc) incorrectly specify that dbpath (envpath) comes before options. $ ./mdb_stat jp -a usage: ./mdb_stat dbpath [-V] [-n] [-e] [-r[r]] [-f[f[f]]] [-a|-s subdb] $ ./mdb_stat -a jp Status of Main DB ... This also requires a documentation update in the man pages.

1 0

Re: (ITS#8258) LMDB cursor_del followed by MDB_NEXT can trigger assert crash
by hyc＠symas.com 30 Sep '15

30 Sep '15

steven.lang(a)hgst.com wrote: > Full_Name: Steven Lang > Version: LMDB 0.9.16 > OS: Ubuntu 14.04 > URL: ftp://ftp.openldap.org/incoming/steven-lang-150929.c > Submission from: (NULL) (199.255.44.5) > > > While doing some testing using randomized key and data lengths and random puts > and deletes, I found a situation in which mdb_cursor_del(...) followed by > mdb_cursor_get(..., MDB_NEXT) causes an error: > > mdb.c:5726: Assertion 'IS_LEAF(mp)' failed in mdb_cursor_next() > Aborted > > After a little debugging I was able to isolate what the cause was and produce a > simple program to reproduce the issue; during the re-balance following a delete, > it would try to move a node from the first child of the root page to the second. > If the node it moves has a key longer than the second node in the root page, and > the new key doesn't fit, it will split the root page. As a result, by deleting a > node, the tree becomes deeper. > > However, the cursor only checks and compensates for the tree becoming shallower. > So now the cursor was pointing to a branch page rather than a leaf page. Any > further cursor operations fail. (Trying to do a MDB_SET, MDB_SET_RANGE, etc will > silently fail at this point, while MDB_NEXT and possibly MDB_PREV will assert.) > > The latest head with the fix for ITS#8221 changes the behavior slightly, due to > the different arrangement of the tree with the less aggressive merging. However, > it still fails. > > Attached is a program which fills a DB, then deletes keys until it asserts. Thanks for the report. Our alternate approach to solve #8221 was to check the page fill factor including the (usually omitted) key #0 size; we didn't go that way because it was slightly more processing. But given this bug, it seems that's the only way to go. -- -- 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#8258) LMDB cursor_del followed by MDB_NEXT can trigger assert crash
by steven.lang＠hgst.com 30 Sep '15

30 Sep '15

Full_Name: Steven Lang Version: LMDB 0.9.16 OS: Ubuntu 14.04 URL: ftp://ftp.openldap.org/incoming/steven-lang-150929.c Submission from: (NULL) (199.255.44.5) While doing some testing using randomized key and data lengths and random puts and deletes, I found a situation in which mdb_cursor_del(...) followed by mdb_cursor_get(..., MDB_NEXT) causes an error: mdb.c:5726: Assertion 'IS_LEAF(mp)' failed in mdb_cursor_next() Aborted After a little debugging I was able to isolate what the cause was and produce a simple program to reproduce the issue; during the re-balance following a delete, it would try to move a node from the first child of the root page to the second. If the node it moves has a key longer than the second node in the root page, and the new key doesn't fit, it will split the root page. As a result, by deleting a node, the tree becomes deeper. However, the cursor only checks and compensates for the tree becoming shallower. So now the cursor was pointing to a branch page rather than a leaf page. Any further cursor operations fail. (Trying to do a MDB_SET, MDB_SET_RANGE, etc will silently fail at this point, while MDB_NEXT and possibly MDB_PREV will assert.) The latest head with the fix for ITS#8221 changes the behavior slightly, due to the different arrangement of the tree with the less aggressive merging. However, it still fails. Attached is a program which fills a DB, then deletes keys until it asserts.

1 0

Re: (ITS#8257) test061-syncreplication-initiation seg faults
by hyc＠symas.com 29 Sep '15

29 Sep '15

michael(a)stroeder.com wrote: > Full_Name: > Version: openSUSE Linux > OS: RE24 branch > URL: > Submission from: (NULL) (84.178.28.66) > > > The current re24 branch seg faults: Fixed on mdb.RE/0.9. Closing this ITS, use #8221. > >>>>>> Starting test061-syncreplication-initiation for mdb... > Running defines.sh > Initializing server configurations > Starting provider slapd on ldap://localhost:9011/ > Starting forward1 slapd on ldap://localhost:9013/ > Starting consumer slapd on ldap://localhost:9012/ > Adding schema on ldap://localhost:9011/ > Adding backend module on ldap://localhost:9011/... > Adding schema on ldap://localhost:9012/ > Adding backend module on ldap://localhost:9012/... > Adding schema on ldap://localhost:9013/ > Adding backend module on ldap://localhost:9013/... > Adding database configuration on ldap://localhost:9011/ > Populating provider on ldap://localhost:9011/ > Adding database configuration on ldap://localhost:9013/ > Adding database configuration on ldap://localhost:9012/ > Using ldapsearch to check that ldap://localhost:9013/ received database... > Using ldapsearch to check that ldap://localhost:9012/ received database... > Running 1 of 1 syncrepl initiation race tests... > Stopping forwarders for add test > Using ldapadd to add 10 entries on provider > Starting forwarders again > Using ldapadd to add 10 more entries on provider > Checking replication to ldap://localhost:9013/ > Checking replication to ldap://localhost:9012/ > Stopping forwarders for add/delete test > Using ldapadd to add 10 entries on provider > Using ldapdelete to delete 10 entries on provider > Starting forwarders again > Using ldapadd to add 10 more entries on provider > Using ldapdelete to delete 10 more entries on provider > Checking replication to ldap://localhost:9013/ > Checking replication to ldap://localhost:9012/ > Stopping forwarders for delete test > Using ldapdelete to delete entries on provider > Starting forwarders again > Using ldapdelete to delete 10 more entries on provider > ldap_result: Can't contact LDAP server (-1) > ldapdelete failed (255)! >>>>>> test061-syncreplication-initiation failed for mdb > (exit 1) > Makefile:309: recipe for target 'mdb-mod' failed > make[2]: *** [mdb-mod] Error 1 > make[2]: Leaving directy %2'/usr/src/michael/openldap-git/re24/openldap/tests' > Makefile:279: recipe for target 'test' failed > make[1]: *** [test] Error 2 > make[1]: Leaving directory '/usr/src/michael/openldap-git/re24/openldap/tests' > Makefile:291: recipe for target 'test' failed > make: *** [test] Error 2 > michael@nb2:/usr/src/michael/openldap-git/re24/openldap> find -name core > ./tests/testrun/prov/core > > > -- -- 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

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs