https://www.nbcs.rutgers.edu/~richton/test008deadlock-RE24_20080414.txt Could just be ITS#5391 proving that it still exists. BDB 4.2.52. testrun and the process are still just sitting there (from 10 days ago, should've looked at the machine more often...)

Current function is ldap_pvt_thread_mutex_lock 296 return ERRVAL( pthread_mutex_lock( mutex ) ); t@12 (l@12) stopped in __lwp_park at 0xff1654b0 0xff1654b0: __lwp_park+0x0010: ta %icc,0x00000008 (dbx) print *mutex *mutex = { __pthread_mutex_flags = { __pthread_mutex_flag1 = 4U __pthread_mutex_flag2 = '\0' __pthread_mutex_ceiling = '\0' __pthread_mutex_type = 0 __pthread_mutex_magic = 19800U } __pthread_mutex_lock = { __pthread_mutex_lock64 = { __pthread_mutex_pad = "" } __pthread_mutex_lock32 = { __pthread_ownerpid = 0 __pthread_lockword = 4278190081U } __pthread_mutex_owner64 = 4278190081ULL }

On Mon, 28 Apr 2008, Howard Chu wrote: > Your stack trace shows that this is due to the latest patch to > back-bdb/cache.c, rev 1.175. If you revert that patch this deadlock will go > away. But that's probably not the ultimate solution. OK. This isn't hitting me in production (to my knowledge at least), only as "please test RE24." So I'll wait for the next "please test RE24" and give it another go...I'm sleeping until then. Thanks.

On Tue, 29 Apr 2008, Howard Chu wrote:

> Go ahead and test the patch in HEAD, thanks. The HEAD patch causes a deadlock when bdb_cache_delete_cleanup() is called by bdb_cache_lru_purge(), as the latter already has the entryinfo locked.