[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
RE: slapd hangs at 100% cpu in sched_yield (ITS#2030)
We will fix the code to check the result from LOCK_ID. In the meantime,
you should configure more BDB locks in your database environment to avoid
running out of them.
-- Howard Chu
Chief Architect, Symas Corp. Director, Highland Sun
http://www.symas.com http://highlandsun.com/hyc
Symas: Premier OpenSource Development and Support
> -----Original Message-----
> From: owner-openldap-bugs@OpenLDAP.org
> [mailto:owner-openldap-bugs@OpenLDAP.org]On Behalf Of
> I had a look at the current code for OPENLDAP_REL_ENG_2_1 via web
> cvs, and it does not look like the cause of the problem has been
> fixed. The problem is that the bdb backend may or may not
> successfully get a lock when you ask for for one. On ~line 74 of
> servers/slapd/back-bdb/search.c the ldap server runs LOCK_ID(),
> but does not check the return value, and continues, assuming it
> has a valid lock. This lock is passed from function to function
> until we hit ~line 849-921 in cache.c, where
>
> state != CACHE_ENTRY_READY
>
> and
>
> rc = bdb_cache_entry_db_lock ( env, locker, ep, rw, 0, lock );
> fails because the lock is invalid, so we log, yield and try again.
> This is an endless loop unless we can guarantee that we have a
> valid bdb lock in the first place.