Login | Register For Free | Help
Search for: (Advanced)

Mailing List Archive: Apache: Dev

Memory usage, core output filter, and apr_brigade_destroy

 

 

Apache dev RSS feed   Index | Next | Previous | View Threaded


sf at sfritsch

Sep 13, 2009, 4:11 AM

Post #1 of 14 (688 views)
Permalink
Memory usage, core output filter, and apr_brigade_destroy

Hi,

http://httpd.apache.org/docs/trunk/developer/output-filters.html
recommends to reuse bucket brigades and to not use apr_brigade_destroy.
However, both in 2.2 and in trunk, the core output filter sometimes calls
apr_brigade_destroy on brigades that it has received down the chain from
earlier output filters. Is this not bound to cause problems since the
brigade's pool cleanup is then removed but the brigade is still reused
later on?

Also, the core output filter often creates new brigades instead of reusing
an existing brigade. This should also be changed to reduce memory usage,
shouldn't it?

For trunk, the attached patch at least keeps the temporary brigade for
flush buckets around. Do the versioning rules allow to add elements to
core_output_filter_ctx for 2.2.x, too? It's defined in httpd.h.

Cheers,
Stefan
Attachments: keep_bridade_for_flush_buckets.diff (1.38 KB)


rpluem at apache

Sep 13, 2009, 5:48 AM

Post #2 of 14 (650 views)
Permalink
Re: Memory usage, core output filter, and apr_brigade_destroy [In reply to]

On 09/13/2009 01:11 PM, Stefan Fritsch wrote:
> Hi,
>
> http://httpd.apache.org/docs/trunk/developer/output-filters.html
> recommends to reuse bucket brigades and to not use apr_brigade_destroy.
> However, both in 2.2 and in trunk, the core output filter sometimes
> calls apr_brigade_destroy on brigades that it has received down the
> chain from earlier output filters. Is this not bound to cause problems
> since the brigade's pool cleanup is then removed but the brigade is
> still reused later on?

It could be. But the questions is if it is really reused later on.

>
> Also, the core output filter often creates new brigades instead of
> reusing an existing brigade. This should also be changed to reduce
> memory usage, shouldn't it?

Yes. That was the reason for adding apr_brigade_split_ex to apr-util 1.3.
But so far nobody has found time to get through the current httpd code
and improve the needed sections by using it.

>
> For trunk, the attached patch at least keeps the temporary brigade for
> flush buckets around. Do the versioning rules allow to add elements to
> core_output_filter_ctx for 2.2.x, too? It's defined in httpd.h.

Yes, if you add it to the end of the struct. Then only a minor bump is
required which is allowed. The other possibly more formal problem is
that we currently do not require apr / apr-util 1.3 for httpd 2.2.x but only
1.2. But after shipping 2.2.x for more then one year with apr / apr-util 1.3
without problems I guess we can change this and require apr / apr-util 1.3
for the next 2.2.x release.

