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

Refint overlay hangs with ldbm (ITS#3108)



Full_Name: Luca Scamoni
Version: HEAD
OS: Linux RH 7.3
URL: ftp://ftp.openldap.org/incoming/
Submission from: (NULL) (193.227.212.131)


test023-refint hangs with ldbm backend during the modrdn.
Looking through the execution of the code ldbm_back_modrdn invokes and
ldap_pvt_thread_rdwr_rlock(&li->li_giant_rwlock) and after the modrdn ops
(delete old dn, add new dn) calls ldap_back_search that tries to invoke
ldap_pvt_thread_rdwr_rlock(&li->li_giant_rwlock) too.
At this point slapd enters ldap_pvt_thread_cond_wait and waits forever (or at
least I have not seen the end of the loop for at least 20 minutes).
Since slapd passes the same test with both bdb and hdb, I believe this can be
related to the use of the gigantic lock done by ldbm. Maybe releasing the lock
before invoking ldbm_back_search or checking if the lock is already in place and
the call has been done by ldbm_back_modrdn could help but the code is still a
bit obscure to me.
Anyway this is the bt after entering the loop:

Program received signal SIGINT, Interrupt.
0x420293d5 in sigsuspend () from /lib/i686/libc.so.6
(gdb) bt
#0  0x420293d5 in sigsuspend () from /lib/i686/libc.so.6
#1  0x40311609 in __pthread_wait_for_restart_signal () from
/lib/i686/libpthread.so.0
#2  0x4030deec in pthread_cond_wait () from /lib/i686/libpthread.so.0
#3  0x4002153c in ldap_pvt_thread_cond_wait (cond=0x81c17f8, mutex=0x81c17e0) at
thr_posix.c:261
#4  0x4001f496 in ldap_pvt_thread_rdwr_rlock (rwlock=0x81f72f0) at rdwr.c:157
#5  0x080e694c in ldbm_back_search (op=0x40b19f4c, rs=0x40b19f0c) at
search.c:59
#6  0x080bec39 in over_op_func (op=0x40b19f4c, rs=0x40b19f0c, which=op_search)
at backover.c:215
#7  0x080becde in over_op_search (op=0x40b19f4c, rs=0x40b19f0c) at
backover.c:240
#8  0x40349642 in refint_response (op=0x8240cb8, rs=0x40b1a87c) at refint.c:560
#9  0x080bea9f in over_back_response (op=0x8240cb8, rs=0x40b1a87c) at
backover.c:141
#10 0x0807aa26 in send_ldap_response (op=0x8240cb8, rs=0x40b1a87c) at
result.c:308
#11 0x0807b81c in slap_send_ldap_result (op=0x8240cb8, rs=0x40b1a87c) at
result.c:634
#12 0x080e618f in ldbm_back_modrdn (op=0x8240cb8, rs=0x40b1a87c) at
modrdn.c:666
#13 0x080bec39 in over_op_func (op=0x8240cb8, rs=0x40b1a87c, which=op_modrdn) at
backover.c:215
#14 0x080bed44 in over_op_modrdn (op=0x8240cb8, rs=0x40b1a87c) at
backover.c:258
#15 0x0808641f in do_modrdn (op=0x8240cb8, rs=0x40b1a87c) at modrdn.c:379
#16 0x0806b2d4 in connection_operation (ctx=0x40b1a90c, arg_v=0x8240cb8) at
connection.c:1027
#17 0x4002092e in ldap_int_thread_pool_wrapper (xpool=0x81bb870) at tpool.c:467
#18 0x4030efaf in pthread_start_thread () from /lib/i686/libpthread.so.0
#19 0x4030f09f in pthread_start_thread_event () from /lib/i686/libpthread.so.0

The easy way is to disable the test for ldbm ...