Re: (ITS#7487) memberof & mirrormode with delta-syncrepl crashing when using dynamic configuration
by afrunning＠gmail.com
> > 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
10 years, 10 months
Re: (ITS#7487) memberof & mirrormode with delta-syncrepl crashing when using dynamic configuration
by masarati＠aero.polimi.it
> 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
10 years, 10 months
(ITS#7487) memberof & mirrormode with delta-syncrepl crashing when using dynamic configuration
by afrunning＠gmail.com
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.
10 years, 10 months
(ITS#7486) slapo-dynlist.5 enhancement request
by tedcheng＠symas.com
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.
10 years, 10 months
(ITS#7485) libmdb key/data limits not checked/documented.
by h.b.furuseth＠usit.uio.no
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);
10 years, 10 months
Re: (ITS#7462) olcPcache cannot be modified
by masarati＠aero.polimi.it
> 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
10 years, 10 months
Re: (ITS#7484) sssvlv-maxpercon(n) configuration option
by masarati＠aero.polimi.it
> 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
10 years, 10 months
(ITS#7484) sssvlv-maxpercon(n) configuration option
by liam.gretton＠leicester.ac.uk
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).
10 years, 11 months
