Mostly done with the easily spotted cases. Hopefully HEAD's code
stayed valid through my commits. Need to think some more for the
rest. The decisions with greater chance of breaking things
remain, like ITS#6763.
* hyc, please have a look at slapd/bconfig.c 1.419. If I have
gotten things wrong, that one summarizes my mistakes nicely:-)
* If slap_send_ldap_result() or send_ldap_disconnect() see an entry
with REP_ENTRY_MUST<RELEASE/BEFREED> and REP_SEARCH/SEARCHREF,
should release/free the entry? That helps code which sends error
without freeing sr_entry. It breaks if the entry comes from
another Operation, or if the caller reuses a Search SlapReply for
a non-Search and trusts rs->sr_un.sru_search to stay untouched.
* Is the code getting clean enough that slap_send_search_entry's
cleanup code can flush the entry independently of whether
op->o_tag == LDAP_REQ_SEARCH?
* slapi/slapi_pblock.c 1.81:
/* TODO: Should REP_ENTRY_MODIFIABLE be set? */
I've no idea, and I've more pressing things to look at...
Notes on the updates:
* "Reset some SlapReply flags & data" commits vs "avoid SlapReply
commits: The combination might be redundant/overcautious, but tries
to catch problems from remaining unclean code from both ends.
* result.c, freeing as well as releasing entries as soon as possible:
More readable, and since the entry isn't needed: The sooner we get
rid of it, the less chance for an entry leak.
* commits "Use rs_*() to manage SlapReply entries."
Switching to rs_flush_entry():
- result.c:slap_send_search_entry(), overlays/pcache.c,
These did not clear the MODIFIABLE flag along with MUSTBEFREED.
Switching to use rs_ensure_entry_modifiable():
- syncprov_operational(), overlay collect:
noop change (except operational should not update the entry)
- overlay valsort:
It needlessly required REP_ENTRY_MUSTBEFREED as well as MODIFIABLE.
But the entry can also be MODIFIABLE and e.g. on the stack.
- contrib overlays cloak, usn:
Had entry leaks.