openldap-bugs January 2013

openldap-bugs@openldap.org

24 participants
98 discussions

Re: (ITS#7487) memberof & mirrormode with delta-syncrepl crashing when using dynamic configuration
by afrunning＠gmail.com 08 Jan '13

08 Jan '13

> > slapd: memberof.c:1465: memberof_res_modify: Assertion `0' failed. > > If you have the core file handy, or if you can quickly reproduce the > problem, could you print the value of ml->sml_mod, i.e. from within gdb: > > (to see the backtrace) > $ bt > (where <x> is the number of the frame of function memberof_res_modify) > $ f <x> > (to see the value) > $ print ml->sml_mod (gdb) bt #0 0x00000032b04328a5 in raise () from /lib64/libc.so.6 #1 0x00000032b0434085 in abort () from /lib64/libc.so.6 #2 0x00000032b042ba1e in __assert_fail_base () from /lib64/libc.so.6 #3 0x00000032b042bae0 in __assert_fail () from /lib64/libc.so.6 #4 0x00000000004fc989 in memberof_res_modify (op=0x7fffebffe330, rs=<value optimized out>) at memberof.c:1465 #5 0x000000000042f91e in slap_response_play (op=0x7fffebffe330, rs=0x7fffebffd620) at result.c:507 #6 0x00000000004304a9 in send_ldap_response (op=0x7fffebffe330, rs=0x7fffebffd620) at result.c:582 #7 0x000000000043119c in slap_send_ldap_result (op=0x7fffebffe330, rs=0x7fffebffd620) at result.c:860 #8 0x00000000004b4035 in mdb_modify (op=0x7fffebffe330, rs=0x7fffebffd620) at modify.c:656 #9 0x00000000004845a7 in overlay_op_walk (op=0x7fffebffe330, rs=0x7fffebffd620, which=op_modify, oi=0x963b20, on=0x0) at backover.c:671 #10 0x0000000000484f87 in over_op_func (op=0x7fffebffe330, rs=<value optimized out>, which=<value optimized out>) at backover.c:723 #11 0x000000000047738d in syncrepl_message_to_op (si=0x9636f0, op=0x7fffebffe330, msg=<value optimized out>) at syncrepl.c:2318 #12 0x000000000047b1bf in do_syncrep2 (op=0x7fffebffe330, si=0x9636f0) at syncrepl.c:986 #13 0x00000000004809c2 in do_syncrepl (ctx=<value optimized out>, arg=0x963ee0) at syncrepl.c:1523 #14 0x00000000004210e1 in connection_read_thread (ctx=0x7fffebffeab0, argv=<value optimized out>) at connection.c:1288 #15 0x00000000005230a0 in ldap_int_thread_pool_wrapper (xpool=0x8b7640) at tpool.c:688 #16 0x00000032b0807851 in start_thread () from /lib64/libpthread.so.0 #17 0x00000032b04e811d in clone () from /lib64/libc.so.6 (gdb) f 4 #4 0x00000000004fc989 in memberof_res_modify (op=0x7fffebffe330, rs=<value optimized out>) at memberof.c:1465 1465 assert( 0 ); (gdb) print ml->sml_mod $1 = {sm_desc = 0x9640f0, sm_values = 0x7fffe00009b0, sm_nvalues = 0x7fffe00009d0, sm_numvals = 1, sm_op = 4097, sm_flags = 0, sm_type = {bv_len = 48, bv_val = 0x70756f72673d6e63 <Address 0x70756f72673d6e63 out of bounds>}} (gdb) Regards, Al

1 0

Re: (ITS#7487) memberof & mirrormode with delta-syncrepl crashing when using dynamic configuration
by masarati＠aero.polimi.it 08 Jan '13

08 Jan '13

> Full_Name: Al F > Version: 2.4.33 > OS: Redhat 6.3 x64 > URL: ftp://ftp.openldap.org/incoming/openldap-af.zip > Submission from: (NULL) (74.123.146.10) > > > I'm having an issue with mirrormode replication (via delta syncrepl) and > the > memberof overlay when using dynamic configuration. When a group member is > deleted on the first instance, slapd on the second instance is crashing > with the > following error (as seen from running slapd with -d-1): > > slapd: memberof.c:1465: memberof_res_modify: Assertion `0' failed. If you have the core file handy, or if you can quickly reproduce the problem, could you print the value of ml->sml_mod, i.e. from within gdb: (to see the backtrace) $ bt (where <x> is the number of the frame of function memberof_res_modify) $ f <x> (to see the value) $ print ml->sml_mod Thanks, p. -- Pierangelo Masarati Associate Professor Dipartimento di Ingegneria Aerospaziale Politecnico di Milano

1 0

(ITS#7487) memberof & mirrormode with delta-syncrepl crashing when using dynamic configuration
by afrunning＠gmail.com 08 Jan '13

08 Jan '13

Full_Name: Al F Version: 2.4.33 OS: Redhat 6.3 x64 URL: ftp://ftp.openldap.org/incoming/openldap-af.zip Submission from: (NULL) (74.123.146.10) I'm having an issue with mirrormode replication (via delta syncrepl) and the memberof overlay when using dynamic configuration. When a group member is deleted on the first instance, slapd on the second instance is crashing with the following error (as seen from running slapd with -d-1): slapd: memberof.c:1465: memberof_res_modify: Assertion `0' failed. If I disable either memberof or mirrormode, the change replicates correctly. If I use an identical static configuration file instead of a dynamic configuration, the change replicates correctly. This behavior happens on both bdb and mdb backends. I have setup a very basic test and have included the configurations for server1 and server2 in both static and dynamic configuration (both running on the same machine, just different ports), ldif file to populate tree (ldifs/basic.ldif), as well as the ldif file to crash the second node (ldifs/crash.ldif). the zip file contents (ftp://ftp.openldap.org/incoming/openldap-af.zip) are: openldap-af/ openldap-af/bt full.txt (output from gdb bt full) openldap-af/config.txt (output from source compilation) openldap-af/debug level logging.txt (output of the crash while running debug logs) openldap-af/ldifs/basic.ldif (the basic tree) openldap-af/ldifs/crash.ldif (ldif file applied to cause the failure) openldap-af/server1slapd.conf (server1's static configuration) openldap-af/server1slapd.d/* (server1's dynamic configuration - produced directly from static configuration with slaptest) openldap-af/server2slapd.conf (server2's static configuration) openldap-af/server2slapd.d/* (server2's dynamic configuration - produced directly from static configuration with slaptest) openldap-af/thread apply all bt.txt (output from gdb thread apply all bt) version & config information: OL_PACKAGE="OpenLDAP" OL_MAJOR=2 OL_MINOR=4 OL_PATCH=33 OL_API_INC=20433 OL_API_LIB_RELEASE=2.4 OL_API_LIB_VERSION=10:5:8 OL_VERSION=2.4.33 OL_TYPE=Release OL_STRING="OpenLDAP 2.4.33-Release" OL_RELEASE_DATE="2012/10/10" Red Hat Enterprise Linux Server release 6.3 (Santiago) kernel 2.6.32-279.19.1.el6.x86_64 running on a vmware esx host, with a single AMD Opteron(tm) Processor 6134. 4Gig RAM. please let me know if you need any more information. This is my first time using gdb, so I appologize if I missed something critical.

1 0

(ITS#7486) slapo-dynlist.5 enhancement request
by tedcheng＠symas.com 07 Jan '13

07 Jan '13

Full_Name: Ted C. Cheng Version: trunk OS: Linux/Solaris URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (76.174.253.197) This is an enhancement request to the slapo-dynlist.5 man page to call out the fact that searches with filters based on dynamic lists/groups attributes will not produce the desired results: Dynamic lists/groups, as their names suggest, are constructed dynamically when the entries are to be returned. Their attributes and values are not available at the time when searches based on filters are performed. As a result, searches with dynamic lists/groups attributes in filters will not produce the desired results.

1 0

(ITS#7485) libmdb key/data limits not checked/documented.
by h.b.furuseth＠usit.uio.no 06 Jan '13

06 Jan '13

Full_Name: Hallvard B Furuseth Version: mdb.master 057e0686303444d56f29a7bee0536e261fdf0b6a OS: Linux x86_64 URL: Submission from: (NULL) (193.69.163.163) Submitted by: hallvard mdb_put() not check for too big data. mdb_cursor_put() does not check for too big key either. Nor can I see that ldmb.h documents the limits, and there is no way to ask liblmdb what the limits are. This can write an item of size (5000000000 & 0xffffffff) or crash: MDB_val k1 = {3, "foo"}, x = {5000000000, NULL}; mdb_dbi_open(txn, NULL, MDB_CREATE, &dbi); mdb_put(txn, dbi, &k1, &x, MDB_RESERVE); Crash: MDB_val k1 = {3, "foo"}, y = {5, "xyzzy"}, z = {10000, calloc(1,10000)}; mdb_dbi_open(txn, NULL, MDB_CREATE|MDB_DUPSORT, &dbi); mdb_put(txn, dbi, &k1, &y, 0); mdb_put(txn, dbi, &k1, &z, 0); /* segfault */ Crash: MDB_val k2 = {8000, calloc(1, 8000)}, y = {5, "xyzzy"}; mdb_cursor_put(mc, &k2, &y, 0); while this gives a proper EINVAL: mdb_put(txn, dbi, &k2, &y, 0);

1 0

Re: (ITS#7462) olcPcache cannot be modified
by masarati＠aero.polimi.it 06 Jan '13

06 Jan '13

> Full_Name: Tio Teath > Version: 2.4.33 > OS: Debian GNU Linux Wheezy > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (178.172.239.4) > > > I'm getting 'LDAP: error code 80 - cannot delete olcPcache' while I'm > trying to > perform olcPcache modification: > dn: olcOverlay={0}pcache,olcDatabase={1}ldap,cn=config > changetype: modify > replace: olcPcache > olcPcache: hdb 10000 4 500 100 > - > > I have to perform this action in case, I need to extend the number of > pcacheAttrset directives. Although the impossibility to modify olcPcache may be viewed as a bug, I have the impression that a broad class of modifications e.g. to olcPcacheTemplate are likely to invalidate an existing cache. The fix should also consider the opportunity of thrashing the whole cache, unless a clever means to only address entries associated with the olcPcacheTemplate involved in the modification is found. My 2c. p. -- Pierangelo Masarati Associate Professor Dipartimento di Ingegneria Aerospaziale Politecnico di Milano

1 0

Re: (ITS#7484) sssvlv-maxpercon(n) configuration option
by masarati＠aero.polimi.it 06 Jan '13

06 Jan '13

> Full_Name: Liam Gretton > Version: 2.4.33 > OS: SLES 11 SP 2 > URL: > Submission from: (NULL) (143.210.13.77) > > > There's a mismatch between the documentation for the sssvlv-maxpercon > option and > the actual configuration option name. > > The man page documentation for slapo-sssvlv states that the maximum number > of > concurrent paged search requests per connection option is > 'sssvlv-maxperconn'. > For an LDAP-based configuration the option is 'olcSssVlvMaxPerConn' but > for a > slapd.conf based configuration the option is 'sssvlv-maxpercon' (note only > one > 'n', not two). Good catch; should be fixed now in HEAD, please test. Thanks, p. -- Pierangelo Masarati Associate Professor Dipartimento di Ingegneria Aerospaziale Politecnico di Milano

1 0

(ITS#7484) sssvlv-maxpercon(n) configuration option
by liam.gretton＠leicester.ac.uk 04 Jan '13

04 Jan '13

Full_Name: Liam Gretton Version: 2.4.33 OS: SLES 11 SP 2 URL: Submission from: (NULL) (143.210.13.77) There's a mismatch between the documentation for the sssvlv-maxpercon option and the actual configuration option name. The man page documentation for slapo-sssvlv states that the maximum number of concurrent paged search requests per connection option is 'sssvlv-maxperconn'. For an LDAP-based configuration the option is 'olcSssVlvMaxPerConn' but for a slapd.conf based configuration the option is 'sssvlv-maxpercon' (note only one 'n', not two).

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs January 2013