Re: svn commit: r1706669 - in /httpd/httpd/trunk: ./ include/ modules/http/ modules/ssl/ server/ server/mpm/event/ server/mpm/motorz/ server/mpm/simple/

Le 04/10/2015 12:10, minf...@apache.org a écrit : Author: minfrin Date: Sun Oct 4 10:10:51 2015 New Revision: 1706669 URL: http://svn.apache.org/viewvc?rev=1706669=rev Log: core: Extend support for asynchronous write completion from the network filter to any connection or request filter.

Re: svn commit: r1706669 - in /httpd/httpd/trunk: ./ include/ modules/http/ modules/ssl/ server/ server/mpm/event/ server/mpm/motorz/ server/mpm/simple/

On Tue, Oct 6, 2015 at 5:34 PM, Graham Leggett wrote: > > apr_bucket_simple_copy() looks wrong - in theory we should have a proper copy > function that does the right thing with the second copy, for example by not > copying the pool. If we blindly copy the pool (or the request

Re: svn commit: r1706669 - in /httpd/httpd/trunk: ./ include/ modules/http/ modules/ssl/ server/ server/mpm/event/ server/mpm/motorz/ server/mpm/simple/

On Tue, Oct 6, 2015 at 3:51 PM, Yann Ylavic wrote: > On Tue, Oct 6, 2015 at 3:41 PM, Graham Leggett wrote: >> On 6 Oct 2015, at 14:32, Yann Ylavic wrote: >> >>> So it seems to relate to the EOR bucket, first not being passed >>>

Re: svn commit: r1706669 - in /httpd/httpd/trunk: ./ include/ modules/http/ modules/ssl/ server/ server/mpm/event/ server/mpm/motorz/ server/mpm/simple/

On 06 Oct 2015, at 3:36 PM, Stefan Eissing wrote: > FYI: /trunk no longer works with mod_http2. 2.4.x does. I see missing > response data, it seems, so the most likely cause are the changes in filter > handling. Did not find the time to investigate further. > >

Re: svn commit: r1706669 - in /httpd/httpd/trunk: ./ include/ modules/http/ modules/ssl/ server/ server/mpm/event/ server/mpm/motorz/ server/mpm/simple/

On 06 Oct 2015, at 5:22 PM, Yann Ylavic wrote: >> Just did that, same thing. >> I was using mpm_worker, but now tried mpm_event with same segfaults. > > Looks like mod_bucketeer is the culprit. > It fails to remove itself from the filter stack on EOS, and hence > makes a

AW: svn commit: r1706669 - in /httpd/httpd/trunk: ./ include/ modules/http/ modules/ssl/ server/ server/mpm/event/ server/mpm/motorz/ server/mpm/simple/

> -Ursprüngliche Nachricht- > Von: Yann Ylavic [mailto:ylavic@gmail.com] > Gesendet: Dienstag, 6. Oktober 2015 17:54 > An: dev@httpd.apache.org > Betreff: Re: svn commit: r1706669 - in /httpd/httpd/trunk: ./ include/ > modules/http/ modules/ssl/ server/ server/mpm

Re: svn commit: r1706669 - in /httpd/httpd/trunk: ./ include/ modules/http/ modules/ssl/ server/ server/mpm/event/ server/mpm/motorz/ server/mpm/simple/

> On Oct 6, 2015, at 1:29 PM, Graham Leggett wrote: > > On 06 Oct 2015, at 7:00 PM, Yann Ylavic wrote: > >> Yet another filter which does not remove itself after the EOS, and >> destroys the EOR bucket while still using *r after. > > I am wondering if

RE: svn commit: r1706669 - in /httpd/httpd/trunk: ./ include/ modules/http/ modules/ssl/ server/ server/mpm/event/ server/mpm/motorz/ server/mpm/simple/

> -Original Message- > From: Yann Ylavic [mailto:ylavic@gmail.com] > Sent: Dienstag, 6. Oktober 2015 01:40 > To: dev@httpd.apache.org > Subject: Re: svn commit: r1706669 - in /httpd/httpd/trunk: ./ include/ > modules/http/ modules/ssl/ server/ server/mpm/event/

Re: svn commit: r1706669 - in /httpd/httpd/trunk: ./ include/ modules/http/ modules/ssl/ server/ server/mpm/event/ server/mpm/motorz/ server/mpm/simple/

On 06 Oct 2015, at 7:29 PM, Graham Leggett wrote: > I am wondering if the EOR bucket is a suboptimal way to clean up after > ourselves. > > The MPM itself is in a position to know when the filter buffers are all empty > and it is safe to delete a request pool. I am imagining

Re: svn commit: r1706669 - in /httpd/httpd/trunk: ./ include/ modules/http/ modules/ssl/ server/ server/mpm/event/ server/mpm/motorz/ server/mpm/simple/

On Tue, Oct 6, 2015 at 9:37 AM, Plüm, Rüdiger, Vodafone Group wrote: > >> From: Yann Ylavic [mailto:ylavic@gmail.com] >> >> Also it seems that we leak the hash iterator here (on c->pool). > > Why do we leak here? apr_hash_first(NULL, is used. So no new iterator is

Re: svn commit: r1706669 - in /httpd/httpd/trunk: ./ include/ modules/http/ modules/ssl/ server/ server/mpm/event/ server/mpm/motorz/ server/mpm/simple/

On Tue, Oct 6, 2015 at 9:37 AM, Plüm, Rüdiger, Vodafone Group wrote: > >> -Original Message- >> From: Yann Ylavic [mailto:ylavic@gmail.com] >> >> > Modified: httpd/httpd/trunk/server/mpm/event/event.c >> > URL: >>

RE: svn commit: r1706669 - in /httpd/httpd/trunk: ./ include/ modules/http/ modules/ssl/ server/ server/mpm/event/ server/mpm/motorz/ server/mpm/simple/

> -Original Message- > From: Yann Ylavic [mailto:ylavic@gmail.com] > Sent: Dienstag, 6. Oktober 2015 11:13 > To: dev@httpd.apache.org > Subject: Re: svn commit: r1706669 - in /httpd/httpd/trunk: ./ include/ > modules/http/ modules/ssl/ server/ server/mpm/event/

Re: svn commit: r1706669 - in /httpd/httpd/trunk: ./ include/ modules/http/ modules/ssl/ server/ server/mpm/event/ server/mpm/motorz/ server/mpm/simple/

On 06 Oct 2015, at 1:39 AM, Yann Ylavic wrote: >> + >> +/** Buffered data associated with the current filter. */ >> +apr_bucket_brigade *bb; >> + >> +/** Dedicated pool to use for deferred writes. */ >> +apr_pool_t *deferred_pool; > > Could we make these

RE: svn commit: r1706669 - in /httpd/httpd/trunk: ./ include/ modules/http/ modules/ssl/ server/ server/mpm/event/ server/mpm/motorz/ server/mpm/simple/

> -Original Message- > From: Graham Leggett [mailto:minf...@sharp.fm] > Sent: Dienstag, 6. Oktober 2015 12:16 > To: dev@httpd.apache.org > Subject: Re: svn commit: r1706669 - in /httpd/httpd/trunk: ./ include/ > modules/http/ modules/ssl/ server/ server/mpm/event/

Re: svn commit: r1706669 - in /httpd/httpd/trunk: ./ include/ modules/http/ modules/ssl/ server/ server/mpm/event/ server/mpm/motorz/ server/mpm/simple/

>> Subject: Re: svn commit: r1706669 - in /httpd/httpd/trunk: ./ include/ >> modules/http/ modules/ssl/ server/ server/mpm/event/ server/mpm/motorz/ >> server/mpm/simple/ >> >> On Tue, Oct 6, 2015 at 9:37 AM, Plüm, Rüdiger, Vodafone Group >> <ruediger.pl...@vodafon

Re: svn commit: r1706669 - in /httpd/httpd/trunk: ./ include/ modules/http/ modules/ssl/ server/ server/mpm/event/ server/mpm/motorz/ server/mpm/simple/

On 06 Oct 2015, at 12:26 PM, Plüm, Rüdiger, Vodafone Group wrote: > How can you be sure that you don't have transient buckets in the brigade that > point to memory that changed or is invalid, once you reinstate the brigade? Because it’s a request filter, not a

Re: svn commit: r1706669 - in /httpd/httpd/trunk: ./ include/ modules/http/ modules/ssl/ server/ server/mpm/event/ server/mpm/motorz/ server/mpm/simple/

On 06 Oct 2015, at 12:36 PM, Yann Ylavic wrote: >> Although the brigade is empty, don't we need to prevent the brigade being >> used by multiple threads in parallel? >> Using one per connection prevents this. > > Hmm, the filters are also allocated per connection/request

Re: svn commit: r1706669 - in /httpd/httpd/trunk: ./ include/ modules/http/ modules/ssl/ server/ server/mpm/event/ server/mpm/motorz/ server/mpm/simple/

On Tue, Oct 6, 2015 at 12:15 PM, Graham Leggett wrote: > On 06 Oct 2015, at 1:39 AM, Yann Ylavic wrote: > >>> + >>> +/** Buffered data associated with the current filter. */ >>> +apr_bucket_brigade *bb; >>> + >>> +/** Dedicated pool to use for

Re: svn commit: r1706669 - in /httpd/httpd/trunk: ./ include/ modules/http/ modules/ssl/ server/ server/mpm/event/ server/mpm/motorz/ server/mpm/simple/

On Tue, Oct 6, 2015 at 12:57 PM, Graham Leggett wrote: > > On 06 Oct 2015, at 12:36 PM, Yann Ylavic wrote: >> BTW, I wonder if we can "reinstate" the filters in arbitrary order >> like in the above loop (the order seems to depend on the calls to >>

Re: svn commit: r1706669 - in /httpd/httpd/trunk: ./ include/ modules/http/ modules/ssl/ server/ server/mpm/event/ server/mpm/motorz/ server/mpm/simple/

On Tue, Oct 6, 2015 at 3:51 PM, Yann Ylavic wrote: > > Just did that, same thing. > I was using mpm_worker, but now tried mpm_event with same segfaults. FWIW, I'm running an (old) Debian 6.0.10 (squeeze, 64bit).

Re: svn commit: r1706669 - in /httpd/httpd/trunk: ./ include/ modules/http/ modules/ssl/ server/ server/mpm/event/ server/mpm/motorz/ server/mpm/simple/

On 06 Oct 2015, at 1:07 PM, Yann Ylavic wrote: > What I meant is that passing an empty brigade to a reinstate-able > filter may make it pass its data to the next filter, so we may want to > do this only on the first reinstate-able filter starting from > r->output_filters.

Re: svn commit: r1706669 - in /httpd/httpd/trunk: ./ include/ modules/http/ modules/ssl/ server/ server/mpm/event/ server/mpm/motorz/ server/mpm/simple/

On 06 Oct 2015, at 12:36 PM, Graham Leggett wrote: >> How can you be sure that you don't have transient buckets in the brigade >> that point to memory that changed or is invalid, once you reinstate the >> brigade? > > Because it’s a request filter, not a connection filter.

Re: svn commit: r1706669 - in /httpd/httpd/trunk: ./ include/ modules/http/ modules/ssl/ server/ server/mpm/event/ server/mpm/motorz/ server/mpm/simple/

On Tue, Oct 6, 2015 at 3:41 PM, Graham Leggett wrote: > On 6 Oct 2015, at 14:32, Yann Ylavic wrote: > >> So it seems to relate to the EOR bucket, first not being passed >> through, and second leading to a double-free or alike. >> >> Did not investigate

Re: svn commit: r1706669 - in /httpd/httpd/trunk: ./ include/ modules/http/ modules/ssl/ server/ server/mpm/event/ server/mpm/motorz/ server/mpm/simple/

On Sun, Oct 4, 2015 at 12:10 PM, wrote: > Author: minfrin > Date: Sun Oct 4 10:10:51 2015 > New Revision: 1706669 > > URL: http://svn.apache.org/viewvc?rev=1706669=rev > Log: > core: Extend support for asynchronous write completion from the > network filter to any connection

Re: svn commit: r1706669 - in /httpd/httpd/trunk: ./ include/ modules/http/ modules/ssl/ server/ server/mpm/event/ server/mpm/motorz/ server/mpm/simple/

On Tue, Oct 6, 2015 at 3:32 PM, Yann Ylavic wrote: > > Just wanted to run the tests framework on trunk for a local change but > it seems that this commit (bisected to) makes many tests to segfault. Forgot to mention, same thing with follow up r1706670 applied.

Re: svn commit: r1706669 - in /httpd/httpd/trunk: ./ include/ modules/http/ modules/ssl/ server/ server/mpm/event/ server/mpm/motorz/ server/mpm/simple/

FYI: /trunk no longer works with mod_http2. 2.4.x does. I see missing response data, it seems, so the most likely cause are the changes in filter handling. Did not find the time to investigate further. Please be aware the mod_h2 uses pool/brigade hierarchies in new and unexpected ways. The

Re: svn commit: r1706669 - in /httpd/httpd/trunk: ./ include/ modules/http/ modules/ssl/ server/ server/mpm/event/ server/mpm/motorz/ server/mpm/simple/

On 6 Oct 2015, at 14:32, Yann Ylavic wrote: > So it seems to relate to the EOR bucket, first not being passed > through, and second leading to a double-free or alike. > > Did not investigate further... Did you rebuild you tree completely clean before trying it out?

Re: svn commit: r1706669 - in /httpd/httpd/trunk: ./ include/ modules/http/ modules/ssl/ server/ server/mpm/event/ server/mpm/motorz/ server/mpm/simple/

+1 (concept) > On Oct 6, 2015, at 11:53 AM, Yann Ylavic wrote: > > On Tue, Oct 6, 2015 at 5:34 PM, Graham Leggett wrote: >> >> apr_bucket_simple_copy() looks wrong - in theory we should have a proper >> copy function that does the right thing with the

Re: svn commit: r1706669 - in /httpd/httpd/trunk: ./ include/ modules/http/ modules/ssl/ server/ server/mpm/event/ server/mpm/motorz/ server/mpm/simple/

On 06 Oct 2015, at 7:00 PM, Yann Ylavic wrote: > Yet another filter which does not remove itself after the EOS, and > destroys the EOR bucket while still using *r after. I am wondering if the EOR bucket is a suboptimal way to clean up after ourselves. The MPM itself is

Re: svn commit: r1706669 - in /httpd/httpd/trunk: ./ include/ modules/http/ modules/ssl/ server/ server/mpm/event/ server/mpm/motorz/ server/mpm/simple/

On Tue, Oct 6, 2015 at 5:53 PM, Yann Ylavic wrote: > On Tue, Oct 6, 2015 at 5:34 PM, Graham Leggett wrote: >> >> apr_bucket_simple_copy() looks wrong - in theory we should have a proper >> copy function that does the right thing with the second copy, for

Re: svn commit: r1706669 - in /httpd/httpd/trunk: ./ include/ modules/http/ modules/ssl/ server/ server/mpm/event/ server/mpm/motorz/ server/mpm/simple/

On Tue, Oct 6, 2015 at 6:29 PM, Yann Ylavic wrote: > > all tests pass now. I spoke too soon... New segfault is in mod_substitute: Program terminated with signal 11, Segmentation fault. (gdb) bt #0 0x7fa02fbaec2b in allocator_free (allocator=0x1cedcb0, node=0x0) at

Re: svn commit: r1706669 - in /httpd/httpd/trunk: ./ include/ modules/http/ modules/ssl/ server/ server/mpm/event/ server/mpm/motorz/ server/mpm/simple/

On Tue, Oct 6, 2015 at 7:00 PM, Yann Ylavic wrote: > On Tue, Oct 6, 2015 at 6:29 PM, Yann Ylavic wrote: >> >> all tests pass now. > > I spoke too soon... > > New segfault is in mod_substitute: Fixed in r1707091. Now all tests really pass :p I wonder

Re: svn commit: r1706669 - in /httpd/httpd/trunk: ./ include/ modules/http/ modules/ssl/ server/ server/mpm/event/ server/mpm/motorz/ server/mpm/simple/

On Tue, Oct 6, 2015 at 5:22 PM, Yann Ylavic wrote: > still the new filter should probably work > with the existing... s/new filter/new filter stack mechanism/

Re: svn commit: r1706669 - in /httpd/httpd/trunk: ./ include/ modules/http/ modules/ssl/ server/ server/mpm/event/ server/mpm/motorz/ server/mpm/simple/

Thanks Graham for this great patch, comments inline... On Sun, Oct 4, 2015 at 12:10 PM, wrote: > Author: minfrin > Date: Sun Oct 4 10:10:51 2015 > New Revision: 1706669 > > URL: http://svn.apache.org/viewvc?rev=1706669=rev > Log: > core: Extend support for asynchronous