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

[rhafer@suse.de]

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. 

With the suggested fix I get this, if I abort the ldapsearch during that time, 
as the op->o_abandon is set in cleanup handler:

==26949== Invalid free() / delete / delete[]
==26949==    at 0x4C226DB: free 
(in /usr/lib64/valgrind/amd64-linux/vgpreload_memcheck.so)
==26949==    by 0x508A819: ber_memfree_x (memory.c:152)
==26949==    by 0x4AC9D7: slap_sl_free (sl_malloc.c:455)
==26949==    by 0x44797D: filter_free_x (filter.c:526)
==26949==    by 0x4478C9: filter_free_x (filter.c:509)
==26949==    by 0x4479D9: filter_free (filter.c:538)
==26949==    by 0x5A7794: free_query (pcache.c:1126)
==26949==    by 0x5AF9B0: pcache_db_close (pcache.c:3282)
==26949==    by 0x4C2F87: over_db_close (backover.c:192)
==26949==    by 0x452658: backend_shutdown (backend.c:365)
==26949==    by 0x47C03E: slap_shutdown (init.c:253)
==26949==    by 0x422D65: main (main.c:943)
==26949==  Address 0xA533A68 is 0 bytes inside a block of size 24 free'd
==26949==    at 0x4C226DB: free 
(in /usr/lib64/valgrind/amd64-linux/vgpreload_memcheck.so)
==26949==    by 0x508A819: ber_memfree_x (memory.c:152)
==26949==    by 0x4AC9D7: slap_sl_free (sl_malloc.c:455)
==26949==    by 0x44797D: filter_free_x (filter.c:526)
==26949==    by 0x4478C9: filter_free_x (filter.c:509)
==26949==    by 0x4479D9: filter_free (filter.c:538)
==26949==    by 0x5A9F7F: pcache_op_cleanup (pcache.c:1886)
==26949==    by 0x456A69: slap_cleanup_play (result.c:344)
==26949==    by 0x4571DC: send_ldap_response (result.c:526)
==26949==    by 0x457935: slap_send_ldap_result (result.c:632)
==26949==    by 0x4F7AE4: ldap_back_search (search.c:528)
==26949==    by 0x4C3FD0: overlay_op_walk (backover.c:652)

-- 
Ralf