core dump with syncrepl in 2.3.20 and 2.3.21

[Marc MacIntyre <marcmac@zimbra.com>]

Running a bdb backend and sync replication, I was getting a core dump on the consumer whenever there was a modify or delete on the producer (though NOT on add).  I traced it to the lack of a "searchbase" entry in the consumer's slapd.conf - adding searchbase="" seems to have fixed the problem.  (Happened with db 2.2.52.4)


gdb sez:

#0  0x002139fa in strcmp () from /lib/tls/libc.so.6
#1  0x08068266 in select_backend (dn=0xb7349f6c, manageDSAit=0, noSubs=0) at backend.c:611
#2  0x08069b44 in fe_aux_operational (op=0xb7349f50, rs=0xb7349a40) at backend.c:1703
#3  0x0806933f in backend_operational (op=0xb7349f50, rs=0xb7349a40) at backend.c:1725
#4  0x0806bbb8 in slap_send_search_entry (op=0xb7349f50, rs=0xb7349a40) at result.c:704
#5  0x080b4301 in bdb_search (op=0xb7349f50, rs=0xb7349a40) at search.c:878
#6  0x0809f978 in syncrepl_entry (si=0x8289f20, op=0xb7349f50, entry=0x0, modlist=0xb7349b84, syncstate=3, syncUUID=0xb7349c18, 
   syncCookie_req=0xb7349da0, syncCSN=0xb7349dc0) at syncrepl.c:1711
#7  0x080a0fcc in do_syncrep2 (op=0xb7349f50, si=0x8289f20) at syncrepl.c:727
#8  0x080a2c68 in do_syncrepl (ctx=0xb734a2b0, arg=0x8289cf0) at syncrepl.c:1085
#9  0x08110177 in ldap_int_thread_pool_wrapper (xpool=0x8268410) at tpool.c:479
#10 0x003f8371 in start_thread (arg=0xb734abb0) at pthread_create.c:261
#11 0x002729be in clone () from /lib/tls/libc.so.6

Looks like line 611 of backend.c (in 2.3.21) is the culprit:
            if ( strcmp( be->be_nsuffix[j].bv_val,
                &dn->bv_val[dnlen-len] ) == 0 )


Can anyone reproduce this?  Seems like the kind of thing the config parser should check for - core dumps are so unfriendly.

-- 
marcmac@zimbra.com