rein@tollevik.no wrote:

On Wed, 9 Apr 2008, h.b.furuseth@usit.uio.no wrote:

...

Does this help? From my fiddling with ITS#5340 (REP_ENTRY_MODIFIABLE). I do not understand syncprov's handling of REP_ENTRY_MUSTRELEASE though. (For one thing it seems to assume that REP_ENTRY_MUSTRELEASE is set if and only if rs.sr_entry->e_private != NULL. Which is possibly true with back-bdb but seems a shaky assumption in general.)

Almost, except that it triggers an abort.. Using be_entry_release_r() was not correct, as it ended up calling entry_free(). It works if I changes it to use overlay_entry_release_ov() instead, as in the alternative patch at the end.

I have put a test script that shows this deadlock on:

ftp://ftp.openldap.org/incoming/test053-syncprov-glue

It deadlocks without this patch, it and the rest of the test suite succeed with it :-) I haven't tested it in production though..

This last patch is now committed to HEAD. I am ignoring the first patch; it is unsafe because it unlocks the si_csn_rwlock too soon. (si_ctxcsn is being used directly in the modify request and must be held consistent until that completes.)