Re: bdb db / cache locking problem (ITS#3201)

[hyc@symas.com]

jongchoi@OpenLDAP.org wrote:
> Full_Name: Jong-Hyuk
> Version: HEAD
> OS: RedHat 9
> URL: ftp://ftp.openldap.org/incoming/
> Submission from: (NULL) (129.34.20.23)

Is there any way for you to repeat this test on a different version of 
Linux?

> I was met by a rather wierd threaing / locking problem while I tested concurrent
> adding to a single slapd.
> 
> Server: single slapd server without any syncrepl setting
> Clients: four add operations each of which is set to add 16K entries
>          + two subsequent search operations initiated after the add was stuck

I wonder if this problem shows up sooner if you have a very small entry 
cache set.

> ACL : group acl
>       two of the four add operations were done by cn=ldap3,o=ibm,c=us
>       two of the four add operations were done by cn=ldap4,o=ibm,c=us
>       both cn=ldap3,o=ibm,c=us and cn=ldap4,o=ibm,c=us are the members of
>       the cn=ldapadmin,o=ibm,c=us group which has write permission to *
> 
> Four adds were stuck after a quite while. Interestingly, if I attach the
> debugger to the slapd process and do "continue", it will continue for a while.

I've seen this happen before; I think gdb is not restoring state 
properly, or is causing some syscall to return with EINTR, or something 
similar. Not really sure if it's a gdb bug or a libpthread bug.

> After some trials it seemed completely stuck. At this point I tried a subtree
> search
> to the base object but it returned "No such object". When I tried a second
> search, now the search was stuck as well. Below is the stack trace obtained at
> this point.

-- 
   -- Howard Chu
   Chief Architect, Symas Corp.       Director, Highland Sun
   http://www.symas.com               http://highlandsun.com/hyc
   Symas: Premier OpenSource Development and Support