openldap-bugs May 2013

openldap-bugs@openldap.org

30 participants
83 discussions

Re: (ITS#7607) Assertion triggers during many sequential transaction commits
by hyc＠symas.com 24 May '13

24 May '13

ilya.lukyanov(a)gmail.com wrote: > Full_Name: Ilya Lukyanov > Version: 2.4.35 > OS: Windows 7 x64 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (95.25.254.250) > > > I've built lmdb from source distribution of OpenLDAP 2.4.35 under Windows 7 x64 > under Visual Studio 2012. All tests included into source distribution pass > successfully. > > Then i'm executing my own test with code as follows: > https://gist.github.com/ilyalukyanov/5644971 > And i'm allways get an asserion when executing near 32500-th mdb_txn_commit > (line 2231 - assert(oldpg_txnid <= env->me_pglast);) > I think this is a bug because if consider the scenario with separate usage of > LightningDB under high write-load scenario, 32k commits is not enough. Your test runs fine on my Linux box. I don't currently have a Windows 7 x64 test machine, won't be able to investigate this any time soon. -- -- 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#7607) Assertion triggers during many sequential transaction commits
by ilya.lukyanov＠gmail.com 24 May '13

24 May '13

Full_Name: Ilya Lukyanov Version: 2.4.35 OS: Windows 7 x64 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (95.25.254.250) I've built lmdb from source distribution of OpenLDAP 2.4.35 under Windows 7 x64 under Visual Studio 2012. All tests included into source distribution pass successfully. Then i'm executing my own test with code as follows: https://gist.github.com/ilyalukyanov/5644971 And i'm allways get an asserion when executing near 32500-th mdb_txn_commit (line 2231 - assert(oldpg_txnid <= env->me_pglast);) I think this is a bug because if consider the scenario with separate usage of LightningDB under high write-load scenario, 32k commits is not enough.

1 0

Re: reference through null pointer and memory leak (related to ITS#7588)
by hyc＠symas.com 24 May '13

24 May '13

jdhgit(a)yahoo.com wrote: > Full_Name: John Hardin > Version: master > OS: Centos 6.4 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (50.23.115.111) > > > The commit for ITS#7588 causes a crash if next_node is NULL: > > /* Set the first entry to send for the next page */ > so->so_tree = next_node; > + next_node->avl_left = NULL; > > next_node will be NULL if all entries have been sent, or if slapd_shutdown is > true. Thanks for pointing this out, will fix it shortly. > Another issue related to ITS#7588 is a memory leak when a sorted search with > paged results is aborted. This may be because so->so_tree is not the root of the > tree when free_sort_op() calls tavl_free(). Not being root of the tree is irrelevant. The tree is threaded, and every remaining node is connected by its preceding node's right child pointer. The tavl_free() function recurses over all of the right and left children, so this should not be a problem. Can you post a test case that demonstrates the leak? -- -- 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#7605) Configuration entries (under cn=config) does not allow 'objectclass' attribute modification to include full object classes hierarchy
by pa＠marcelot.net 24 May '13

24 May '13

On 23 mai 2013, at 19:41, Michael Ströder <michael(a)stroeder.com> wrote: > pa(a)marcelot.net wrote: >> On 23 mai 2013, at 16:31, Howard Chu <hyc(a)symas.com> wrote: >>> Don't do that. >> >> Sure, that's why I have a *bad* workaround to not update the 'objectClass' >> attribute even if the original and my generated one don't match. > > IMO this is not a *bad* workaround. I think it's good practice in a UI client > to *not* automagically modify attribute 'objectClass' without explicit user > interaction asking for modification. In the case of our UI, we don't even present the entries or attributes as is to the user but in an "abstracted" way. They may not even know it's read/stored internally from/as attributes or entries. So, yeah, so it's not so *bad*. It's more of an implementation tuning I wish would have not been required, because the modification seemed harmless and legit (according to LDAP standards). > Ciao, Michael. Regards, Pierre-Arnaud

1 0

Re: (ITS#7605) Configuration entries (under cn=config) does not allow 'objectclass' attribute modification to include full object classes hierarchy
by pa＠marcelot.net 24 May '13

24 May '13

On 23 mai 2013, at 19:26, Michael Ströder <michael(a)stroeder.com> wrote: > pa(a)marcelot.net wrote: >> It looks like it's not possible to modify the 'objectClass' attribute of >> configuration entries. >> >> I have some code generating entries for OpenLDAP configuration from a UI utility >> and updating existing configuration entries in DIT. >> This code generates entries with the 'objectClass' attribute containing the full >> object class hierarchy (all the way to 'top') and not only the highest >> structural object class (which is the case of default OpenLDAP configuration). >> >> When updating the configuration in the DIT, the code then tries to complete the >> 'objectClass' attribute with the full list of object classes. >> That operations ends with "error code 53- UnwillingToPerform". >> >> >> Here's an example on the "cn=config" entry: >> #!RESULT ERROR >> #!CONNECTION ldap://10.211.55.13:389 >> #!DATE 2013-05-22T14:56:03.039 >> #!ERROR [LDAP: error code 53 - UnwillingToPerform] >> dn: cn=config >> changetype: modify >> replace: objectClass >> objectClass: olcConfig >> objectClass: olcGlobal >> objectClass: top > > It's not necessarily a bug. > > I think LDAP clients should not act too "smart" and therefore should not > automagically add object classes from the structural object class chain if > they are not already present. You will run into issues with various LDAP > server implementations - at least according to experiences I made with > conducting interop testing with web2ldap and several server implementations. Right, it's just that this kind of modifications is perfectly valid. I mean, I'm not breaking any LDAP rule or concept and if I add the same entry (as a new entry) with the full object class hierarchy, the server is allowing it without a hitch. I still think it should be possible to modify the objectclass but I'll take into account that the implementation does not allow it (yet? ;-)). > A schema-aware client could auto-complete structural object class chain if > adding a new entry though. But again: Don't be too smart. Exactly, that's why I updated my code to do. Let's be dumb, sometimes... > May I ask which UI utility you're using? Sure, that's an internal application we wrote to edit some parts of the OpenLDAP configuration. > Ciao, Michael. Regards, Pierre-Arnaud

1 0

Re: (ITS#7448) "assertion failed" in MDB
by dhawes＠vt.edu 23 May '13

23 May '13

On Wed, May 22, 2013 at 5:49 PM, Quanah Gibson-Mount <quanah(a)zimbra.com> wrote: > This is ITS#7536. There were more fixes for it in RE24 after 2.4.35 was > released. I just wanted to verify that RE24 does indeed fix this issue.

1 0

reference through null pointer and memory leak (related to ITS#7588)
by jdhgit＠yahoo.com 23 May '13

23 May '13

Full_Name: John Hardin Version: master OS: Centos 6.4 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (50.23.115.111) The commit for ITS#7588 causes a crash if next_node is NULL: /* Set the first entry to send for the next page */ so->so_tree = next_node; + next_node->avl_left = NULL; next_node will be NULL if all entries have been sent, or if slapd_shutdown is true. Another issue related to ITS#7588 is a memory leak when a sorted search with paged results is aborted. This may be because so->so_tree is not the root of the tree when free_sort_op() calls tavl_free().

1 0

Re: (ITS#7583) ldap_init_fd() does not work with LDAP_PROTO_UDP
by hyc＠symas.com 23 May '13

23 May '13

stefw(a)redhat.com wrote: > Full_Name: Stef Walter > Version: 2.4.35 > OS: Fedora 18 > URL: http://fedorapeople.org/~stefw/patches/openldap-02/0001-Make-ldap_init_fd-w… > Submission from: (NULL) (77.3.95.123) > > > The ldap_init_fd() function does not work with UDP sockets (ie: LDAP_PROTO_UDP > passed in as the proto argument). Later uses of the LDAP connection returned > fail unceremoniously. > > This patch fixes the issue: Thanks, patch applied to git master. > > http://fedorapeople.org/~stefw/patches/openldap-02/0001-Make-ldap_init_fd-w… > > Some test code to exercise and demonstrate the problem. The code does not > actually wait for a UDP response, but should exit with a zero return code when > successful. > > http://fedorapeople.org/~stefw/patches/openldap-02/frob-cldap-initfd.c > > $ gcc -o frob-cldap-initfd -Wall -lldap -llber frob-cldap-initfd.c > $ ./frob-cldap-initfd > frob-cldap-initfd: ldap_search_ext: -1 > > The above result occurs before the patch is applied. > > -- -- 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#7582) Access to uninitialized memory when sending cldap packet
by hyc＠symas.com 23 May '13

23 May '13

stefw(a)redhat.com wrote: > Full_Name: Stef Walter > Version: 2.4.35 > OS: Fedora 18 > URL: http://fedorapeople.org/~stefw/patches/openldap-01/0001-Fix-usage-of-uninit… > Submission from: (NULL) (77.3.95.123) > > > When sending a cldap (UDP) packet, like a search request, uninitialized memory > is accessed. This shows up in valgrind like this: > > ==31445== Conditional jump or move depends on uninitialised value(s) > ==31445== at 0x36632244E6: ldap_send_server_request (request.c:377) > ==31445== by 0x36632247C2: ldap_send_initial_request (request.c:166) > ==31445== by 0x36632142F8: ldap_pvt_search (search.c:128) > ==31445== by 0x366321454F: ldap_search_ext (search.c:69) > ==31445== by 0x400838: main (in /data/projects/openldap/frob-cldap-search) > ==31445== > > This is due to parsing the resulting packet to pull out a requestDN. UDP packets > have different BER layout, and therefore the assumptions made when parsing the > outgoing request are invalid. > > It does not seem necessary to track the request DN for UDP packets. The linked > patch disables this code path for UDP packets. > > Patch which fixes the issue: > http://fedorapeople.org/~stefw/patches/openldap-01/0001-Fix-usage-of-uninit… > > Test code for the issue: > http://fedorapeople.org/~stefw/patches/openldap-01/frob-cldap-search.c > > Note that the test code doesn't detect the issue on its own (or do anything > useful). Use valgrind to detect the issue: > > $ gcc -o frob-cldap-search -Wall -lldap -llber frob-cldap-search.c > $ valgrind ./frob-cldap-search Your patch doesn't fix the issue. The behavior under valgrind is unchanged either way. Seems you're missing a '!' in your test. -- -- 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#7594) incomplete MDB subdb cursor cleanup
by hyc＠symas.com 23 May '13

23 May '13

h.b.furuseth(a)usit.uio.no wrote: > Full_Name: Hallvard B Furuseth > Version: mdb.master 0cdd9dffddf66c730a35f48db2bb02d8bb3e5731 > OS: Linux x86_64 > URL: > Submission from: (NULL) (193.69.163.163) > Submitted by: hallvard > > > If a cursor is at a clean subDB page, and its current item is deleted > by another cursor, then MDB_GET_CURRENT returns the deleted item. Fixed now in mdb.master. The subcursor on the clean page will be invalidated when the page is touched. > Test program below, run with no args, the "m2/del" output line. > > If the page was dirty, I instead got (key = old, data = size 0). > I don't know if it should give MDB_NOTFOUND instead. > That's the test program run with one arg. > I did not check what happens if the other cursor rearranged > the pages, e.g. split the item off to another page. > > #include "lmdb.h" > #include <assert.h> > #include <stdio.h> > #include <stdlib.h> > > int main(int argc, char **argv) > { > char *fname = "test.mdb"; > MDB_env *env; > MDB_txn *txn; > MDB_dbi dbi; > MDB_cursor *mc, *m2; > MDB_val key, data; > int rc; > # define STR2VAL(s) (&(MDB_val){sizeof(s), s}) /* includes final \0 */ > # define SHOW(name) printf("%s:\t%s[%zd] -> %s[%zd]\n", name, \ > (char*)key.mv_data, key.mv_size, (char*)data.mv_data, data.mv_size) > # define E(e) { rc = (e); if (rc) { fprintf(stderr, "%s:%d: %s: %s\n",\ > __FILE__, __LINE__, #e, mdb_strerror(rc)); abort(); } } > > remove(fname); > E(mdb_env_create(&env)); > E(mdb_env_open(env, fname, MDB_NOSUBDIR, 0666)); > E(mdb_txn_begin(env, NULL, 0, &txn)); > E(mdb_dbi_open(txn, NULL, MDB_DUPSORT, &dbi)); > > E(mdb_cursor_open(txn, dbi, &mc)); > E(mdb_cursor_put(mc, STR2VAL("a"), STR2VAL("x"), 0)); > E(mdb_cursor_put(mc, STR2VAL("a"), STR2VAL("y"), 0)); > > if (argc < 2) { > E(mdb_txn_commit(txn)); > E(mdb_txn_begin(env, NULL, 0, &txn)); > E(mdb_cursor_open(txn, dbi, &mc)); > puts("With clean page:"); > } > E(mdb_cursor_open(txn, dbi, &m2)); > > E(mdb_cursor_get(mc, &key, &data, MDB_FIRST)); > E(mdb_cursor_get(m2, &key, &data, MDB_FIRST)); > SHOW("Name:\tKey -> Data (mv_data[mv_len]):\n" "m2"); > > E(mdb_cursor_del(mc, 0)); > E(mdb_cursor_get(m2, &key, &data, MDB_GET_CURRENT)); > SHOW("m2/del"); /* Should output the same as... */ > E(mdb_cursor_get(mc, &key, &data, MDB_GET_CURRENT)); > SHOW("mc/del"); /* ...this: "a[2] -> [0]". */ > > mdb_txn_abort(txn); > mdb_env_close(env); > return 0; > } > > -- -- 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

← Newer
1
2
3
4
5
6
7
8
9
Older →

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs May 2013