You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@apr.apache.org by Stefan Fritsch <sf...@sfritsch.de> on 2010/02/17 21:26:28 UTC
Re: Finding memory leaks in httpd and httpd modules
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. It'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.
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).
Re: Finding memory leaks in httpd and httpd modules
Posted by Stefan Fritsch <sf...@sfritsch.de>.
On Wednesday 17 February 2010, Jeff Trawick wrote:
> > 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 = apr_brigade_create();
> }
> ...
> APR_BRIGADE_INSERT_TAIL(foo->bb, b);
> /* no automatic cleanup of b */
Exactly. I have fixed a few of these in httpd trunk but I guess these
can appear in third party modules, too. And 2.2.x has these problems,
too.
One particular problem is that 2.2's core_output_filter may call
apr_brigade_destroy() on brigades which have been passed down the
filter chain and which may be later reused by the filter that has
created them. I have attached an (untested) patch for this issue. A
simpler variant would just change all three apr_brigade_destroy()
calls to apr_brigade_cleanup().
Finding memory leaks in brigade usage
Posted by Stefan Fritsch <sf...@sfritsch.de>.
On Wednesday 17 February 2010, Jeff Trawick wrote:
> > 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 = apr_brigade_create();
> }
> ...
> APR_BRIGADE_INSERT_TAIL(foo->bb, b);
> /* no automatic cleanup of b */
Exactly.
> > 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
True, but that would only be triggered if brigade debugging is
enabled. I was hoping to also get something more light-weight. But I
now see that setting pool and bucket_alloc to NULL won't trigger
segfaults when buckets are just moved from one brigade to another.
Maybe it's not worth the effort without full APR_BUCKET_DEBUG.
Re: Finding memory leaks in httpd and httpd modules
Posted by Jeff Trawick <tr...@gmail.com>.
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. It'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 = 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
Re: Finding memory leaks in httpd and httpd modules
Posted by Jeff Trawick <tr...@gmail.com>.
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. It'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 = 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