#246 Modifying ruv entry deadlocks server
Closed: Fixed None Opened 8 years ago by rmeggins.


Another data point - attempting to use ldapmodify to fix the ruv deadlocks the
server e.g.
ldapmodify -x -h localhost -p 1389 -D "cn=directory manager" -w password <<EOF
dn: nsuniqueid=ffffffff-ffffffff-ffffffff-ffffffff,dc=example,dc=com
changetype: modify
delete: nsds50ruv
nsds50ruv: {replica 3 ldap://localhost.localdomain:3389} 3e67cd37000000030000

This causes a deadlock here:
#0  0x000000305280dfe4 in __lll_lock_wait () from /lib64/libpthread.so.0
#1  0x000000305280934e in _L_lock_995 () from /lib64/libpthread.so.0
#2  0x00000030528092b6 in pthread_mutex_lock () from /lib64/libpthread.so.0
#3  0x0000003061023bd9 in PR_Lock (lock=0x901d20)
    at ../../../mozilla/nsprpub/pr/src/pthreads/ptsynch.c:206
#4  0x00007f24b9f512a3 in cache_lock_entry (cache=0x96d308, e=0xae0ed0)
    at ../ds.git/ldap/servers/slapd/back-ldbm/cache.c:1444
#5  0x00007f24b9f664fa in find_entry_internal_uniqueid (pb=0xae69f0,
    be=0x96b010, uniqueid=0xae1f00 "ffffffff-ffffffff-ffffffff-ffffffff",
    lock=1, txn=0x0) at ../ds.git/ldap/servers/slapd/back-ldbm/findentry.c:228
#6  0x00007f24b9f66723 in find_entry_internal (pb=0xae69f0, be=0x96b010,
    addr=0x7f24afcef900, lock=1, txn=0x0, really_internal=1)
    at ../ds.git/ldap/servers/slapd/back-ldbm/findentry.c:275
#7  0x00007f24b9f668d8 in find_entry2modify_only (pb=0xae69f0, be=0x96b010,
    addr=0x7f24afcef900, txn=0x0)
    at ../ds.git/ldap/servers/slapd/back-ldbm/findentry.c:337
#8  0x00007f24b9fb217f in ldbm_txn_ruv_modify_context (pb=0xae69f0,
    mc=0x7f24afcef980) at ../ds.git/ldap/servers/slapd/back-ldbm/misc.c:431
#9  0x00007f24b9f9e741 in ldbm_back_modify (pb=0xae69f0)
    at ../ds.git/ldap/servers/slapd/back-ldbm/ldbm_modify.c:390
#10 0x00007f24be0bd2e4 in op_shared_modify (pb=0xae69f0, pw_change=0,
    old_pw=0x0) at ../ds.git/ldap/servers/slapd/modify.c:888
#11 0x00007f24be0bc06d in do_modify (pb=0xae69f0)
    at ../ds.git/ldap/servers/slapd/modify.c:384
#12 0x0000000000413f17 in connection_dispatch_operation (conn=0x7f24b06fd410,
    op=0xac9200, pb=0xae69f0) at ../ds.git/ldap/servers/slapd/connection.c:583
#13 0x00000000004158e4 in connection_threadmain ()
    at ../ds.git/ldap/servers/slapd/connection.c:2328
#14 0x0000003061029633 in _pt_root (arg=0xadbf70)
    at ../../../mozilla/nsprpub/pr/src/pthreads/ptthread.c:187
#15 0x00000030528077e1 in start_thread () from /lib64/libpthread.so.0
#16 0x0000003051ce577d in clone () from /lib64/libc.so.6

The entry has already been locked for the modify, and
ldbm_txn_ruv_modify_context attempts to lock it again.

This is due to the fix for Bug 543633

commit changeset:37a2a4d/389-ds-base
Author: Rich Megginson rmeggins@redhat.com
Date: Fri Sep 9 12:48:31 2011 -0600
Reviewed by: nkinder (Thanks!)
Branch: master
Fix Description: Disallow modifying the RUV entry directly. Server returns
OPERATIONS_ERROR. Error log says to use CLEANRUV task instead.
Platforms tested: RHEL6 x86_64
Flag Day: no
Doc impact: no

Added initial screened field value.

Metadata Update from @nkinder:
- Issue assigned to nhosoi
- Issue set to the milestone: 1.2.10

3 years ago

Login to comment on this ticket.