openldap-bugs

openldap-bugs@openldap.org

1 participants
20960 discussions

Re: (ITS#7775) LMDB terminates Postfix daemon process without logfile record
by wietse＠porcupine.org 02 Jan '14

02 Jan '14

Wietse Venema: > Hallvard Breien Furuseth: > > wietse(a)porcupine.org writes: > > >Hallvard Breien Furuseth: > > >> I suppose we could s/assert(foo)/mdb_assert(mc, foo)/ when that > > >> compiles so it can report env, txn, dbi. Howard, should I do that? > > > > > > That was my idea. Allow me to code up an example, it is simpler > > > than arguing in the abstract. > > > > By all means, but I expect we understand each other. I just needed to > > know how muchimpact this needs to have on the lmdb's code. The answer > > is it must walk all over it. And now that I think of it, it'll likely > > introduce merge conflicts in every outstanding branch of any size. > > So my preference is not to do this just yet. > > I am settling for less, and come with a few-line change, so that > LMDB might still end up in this month's stable Postfix release. > > Hang on for a few more minutes. Below is my "least painful" patch for both parties. What do you think? Wietse *** ./work/mdb-mdb/libraries/liblmdb/mdb.c- Tue Nov 12 11:10:33 2013 --- ./work/mdb-mdb/libraries/liblmdb/mdb.c Thu Jan 2 16:30:47 2014 *************** *** 65,71 **** #include <fcntl.h> #endif - #include <assert.h> #include <errno.h> #include <limits.h> #include <stddef.h> --- 65,70 ---- *************** *** 146,151 **** --- 145,155 ---- # error "Two's complement, reasonably sized integer types, please" #endif + /* assert(3) clone. Move this to the project-correct location. */ + static void mdb_assert(const char *, const char *, int, const char *); + #define assert(e) ((e) ? (void) 0 : mdb_assert(__func__, __FILE__, \ + __LINE__, #e)) + /** @defgroup internal MDB Internals * @{ */ *************** *** 3288,3293 **** --- 3292,3311 ---- return MDB_SUCCESS; } + void + (*mdb_assert_cb)(const char *,...); + + static void + mdb_assert(const char *func, const char *file, int line, const char *text) + { + if (mdb_assert_cb != 0) + mdb_assert_cb("Assertion failed: file %s, line %d, function %s: %s", + file, line, func, text); + fprintf(stderr, "Assertion failed: file %s, line %d, function %s: %s\n", + file, line, func, text); + abort(); + } + static int mdb_env_map(MDB_env *env, void *addr, int newsize) { *** ./work/mdb-mdb/libraries/liblmdb/lmdb.h- Tue Nov 12 11:10:33 2013 --- ./work/mdb-mdb/libraries/liblmdb/lmdb.h Thu Jan 2 16:01:37 2014 *************** *** 1429,1434 **** --- 1429,1441 ---- * @return 0 on success, non-zero on failure. */ int mdb_reader_check(MDB_env *env, int *dead); + + /** @brief Notify application of assertion failure. + * This should become obsolete as lmdb's error handling matures. + * @param[in] fmt The assertion message, not including newline. + */ + extern void (*mdb_assert_cb)(const char *fmt, ...); + /** @} */ #ifdef __cplusplus

1 0

Re: (ITS#7775) LMDB terminates Postfix daemon process without logfile record
by wietse＠porcupine.org 02 Jan '14

02 Jan '14

Hallvard Breien Furuseth: > wietse(a)porcupine.org writes: > >Hallvard Breien Furuseth: > >> I suppose we could s/assert(foo)/mdb_assert(mc, foo)/ when that > >> compiles so it can report env, txn, dbi. Howard, should I do that? > > > > That was my idea. Allow me to code up an example, it is simpler > > than arguing in the abstract. > > By all means, but I expect we understand each other. I just needed to > know how muchimpact this needs to have on the lmdb's code. The answer > is it must walk all over it. And now that I think of it, it'll likely > introduce merge conflicts in every outstanding branch of any size. > So my preference is not to do this just yet. I am settling for less, and come with a few-line change, so that LMDB might still end up in this month's stable Postfix release. Hang on for a few more minutes. Wietse

1 0

Re: (ITS#7775) LMDB terminates Postfix daemon process without logfile record
by h.b.furuseth＠usit.uio.no 02 Jan '14

02 Jan '14

wietse(a)porcupine.org writes: >Hallvard Breien Furuseth: >> I suppose we could s/assert(foo)/mdb_assert(mc, foo)/ when that >> compiles so it can report env, txn, dbi. Howard, should I do that? > > That was my idea. Allow me to code up an example, it is simpler > than arguing in the abstract. By all means, but I expect we understand each other. I just needed to know how muchimpact this needs to have on the lmdb's code. The answer is it must walk all over it. And now that I think of it, it'll likely introduce merge conflicts in every outstanding branch of any size. So my preference is not to do this just yet. -- Hallvard

1 0

Re: (ITS#7775) LMDB terminates Postfix daemon process without logfile record
by wietse＠porcupine.org 02 Jan '14

02 Jan '14

Hallvard Breien Furuseth: > wietse(a)porcupine.org writes: > >Hallvard Breien Furuseth: > >> /** User-settable callback for assert(), called before abort() > >> * instead of printing the message. > >> * > >> * assert(some user errors) might be unaffected. This hack > >> * should become obsolete as lmdb's error handling matures. > >> * @param[in] msg The assertion message, not including newline. > >> * @parem[in] info Currently NULL. Might change in the future. > >> */ > >> extern void (*mdb_assert_cb)(char *msg, void *info); > >> > >> (Or maybe call it -before- printing the message, you can abort or > >> longjmp yourself if you don't want the message.) > > > > Looks good. I'll code up an example implementation to set and use > > the callback. The "info" argument should be sufficient to figure > > out which database is failing. > > To repeat, 'info' would be NULL initially. Does that make it useless to > you? Various pieces of code don't know any context of interest to the > user anyway. That is unhelpful, as my opens lots of databases. Instead I propose that for each open database I give you my function pointer AND my context pointer. Then, you call my function with my context pointer when there is a problem. My program opens multiple databases. It is useless if you pass me your LMDB handle, as I now have to find out a) which of all my open databases is LMDB and b) which of those LMDB databases is messed up. That totally breaks all abstractions. > I suppose we could s/assert(foo)/mdb_assert(mc, foo)/ when that > compiles so it can report env, txn, dbi. Howard, should I do that? That was my idea. Allow me to code up an example, it is simpler than arguing in the abstract. Wietse

1 0

Re: (ITS#7774) LMDB assertion failure during Postfix cache cleanup
by h.b.furuseth＠usit.uio.no 02 Jan '14

02 Jan '14

Wietse Venema writes: > As written in the bug report the assertion also failed with > mdb_map_size set to an insanely large value (half a billion) in > which case the map size never changes. Yes... > But, it is good to know that the cursor is invalidated by both map > size changes and transactions that change the database. No, that's the wrong idea. This is a case of a user error breaking snapshot isolation: Ending the transaction invalidates its cursors, and you have to end the transaction in these two cases (modifying when using MDB_NOLOCK, or resizing). Those are "user errors" because that made it simple to code those features. We could add code to make them non-errors on in common cases and on common hosts, but I'm not sure if that's worth the trouble. > I can confirm that with LMDB-0.9.10 + ITS#7756 patch, the assertion > failure goes away when I close the cursor (and its read transaction) > before changing the map or the database, and restore the cursor > afterwards. I guess this got broken when things were changed to use > external locks in order to avoid world-writable lockfiles. Yes. Ending the read-only transaction and starting a new one means you are no longer seeing the same snapshot, though. So I hope the reason you couldn't use single transaction which I suggested previously, was that the reader transaction needed to keep seeing the same snapshot. -- Hallvard

1 0

Re: (ITS#7775) LMDB terminates Postfix daemon process without logfile record
by h.b.furuseth＠usit.uio.no 02 Jan '14

02 Jan '14

wietse(a)porcupine.org writes: >Hallvard Breien Furuseth: >> /** User-settable callback for assert(), called before abort() >> * instead of printing the message. >> * >> * assert(some user errors) might be unaffected. This hack >> * should become obsolete as lmdb's error handling matures. >> * @param[in] msg The assertion message, not including newline. >> * @parem[in] info Currently NULL. Might change in the future. >> */ >> extern void (*mdb_assert_cb)(char *msg, void *info); >> >> (Or maybe call it -before- printing the message, you can abort or >> longjmp yourself if you don't want the message.) > > Looks good. I'll code up an example implementation to set and use > the callback. The "info" argument should be sufficient to figure > out which database is failing. To repeat, 'info' would be NULL initially. Does that make it useless to you? Various pieces of code don't know any context of interest to the user anyway. I suppose we could s/assert(foo)/mdb_assert(mc, foo)/ when that compiles so it can report env, txn, dbi. Howard, should I do that? -- Hallvard

1 0

Re: (ITS#7775) LMDB terminates Postfix daemon process without logfile record
by wietse＠porcupine.org 02 Jan '14

02 Jan '14

Hallvard Breien Furuseth: > > - Invoke an application call-back function with the error code and > > problem description text. If the error code is MDB_PANIC then > > the application knows that it needs to make final arrangements. > > Sounds good to me for now, since it doesn't mean walking all over > the code. mdb.c can just #define its own assert(). No error > code, the context is just "we're about to abort" and I don't know > of other planned callbacks which the code would help. > > /** User-settable callback for assert(), called before abort() > * instead of printing the message. > * > * assert(some user errors) might be unaffected. This hack > * should become obsolete as lmdb's error handling matures. > * @param[in] msg The assertion message, not including newline. > * @parem[in] info Currently NULL. Might change in the future. > */ > extern void (*mdb_assert_cb)(char *msg, void *info); > > (Or maybe call it -before- printing the message, you can abort or > longjmp yourself if you don't want the message.) Looks good. I'll code up an example implementation to set and use the callback. The "info" argument should be sufficient to figure out which database is failing. Wietse

1 0

Re: (ITS#7774) LMDB assertion failure during Postfix cache cleanup
by wietse＠porcupine.org 02 Jan '14

02 Jan '14

Hallvard Breien Furuseth: > Wietse Venema writes: > > Why do you talk about map size changes when I delete a database entry?? > > That's how Postfix uses lmdb. It calls mdb_env_set_mapsize(). Looking As written in the bug report the assertion also failed with mdb_map_size set to an insanely large value (half a billion) in which case the map size never changes. But, it is good to know that the cursor is invalidated by both map size changes and transactions that change the database. I can confirm that with LMDB-0.9.10 + ITS#7756 patch, the assertion failure goes away when I close the cursor (and its read transaction) before changing the map or the database, and restore the cursor afterwards. I guess this got broken when things were changed to use external locks in order to avoid world-writable lockfiles. Wietse

1 0

Re: (ITS#7776) Bulk user add on ldap server
by quanah＠zimbra.com 02 Jan '14

02 Jan '14

--On Thursday, January 02, 2014 9:26 AM +0000 s.puspharaj(a)gmail.com wrote: > Full_Name: Puspharaj > Version: $OpenLDAP: slapd 2.4.23 (Apr 22 2013 05:03:41) > OS: Red Hat Enterprise Linux Server release 6.5 (Santiago) > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (103.4.125.30) The ITS system is for reporting bugs, not asking usage questions. I would advise you to take your question to the openldap-technical(a)openldap.org list. I would note a few things: a) The version of OpenLDAP shipped by RHEL is extremely broken. If you insist on using it, you must contact Red Hat for support. b) You can get up to date current OpenLDAP builds from Symas (http://www.symas.com) or the LTB project (<http://ltb-project.org/wiki/download#openldap>) c) I'm going to guess you are using back-bdb or back-hdb. Since you have groups with large membership, it is entirely possible you are running out of locks, lockers, or lock objects. I would advise setting an appropriate debugging level and looking for errors originating from Berkeley DB. --Quanah -- Quanah Gibson-Mount Architect - Server Zimbra, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

(ITS#7776) Bulk user add on ldap server
by s.puspharaj＠gmail.com 02 Jan '14

02 Jan '14

Full_Name: Puspharaj Version: $OpenLDAP: slapd 2.4.23 (Apr 22 2013 05:03:41) OS: Red Hat Enterprise Linux Server release 6.5 (Santiago) URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (103.4.125.30) Hi There, I have around 3000 user in people section were they hold multiple attributes and other things. The problem is, I have couple of groups that holds no user in it, When i tried to add users using ldapmodify command it sometimes not responding or it says the user exist even if the users won't exist in that group. Groupadd.ldif file contains : ################################################################# # dn: cn=typo3_frontend_global_salespartner,ou=Groups,o=company # # changetype: modify # # add: member # # member: uid=alesgian,ou=internal,c=it,ou=People,o=company # # member: uid=alesspin,ou=internal,c=it,ou=People,o=company # ################################################################# Somtimes the uid contains some special characters inbetween like . # , . When the user has the above characters it won't respond or it says the user exist. But when i added manually or with single line of user instead of 1000 user in that file. It accepts the ldapmodify command with that file. The command is ldapmodify -D "cn=Directory Manager,o=company" -f Groupadd.ldif -W This openldap version has any bug related to ldapmodify when adding 2000 users to a group through a single file? Thanks, Puspharaj

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