But your patch is causing core dumps during the proxy tests when
running the test suite :-(.
I currently don't understand why.

Regards

Rüdiger


jim at jaguNET

Sep 13, 2009, 8:12 AM

Post #3 of 14 (653 views)
Permalink
Re: Memory usage, core output filter, and apr_brigade_destroy [In reply to]

On Sep 13, 2009, at 8:48 AM, Ruediger Pluem wrote:

>
>
> On 09/13/2009 01:11 PM, Stefan Fritsch wrote:
>> Hi,
>>
>> http://httpd.apache.org/docs/trunk/developer/output-filters.html
>> recommends to reuse bucket brigades and to not use
>> apr_brigade_destroy.
>> However, both in 2.2 and in trunk, the core output filter sometimes
>> calls apr_brigade_destroy on brigades that it has received down the
>> chain from earlier output filters. Is this not bound to cause
>> problems
>> since the brigade's pool cleanup is then removed but the brigade is
>> still reused later on?
>
> It could be. But the questions is if it is really reused later on.
>
>>
>> Also, the core output filter often creates new brigades instead of
>> reusing an existing brigade. This should also be changed to reduce
>> memory usage, shouldn't it?
>
> Yes. That was the reason for adding apr_brigade_split_ex to apr-util
> 1.3.
> But so far nobody has found time to get through the current httpd code
> and improve the needed sections by using it.
>
>>
>> For trunk, the attached patch at least keeps the temporary brigade
>> for
>> flush buckets around. Do the versioning rules allow to add elements
>> to
>> core_output_filter_ctx for 2.2.x, too? It's defined in httpd.h.
>
> Yes, if you add it to the end of the struct. Then only a minor bump is
> required which is allowed. The other possibly more formal problem is
> that we currently do not require apr / apr-util 1.3 for httpd 2.2.x
> but only
> 1.2. But after shipping 2.2.x for more then one year with apr / apr-
> util 1.3
> without problems I guess we can change this and require apr / apr-
> util 1.3
> for the next 2.2.x release.
>
> But your patch is causing core dumps during the proxy tests when
> running the test suite :-(.
> I currently don't understand why.
>

Hmmm... either ctx->tmp_flush_bb is NULL or, since it was added in the
middle of the struct, you didn't do a make distclean 1st....


rpluem at apache

Sep 13, 2009, 9:03 AM

Post #4 of 14 (650 views)
Permalink
Re: Memory usage, core output filter, and apr_brigade_destroy [In reply to]

On 09/13/2009 05:12 PM, Jim Jagielski wrote:
>
> On Sep 13, 2009, at 8:48 AM, Ruediger Pluem wrote:
>
>>
>>
>> On 09/13/2009 01:11 PM, Stefan Fritsch wrote:
>>> Hi,
>>>
>>> http://httpd.apache.org/docs/trunk/developer/output-filters.html
>>> recommends to reuse bucket brigades and to not use apr_brigade_destroy.
>>> However, both in 2.2 and in trunk, the core output filter sometimes
>>> calls apr_brigade_destroy on brigades that it has received down the
>>> chain from earlier output filters. Is this not bound to cause problems
>>> since the brigade's pool cleanup is then removed but the brigade is
>>> still reused later on?
>>
>> It could be. But the questions is if it is really reused later on.
>>
>>>
>>> Also, the core output filter often creates new brigades instead of
>>> reusing an existing brigade. This should also be changed to reduce
>>> memory usage, shouldn't it?
>>
>> Yes. That was the reason for adding apr_brigade_split_ex to apr-util 1.3.
>> But so far nobody has found time to get through the current httpd code
>> and improve the needed sections by using it.
>>
>>>
>>> For trunk, the attached patch at least keeps the temporary brigade for
>>> flush buckets around. Do the versioning rules allow to add elements to
>>> core_output_filter_ctx for 2.2.x, too? It's defined in httpd.h.
>>
>> Yes, if you add it to the end of the struct. Then only a minor bump is
>> required which is allowed. The other possibly more formal problem is
>> that we currently do not require apr / apr-util 1.3 for httpd 2.2.x
>> but only
>> 1.2. But after shipping 2.2.x for more then one year with apr /
>> apr-util 1.3
>> without problems I guess we can change this and require apr / apr-util
>> 1.3
>> for the next 2.2.x release.
>>
>> But your patch is causing core dumps during the proxy tests when
>> running the test suite :-(.
>> I currently don't understand why.
>>
>
> Hmmm... either ctx->tmp_flush_bb is NULL or, since it was added in the
> middle of the struct, you didn't do a make distclean 1st....

That is not the problem. I did a slightly modified patch that added it to the
end. I suppose it has something to do with not matching pools or bucket
allocators between bb and ctx->tmp_flush_bb.
It fails on in the proxy case and in the proxy case we have some mixtures going
on there regarding pools and bucket allocators caused by the pooled backend
connections.


Regards

Rüdiger


sf at sfritsch

Sep 13, 2009, 10:09 AM

Post #5 of 14 (652 views)
Permalink
Re: Memory usage, core output filter, and apr_brigade_destroy [In reply to]

Hi Rüdiger,

thanks for the response.

On Sunday 13 September 2009, Ruediger Pluem wrote:
> On 09/13/2009 01:11 PM, Stefan Fritsch wrote:
> > http://httpd.apache.org/docs/trunk/developer/output-filters.html
> > recommends to reuse bucket brigades and to not use
> > apr_brigade_destroy. However, both in 2.2 and in trunk, the core
> > output filter sometimes calls apr_brigade_destroy on brigades
> > that it has received down the chain from earlier output filters.
> > Is this not bound to cause problems since the brigade's pool
> > cleanup is then removed but the brigade is still reused later on?
>
> It could be. But the questions is if it is really reused later on.

Since this is the recommended design for output filters, I am sure it
can happen.

> But your patch is causing core dumps during the proxy tests when
> running the test suite :-(.

It seems I should install the test suite, too. I will look at it when
I have some free cycles again.

Cheers,
Stefan


rpluem at apache

Sep 13, 2009, 1:41 PM

Post #6 of 14 (645 views)
Permalink
Re: Memory usage, core output filter, and apr_brigade_destroy [In reply to]

On 09/13/2009 07:09 PM, Stefan Fritsch wrote:
> Hi Rüdiger,
>
> thanks for the response.
>
> On Sunday 13 September 2009, Ruediger Pluem wrote:
>> On 09/13/2009 01:11 PM, Stefan Fritsch wrote:
>>> http://httpd.apache.org/docs/trunk/developer/output-filters.html
>>> recommends to reuse bucket brigades and to not use
>>> apr_brigade_destroy. However, both in 2.2 and in trunk, the core
>>> output filter sometimes calls apr_brigade_destroy on brigades
>>> that it has received down the chain from earlier output filters.
>>> Is this not bound to cause problems since the brigade's pool
>>> cleanup is then removed but the brigade is still reused later on?
>> It could be. But the questions is if it is really reused later on.
>
> Since this is the recommended design for output filters, I am sure it
> can happen.
>
>> But your patch is causing core dumps during the proxy tests when
>> running the test suite :-(.
>
> It seems I should install the test suite, too. I will look at it when
> I have some free cycles again.

Its easy:

svn co https://svn.apache.org/repos/asf/httpd/test/framework/trunk perl-framework
cd perl-framework
perl Makefile.PL -apxs <apx binary of your httpd installation you want to test>
t/TEST

Regards

Rüdiger


sf at sfritsch

Sep 14, 2009, 10:32 AM

Post #7 of 14 (626 views)
Permalink
Re: Memory usage, core output filter, and apr_brigade_destroy [In reply to]

On Sun, 13 Sep 2009, Ruediger Pluem wrote:
>>> But your patch is causing core dumps during the proxy tests when
>>> running the test suite :-(.
>>> I currently don't understand why.
>>>
>>
>> Hmmm... either ctx->tmp_flush_bb is NULL or, since it was added in the
>> middle of the struct, you didn't do a make distclean 1st....
>
> That is not the problem. I did a slightly modified patch that added it to the
> end. I suppose it has something to do with not matching pools or bucket
> allocators between bb and ctx->tmp_flush_bb.
> It fails on in the proxy case and in the proxy case we have some mixtures going
> on there regarding pools and bucket allocators caused by the pooled backend
> connections.

Yes, the lifetime of the brigade was wrong. The attached patch works
without segfaults.

Cheers,
Stefan
Attachments: keep_bridade_for_flush_buckets.diff (1.86 KB)


rpluem at apache

Sep 14, 2009, 12:48 PM

Post #8 of 14 (618 views)
Permalink
Re: Memory usage, core output filter, and apr_brigade_destroy [In reply to]

On 09/14/2009 07:32 PM, Stefan Fritsch wrote:
> On Sun, 13 Sep 2009, Ruediger Pluem wrote:
>>>> But your patch is causing core dumps during the proxy tests when
>>>> running the test suite :-(.
>>>> I currently don't understand why.
>>>>
>>>
>>> Hmmm... either ctx->tmp_flush_bb is NULL or, since it was added in the
>>> middle of the struct, you didn't do a make distclean 1st....
>>
>> That is not the problem. I did a slightly modified patch that added it
>> to the
>> end. I suppose it has something to do with not matching pools or bucket
>> allocators between bb and ctx->tmp_flush_bb.
>> It fails on in the proxy case and in the proxy case we have some
>> mixtures going
>> on there regarding pools and bucket allocators caused by the pooled
>> backend
>> connections.
>
> Yes, the lifetime of the brigade was wrong. The attached patch works
> without segfaults.

Thanks for the update. I committed a slightly modified version as
r814807. It avoids the constant if check in the flush bucket case
at the expense of always creating the brigade when setting up the
context.

Regards

Rüdiger


paul at querna

Sep 14, 2009, 1:29 PM

Post #9 of 14 (619 views)
Permalink
Re: Memory usage, core output filter, and apr_brigade_destroy [In reply to]

On Mon, Sep 14, 2009 at 12:48 PM, Ruediger Pluem <rpluem [at] apache> wrote:
>
>
> On 09/14/2009 07:32 PM, Stefan Fritsch wrote:
>> On Sun, 13 Sep 2009, Ruediger Pluem wrote:
>>>>> But your patch is causing core dumps during the proxy tests when
>>>>> running the test suite :-(.
>>>>> I currently don't understand why.
>>>>>
>>>>
>>>> Hmmm... either ctx->tmp_flush_bb is NULL or, since it was added in the
>>>> middle of the struct, you didn't do a make distclean 1st....
>>>
>>> That is not the problem. I did a slightly modified patch that added it
>>> to the
>>> end. I suppose it has something to do with not matching pools or bucket
>>> allocators between bb and ctx->tmp_flush_bb.
>>> It fails on in the proxy case and in the proxy case we have some
>>> mixtures going
>>> on there regarding pools and bucket allocators caused by the pooled
>>> backend
>>> connections.
>>
>> Yes, the lifetime of the brigade was wrong. The attached patch works
>> without segfaults.
>
> Thanks for the update. I committed a slightly modified version as
> r814807. It avoids the constant if check in the flush bucket case
> at the expense of always creating the brigade when setting up the
> context.
>

regarding r814807, if you look in core_fitlers.c, there is a
brigade_move function that pre-dated apr_brigade_split_ex existing, I
think brigade_move could be converted to apr_brigade_split_ex.......


rpluem at apache

Sep 14, 2009, 1:53 PM

Post #10 of 14 (619 views)
Permalink
Re: Memory usage, core output filter, and apr_brigade_destroy [In reply to]

On 09/14/2009 10:29 PM, Paul Querna wrote:
> On Mon, Sep 14, 2009 at 12:48 PM, Ruediger Pluem <rpluem [at] apache> wrote:
>>
>> On 09/14/2009 07:32 PM, Stefan Fritsch wrote:
>>> On Sun, 13 Sep 2009, Ruediger Pluem wrote:
>>>>>> But your patch is causing core dumps during the proxy tests when
>>>>>> running the test suite :-(.
>>>>>> I currently don't understand why.
>>>>>>
>>>>> Hmmm... either ctx->tmp_flush_bb is NULL or, since it was added in the
>>>>> middle of the struct, you didn't do a make distclean 1st....
>>>> That is not the problem. I did a slightly modified patch that added it
>>>> to the
>>>> end. I suppose it has something to do with not matching pools or bucket
>>>> allocators between bb and ctx->tmp_flush_bb.
>>>> It fails on in the proxy case and in the proxy case we have some
>>>> mixtures going
>>>> on there regarding pools and bucket allocators caused by the pooled
>>>> backend
>>>> connections.
>>> Yes, the lifetime of the brigade was wrong. The attached patch works
>>> without segfaults.
>> Thanks for the update. I committed a slightly modified version as
>> r814807. It avoids the constant if check in the flush bucket case
>> at the expense of always creating the brigade when setting up the
>> context.
>>
>
> regarding r814807, if you look in core_fitlers.c, there is a
> brigade_move function that pre-dated apr_brigade_split_ex existing, I
> think brigade_move could be converted to apr_brigade_split_ex.......

Good catch. They are nearly the same with the exception that
apr_brigrade_split_ex cleans up brigade a where the tail ends if it
is not empty at the beginning, but this is IHMO a benefit.

Regards

Rüdiger


sf at sfritsch

Sep 22, 2009, 12:19 PM

Post #11 of 14 (564 views)
Permalink
Re: Memory usage, core output filter, and apr_brigade_destroy [In reply to]

On Sunday 13 September 2009, Stefan Fritsch wrote:
> On Sunday 13 September 2009, Ruediger Pluem wrote:
> > On 09/13/2009 01:11 PM, Stefan Fritsch wrote:
> > > http://httpd.apache.org/docs/trunk/developer/output-filters.htm
> > >l recommends to reuse bucket brigades and to not use
> > > apr_brigade_destroy. However, both in 2.2 and in trunk, the
> > > core output filter sometimes calls apr_brigade_destroy on
> > > brigades that it has received down the chain from earlier
> > > output filters. Is this not bound to cause problems since the
> > > brigade's pool cleanup is then removed but the brigade is still
> > > reused later on?
> >
> > It could be. But the questions is if it is really reused later
> > on.
>
> Since this is the recommended design for output filters, I am sure
> it can happen.

I have attached two patches:

In the first, I change (hopefully) all places to not
apr_brigade_destroy brigades that have been passed down the filter
chain. Especially the core_output_filter change needs some review.

In the second, I have changed all occurences of apr_brigade_split to
apr_brigade_split_ex and I have made some more changes where bucket
brigades can be reused.

The test suite shows no regressions.

Cheers,
Stefan
Attachments: dont_destroy_others_brigades.diff (4.28 KB)
  reuse_brigades.diff (9.27 KB)


rpluem at apache

Sep 23, 2009, 1:58 PM

Post #12 of 14 (531 views)
Permalink
Re: Memory usage, core output filter, and apr_brigade_destroy [In reply to]

On 09/22/2009 09:19 PM, Stefan Fritsch wrote:
> On Sunday 13 September 2009, Stefan Fritsch wrote:
>> On Sunday 13 September 2009, Ruediger Pluem wrote:
>>> On 09/13/2009 01:11 PM, Stefan Fritsch wrote:
>>>> http://httpd.apache.org/docs/trunk/developer/output-filters.htm
>>>> l recommends to reuse bucket brigades and to not use
>>>> apr_brigade_destroy. However, both in 2.2 and in trunk, the
>>>> core output filter sometimes calls apr_brigade_destroy on
>>>> brigades that it has received down the chain from earlier
>>>> output filters. Is this not bound to cause problems since the
>>>> brigade's pool cleanup is then removed but the brigade is still
>>>> reused later on?
>>> It could be. But the questions is if it is really reused later
>>> on.
>> Since this is the recommended design for output filters, I am sure
>> it can happen.
>
> I have attached two patches:
>
> In the first, I change (hopefully) all places to not
> apr_brigade_destroy brigades that have been passed down the filter
> chain. Especially the core_output_filter change needs some review.
>
> In the second, I have changed all occurences of apr_brigade_split to
> apr_brigade_split_ex and I have made some more changes where bucket
> brigades can be reused.
>
> The test suite shows no regressions.


Index: server/protocol.c
===================================================================
--- server/protocol.c (Revision 818232)
+++ server/protocol.c (Arbeitskopie)
@@ -1239,6 +1239,7 @@
* least one bucket on to the next output filter
* for this request
*/
+ apr_bucket_brigade *tmpbb;
};

/* This filter computes the content length, but it also computes the number
@@ -1259,6 +1260,8 @@
if (!ctx) {
f->ctx = ctx = apr_palloc(r->pool, sizeof(*ctx));
ctx->data_sent = 0;
+ ctx->tmpbb = apr_brigade_create(r->connection->pool,

This should be r->pool instead. The lifetime of ctx itself is limited to r->pool

+ r->connection->bucket_alloc);
}


@@ -1433,24 +1431,38 @@
if (f == NULL) {
/* our filter hasn't been added yet */
ctx = apr_pcalloc(r->pool, sizeof(*ctx));
+ ctx->tmpbb = apr_brigade_create(r->pool, r->connection->bucket_alloc);
+
ap_add_output_filter("OLD_WRITE", ctx, r, r->connection);
f = r->output_filters;
}

+ return f;
+}
+
+static apr_status_t buffer_output(request_rec *r,
+ const char *str, apr_size_t len)
+{
+ conn_rec *c = r->connection;
+ ap_filter_t *f;
+ old_write_filter_ctx *ctx;
+
+ if (len == 0)
+ return APR_SUCCESS;
+
+ f = insert_old_write_filter(r);
+ ctx = f->ctx;
+
/* if the first filter is not our buffering filter, then we have to
* deliver the content through the normal filter chain
*/
if (f != r->output_filters) {
- apr_bucket_brigade *bb = apr_brigade_create(r->pool, c->bucket_alloc);
apr_bucket *b = apr_bucket_transient_create(str, len, c->bucket_alloc);
- APR_BRIGADE_INSERT_TAIL(bb, b);
+ APR_BRIGADE_INSERT_TAIL(ctx->tmpbb, b);

- return ap_pass_brigade(r->output_filters, bb);
+ return ap_pass_brigade(r->output_filters, ctx->tmpbb);

To be on the save side I think an apr_brigade_cleanup(ctx->tmpbb) is due
before doing the return, just in case a filter did not consume the buckets
properly.

}
@@ -1605,13 +1617,17 @@
AP_DECLARE(int) ap_rflush(request_rec *r)
{
conn_rec *c = r->connection;
- apr_bucket_brigade *bb;
apr_bucket *b;
+ ap_filter_t *f;
+ old_write_filter_ctx *ctx;

- bb = apr_brigade_create(r->pool, c->bucket_alloc);
+ f = insert_old_write_filter(r);
+ ctx = f->ctx;
+
b = apr_bucket_flush_create(c->bucket_alloc);
- APR_BRIGADE_INSERT_TAIL(bb, b);
- if (ap_pass_brigade(r->output_filters, bb) != APR_SUCCESS)
+ APR_BRIGADE_INSERT_TAIL(ctx->tmpbb, b);
+
+ if (ap_pass_brigade(r->output_filters, ctx->tmpbb) != APR_SUCCESS)

Same as above: We should call apr_brigade_cleanup(ctx->tmpbb) to be on the save side.

return -1;

return 0;


--- modules/http/chunk_filter.c (Revision 818232)
+++ modules/http/chunk_filter.c (Arbeitskopie)
@@ -49,11 +49,11 @@
#define ASCII_CRLF "\015\012"
#define ASCII_ZERO "\060"
conn_rec *c = f->r->connection;
- apr_bucket_brigade *more;
+ apr_bucket_brigade *more, *tmp;
apr_bucket *e;
apr_status_t rv;

- for (more = NULL; b; b = more, more = NULL) {
+ for (more = tmp = NULL; b; tmp = b, b = more, more = NULL) {
apr_off_t bytes = 0;
apr_bucket *eos = NULL;
apr_bucket *flush = NULL;
@@ -85,7 +85,8 @@
if (APR_BUCKET_IS_FLUSH(e)) {
flush = e;
if (e != APR_BRIGADE_LAST(b)) {
- more = apr_brigade_split(b, APR_BUCKET_NEXT(e));
+ more = apr_brigade_split_ex(b, APR_BUCKET_NEXT(e), tmp);
+ tmp = NULL;
}
break;
}
@@ -105,7 +106,8 @@
* block so we pass down what we have so far.
*/
bytes += len;
- more = apr_brigade_split(b, APR_BUCKET_NEXT(e));
+ more = apr_brigade_split_ex(b, APR_BUCKET_NEXT(e), tmp);
+ tmp = NULL;
break;
}
else {

What is the point here? tmp is always NULL when passed to apr_brigade_split_ex
so apr_brigade_split_ex == apr_brigade_split

--- modules/filters/mod_sed.c (Revision 818232)
+++ modules/filters/mod_sed.c (Arbeitskopie)
@@ -435,11 +440,9 @@
* the question is where to add it?
*/
while (APR_BRIGADE_EMPTY(ctx->bb)) {
- apr_bucket_brigade *bbinp;
apr_bucket *b;

/* read the bytes from next level filter */
- bbinp = apr_brigade_create(f->r->pool, f->c->bucket_alloc);
status = ap_get_brigade(f->next, bbinp, mode, block, readbytes);
if (status != APR_SUCCESS) {
return status;
@@ -470,19 +473,16 @@
}
}
apr_brigade_cleanup(bbinp);

This one should be moved *before* the ap_get_brigade. It ensures that we always
call ap_get_brigade with an empty brigade.

- apr_brigade_destroy(bbinp);
}



Regards

Rüdiger


sf at sfritsch

Oct 4, 2009, 12:37 AM

Post #13 of 14 (457 views)
Permalink
Re: Memory usage, core output filter, and apr_brigade_destroy [In reply to]

Thanks for your comments.

On Wednesday 23 September 2009, Ruediger Pluem wrote:
> --- modules/http/chunk_filter.c (Revision 818232)
> +++ modules/http/chunk_filter.c (Arbeitskopie)
> @@ -49,11 +49,11 @@
> #define ASCII_CRLF "\015\012"
> #define ASCII_ZERO "\060"
> conn_rec *c = f->r->connection;
> - apr_bucket_brigade *more;
> + apr_bucket_brigade *more, *tmp;
> apr_bucket *e;
> apr_status_t rv;
>
> - for (more = NULL; b; b = more, more = NULL) {
> + for (more = tmp = NULL; b; tmp = b, b = more, more = NULL) {
> apr_off_t bytes = 0;
> apr_bucket *eos = NULL;
> apr_bucket *flush = NULL;
> @@ -85,7 +85,8 @@
> if (APR_BUCKET_IS_FLUSH(e)) {
> flush = e;
> if (e != APR_BRIGADE_LAST(b)) {
> - more = apr_brigade_split(b,
> APR_BUCKET_NEXT(e)); + more =
> apr_brigade_split_ex(b, APR_BUCKET_NEXT(e), tmp); +
> tmp = NULL;
> }
> break;
> }
> @@ -105,7 +106,8 @@
> * block so we pass down what we have so far.
> */
> bytes += len;
> - more = apr_brigade_split(b,
> APR_BUCKET_NEXT(e)); + more =
> apr_brigade_split_ex(b, APR_BUCKET_NEXT(e), tmp); +
> tmp = NULL;
> break;
> }
> else {
>
> What is the point here? tmp is always NULL when passed to
> apr_brigade_split_ex so apr_brigade_split_ex == apr_brigade_split

You missed the tmp = b at the beginning of the loop. The tmp = NULL
lines were actually not needed. I have changed this a bit to hopefully
make it clearer and commited the patch together with the other changes
you suggested.

Cheers,
Stefan


rpluem at apache

Oct 4, 2009, 1:29 AM

Post #14 of 14 (443 views)
Permalink
Re: Memory usage, core output filter, and apr_brigade_destroy [In reply to]

On 10/04/2009 09:37 AM, Stefan Fritsch wrote:
> Thanks for your comments.
>
> On Wednesday 23 September 2009, Ruediger Pluem wrote:

>>
>> What is the point here? tmp is always NULL when passed to
>> apr_brigade_split_ex so apr_brigade_split_ex == apr_brigade_split
>
> You missed the tmp = b at the beginning of the loop. The tmp = NULL
> lines were actually not needed. I have changed this a bit to hopefully
> make it clearer and commited the patch together with the other changes
> you suggested.

Yes, I missed that. Thanks for explaining.

Regards

Rüdiger

Apache dev RSS feed   Index | Next | Previous | View Threaded
 
 


Interested in having your list archived? Contact Gossamer Threads
 
  Web Applications & Managed Hosting Powered by Gossamer Threads Inc.