[Date Prev][Date Next]
Re: bdb db / cache locking problem (ITS#3201)
> Full_Name: Jong-Hyuk
> Version: HEAD
> OS: RedHat 9
> URL: ftp://ftp.openldap.org/incoming/
> Submission from: (NULL) (18.104.22.168)
Is there any way for you to repeat this test on a different version of
> 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
> 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
> 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
Symas: Premier OpenSource Development and Support