[Date Prev][Date Next] [Chronological] [Thread] [Top]
(ITS#6970)

To: openldap-its@OpenLDAP.org
Subject: (ITS#6970)
From: breuil@craig.fr
Date: Fri, 14 Jun 2013 14:29:54 GMT
Auto-submitted: auto-generated (OpenLDAP-ITS)
Hi,

i'm also experiencing slapd deadlocks/lockups when using memberOf &
autogroup, w/ 2.4.31. Both modules/overlays seem to step on each other's
toes when updating an entry. Not 100% sure if it's the same issue as the
OP was experiencing though.

My config is the following :
- i have a ou=people branch with inetOrgPerson objects, each one having
an organization attr.
- i have a ou=groups branch with groupOfNames objects, each populated by
autogroup by using a labeledURI doing a filter on the organization attr
(among other conditions) of the inetOrgPerson objects.
- and finally, i have memberOf overlay that updates the inetOrgPerson
objects with the final groups membership.

When modifiying the organization attribute of an inetOrgPerson (and thus
triggering an update of groups & membership at the same time), slapd
deadlocks. It happens both if the inetOrgPerson gets out of a group, or
is now a new member of a group (only showing the tail of the debug log,
but i can provide it all):

51bb233b oc_check_required entry (uid=person,ou=people,dc=myorg,dc=fr),
objectClass "inetOrgPerson"
51bb233b oc_check_allowed type "cn"
51bb233b oc_check_allowed type "structuralObjectClass"
51bb233b oc_check_allowed type "entryUUID"
51bb233b oc_check_allowed type "creatorsName"
51bb233b oc_check_allowed type "createTimestamp"
51bb233b oc_check_allowed type "objectClass"
51bb233b oc_check_allowed type "uid"
51bb233b oc_check_allowed type "givenName"
51bb233b oc_check_allowed type "sn"
51bb233b oc_check_allowed type "userPassword"
51bb233b oc_check_allowed type "title"
51bb233b oc_check_allowed type "employeeType"
51bb233b oc_check_allowed type "roomNumber"
51bb233b oc_check_allowed type "mail"
51bb233b oc_check_allowed type "telephoneNumber"
51bb233b oc_check_allowed type "memberOf"
51bb233b oc_check_allowed type "o"
51bb233b oc_check_allowed type "entryCSN"
51bb233b oc_check_allowed type "modifyTimestamp"
51bb233b oc_check_allowed type "modifiersName"
51bb233b => entry_encode(0x00000006):
51bb233b <= entry_encode(0x00000006):

At that point, there are three active threads in gdb:

^C
Program received signal SIGINT, Interrupt.
0x00007ffff5c67e75 in pthread_join () from
/lib/x86_64-linux-gnu/libpthread.so.0
(gdb) info thread
  Id   Target Id         Frame
  3    Thread 0x7ffff0f53700 (LWP 16492) 0x00007ffff5c6b2d4 in
pthread_cond_wait@@GLIBC_2.3.2 () from /lib/x86_64-linux-gnu/libpthread.so.0
  2    Thread 0x7ffff1754700 (LWP 16491) 0x00007ffff59b10d3 in
epoll_wait () from /lib/x86_64-linux-gnu/libc.so.6
* 1    Thread 0x7ffff7ebb700 (LWP 16490) 0x00007ffff5c67e75 in
pthread_join () from /lib/x86_64-linux-gnu/libpthread.so.0

thread 1 & 2 seem okay...

(gdb) bt
#0  0x00007ffff5c67e75 in pthread_join () from
/lib/x86_64-linux-gnu/libpthread.so.0
#1  0x00007ffff7f0fca9 in slapd_daemon () at
../../../../servers/slapd/daemon.c:2930
#2  0x00007ffff7ef687c in main (argc=<optimized out>, argv=<optimized
out>) at ../../../../servers/slapd/main.c:1012
(gdb) thread 2
[Switching to thread 2 (Thread 0x7ffff1754700 (LWP 16491))]
#0  0x00007ffff59b10d3 in epoll_wait () from /lib/x86_64-linux-gnu/libc.so.6
(gdb) bt
#0  0x00007ffff59b10d3 in epoll_wait () from /lib/x86_64-linux-gnu/libc.so.6
#1  0x00007ffff7f0d721 in slapd_daemon_task (ptr=<optimized out>) at
../../../../servers/slapd/daemon.c:2540
#2  0x00007ffff5c66b50 in start_thread () from
/lib/x86_64-linux-gnu/libpthread.so.0
#3  0x00007ffff59b0a7d in clone () from /lib/x86_64-linux-gnu/libc.so.6
#4  0x0000000000000000 in ?? ()

but thread 3 seems to lock with himself, maybe trying to modify the same
entry via autogroup & memberof at the same time ?

(gdb) thread 3
[Switching to thread 3 (Thread 0x7ffff0f53700 (LWP 16492))]
#0  0x00007ffff5c6b2d4 in pthread_cond_wait@@GLIBC_2.3.2 () from
/lib/x86_64-linux-gnu/libpthread.so.0
(gdb) bt
#0  0x00007ffff5c6b2d4 in pthread_cond_wait@@GLIBC_2.3.2 () from
/lib/x86_64-linux-gnu/libpthread.so.0
#1  0x00007ffff74fe9ab in __db_pthread_mutex_lock () from
/usr/lib/x86_64-linux-gnu/libdb-5.1.so
#2  0x00007ffff758d5ca in __lock_get_internal () from
/usr/lib/x86_64-linux-gnu/libdb-5.1.so
#3  0x00007ffff758e9b3 in __lock_vec () from
/usr/lib/x86_64-linux-gnu/libdb-5.1.so
#4  0x00007ffff758ef18 in __lock_vec_pp () from
/usr/lib/x86_64-linux-gnu/libdb-5.1.so
#5  0x00007ffff32234a0 in hdb_cache_entry_db_relock
(bdb=bdb@entry=0x7ffff83226a0, txn=<optimized out>, ei=0x7ffff82db7b0,
rw=rw@entry=1, tryOnly=tryOnly@entry=0, lock=lock@entry=0x7ffff0f4fc70)
at cache.c:198
#6  0x00007ffff3223eb3 in hdb_cache_modify
(bdb=bdb@entry=0x7ffff83226a0, e=e@entry=0x7ffff85045c8,
newAttrs=0x7ffff8517f48, txn=<optimized out>,
lock=lock@entry=0x7ffff0f4fc70) at cache.c:1231
#7  0x00007ffff321255a in hdb_modify (op=0x7ffff0f503b0,
rs=0x7ffff0f501d0) at modify.c:711
#8  0x00007ffff7f801c6 in overlay_op_walk (op=op@entry=0x7ffff0f503b0,
rs=0x7ffff0f501d0, which=op_modify, oi=0x7ffff8325c90, on=0x0) at
../../../../servers/slapd/backover.c:671
#9  0x00007ffff7f8031b in over_op_func (op=0x7ffff0f503b0, rs=<optimized
out>, which=<optimized out>) at ../../../../servers/slapd/backover.c:723
#10 0x00007ffff29dabb9 in memberof_value_modify
(op=op@entry=0x7ffff0f50d40, ndn=<optimized out>, ad=0x7ffff82d3420,
old_dn=old_dn@entry=0x0, old_ndn=old_ndn@entry=0x0,
new_dn=new_dn@entry=0x7ffff0f50d68, new_ndn=new_ndn@entry=0x7ffff0f50d78)
    at ../../../../../servers/slapd/overlays/memberof.c:411
