Mailing-List: contact dev-help@apr.apache.org; run by ezmlm
Precedence: bulk
Received-SPF: pass (athena.apache.org: domain of trawick@gmail.com designates
 209.85.210.171 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=mime-version:in-reply-to:references:date:message-id:subject:from:to
         :content-type:content-transfer-encoding;
        b=j22DifKJ4N8Ly41hdPv9ELxrG/nx3GL8p8OCXzlAwXqZznxm2xuGOVInTUExE3FxIv
         UpNnCcDxHdtg5UhJasNcau7K8Z//ytAXYZ3vvwovNau05Y2gtPkBK07Dwn87vmHkTB00
         PdN2wrtQrCxnu/pMPY2mlXT83UaPcaskGnDNI=
MIME-Version: 1.0
In-Reply-To: <201002172126.28301.sf@sfritsch.de>
References: <e8349cf61002160009u229cd521r118af12fb9cfe396@mail.gmail.com>
	 <cc67648e1002170612ma719064gd34cc6c98004cfc2@mail.gmail.com>
	 <20100217161036.GA9086@redhat.com> <201002172126.28301.sf@sfritsch.de>
Date: Wed, 17 Feb 2010 15:59:38 -0500
Message-ID: <cc67648e1002171259m6b353f37h1e6ba612be6b83a7@mail.gmail.com>
Subject: Re: Finding memory leaks in httpd and httpd modules
From: Jeff Trawick <trawick@gmail.com>
To: dev@httpd.apache.org, dev@apr.apache.org
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On Wed, Feb 17, 2010 at 3:26 PM, Stefan Fritsch <sf@sfritsch.de> wrote:
> On Wednesday 17 February 2010, Joe Orton wrote:
>> On Wed, Feb 17, 2010 at 09:12:03AM -0500, Jeff Trawick wrote:
>> > a. get the server to steady state
>>
>> ...
>>
>> > b. see what causes the heap to expand (brk/sbrk)
>>
>> This is what I do too, FWIW. =A0It's primitive but usually effective.
>
> What about adding some code to apr-util's bucket debugging that logs
> when destroyed brigades (i.e. where the pool cleanup has been removed)
> are reused? I think this may be a common cause for memory leaks.

as in something like this?

  apr_brigade_destroy(foo->bb)
  ...
  if (!foo->bb) {
    foo->bb =3D apr_brigade_create();
  }
  ...
  APR_BRIGADE_INSERT_TAIL(foo->bb, b);
  /* no automatic cleanup of b */

> A simpler alternative would be to set bb->pool and bb->bucket_alloc to
> NULL in apr_brigade_destroy(). The latter could maybe even be enabled
> in some apr-util maintainer mode (just like httpd enables some
> debugging in maintainer mode).

APR_BRIGADE_CHECK_CONSISTENCY() would presumably be changed to abort
if !bb->pool