[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: (ITS#5112) memory leak in pcache overlay

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 

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/