h.b.furuseth@usit.uio.no wrote:

Though the original case is now fixed in master, this simpler test case crashes in the same way. It forces REP_ENTRY_MUSTRELEASE to be set, since the current fix is to restore OpenLDAP 2.4.23's behavior of not flushing the entry otherwise. But 2.4.23 also crashes with this:

$ cat<<EOF>its6981.conf include servers/slapd/schema/core.schema database bdb suffix o=test rootdn o=test directory its6981/a

overlay pcache pcache bdb 10000 1 50 100 pcacheAttrset 0 * + pcacheTemplate (objectClass=) 0 60 pcacheTemplate (o=) 0 60 pcache-directory its6981/b EOF

$ mkdir -p its6981/a its6981/b; rm -f its6981/?/* $ servers/slapd/slapd -Tadd -f its6981.conf<<EOF dn: o=test objectclass: organization o: test EOF

$ servers/slapd/slapd -f its6981.conf -d0 -h ldap://localhost:3890/& $ clients/tools/ldapsearch -LLLxh localhost:3890 -b o=test '(o=test)'

It doesn't seem to make sense for code to assume sr_entry persists past the point it'd be flushed if REP_ENTRY_MUSTRELEASE is set. That's why this change snuck into ITS#6758 (SlapyReply usage). Probably we should put the flush back someday - after checking better than I did last time.

OK, the flush is back to where it was in 2.4.26. pcache.c has been reorganized again, taking ITS#5112 into account. REP_RESULT handling is still in pcache_op_cleanup (as #5112 requires) but REP_SEARCH is back in op_response (where it used to be, before the #5112 patch).