Re: svn commit: r678323 - /apr/apr-util/trunk/memcache/apr_memcache.c

[Peter Poeml]

On Mon, Jul 21, 2008 at 06:46:48PM +1000, Bojan Smojver wrote:
> On Mon, 2008-07-21 at 07:34 +0200, Mladen Turk wrote:
> 
> > Although IMHO it makes reslist API behave like it should
> 
> Agreed.
> 
> > it might
> > break some of the existing usages where users were doing nasty tricks
> > with reslist to make the things not to leak memory.
> 
> Yeah, that's what I was worried about as well. Let's see what others on
> the list think about it.

Hi, (as mentioned in another thread some minutes ago) I am using
apr_memcache quite a lot. I am experiencing a memleak.  I am facing the
following puzzling situation. 

I have been apr_memcache.c from trunk since over a year, and it worked
fine for me, with the 1.2.x. branch.

In June, I upgraded to apr/apu 1.3.0 and httpd-2.2.9, and had a big
memleak since then. I had to downgrade before I could investigate it,
but I revisited it today, and here is what I found:

My Apache leaks memory when I call apr_memcache_getp(), and I can
reproduce this with

 * apr/apu 1.3.0
 * apr/apu 1.3.2
 * apr/apu pre-1.3.3 (current svn branch)

I can NOT reproduce it with

 * 1.2.12 and the apr_memcache.c version which has been in trunk a long
   time (I picked it up from r577947 in September last year)

I saw the commit r678323 from apr-util trunk and I just tried it out on
1.3.2. Indeed, it fixes the memleak for me.
(the one that adds an apr_pool_destroy() call to the end of
mc_conn_destruct()

What's puzzling to me is 
 1) that the apr_memcache.c file in the released
    apr-util 1.3.2 tarball is more or less identical to the one I have
    been using since nearly a year -- still I didn't have the memleak
    with the latter! (Identical except for some type changes and
    renames)
 2) another module I'm using is mod_ip_count. It also calls
    apr_memcache_getp() but I'm not seeing a memleak in this case. (At
    least I am not noticing it... but that is machine with much less
    traffic)
I use mod_memcache in all cases to configure the memcache context and
acquire it during request processing.


Anyway, there must be something that I overlook, or there may be other
circumstances that influence the behaviour (1.2/1.3 difference in pool
handling??). The patch from trunk fixes the issue for me although I
can't say why. I can only say for sure that I have a large memleak with
the current 1.3.x code.

Bojan, I'll test the other patch you posted in a bit.

Thanks,
Peter
-- 
"WARNING: This bug is visible to non-employees. Please be respectful!"
 
SUSE LINUX Products GmbH
Research & Development

pgpeRS5Hh8uKO.pgp
Description: PGP signature