(ITS#7607) Assertion triggers during many sequential transaction commits
by ilya.lukyanov＠gmail.com
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.
7 years, 11 months
Re: reference through null pointer and memory leak (related to ITS#7588)
by hyc＠symas.com
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/
7 years, 11 months
Re: (ITS#7605) Configuration entries (under cn=config) does not allow 'objectclass' attribute modification to include full object classes hierarchy
by pa＠marcelot.net
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
7 years, 11 months
Re: (ITS#7605) Configuration entries (under cn=config) does not allow 'objectclass' attribute modification to include full object classes hierarchy
by pa＠marcelot.net
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
7 years, 11 months
Re: (ITS#7448) "assertion failed" in MDB
by dhawes＠vt.edu
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.
7 years, 11 months
reference through null pointer and memory leak (related to ITS#7588)
by jdhgit＠yahoo.com
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().
7 years, 11 months
Re: (ITS#7582) Access to uninitialized memory when sending cldap packet
by hyc＠symas.com
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-unin...
> 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-unin...
>
> 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/
7 years, 11 months
Re: (ITS#7594) incomplete MDB subdb cursor cleanup
by hyc＠symas.com
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/
7 years, 11 months
