(ITS#5541) slapd segfaults with specific search on string bdb and hdb backend
by pwadas＠jewish.org.pl
Full_Name: Piotr Wadas
Version: 2.4.7 upto 2.4.9
OS: debian 2.6.18+ kernel
URL:
Submission from: (NULL) (195.95.182.4)
The issue is discussed at
http://www.openldap.org/lists/openldap-software/200805/msg00136.html
List message contains debug information, steps to reproduce,
backtrace logs etc.
Issue appears since 2.4.7 in 2.4 series.
gdb bt quick ref:
#0 0xb7b4842c in free () from /usr/lib/i486-linux-gnu/i686/cmov/libc.so.6
#1 0xb7e901aa in ber_memfree_x (p=0x0, ctx=0x0) at
/home/pwadas/SRC/SLAPD/DEB249/openldap2.3-2.4.9/libraries/liblber/memory.c:152
#2 0xb7e9019c in ber_memfree_x (p=0x0, ctx=0x0) at
/home/pwadas/SRC/SLAPD/DEB249/openldap2.3-2.4.9/libraries/liblber/memory.c:159
#3 0xb7e90235 in ber_bvarray_free_x (a=0xa96e3354, ctx=0x8279658) at
/home/pwadas/SRC/SLAPD/DEB249/openldap2.3-2.4.9/libraries/liblber/memory.c:731
#4 0xb73028e5 in bdb_filter_candidates (op=0x82792e0, locker=34, f=0xa96e325c,
ids=0xa9062008, tmp=0xa8ee2008, stack=0xa90e2008)
at /home/pwadas/SRC/SLAPD/DEB249/openldap2.3-2.4.9/servers/slapd/back-bdb/filterindex.c:803
#5 0xb7303064 in list_candidates (op=0x82792e0, locker=34, flist=0xa96e31ec,
ftype=160, ids=0xa8fe2008, tmp=0xa8ee2008, save=0xa9062008)
at /home/pwadas/SRC/SLAPD/DEB249/openldap2.3-2.4.9/servers/slapd/back-bdb/filterindex.c:581
#6 0xb73017c7 in bdb_filter_candidates (op=0x82792e0, locker=34, f=0xa96e32bc,
ids=0xa8fe2008, tmp=0xa8ee2008, stack=0xa9062008)
at /home/pwadas/SRC/SLAPD/DEB249/openldap2.3-2.4.9/servers/slapd/back-bdb/filterindex.c:198
#7 0xb7303064 in list_candidates (op=0x82792e0, locker=34, flist=0xa9be2ec8,
ftype=161, ids=0xa8f62008, tmp=0xa8ee2008, save=0xa8fe2008)
at /home/pwadas/SRC/SLAPD/DEB249/openldap2.3-2.4.9/servers/slapd/back-bdb/filterindex.c:581
#8 0xb73015ca in bdb_filter_candidates (op=0x82792e0, locker=34, f=0xa9be2ebc,
ids=0xa8f62008, tmp=0xa8ee2008, stack=0xa8fe2008)
at /home/pwadas/SRC/SLAPD/DEB249/openldap2.3-2.4.9/servers/slapd/back-bdb/filterindex.c:204
#9 0xb7303064 in list_candidates (op=0x82792e0, locker=34, flist=0xa9be2eb0,
ftype=160, ids=0xa9b22e1c, tmp=0xa8ee2008, save=0xa8f62008)
at /home/pwadas/SRC/SLAPD/DEB249/openldap2.3-2.4.9/servers/slapd/back-bdb/filterindex.c:581
#10 0xb73017c7 in bdb_filter_candidates (op=0x82792e0, locker=34, f=0xa9be2ed4,
ids=0xa9b22e1c, tmp=0xa8ee2008, stack=0xa8f62008)
at /home/pwadas/SRC/SLAPD/DEB249/openldap2.3-2.4.9/servers/slapd/back-bdb/filterindex.c:198
#11 0xb72fc858 in bdb_search (op=0x82792e0, rs=0xa9be4168) at
/home/pwadas/SRC/SLAPD/DEB249/openldap2.3-2.4.9/servers/slapd/back-bdb/search.c:1109
#12 0x080d76f1 in overlay_op_walk (op=0x82792e0, rs=0xa9be4168, which=op_search,
oi=0x81f63d8, on=0x81f64d8) at
/home/pwadas/SRC/SLAPD/DEB249/openldap2.3-2.4.9/servers/slapd/backover.c:646
#13 0x080d7c5d in over_op_func (op=0x82792e0, rs=0xa9be4168, which=op_search) at
/home/pwadas/SRC/SLAPD/DEB249/openldap2.3-2.4.9/servers/slapd/backover.c:698
#14 0x08077fd3 in fe_op_search (op=0x82792e0, rs=0xa9be4168) at
/home/pwadas/SRC/SLAPD/DEB249/openldap2.3-2.4.9/servers/slapd/search.c:366
#15 0x080787fc in do_search (op=0x82792e0, rs=0xa9be4168) at
/home/pwadas/SRC/SLAPD/DEB249/openldap2.3-2.4.9/servers/slapd/search.c:217
#16 0x08075a9f in connection_operation (ctx=0xa9be4248, arg_v=0x82792e0) at
/home/pwadas/SRC/SLAPD/DEB249/openldap2.3-2.4.9/servers/slapd/connection.c:1084
#17 0x08076196 in connection_read_thread (ctx=0xa9be4248, argv=0x10) at
/home/pwadas/SRC/SLAPD/DEB249/openldap2.3-2.4.9/servers/slapd/connection.c:1211
#18 0xb7ea1d64 in ldap_int_thread_pool_wrapper (xpool=0x81b09b8) at
/home/pwadas/SRC/SLAPD/DEB249/openldap2.3-2.4.9/libraries/libldap_r/tpool.c:663
#19 0xb7c2c4fb in start_thread () from
/usr/lib/i486-linux-gnu/i686/cmov/libpthread.so.0
#20 0xb7bafe8e in clone () from /usr/lib/i486-linux-gnu/i686/cmov/libc.so.6
15 years
Re: (ITS#5540) Normalization assertion in attr.c
by hyc＠symas.com
This is a multi-part message in MIME format.
--------------050600010007030200030106
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
hyc(a)symas.com wrote:
> We'll probably need to discuss on the -devel list what steps to take from here.
>
I wrote the attached patch for the original issue. Unfortunately it asserted
right away:
[Switching to Thread 1090525504 (LWP 23577)]
0x00002b55e738d535 in raise () from /lib64/libc.so.6
(gdb) bt
#0 0x00002b55e738d535 in raise () from /lib64/libc.so.6
#1 0x00002b55e738e990 in abort () from /lib64/libc.so.6
#2 0x00002b55e7386c16 in __assert_fail () from /lib64/libc.so.6
#3 0x00000000004410e5 in attr_valadd (a=0xb866c8, vals=0x41000670, nvals=0x0,
nn=1) at ../../../r24/servers/slapd/attr.c:394
#4 0x0000000000441a06 in attr_merge_one (e=0xb72c08, desc=0x8b3780,
val=0x41000670, nval=0x0)
at ../../../r24/servers/slapd/attr.c:599
#5 0x000000000043ea0f in slap_add_opattrs (op=0x965ec0, text=<value optimized
out>, textbuf=<value optimized out>,
textlen=<value optimized out>, manage_ctxcsn=<value optimized out>) at
../../../r24/servers/slapd/add.c:664
#6 0x00000000004d9c42 in hdb_add (op=0x965ec0, rs=0x41000ca0) at add.c:108
#7 0x000000000043f1a6 in fe_op_add (op=0x965ec0, rs=0x41000ca0) at
../../../r24/servers/slapd/add.c:334
#8 0x000000000043fa12 in do_add (op=0x965ec0, rs=0x41000ca0) at
../../../r24/servers/slapd/add.c:194
#9 0x00000000004383a7 in connection_operation (ctx=0x41000de0,
arg_v=0x965ec0) at ../../../r24/servers/slapd/connection.c:1084
#10 0x00000000004388cf in connection_read_thread (ctx=0x41000de0, argv=0xc) at
../../../r24/servers/slapd/connection.c:1211
#11 0x000000000054b8ca in ldap_int_thread_pool_wrapper (xpool=0x8bf070) at
../../../r24/libraries/libldap_r/tpool.c:663
#12 0x00002b55e655e09e in start_thread () from /lib64/libpthread.so.0
#13 0x00002b55e741e4cd in clone () from /lib64/libc.so.6
#14 0x0000000000000000 in ?? ()
It was adding the createTimestamp attribute, without providing normalized
values. slap_add_opattrs was written before the generalizedTimeNormalize
function was written... I suspect there will be a fair number of cases that
need to be cleaned up. I don't have time at the moment to chase them all down.
Anyone else want to jump in here? If not, we may have to push this back a bit.
Note that this patch will probably require a fair number of databases to be
reloaded.
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
--------------050600010007030200030106
Content-Type: text/plain;
name="dif.txt"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline;
filename="dif.txt"
Index: attr.c
===================================================================
RCS file: /repo/OpenLDAP/pkg/ldap/servers/slapd/attr.c,v
retrieving revision 1.112.2.7
diff -u -r1.112.2.7 attr.c
--- attr.c 11 Feb 2008 23:26:43 -0000 1.112.2.7
+++ attr.c 30 May 2008 09:33:43 -0000
@@ -366,8 +366,39 @@
BerVarray nvals,
int nn )
{
- int i;
BerVarray v2;
+ int i;
+
+ {
+ /* FIXME: if the schema has been edited, and an equality matching rule
+ * has been added or removed from the attribute definition, the database
+ * values may no longer be in sync with our expectations. Currently this
+ * means the DB must be reloaded.
+ */
+ int have_norm, have_nval, new_nval;
+ have_norm = a->a_desc->ad_type->sat_equality->smr_normalize != NULL;
+ have_nval = a->a_nvals != a->a_vals;
+ new_nval = nvals != NULL;
+
+ /* this check is only relevant if any values already exist */
+ if ( a->a_vals != NULL && have_norm != have_nval ) {
+ Debug(LDAP_DEBUG_ANY,
+ "attr_valadd: database inconsistent with schema definition of %s, reload the DB\n",
+ a->a_desc->ad_cname.bv_val, 0, 0 );
+ return LDAP_OTHER;
+ /* no need to compare have_nval with new_nval; by transitivity they will match if
+ * the above check and the following check succeed.
+ */
+ }
+
+ assert( have_norm == new_nval );
+ if ( have_norm != new_nval ) {
+ Debug(LDAP_DEBUG_ANY,
+ "attr_valadd: new values of %s not properly normalized (should never happen!)\n",
+ a->a_desc->ad_cname.bv_val, 0, 0 );
+ return LDAP_OTHER;
+ }
+ }
v2 = (BerVarray) SLAP_REALLOC( (char *) a->a_vals,
(a->a_numvals + nn + 1) * sizeof(struct berval) );
@@ -469,15 +500,6 @@
if ( *a == NULL ) {
*a = attr_alloc( desc );
- } else {
- /*
- * FIXME: if the attribute already exists, the presence
- * of nvals and the value of (*a)->a_nvals must be consistent
- */
- assert( ( nvals == NULL && (*a)->a_nvals == (*a)->a_vals )
- || ( nvals != NULL && (
- ( (*a)->a_vals == NULL && (*a)->a_nvals == NULL )
- || ( (*a)->a_nvals != (*a)->a_vals ) ) ) );
}
if ( vals != NULL ) {
--------------050600010007030200030106--
15 years
Re: (ITS#5540) Normalization assertion in attr.c
by hyc＠symas.com
unix.gurus(a)gmail.com wrote:
> ------=_Part_4694_18767492.1212106829556
> Content-Type: text/plain; charset=UTF-8
> Content-Transfer-Encoding: base64
> Content-Disposition: inline
>
> VGhpcyBiYWNrdHJhY2UgbWF5IHByb3ZpZGUgc29tZSBmdXJ0aGVyIGluZm86CgojMCAgMHgwMDAw
> N2Y3MjU1OGFhMDk1IGluIHJhaXNlICgpIGZyb20gL2xpYi9saWJjLnNvLjYKIzEgIDB4MDAwMDdm
> NzI1NThhYmFmMCBpbiBhYm9ydCAoKSBmcm9tIC9saWIvbGliYy5zby42CiMyICAweDAwMDA3Zjcy
> NTU4YTMyZGYgaW4gX19hc3NlcnRfZmFpbCAoKSBmcm9tIC9saWIvbGliYy5zby42CiMzICAweDAw
Thanks, the original report was sufficient. It surfaces a larger problem,
which we've been ignoring up till now. The correct action would be to iterate
through all the databases and generate the normalized values for all the
affected attributes. There is currently no code to make that happen though.
(Likewise, if deleting matching rules, the normalized values must also be
deleted.) As such, the only way to progress after such a change would be to
dump and reload the DBs (slapcat/slapadd).
We'll probably need to discuss on the -devel list what steps to take from here.
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
15 years
Re: (ITS#5540) Normalization assertion in attr.c
by unix.gurus＠gmail.com
------=_Part_4694_18767492.1212106829556
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: base64
Content-Disposition: inline
VGhpcyBiYWNrdHJhY2UgbWF5IHByb3ZpZGUgc29tZSBmdXJ0aGVyIGluZm86CgojMCAgMHgwMDAw
N2Y3MjU1OGFhMDk1IGluIHJhaXNlICgpIGZyb20gL2xpYi9saWJjLnNvLjYKIzEgIDB4MDAwMDdm
NzI1NThhYmFmMCBpbiBhYm9ydCAoKSBmcm9tIC9saWIvbGliYy5zby42CiMyICAweDAwMDA3Zjcy
NTU4YTMyZGYgaW4gX19hc3NlcnRfZmFpbCAoKSBmcm9tIC9saWIvbGliYy5zby42CiMzICAweDAw
MDAwMDAwMDA0MjZlNDEgaW4gYXR0cl9tZXJnZSAoZT08dmFsdWUgb3B0aW1pemVkIG91dD4sCiAg
ICBkZXNjPTx2YWx1ZSBvcHRpbWl6ZWQgb3V0PiwgdmFscz0weDk4Y2ViMCwgbnZhbHM9MHg5NTNi
ZjApIGF0IGF0dHIuYzo0NzcKIzQgIDB4MDAwMDAwMDAwMDQ2ODFiYyBpbiBtb2RpZnlfYWRkX3Zh
bHVlcyAoZT0weDQwODVmN2IwLCBtb2Q9MHg5OGNlNzAsCiAgICBwZXJtaXNzaXZlPTAsIHRleHQ9
MHg0MDg2MGNkMCwgdGV4dGJ1Zj0weDQwODVmOGIwICIw77+9XDIzMCIsIHRleHRsZW49MjU2KQog
ICAgYXQgbW9kcy5jOjE1NQojNSAgMHgwMDAwMDAwMDAwNDhlNGJmIGluIGhkYl9tb2RpZnlfaW50
ZXJuYWwgKG9wPTB4OTUyNDAwLCB0aWQ9MHg5NTM2NDAsCiAgICBtb2RsaXN0PTB4OThjZTcwLCBl
PTB4NDA4NWY3YjAsIHRleHQ9MHg0MDg2MGNkMCwKICAgIHRleHRidWY9MHg0MDg1ZjhiMCAiMO+/
vVwyMzAiLCB0ZXh0bGVuPTI1NikgYXQgbW9kaWZ5LmM6MTAxCiM2ICAweDAwMDAwMDAwMDA0OGVl
YWQgaW4gaGRiX21vZGlmeSAob3A9MHg5NTI0MDAsIHJzPTB4NDA4NjBjYjApCiAgICBhdCBtb2Rp
ZnkuYzo1NzgKIzcgIDB4MDAwMDAwMDAwMDQzNDZlZCBpbiBmZV9vcF9tb2RpZnkgKG9wPTB4OTUy
NDAwLCBycz0weDQwODYwY2IwKQogICAgYXQgbW9kaWZ5LmM6MzAwCiM4ICAweDAwMDAwMDAwMDA0
MzRmZGEgaW4gZG9fbW9kaWZ5IChvcD0weDk1MjQwMCwgcnM9MHg0MDg2MGNiMCkKICAgIGF0IG1v
ZGlmeS5jOjE3NQojOSAgMHgwMDAwMDAwMDAwNDFlMTkzIGluIGNvbm5lY3Rpb25fb3BlcmF0aW9u
IChjdHg9MHg0MDg2MGUwMCwKICAgIGFyZ192PTx2YWx1ZSBvcHRpbWl6ZWQgb3V0PikgYXQgY29u
bmVjdGlvbi5jOjEwODQKIzEwIDB4MDAwMDAwMDAwMDQxZTk5NSBpbiBjb25uZWN0aW9uX3JlYWRf
dGhyZWFkIChjdHg9MHg0MDg2MGUwMCwKICAgIGFyZ3Y9PHZhbHVlIG9wdGltaXplZCBvdXQ+KSBh
dCBjb25uZWN0aW9uLmM6MTIxMQojMTEgMHgwMDAwMDAwMDAwNTQzMGRhIGluIGxkYXBfaW50X3Ro
cmVhZF9wb29sX3dyYXBwZXIgKHhwb29sPTB4OGQ3YzYwKQogICAgYXQgdHBvb2wuYzo2NjMKIzEy
IDB4MDAwMDdmNzI1NmU2ZDNmNyBpbiBzdGFydF90aHJlYWQgKCkgZnJvbSAvbGliL2xpYnB0aHJl
YWQuc28uMAojMTMgMHgwMDAwN2Y3MjU1OTRmYjJkIGluIGNsb25lICgpIGZyb20gL2xpYi9saWJj
LnNvLjYKIzE0IDB4MDAwMDAwMDAwMDAwMDAwMCBpbiA/PyAoKQo=
------=_Part_4694_18767492.1212106829556
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: base64
Content-Disposition: inline
VGhpcyBiYWNrdHJhY2UgbWF5IHByb3ZpZGUgc29tZSBmdXJ0aGVyIGluZm86PGJyPjxicj4jMCZu
YnNwOyAweDAwMDA3ZjcyNTU4YWEwOTUgaW4gcmFpc2UgKCkgZnJvbSAvbGliL2xpYmMuc28uNjxi
cj4jMSZuYnNwOyAweDAwMDA3ZjcyNTU4YWJhZjAgaW4gYWJvcnQgKCkgZnJvbSAvbGliL2xpYmMu
c28uNjxicj4jMiZuYnNwOyAweDAwMDA3ZjcyNTU4YTMyZGYgaW4gX19hc3NlcnRfZmFpbCAoKSBm
cm9tIC9saWIvbGliYy5zby42PGJyPgojMyZuYnNwOyAweDAwMDAwMDAwMDA0MjZlNDEgaW4gYXR0
cl9tZXJnZSAoZT0mbHQ7dmFsdWUgb3B0aW1pemVkIG91dCZndDssPGJyPiZuYnNwOyZuYnNwOyZu
YnNwOyBkZXNjPSZsdDt2YWx1ZSBvcHRpbWl6ZWQgb3V0Jmd0OywgdmFscz0weDk4Y2ViMCwgbnZh
bHM9MHg5NTNiZjApIGF0IGF0dHIuYzo0Nzc8YnI+IzQmbmJzcDsgMHgwMDAwMDAwMDAwNDY4MWJj
IGluIG1vZGlmeV9hZGRfdmFsdWVzIChlPTB4NDA4NWY3YjAsIG1vZD0weDk4Y2U3MCw8YnI+CiZu
YnNwOyZuYnNwOyZuYnNwOyBwZXJtaXNzaXZlPTAsIHRleHQ9MHg0MDg2MGNkMCwgdGV4dGJ1Zj0w
eDQwODVmOGIwICZxdW90OzDvv71cMjMwJnF1b3Q7LCB0ZXh0bGVuPTI1Nik8YnI+Jm5ic3A7Jm5i
c3A7Jm5ic3A7IGF0IG1vZHMuYzoxNTU8YnI+IzUmbmJzcDsgMHgwMDAwMDAwMDAwNDhlNGJmIGlu
IGhkYl9tb2RpZnlfaW50ZXJuYWwgKG9wPTB4OTUyNDAwLCB0aWQ9MHg5NTM2NDAsPGJyPiZuYnNw
OyZuYnNwOyZuYnNwOyBtb2RsaXN0PTB4OThjZTcwLCBlPTB4NDA4NWY3YjAsIHRleHQ9MHg0MDg2
MGNkMCw8YnI+CiZuYnNwOyZuYnNwOyZuYnNwOyB0ZXh0YnVmPTB4NDA4NWY4YjAgJnF1b3Q7MO+/
vVwyMzAmcXVvdDssIHRleHRsZW49MjU2KSBhdCBtb2RpZnkuYzoxMDE8YnI+IzYmbmJzcDsgMHgw
MDAwMDAwMDAwNDhlZWFkIGluIGhkYl9tb2RpZnkgKG9wPTB4OTUyNDAwLCBycz0weDQwODYwY2Iw
KTxicj4mbmJzcDsmbmJzcDsmbmJzcDsgYXQgbW9kaWZ5LmM6NTc4PGJyPiM3Jm5ic3A7IDB4MDAw
MDAwMDAwMDQzNDZlZCBpbiBmZV9vcF9tb2RpZnkgKG9wPTB4OTUyNDAwLCBycz0weDQwODYwY2Iw
KTxicj4KJm5ic3A7Jm5ic3A7Jm5ic3A7IGF0IG1vZGlmeS5jOjMwMDxicj4jOCZuYnNwOyAweDAw
MDAwMDAwMDA0MzRmZGEgaW4gZG9fbW9kaWZ5IChvcD0weDk1MjQwMCwgcnM9MHg0MDg2MGNiMCk8
YnI+Jm5ic3A7Jm5ic3A7Jm5ic3A7IGF0IG1vZGlmeS5jOjE3NTxicj4jOSZuYnNwOyAweDAwMDAw
MDAwMDA0MWUxOTMgaW4gY29ubmVjdGlvbl9vcGVyYXRpb24gKGN0eD0weDQwODYwZTAwLDxicj4m
bmJzcDsmbmJzcDsmbmJzcDsgYXJnX3Y9Jmx0O3ZhbHVlIG9wdGltaXplZCBvdXQmZ3Q7KSBhdCBj
b25uZWN0aW9uLmM6MTA4NDxicj4KIzEwIDB4MDAwMDAwMDAwMDQxZTk5NSBpbiBjb25uZWN0aW9u
X3JlYWRfdGhyZWFkIChjdHg9MHg0MDg2MGUwMCw8YnI+Jm5ic3A7Jm5ic3A7Jm5ic3A7IGFyZ3Y9
Jmx0O3ZhbHVlIG9wdGltaXplZCBvdXQmZ3Q7KSBhdCBjb25uZWN0aW9uLmM6MTIxMTxicj4jMTEg
MHgwMDAwMDAwMDAwNTQzMGRhIGluIGxkYXBfaW50X3RocmVhZF9wb29sX3dyYXBwZXIgKHhwb29s
PTB4OGQ3YzYwKTxicj4mbmJzcDsmbmJzcDsmbmJzcDsgYXQgdHBvb2wuYzo2NjM8YnI+CiMxMiAw
eDAwMDA3ZjcyNTZlNmQzZjcgaW4gc3RhcnRfdGhyZWFkICgpIGZyb20gL2xpYi9saWJwdGhyZWFk
LnNvLjA8YnI+IzEzIDB4MDAwMDdmNzI1NTk0ZmIyZCBpbiBjbG9uZSAoKSBmcm9tIC9saWIvbGli
Yy5zby42PGJyPiMxNCAweDAwMDAwMDAwMDAwMDAwMDAgaW4gPz8gKCk8YnI+PGJyPgo=
------=_Part_4694_18767492.1212106829556--
15 years
(ITS#5540) Normalization assertion in attr.c
by unix.gurus＠gmail.com
Full_Name: Sean Burford
Version: 2.4.9
OS: Linux x86_64
URL: ftp://ftp.openldap.org/incoming/sean-burford-080529.tar.gz.1
Submission from: (NULL) (76.104.224.20)
Adding equality and substring matching to an existing in use attribute causes
the schema and database contents to mismatch. I added equality and substring
matching to an attribute in my schema. A modification of an attribute value was
propogated a few days later, triggering the assertion and taking my replicas
offline. Each restart replicated the change and triggered the assertion again.
When no matching is specified, new database entries do not have their normalized
value populated in the database. When the matching is added, new database
entries with have their normalized value populated in the database. There is an
assertion in attr.c that checks that attributes from the database have the
expected normalization.
I have attached a script and config to demonstrate the issue
(ftp://ftp.openldap.org/incoming/sean-burford-080529.tar.gz.1)
These files are in the tarball:
slapd.d/ contains a server configuration that is suitable for reproducing the
problem.
script/trigger-assertion.sh performs the ldap operations necessary to trigger
the assertion. The important ones are:
- An attribute is added to the schema without equality matching.
- An entry is added to the directory that uses the new attribute.
- The schema is modified so that the attribute has equality matching.
- Another attribute value is added to the entry, triggering the assertion.
patch/attr-assertion.patch causes the operation to be rejected and logged,
rather than triggering the assertion. It might not be the optimal patch
for this problem, but it prevents the assertion and rejects the operation.
15 years
Re: (ITS#5536) Always use a configured serverID in the syncrepl cookie
by hyc＠symas.com
hyc(a)symas.com wrote:
> Rein Tollevik wrote:
>> My thought was that with serverID=0 reserved for the true single-master
>> configuration and tool mode we could safely ignore a contextCSN with 0 in
>> the sid field when serverID>0 is in use (to get rid of values already
>> in the databases). At startup syncprov could update its own contextCSN
>> value with newer entryCSN values that has 0 in the sid field. Ref
>> ITS#5537. Slapadd'ing on more than one master without synchronizing
>> them between each run could still be a potential problem though..
>
> That's not a viable solution.
>
> The syncprov startup check is primarily to recover from unclean shutdowns.
> I.e., it's looking for newer CSNs that may have been saved before syncprov got
> a chance to write its final checkpoint. Ignoring values, or giving special
> treatment to sid 0 isn't going to work for that purpose.
Hm, have to think about this some more.
Generally, slapadd/slapindex require the directory to be offline. As such, if
you have any running servers, you should be adding entries using ldapadd, not
slapadd. So I'm going to ignore this case for now.
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
15 years
Re: (ITS#5536) Always use a configured serverID in the syncrepl cookie
by hyc＠symas.com
Rein Tollevik wrote:
> Yes, this is a sort of multi-master configuration, but not what I think
> of when I hear it (and read the doc). The doc. could be clearer that
> different serverID values are always required when there are multiple
> master servers, even if the configuration ensures that there will never be
> more than one master for any backend.
We should update the manpages with this ITS as well then.
> Btw, if I have understood things correctly there cannot safely be more
> then one subordinate db (in a glued environment) that replicates from any
> single master,
If the master has multiple DBs, and they're being separately replicated into a
single DB, that would be a problem (regardless of glue on the consumer). If
the DBs are glued on the master, then there's no problem.
> My thought was that with serverID=0 reserved for the true single-master
> configuration and tool mode we could safely ignore a contextCSN with 0 in
> the sid field when serverID>0 is in use (to get rid of values already
> in the databases). At startup syncprov could update its own contextCSN
> value with newer entryCSN values that has 0 in the sid field. Ref
> ITS#5537. Slapadd'ing on more than one master without synchronizing
> them between each run could still be a potential problem though..
That's not a viable solution.
The syncprov startup check is primarily to recover from unclean shutdowns.
I.e., it's looking for newer CSNs that may have been saved before syncprov got
a chance to write its final checkpoint. Ignoring values, or giving special
treatment to sid 0 isn't going to work for that purpose.
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
15 years
Re: (ITS#5536) Always use a configured serverID in the syncrepl cookie
by hyc＠symas.com
rein(a)OpenLDAP.org wrote:
> On Wed, 28 May 2008, Howard Chu wrote:
>
>> rein(a)OpenLDAP.org wrote:
>
>>> Syncrepl includes the serverID in the syncCookie in multi-master mode only,
>>> but
>>> there are other configuration that would benefit from it as well.
>
> The commited fix for this bug causes test033-glue-syncrepl to fail. The
> serverID is not set by the config, which makes syncprov_qresp() skip the
> delete when it fins that the consumer presented a cookie with its own sid
> value.
OK then I guess you're right and we need the default to be -1.
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
15 years
Re: (ITS#5536) Always use a configured serverID in the syncrepl cookie
by rein＠OpenLDAP.org
On Wed, 28 May 2008, Howard Chu wrote:
> rein(a)OpenLDAP.org wrote:
>> Syncrepl includes the serverID in the syncCookie in multi-master mode only,
>> but
>> there are other configuration that would benefit from it as well.
The commited fix for this bug causes test033-glue-syncrepl to fail. The
serverID is not set by the config, which makes syncprov_qresp() skip the
delete when it fins that the consumer presented a cookie with its own sid
value.
Rein
15 years