#11 0x00007ffff29db548 in memberof_res_modify (op=0x7ffff0f50d40,
rs=<optimized out>) at ../../../../../servers/slapd/overlays/memberof.c:1457
#12 0x00007ffff7f227d6 in slap_response_play
(op=op@entry=0x7ffff0f50d40, rs=rs@entry=0x7ffff0f50cd0) at
../../../../servers/slapd/result.c:507
#13 0x00007ffff7f22d6e in send_ldap_response
(op=op@entry=0x7ffff0f50d40, rs=rs@entry=0x7ffff0f50cd0) at
../../../../servers/slapd/result.c:582
#14 0x00007ffff7f23816 in slap_send_ldap_result (op=0x7ffff0f50d40,
rs=0x7ffff0f50cd0) at ../../../../servers/slapd/result.c:860
#15 0x00007ffff3211e67 in hdb_modify (op=0x7ffff0f50d40,
rs=0x7ffff0f50cd0) at modify.c:749
#16 0x00007ffff7f801c6 in overlay_op_walk (op=op@entry=0x7ffff0f50d40,
rs=0x7ffff0f50cd0, which=op_modify, oi=0x7ffff8325c90, on=0x0) at
../../../../servers/slapd/backover.c:671
#17 0x00007ffff7f8031b in over_op_func (op=0x7ffff0f50d40, rs=<optimized
out>, which=<optimized out>) at ../../../../servers/slapd/backover.c:723
#18 0x00007ffff2be449f in autogroup_add_member_to_group
(op=op@entry=0x7ffff82d9ab0, dn=dn@entry=0x7ffff82d9ad8,
ndn=ndn@entry=0x7ffff82d9ae8, age=age@entry=0x7ffff82f8ed0) at
autogroup.c:146
#19 0x00007ffff2be6aa2 in autogroup_response (op=0x7ffff82d9ab0,
rs=<optimized out>) at autogroup.c:1302
#20 0x00007ffff7f7f598 in over_back_response (op=0x7ffff82d9ab0,
rs=0x7ffff0f52a50) at ../../../../servers/slapd/backover.c:237
#21 0x00007ffff7f227d6 in slap_response_play
(op=op@entry=0x7ffff82d9ab0, rs=rs@entry=0x7ffff0f52a50) at
../../../../servers/slapd/result.c:507
#22 0x00007ffff7f22d6e in send_ldap_response
(op=op@entry=0x7ffff82d9ab0, rs=rs@entry=0x7ffff0f52a50) at
../../../../servers/slapd/result.c:582
#23 0x00007ffff7f23816 in slap_send_ldap_result (op=0x7ffff82d9ab0,
rs=0x7ffff0f52a50) at ../../../../servers/slapd/result.c:860
#24 0x00007ffff3211e67 in hdb_modify (op=0x7ffff82d9ab0,
rs=0x7ffff0f52a50) at modify.c:749
#25 0x00007ffff7f801c6 in overlay_op_walk (op=op@entry=0x7ffff82d9ab0,
rs=0x7ffff0f52a50, which=op_modify, oi=0x7ffff8325c90, on=0x0) at
../../../../servers/slapd/backover.c:671
#26 0x00007ffff7f8031b in over_op_func (op=0x7ffff82d9ab0, rs=<optimized
out>, which=<optimized out>) at ../../../../servers/slapd/backover.c:723
#27 0x00007ffff7f2a569 in fe_op_modify (op=0x7ffff82d9ab0,
rs=0x7ffff0f52a50) at ../../../../servers/slapd/modify.c:303
#28 0x00007ffff7f2c42d in do_modify (op=0x7ffff82d9ab0,
rs=0x7ffff0f52a50) at ../../../../servers/slapd/modify.c:177
#29 0x00007ffff7f12961 in connection_operation
(ctx=ctx@entry=0x7ffff0f52ba0, arg_v=arg_v@entry=0x7ffff82d9ab0) at
../../../../servers/slapd/connection.c:1150
#30 0x00007ffff7f12c84 in connection_read_thread (ctx=0x7ffff0f52ba0,
argv=<optimized out>) at ../../../../servers/slapd/connection.c:1286
#31 0x00007ffff7a73ff3 in ?? () from
/usr/lib/x86_64-linux-gnu/libldap_r-2.4.so.2
#32 0x00007ffff5c66b50 in start_thread () from
/lib/x86_64-linux-gnu/libpthread.so.0
#33 0x00007ffff59b0a7d in clone () from /lib/x86_64-linux-gnu/libc.so.6
#34 0x0000000000000000 in ?? ()


If i examine the three hdb_modify() calls in that trace, the one in #7
and the one in #24 try to work on the same entry (dummy value is the
modified inetOrgPerson), and the one in #15 modifies the groupOfNames
from which the inetOrgPerson is a new member.

I suppose it shouldn't happen...

-- 
Landry Breuil
Mouton a 5 pattes du CRAIG
Prev by Date: Re: (ITS#7580) autogroup module blowing slapd when using a labeledURI without attribute specification ?
Next by Date: (ITS#7625) ppolicy doesn't support changing olcPasswordHash without restart
Index(es):
- Chronological
- Thread