Mailing-List: contact dev-help@httpd.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@httpd.apache.org
Received-SPF: pass (nike.apache.org: domain of trawick@gmail.com designates
 209.85.217.215 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=JQkJo+D8gf0B8vGP+jvtcxIW1tjzeveVZR1K32dBijUc2EA01YUxeCyHjXYjmDetmL
         jUm8fh6k09zM3L/xG3I+Fk4fHsiNt/uHGdnzjXcvfHBE2NZGUItIAR/S8dlyWYWOkUuy
         UhBCEoPqq/Zs2g9B2mtA0lxRH3sh/W0iuOoRI=
MIME-Version: 1.0
In-Reply-To: <d68cf13d1002170917v58361191r30d6db8dae48a1c7@mail.gmail.com>
References: <e8349cf61002160009u229cd521r118af12fb9cfe396@mail.gmail.com>
	 <d68cf13d1002160310u5e95ad85q1c948a38b48c28cd@mail.gmail.com>
	 <e8349cf61002161136s530bd7c3jc7334e188ff6d02a@mail.gmail.com>
	 <d68cf13d1002170530t400e1050i6ab377a0083016aa@mail.gmail.com>
	 <cc67648e1002170612ma719064gd34cc6c98004cfc2@mail.gmail.com>
	 <20100217161036.GA9086@redhat.com>
	 <d68cf13d1002170917v58361191r30d6db8dae48a1c7@mail.gmail.com>
Date: Wed, 17 Feb 2010 13:03:49 -0500
Message-ID: <cc67648e1002171003u6d7fc093g5b9fc2f0259d1dd6@mail.gmail.com>
Subject: Re: Finding memory leaks in httpd and httpd modules
From: Jeff Trawick <trawick@gmail.com>
To: dev@httpd.apache.org
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On Wed, Feb 17, 2010 at 12:17 PM, harish kulkarni <wasinapple@gmail.com> wr=
ote:
> if you are seeing leaks while using apr memory allocation, it's better to
> use apache pool debug
> i am just pasting some portion of the debug logs which i used to debug
> issue, this might help you.
> In the following "request" means that you are allocated memory from reque=
st
> processing for given connection.
> "proxy_conn_pool" means allocation happened from proxy connection pool.
> I have found this is best approach to find leaks or allocation procedure =
of
> apache.

> POOL DEBUG: [14983/3058834320] =A0PALLOC ( =A0 =A0 =A04463/ =A0 =A0 =A044=
63/ =A0 =A0143668)
> 0x80ffee0 "request" <strings/apr_strings.c:149> (67/67/0)
> POOL DEBUG: [14983/3058834320] =A0PALLOC ( =A0 =A0 =A0 =A081/ =A0 =A0 =A0=
 =A081/ =A0 =A0143685)
> 0x814c038 "proxy_conn_pool" <strings/apr_strings.c:78> (2/7/1)
> POOL DEBUG: [14983/3058834320] PCALLOC ( =A0 =A0 =A0 249/ =A0 =A0 =A0 249=
/ =A0 =A0143853)

Thanks; I had largely forgotten about the nature of these logs.  That
makes it trivial to see when objects are allocated from the wrong
pool, or find when some structure which has been unexpectedly
reused/overlaid was originally allocated (and from which pool).

I can't say for sure without being in a specific debug situation, but
I'd probably start with finding what was calling brk() then if pool
use seemed to be involved (vs. direct calls to the heap or apr
allocator) and/or I got stuck and/or needed this kind of picture of
pool use I'd rebuild/retest with pool debug and have a look at the
log.  (And that requires being able to reproduce it myself on my own
binaries.)