[EMAIL PROTECTED] wrote: > On Wed, 9 Apr 2008, [EMAIL PROTECTED] 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.) -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/
