(ITS#5121) IDL cache issue

[ando@sys-net.it]

Full_Name: Pierangelo Masarati
Version: HEAD
OS: Linux RH AS 4.5
URL: ftp://ftp.openldap.org/incoming/
Submission from: (NULL) (193.203.230.29)
Submitted by: ando


I ran into an issue running HEAD code.  I got the following core dump:

#0  0x08103390 in bdb_idl_cache_put (bdb=0xa3e1110, db=0x3550c800, 
    key=0x35f988a0, ids=0x34afc008, rc=0)
    at ../../../../servers/slapd/back-bdb/idl.c:354
#1  0x08104318 in bdb_idl_fetch_key (be=0x36058ec0, db=0x3550c800, locker=0, 
    key=0x35f988a0, ids=0x34afc008, saved_cursor=0x0, get_flag=0)
    at ../../../../servers/slapd/back-bdb/idl.c:665
#2  0x081084a1 in bdb_key_read (be=0x36058ec0, db=0x3550c800, locker=100, 
    k=0x352ff2d4, ids=0x34afc008, saved_cursor=0x0, get_flag=0)
    at ../../../../servers/slapd/back-bdb/key.c:50
#3  0x081013ab in bdb_filter_candidates (op=0xa46b3f8, locker=100, 
    f=0x352ff2c4, ids=0x34bfc008, tmp=0x34afc008, stack=0x34c7c008)
    at ../../../../servers/slapd/back-bdb/filterindex.c:770
#4  0x081020e9 in list_candidates (op=0xa46b3f8, locker=100, flist=0x35f98dd0, 
    ftype=161, ids=0x34b7c008, tmp=0x34afc008, save=0x34bfc008)
    at ../../../../servers/slapd/back-bdb/filterindex.c:580
#5  0x08100458 in bdb_filter_candidates (op=0xa46b3f8, locker=100, 
    f=0x35f98dc0, ids=0x34b7c008, tmp=0x34afc008, stack=0x34bfc008)
    at ../../../../servers/slapd/back-bdb/filterindex.c:204
#6  0x081020e9 in list_candidates (op=0xa46b3f8, locker=100, flist=0x35f98db0, 
    ftype=160, ids=0x35fd8e30, tmp=0x34afc008, save=0x34b7c008)
    at ../../../../servers/slapd/back-bdb/filterindex.c:580
#7  0x08100458 in bdb_filter_candidates (op=0xa46b3f8, locker=100, 
    f=0x35f98de0, ids=0x35fd8e30, tmp=0x34afc008, stack=0x34b7c008)
#8  0x081109b5 in bdb_search (op=0xa46b3f8, rs=0x3605a0f0)
    at ../../../../servers/slapd/back-bdb/search.c:1111
#9  0x080ee601 in overlay_op_walk (op=0xa46b3f8, rs=0x3605a0f0, 
    which=op_search, oi=0xa3e21e0, on=0xa3e2740)
    at ../../../servers/slapd/backover.c:652
#10 0x080ee72f in over_op_func (op=0xa46b3f8, rs=0x3605a0f0, which=op_bind)
    at ../../../servers/slapd/backover.c:704
#11 0x0808a051 in fe_op_search (op=0xa46b3f8, rs=0x3605a0f0)
    at ../../../servers/slapd/search.c:368
#12 0x080894f7 in do_search (op=0xa46b3f8, rs=0x3605a0f0)
    at ../../../servers/slapd/search.c:217
#13 0x080875c3 in connection_operation (ctx=0x3605a210, arg_v=0xa46b3f8)
    at ../../../servers/slapd/connection.c:1145
#14 0x0808801b in connection_read_thread (ctx=0x3605a210, argv=0x14)
    at ../../../servers/slapd/connection.c:1271
#15 0x081afa01 in ldap_int_thread_pool_wrapper (xpool=0xa304fa8)
    at ../../../libraries/libldap_r/tpool.c:614
#16 0x008ad3cc in start_thread () from /lib/tls/libpthread.so.0
#17 0x00736c3e in clone () from /lib/tls/libc.so.6

where 

(gdb) p bdb->bi_idl_cache_max_size 
$27 = 30000
(gdb) p bdb->bi_idl_lru_head 
$28 = (bdb_idl_cache_entry_t *) 0x3550cd28
(gdb) p bdb->bi_idl_lru_tail 
$29 = (bdb_idl_cache_entry_t *) 0x3550cd28
(gdb) p bdb->bi_idl_lru_tail[0]
$30 = {kstr = {bv_len = 3, bv_val = 0x3550ebd8 "top"}, idl = 0x6, 
  db = 0x3550ebe8, idl_flags = 0, idl_lru_prev = 0x0, idl_lru_next = 0x0}

The latter seems quite odd: obviously the head/tail is corrupted, but either
bdb->bi_idl_lru_tail and bdb->bi_idl_lru_head should be null, or their
idl_lru_prev and idl_lru_next members should be valid.

There seems to be something odd in how entries are cleaned up from the cache: in
fact, if the whole LRU is destroyed, then eprev would remain dangling, but this
should never occur.

p.