(ITS#3954) slapd stability problems with bdb backend

[adrian.gschwend@bfh.ch]

Full_Name: Adrian Gschwend
Version: 2.2.27
OS: FreeBSD 5.3
URL: ftp://ftp.openldap.org/incoming/adrian-gschwend-050819.gdb-backtrace.log
Submission from: (NULL) (147.87.65.205)


slapd consumes 100% cpu and never quits after add or delete operations. I
described the issues detailed under the following URLs:

http://article.gmane.org/gmane.network.openldap.general/30543
http://article.gmane.org/gmane.network.openldap.general/30574
http://article.gmane.org/gmane.network.openldap.general/30604
http://article.gmane.org/gmane.network.openldap.general/30609
http://article.gmane.org/gmane.network.openldap.general/30624
http://article.gmane.org/gmane.network.openldap.general/30633
http://article.gmane.org/gmane.network.openldap.general/30644

Summary: Our DB contains about 4000 entries (bdb backend), it gets updated via a
meta database which connects to OpenLDAP via the perl-interface. During updates
it often happens that the slapd process hangs, which means it consumes 100% CPU
and does not quit anymore. No more queries can be done. On FreeBSD we have to
kill the process hard (-9) and run db_recover -c afterwards to get a clean DB
before we can restart it.

The problem also occurs on Debian 3.1 with slapd 2.2.23 (all precompiled debian
packages). We redid the database several times (slapcat/slapadd) with various
DB_CONFIG options, see the URLs above for details.

Note that the same add operation that fails works perfectly well once we
restarted slapd so the add itself must be ok. Also it was much harder to
reproduce the problem with a debug version of slapd (CFLAGS+= -g). But it still
does lock, see the gdb thread backtrace attached to this bug

We couldn't do a dbstat -CA yet during a lock, we will provide that as soon as
it locks up again.

If necessary we could provide an ssh (root) login to a test machine with gdb and
a test-environment. If you need that please contact me by email.