Hah. thr_debug found it (at least I presume it's the same bug) after 70 iterations over test008.

Compiled with CPPFLAGS='-DLDAP_THREAD_DEBUG -DLDAP_REL_ENG' CFLAGS='-O0 -g' run with export LDAP_THREAD_DEBUG=nocount

backtrace and testrun directory: http://folk.uio.no/hbf/test008bug-071204.tbz

slapd.1.log ends with:

====> bdb_cache_delete( 146 ) thr_debug.c:1024: ldap_pvt_thread_mutex_unlock error: !THREAD_MUTEX_OWNER( mutex )

The mutex owner is ldap_debug_thread_none, i.e. the mutex is not locked.

It's cache.c:874:bdb_cache_entryinfo_unlock( *eip ); in bdb_cache_find_id(). #3 0x00000000004e1df9 in bdb_cache_find_id (op=0x1ebb46a0, tid=0x0, id=4, eip=0x45809ad0, flag=1, locker=38, lock=0x45809b20) at cache.c:874

I had to patch thr_posix.c a bit to detect Linux NPTL threads:

diff -u -2 -r1.50 thr_posix.c --- thr_posix.c 25 Oct 2007 04:42:40 -0000 1.50 +++ thr_posix.c 4 Dec 2007 23:06:29 -0000 @@ -45,6 +45,6 @@ #ifdef LDAP_THREAD_DEBUG # if defined LDAP_INT_THREAD_MUTEXATTR /* May be defined in CPPFLAGS */ -# elif defined HAVE_PTHREAD_KILL_OTHER_THREADS_NP - /* LinuxThreads hack */ +# elif 1 || defined HAVE_PTHREAD_KILL_OTHER_THREADS_NP + /* LinuxThreads and NPTL hack */ # define LDAP_INT_THREAD_MUTEXATTR PTHREAD_MUTEX_ERRORCHECK_NP # else

(BTW, I tried to put it in ftp://ftp.openldap.org/incoming/Hallvard-Furuseth-071203.tbz but got disk full.)