--On October 2, 2007 8:26:10 PM +0000 hyc@symas.com wrote:

Based on the (unreliable) pstack output it appears that all of the threads are waiting for the same mutex. This of course shouldn't be possible since one of those threads must already own it. We really need to have gdb access here to inspect the state of the mutex and see which thread is the owner, then figure out why it's trying to lock it again. In OpenLDAP 2.3 this pretty much means that some operation locked the mutex and somehow completed without unlocking it, i.e. completed without going thru the accesslog response callback.

This has nothing to do with BDB so db_stat isn't relevant here. It's about the accesslog overlay and any other overlays that may be manipulating the callback stack, so your slapd.conf is more relevant here.

I mainly wanted the db_stat information to make sure there were no held writelocks, which it is clear is not the case.

I find I do have another pstack output from this same type of hang with another client at:

http://bugzilla.zimbra.com/attachment.cgi?id=5896

I'm working on getting the slapd.conf in question, but I believe the only overlays affecting the BDB backend are syncprov and accesslog.

--Quanah

--

Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration