On 05/02/2017 10:14 AM, Ruediger Pluem wrote> On 04/28/2017 10:50 PM,
Jacob Champion wrote:
...why does the EOR bucket have memory ownership of a request_rec,
especially when its lifetime is not well defined? And why have we
put business logic into a finalizer? This is ringing all of my
memory
On 04/28/2017 10:50 PM, Jacob Champion wrote:
> On 04/27/2017 02:46 AM, Yann Ylavic wrote:
>> Jacob, does it work better?
>
> Unfortunately not; now we have crashes in mod_case_filter.
>
> If you're having trouble reproducing a crash, try using an APR with pool
> debugging enabled. The
On 04/27/2017 02:46 AM, Yann Ylavic wrote:
Jacob, does it work better?
Unfortunately not; now we have crashes in mod_case_filter.
If you're having trouble reproducing a crash, try using an APR with pool
debugging enabled. The poisoned-on-free memory is showing up really nicely.
I ask
On Thu, Apr 27, 2017 at 2:45 PM, Plüm, Rüdiger, Vodafone Group
wrote:
> Shouldn't we call apr_brigade_cleanup in any case after ap_pass_brigade?
We should yes, I first did this since we don't want possible r->pool's
buckets staying in bb.
I wanted to cleaning up
pl...@vodafone.com>:
> >>
> >>
> >>
> >>> -Ursprüngliche Nachricht-
> >>> Von: Stefan Eissing [mailto:stefan.eiss...@greenbytes.de]
> >>> Gesendet: Mittwoch, 26. April 2017 10:55
> >>> An: dev@httpd.apache.org
> >
t;> Von: Stefan Eissing [mailto:stefan.eiss...@greenbytes.de]
>>> Gesendet: Mittwoch, 26. April 2017 10:55
>>> An: dev@httpd.apache.org
>>> Betreff: Re: svn commit: r1707087 -
>>> /httpd/httpd/trunk/modules/debugging/mod_bucketeer.c
>>>
>>&g
An: dev@httpd.apache.org
>> Betreff: Re: svn commit: r1707087 -
>> /httpd/httpd/trunk/modules/debugging/mod_bucketeer.c
>>
>> Eh, not really into mod_bucketeer and its use cases, but some
>> observations after a quick scan:
>>
>> line 99:
>>
> -Ursprüngliche Nachricht-
> Von: Stefan Eissing [mailto:stefan.eiss...@greenbytes.de]
> Gesendet: Mittwoch, 26. April 2017 10:55
> An: dev@httpd.apache.org
> Betreff: Re: svn commit: r1707087 -
> /httpd/httpd/trunk/modules/debugging/mod_bucketeer.c
&
Eh, not really into mod_bucketeer and its use cases, but some observations
after a quick scan:
line 99:
rv = ap_pass_brigade(f->next, ctx->bb);
apr_brigade_cleanup(ctx->bb);
line 146:
rv = ap_pass_brigade(f->next, ctx->bb);
> -Ursprüngliche Nachricht-
> Von: Jacob Champion [mailto:champio...@gmail.com]
> Gesendet: Mittwoch, 26. April 2017 00:23
> An: dev@httpd.apache.org; Plüm, Rüdiger, Vodafone Group
> <ruediger.pl...@vodafone.com>
> Betreff: Re: AW: svn commit: r1707087 -
>
On 04/25/2017 04:02 PM, Yann Ylavic wrote:
Let me remind this a bit, it's been a long time :)
Will have a look at it tomorrow hopefully..
No problem; sorry for springing it on you again after two months of
silence. :D
--Jacob
Hi Jacob,
On Tue, Apr 25, 2017 at 11:58 PM, Jacob Champion wrote:
>
> Unfortunately the patch just moves the crash to another location. We can't
> call APR_BRIGADE_EMPTY() on a brigade that's pointing at junk. I think a
> bucket that cleans up the brigade it's a part of is
On 02/15/2017 10:10 AM, Plüm, Rüdiger, Vodafone Group wrote:
How about creating it from c->pool and storing it in c->notes for the lifetime
of c?
Would that be unsafe for HTTP/2? Can multiple requests (that use
ap_request_core_filter) be active on the same connection at once?
--Jacob
On 02/15/2017 05:08 AM, Yann Ylavic wrote:
[with the patch]
On Wed, Feb 15, 2017 at 2:07 PM, Yann Ylavic wrote:
Does the attached patch work for you?
I don't like it too much (if ever relevent), we could also possibly
special case the EOR brigade (looks a bit hacky to
> -Ursprüngliche Nachricht-
> Von: Yann Ylavic [mailto:ylavic@gmail.com]
> Gesendet: Mittwoch, 15. Februar 2017 14:08
> An: httpd-dev <dev@httpd.apache.org>
> Betreff: Re: svn commit: r1707087 -
> /httpd/httpd/trunk/modules/debugging/mod_bucketeer.c
>
>
[with the patch]
On Wed, Feb 15, 2017 at 2:07 PM, Yann Ylavic wrote:
> On Tue, Feb 14, 2017 at 10:21 PM, Jacob Champion wrote:
>>
>
> , hence the (default_)handler probably returned
>>
>>> Admittedly bucketeer_out_filter() is not very nice because it
On Tue, Feb 14, 2017 at 10:21 PM, Jacob Champion wrote:
>
, hence the (default_)handler probably returned
>
>> Admittedly bucketeer_out_filter() is not very nice because it does not
>> "consume" its given brigade (nor does default_handler() clear it
>> afterward), but that
On 02/14/2017 05:02 AM, Yann Ylavic wrote:
The previous test (mod_include) does use mod_bucketeer (including with
subrequests), possibly some remaining buckets (EOR?) from there
somewhere in the stack (core or some downstream filter's f->bb)?
That'd be very wrong too (but I can't see something
Hi Jacob,
On Wed, Feb 8, 2017 at 2:16 AM, Jacob Champion wrote:
> On 10/06/2015 09:30 AM, yla...@apache.org wrote:
>>
>> Author: ylavic
>> Date: Tue Oct 6 16:30:53 2015
>> New Revision: 1707087
>>
>> URL: http://svn.apache.org/viewvc?rev=1707087=rev
>> Log:
>>
On 10/06/2015 09:30 AM, yla...@apache.org wrote:
Author: ylavic
Date: Tue Oct 6 16:30:53 2015
New Revision: 1707087
URL: http://svn.apache.org/viewvc?rev=1707087=rev
Log:
mod_bucketeer: cleanup properly on EOS and write.
Hey Yann,
I've started testing reallyall builds of trunk, which are
20 matches
Mail list logo