h.b.furuseth@usit.uio.no wrote:

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

Need to see the full stack trace. Obviously "this should never happen" ...