Re: back-bdb deadlocks?

["Jong-Hyuk" <jongchoi@OpenLDAP.org>]

I could also produce a deadlock case in both a Redhat 7.3 uniprocessor and a
Redhat 9 SMP box,
but I could get the full stack trace only in the Redhat 7.3 box. Weird gdb
behavior in Redhat 9...

Two files were uploaded to the incoming ftp directory:
ftp://ftp.openldap.org/incoming/test008-backtrace.txt for stack trace
ftp://ftp.openldap.org/incoming/test008-db_stat.txt for db_stat -CA result

I tracked down the problem further with gdb, and found the following:

thread 13: modrdn, locker=8000002b, waiting for an entryinfo mutex for
ei->bei_id=4 (ou=alumni association, ou=people, dc=example, dc=com) while
holding a read lock of page 1 and a db lock for the entry corresponding to
the entryinfo (ei->bei_id=4)

thread 5: add, locker=80000028, waiting for a db lock for the ei->bei_id=4
entry, while holding  an entryinfo mutex for ei->bei_id=4

Why should the entryinfo lock be unlocked at the end of bdb_cache_find_id()
?
As exemplified in the thread 13, it should not be unlocked at least when it
is needed again.

As I suggested some time back, the entryinfo mutex need be replaced with the
bdb lock as we did in the original bdb entry cache design.

- Jong-Hyuk