back-bdb replog crash (ITS#2895)

[hyc@OpenLDAP.org]

Full_Name: Howard Chu
Version: HEAD
OS: Linux
URL: 
Submission from: (NULL) (24.126.120.178)
Submitted by: hyc


I encountered this crash by adding replogfile/replica directives to the
slapd.conf used by test008, and removing the sleep(1) call in the slapd-addel
test program.

In this case, an entry is added and then immediately deleted in a tight loop.
When a replogfile is defined, the replog() function tries to print out the
contents of the newly added entry, but that entry has already been freed by the
following delete call.

This is one consequence of back-bdb's entry cache using BDB locks - the locks
all disappear when the transaction commits. I think this problem exists in 2.1
and 2.2 as well.

I also saw another crash under the same test setup, but I'm not sure why it
occurs - a search crashes while accessing an entry that was a target of the
slapd-modrdn test. In this case, the search is accessing the old/freed
attributes of the target entry. This shouldn't happen since modrdn maintains a
write lock on the entry until it is finished swapping the old and new values,
and search obtains a read lock on the entry. I think this problem is particular
to the new entry cache in HEAD/2.2 only, and not in 2.1. It is difficult to
reproduce this crash consistently; perhaps there's something flaky in BDB 4.2's
lock manager as this is the first time I've seen anything like this failure.

To fix the add/delete problem, we could revert to using our own locks for the
back-bdb entry cache, instead of using BDB locks, so that the lock can persist
past the end of the transaction. This has potential deadlock issues that I'm not
keen to revisit. Another possibility is for back-bdb to make a copy of the entry
that actually gets inserted into the cache, so that the original entry from the
Add request remains intact.