[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.