Mailing-List: contact dev-help@apr.apache.org; run by ezmlm
Precedence: bulk
Received-SPF: pass (athena.apache.org: domain of bojan@rexursive.com
 designates 203.171.74.242 as permitted sender)
Subject: Re: svn commit: r678323
	-	/apr/apr-util/trunk/memcache/apr_memcache.c
From: Bojan Smojver <bojan@rexursive.com>
To: APR Development List <dev@apr.apache.org>
In-Reply-To: <20080807231819.GA4387@suse.de>
References: <20080720212913.9822723889F3@eris.apache.org>
	 <1216592684.2754.71.camel@shrek.rexursive.com>
	 <48841FD2.2070708@apache.org>
	 <1216630008.2754.75.camel@shrek.rexursive.com>
	 <20080807231819.GA4387@suse.de>
Content-Type: text/plain
Date: Fri, 08 Aug 2008 09:45:37 +1000
Message-Id: <1218152737.25598.132.camel@shrek.rexursive.com>
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit

On Fri, 2008-08-08 at 01:18 +0200, Peter Poeml wrote:

> 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.

The patch from trunk may work by accident, depending on how
apr_reslist_create() was called and the order of pool destruction.
However, it may create double free situation in some circumstances (this
is what big discussion about pre_cleanups was all about), so it is not
safe.

-- 
Bojan