Re: (ITS#3571) Syncrepl Provider Crash

[rhafer@suse.de]

On Tuesday 01 March 2005 11:05, Howard Chu wrote:
> I am unable to cause a crash in this scenario. Please send your
> slapd.conf (ACLs and syncrepl config are most relevant) as well as a
> backtrace of the crash.

It seems only to crash if a session log is configured. My provider has
this slapd.conf:
-----------------------------
include         /etc/openldap/schema/core.schema
include         /etc/openldap/schema/cosine.schema
include         /etc/openldap/schema/inetorgperson.schema
include         /etc/openldap/schema/rfc2307bis.schema

pidfile         /var/run/slapd/slapd.pid
argsfile        /var/run/slapd/slapd.args

# Global ACLs
access to dn.base=""
        by * read

access to dn.base="cn=Subschema"
        by * read

access to attr=userPassword,userPKCS12
        by dn="cn=replicator,dc=suse,dc=de" read
        by self write
        by * auth

access to attr=shadowLastChange
        by dn="cn=replicator,dc=suse,dc=de" read
        by self write
        by * read

access to *
        by dn="cn=replicator,dc=suse,dc=de" read
        by * read

loglevel 0
sizelimit 5000
database bdb
sessionlog 543 64
suffix "dc=suse,dc=de"
rootdn "cn=Administrator,dc=suse,dc=de"
rootpw secret
directory /var/lib/ldap
checkpoint 1024 5
cachesize 10000
index objectClass,uidNumber,gidNumber eq
index member,mail eq,pres
index cn,displayname,uid,sn,givenname sub,eq,pres
-----------------------------------

The consumer has the same config, but instead of the sessionlog 
directive I have: 
-------------
syncrepl rid=543
  provider=ldap://192.168.1.3
  type=refreshOnly
  interval=00:00:00:05
  searchbase="dc=suse,dc=de"
  filter="(objectClass=*)"
  scope=sub
  schemachecking=off
  updatedn="cn=Replicator,dc=suse,dc=de"
  bindmethod=simple
  binddn="cn=Replicator,dc=suse,dc=de"
  credentials=secret
-----------------
during the test I start it from the commandline with 
"-d 256 -c rid=543,sid=543"

To crash it I loaded these entries:
-----------------------
dn: dc=suse,dc=de
objectclass: organization
objectclass: dcobject
o: suse
dc: suse

dn: cn=replicator,dc=suse,dc=de
objectclass: person
cn: replicator
sn: replicator
userpassword: secret

dn: ou=people,dc=suse,dc=de
objectclass: organizationalUnit
ou: people

dn: ou=group,dc=suse,dc=de
objectclass: organizationalUnit
ou: group
----------------------

The initial sync Operation worked fine. After that I restarted first 
the provider an than the consumer. The provider than crashes after the
consumer issues the next sync Operation. Here's the backtrace:
----------
(gdb) bt
#0  0x404bbec9 in free () from /lib/tls/libc.so.6
#1  0x40055180 in ber_memfree_x (p=0x41f561d4, ctx=0x41f561d4) at memory.c:153
#2  0x080ae4dc in bdb_do_search (op=0x8198f70, rs=0x41f54870, sop=0x8198f70, ps_e=0x0, ps_type=0) at search.c:1452
#3  0x080aee48 in bdb_search (op=0x41f561cc, rs=0x41f54870) at search.c:384
#4  0x08066de9 in do_search (op=0x8198f70, rs=0x41f54870) at search.c:412
#5  0x08065be5 in connection_operation (ctx=0x41f54900, arg_v=0x8198f70) at connection.c:1086
#6  0x40024034 in ldap_int_thread_pool_wrapper (xpool=0x812f058) at tpool.c:467
#7  0x402ae7f3 in start_thread () from /lib/tls/libpthread.so.0
#8  0x4051262a in clone () from /lib/tls/libc.so.6
---------- 

"bt full" gives this:
----------
(gdb) bt full
#0  0x404bbec9 in free () from /lib/tls/libc.so.6
No symbol table info available.
#1  0x40055180 in ber_memfree_x (p=0x41f561d4, ctx=0x41f561d4) at memory.c:153
No locals.
#2  0x080ae4dc in bdb_do_search (op=0x8198f70, rs=0x41f54870, sop=0x8198f70, ps_e=0x0, ps_type=0) at search.c:1452
        cookie = {bv_len = 52, bv_val = 0x8199c90 "csn=20050301105734Z#000004#00#000000,sid=543,rid=543"}
        bdb = (struct bdb_info *) 0x81862f0
        stoptime = 1109678268
        id = 0
        cursor = 0
        candidates = {0 <repeats 128200 times>, 1078638801, 0, 1078539377, 1079356960, 0, 135207520, 1106589728, 1106579640, 1078548671, 
  1106579692, 135207520, 1, 0, 0, 0, 0, 0, 0, 0, 1078545219, 1106579620, 0 <repeats 45 times>, 544407552, 0, 4294967295, 4294967293, 0, 0, 0, 0, 
  0, 0, 0, 0, 0, 10, 1, 0, 0, 1106578548, 0, 3, 1106589640, 1106579620, 0, 135207497, 26, 4294967295, 0 <repeats 23 times>, 135207521, 
  0 <repeats 238 times>, 1106579552, 26, 1106579868, 1106579552, 1079002468, 26, 1078684390, 2, 1106579868, 26, 0, 0, 1079432288, 1106579868, 
  1106579596, 1078683621, 1079432288, 1106579868, 26, 1079432359, 26, 1106579868, 1079431156, 26, 1106579868, 1106579640, 1078684259, 1079432288, 
  4294967295, 0, 26, 0, 0, 1079431156, 26, 26, 1106588072, 1078542597, 1106579676, 0, 26, 1, 26, 1106579692, 135207492, 1076577184, 1079432288, 0, 
  0, 4222451716, 0, 0, 0, 1106579868, 1106579894, 1106588060, 0 <repeats 16 times>, 4294967295, 0 <repeats 13 times>, 1079428736, 1079432288, 0, 
  0, 0, 0, 0, 1852731235, 1864380477, 540097904, 1212371539, 1953784096, 539639154, 1970473515, 1680631155, 1701068131, 1668489250, 1030058095, 
  1701060658, 1030120818, 1768300592, 1919251564, 1864901181, 1667590754, 1634485108, 708670323, 664105, 0 <repeats 525 times>...}
        scopes = {0 <repeats 65536 times>}
        e = (Entry *) 0x0
        base = {e_id = 1, e_name = {bv_len = 0, bv_val = 0x0}, e_nname = {bv_len = 13, bv_val = 0x81925a8 "dc=suse,dc=de"}, e_attrs = 0x0, 
  e_ocflags = 0, e_bv = {bv_len = 0, bv_val = 0x0}, e_private = 0x8191348}
        e_root = {e_id = 0, e_name = {bv_len = 0, bv_val = 0x0}, e_nname = {bv_len = 0, bv_val = 0x0}, e_attrs = 0x0, e_ocflags = 0, e_bv = {
    bv_len = 0, bv_val = 0x0}, e_private = 0x0}
        matched = Variable "matched" is not available.
----------

> >>You should switch to the 2.3 provider as soon as practical.
> >
> >2.3 it not an option at the momemnt. But is it feasible to backport
> > the the syncprov overlay from 2.3 to 2.2? If yes, I might go that
> > way.
>
> Extremely difficult, I think. And you must #if out all of the 2.2
> provider from back-bdb to insure stability.
>
> >>I will apply your patch,  but realize that no more development
> >> effort is going into the 2.2 provider.
> >
> >Thanks for the clarification.

-- 
Ralf