[Date Prev][Date Next]
Re: (ITS#5112) memory leak in pcache overlay
> On Wednesday 29 August 2007 18:10, Howard Chu wrote:
>> Ralf Haferkamp wrote:
>>> On Wednesday 29 August 2007 17:36, Howard Chu wrote:
>>>> firstname.lastname@example.org 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
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.
-- Howard Chu
Chief Architect, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/