rhafer@suse.de wrote:

On Wednesday 29 August 2007 18:10, Howard Chu wrote:

...

Ralf Haferkamp wrote:

...

On Wednesday 29 August 2007 17:36, Howard Chu wrote:

...

rhafer@suse.de wrote:

...

Full_Name: Ralf Haferkamp Version: RE23, HEAD

Valgrind gives me the log pasted below when I abort an ldapsearch command (CTRL-C) that is running against a back-ldap database that uses the pcache overlay.

Makes sense. We need to use the cleanup handler and free the saved query info if op->o_abandon is set. Do you want to code this up?

I am still working on that, but checking for op->o_abandon doesn't seem to be enough. E.g. if I abort the ldapsearch while slapd is updating its cache (all entries have been returned, but the final LDAP_RESULT to the client is still missing) a filter_free in the cleanup handler will invalidly free the filter.

We somehow need to make sure that the query is only free'd if nothing has been written to the cache database.

I don't understand the problem. Nothing can get written to the DB until the LDAP_RESULT has been sent. I.e., rs->sr_result == REP_RESULT.

Hm, but the ldapsearch command only returns after the complete query result has been written to the cache (at least here it behaves so), which can take quite a while. So it seems to me that the client has not received the LDAP_RESULT.

Ah yes, that's correct. I misspoke - the DB is written when the cache has received an LDAP_RESULT from the remote server. The client gets this result when the cache has finished writing. We could move the DB write to a separate cleanup handler instead of running it in the response handler, which would free up the client sooner.