[Date Prev][Date Next] [Chronological] [Thread] [Top]

test020-proxycache crashing with back-ldbm (ITS#2960)



Full_Name: Ralf Haferkamp
Version: 2.2.5
OS: SUSE Linux
URL: ftp://ftp.openldap.org/incoming/
Submission from: (NULL) (212.95.106.45)


When executing test020-proxycache the following happens:
openldap-2.2.5/tests# ./run -b ldbm test020-proxycache 
Cleaning up test run directory leftover from previous run.
Running ./scripts/test020-proxycache...
Starting master slapd on TCP/IP port 9011...
Using ldapsearch to check that master slapd is running...
Using ldapadd to populate the master directory...
Starting proxy cache on TCP/IP port 9012...
Using ldapsearch to check that proxy slapd is running...
Waiting 5 seconds for slapd to start...
Making queries on the proxy cache...
Query 1: filter:(sn=Jon) attrs: all
Query 2: filter:(|(cn=*Jon*)(sn=Jon*)) attrs:cn sn title uid
./scripts/test020-proxycache: line 110: 24808 Killed                  $SLAPD -f
$CONF2 -h $URI2 -d $LVL >$LOG2 2>&1
ldapsearch failed (255)!
./scripts/test020-proxycache: line 114: kill: (24808) - No such process

I was able to produce the following backtrace:

#0  0x4037dd41 in kill () from /lib/libc.so.6
#1  0x4030b541 in pthread_kill () from /lib/libpthread.so.0
#2  0x4030b57b in raise () from /lib/libpthread.so.0
#3  0x4037dad4 in raise () from /lib/libc.so.6
#4  0x4037ef7c in abort () from /lib/libc.so.6
#5  0x40376e1a in __assert_fail () from /lib/libc.so.6
#6  0x40020687 in ldap_pvt_thread_rdwr_wlock (rwlock=0x8117e28) at rdwr.c:242
#7  0x080b7535 in ldbm_open (env=0x816c370, name=0xbf5fce04 "dn2id.dbb", rw=73,
mode=384, dbcachesize=409600) at ldbm.c:346
#8  0x080ce3d4 in ldbm_cache_open (be=0x81602f0, name=0x810342d "dn2id",
suffix=0x8103428 ".dbb", flags=73) at dbcache.c:163
#9  0x080cffda in dn2id (be=0x81602f0, dn=0xbf5fe20c, idp=0xbf5fe01c) at
dn2id.c:157
#10 0x080ca0ba in ldbm_back_add (op=0xbf5fe1e4, rs=0xbf5fe064) at add.c:95
#11 0x080d71b4 in merge_entry (op=0xbf5fe1e4, e=0x81729c8,
query_uuid=0xbf5fe3d4) at pcache.c:173
#12 0x080d919c in cache_entries (op=0x8171de8, rs=0xbf5ff8c4,
query_uuid=0xbf5fe3d4) at pcache.c:1157
#13 0x080d9431 in proxy_cache_response (op=0x8171de8, rs=0xbf5ff8c4) at
pcache.c:1223
#14 0x08070b64 in send_ldap_response (op=0x8171de8, rs=0xbf5ff8c4) at
result.c:308
#15 0x08071649 in slap_send_ldap_result (op=0x8171de8, rs=0xbf5ff8c4) at
result.c:621
#16 0x404a8a0a in ldap_back_search (op=0x8171de8, rs=0xbf5ff8c4) at
search.c:324
#17 0x080a9c45 in over_op_func (op=0x8171de8, rs=0xbf5ff8c4, which=op_search) at
backover.c:184
#18 0x080a9ccc in over_op_search (op=0x8171de8, rs=0xbf5ff8c4) at
backover.c:209
#19 0x080662c4 in do_search (op=0x8171de8, rs=0xbf5ff8c4) at search.c:400
#20 0x08063d7a in connection_operation (ctx=0xbf5ff954, arg_v=0x8171de8) at
connection.c:1038
#21 0x4002164d in ldap_int_thread_pool_wrapper (xpool=0x8125050) at tpool.c:467
#22 0x403081b1 in pthread_start_thread () from /lib/libpthread.so.0
#23 0x40431eaa in clone () from /lib/libc.so.6

The following patch seems to fix my problem:

--- servers/slapd/overlays/pcache.c     2004/02/06 13:01:35     1.1
+++ servers/slapd/overlays/pcache.c     2004/02/06 13:01:48
@@ -1656,6 +1656,12 @@
                                fname, lineno, argv[1] );
                        return( 1 );
                }
+               if ( cm->db.bd_info->bi_open ){
+                       if ( cm->db.bd_info->bi_open( cm->db.bd_info ) ) {     

+                               return( 1 );
+                       }
+               }
+
                if ( cm->db.bd_info->bi_db_init( &cm->db ) ) return( 1 );
 
                cm->max_entries = atoi( argv[2] );

Is this the correct fix?