Bug#568711: slapd: replication : consumer crashes due to assertion failure when replication starts the first time

2010-07-13 Thread Matthijs Mohlmann
Hi Adrien,

Sorry for the late response. The OpenLDAP team doesn't have many
active developers. I try to catch up with the open bug reports.

Can you try to reproduce this bug with the current version in unstable ?
Version in unstable is: 2.4.23-1.

Regards,

Matthijs Möhlmann





--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org



Bug#568711: slapd: replication : consumer crashes due to assertion failure when replication starts the first time

2010-02-06 Thread Adrien Guinet
Package: slapd
Version: 2.4.11-1+lenny1
Severity: important

Hi everyone,

When using ldap with syncrepl and a particular configuration, a consumer 
crashes the first time the replication starts on an empty database, with 
accesslog and logold enabled on the consumer server.

Here are relevant part of the provider's configuration :

--

serverID 000

databasehdb 

# The base of your directory in database #1
suffix  dc=domain,dc=com

# Where the database file are physically stored for database #1
directory   /var/lib/ldap/domain
na
# Log configuration
overlay accesslog
logdb cn=accesslog
logops writes
logold (objectclass=*)
logpurge 4+00:00 1+00:00

# Replication
overlay syncprov
syncprov-checkpoint 100 10

--

And relevant part of the consumer's configuration :



databasehdb 

# The base of your directory in database #1
suffix  dc=domain,dc=com

# Where the database file are physically stored for database #1
directory   /var/lib/ldap/domain

syncrepl rid=000
provider=ldaps://ldap-master./
type=refreshAndPersist
retry=5 5 300 +
searchbase=ou=x,dc=domain,dc=com
attrs=*,+
bindmethod=simple
binddn=cn=xxx,dc=nautile,dc=nc
credentials=xx

# Log configuration
overlay accesslog
logdb cn=accesslog
logops writes
logold (objectclass=*)
logpurge 4+00:00 1+00:00

-

At the beggining, a slapcat on the consumer gives :

dn: dc=domain,dc=com
objectClass: top
objectClass: dcObject
objectClass: organization
o: domain
dc: domain
structuralObjectClass: organization

dn: ou=,dc=domain,dc=com
objectClass: organizationalUnit
objectClass: top
ou: 

With the above configurations and the consumer initialized with this LDIF, 
slapd (on the consumer) crashes :

# gdb --args /usr/sbin/slapd -g openldap -u openldap -d sync
[...]
slapd: /tmp/buildd/openldap-2.4.11/servers/slapd/schema_check.c:88: 
entry_schema_check: Assertion `a-a_vals[0].bv_val != ((void *)0)' failed.

Program received signal SIGABRT, Aborted.
[Switching to Thread 0xa284bb90 (LWP 8270)]
0xb7c00556 in raise () from /lib/libc.so.6
(gdb) bt
#0  0xb7c00556 in raise () from /lib/libc.so.6
#1  0xb7c01d78 in abort () from /lib/libc.so.6
#2  0xb7bf9590 in __assert_fail () from /lib/libc.so.6
#3  0x080ac2ec in entry_schema_check (op=0xa284a040, e=0x8c7a15c, oldattrs=0x0, 
manage=0, add=1, text=0xa284a12c,
textbuf=0xa2849e58 x\236\204�\005\227�...@\234�\b\224�÷2, textlen=256) at 
/tmp/buildd/openldap-2.4.11/servers/slapd/schema_check.c:88
#4  0xb782d253 in hdb_add (op=0xa284a040, rs=0xa284a118) at add.c:97
#5  0xb781c96d in accesslog_response (op=0xa284ada0, rs=0xa284a898) at 
/tmp/buildd/openldap-2.4.11/servers/slapd/overlays/accesslog.c:1650
#6  0x080db50f in over_back_response (op=0xa284ada0, rs=0xa284a898) at 
/tmp/buildd/openldap-2.4.11/servers/slapd/backover.c:235
#7  0x08086596 in slap_response_play (op=0xa284ada0, rs=0xa284a898) at 
/tmp/buildd/openldap-2.4.11/servers/slapd/result.c:307
#8  0x08089448 in send_ldap_response (op=0xa284ada0, rs=0x6) at 
/tmp/buildd/openldap-2.4.11/servers/slapd/result.c:381
#9  0x0808a266 in slap_send_ldap_result (op=0xa284ada0, rs=0xa284a898) at 
/tmp/buildd/openldap-2.4.11/servers/slapd/result.c:642
#10 0xb7831f76 in hdb_modify (op=0xa284ada0, rs=0xa284a898) at modify.c:697
#11 0x080db73c in overlay_op_walk (op=0xa284ada0, rs=0xa284a898, 
which=op_modify, oi=0x8b8, on=0x8c20e20)
at /tmp/buildd/openldap-2.4.11/servers/slapd/backover.c:646
#12 0x080dc205 in over_op_func (op=0xa284ada0, rs=0xa284a898, which=op_modify) 
at /tmp/buildd/openldap-2.4.11/servers/slapd/backover.c:698
#13 0x080d0df2 in syncrepl_updateCookie (si=0x8c208d8, op=0xa284ada0, 
pdn=value optimized out, syncCookie=0xa284ac50)
at /tmp/buildd/openldap-2.4.11/servers/slapd/syncrepl.c:2803
#14 0x080d7092 in do_syncrep2 (op=0xa284ada0, si=0x8c208d8) at 
/tmp/buildd/openldap-2.4.11/servers/slapd/syncrepl.c:1119
#15 0x080d88a2 in do_syncrepl (ctx=0xa284b248, arg=0x8c20c78) at 
/tmp/buildd/openldap-2.4.11/servers/slapd/syncrepl.c:1293
#16 0x0807703b in connection_read_thread (ctx=0xa284b248, argv=0x15) at 
/tmp/buildd/openldap-2.4.11/servers/slapd/connection.c:1213
#17 0xb7f9afb8 in ?? () from /usr/lib/libldap_r-2.4.so.2
#18 0xa284b248 in ?? ()
#19 0x0015 in ?? ()
#20 0x in ?? ()
(gdb) frame 3
#3  0x080ac2ec in entry_schema_check (op=0xa284a040, e=0x8c7a15c, oldattrs=0x0, 
manage=0, add=1, text=0xa284a12c,
textbuf=0xa2849e58 x\236\204�\005\227�...@\234�\b\224�÷2, textlen=256) at 
/tmp/buildd/openldap-2.4.11/servers/slapd/schema_check.c:88
88  assert( a-a_vals[0].bv_val != NULL );
(gdb) p a-a_desc-ad_cname-bv_val
$1 = 0x8c19368 reqOld
(gdb) p a-a_desc-ad_type-sat_cname-bv_val
$2 = 0x8c19368 reqOld

I think that slapd crashes because it doesn't find an old value for the 
accesslog.