httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Graham Leggett <>
Subject Re: svn commit: r1706669 - in /httpd/httpd/trunk: ./ include/ modules/http/ modules/ssl/ server/ server/mpm/event/ server/mpm/motorz/ server/mpm/simple/
Date Tue, 06 Oct 2015 15:34:27 GMT
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 copy of the EOR bucket (as any METADATA bucket) for its own
> brigade when it sees it.
> Then the request gets destroyed twice (once per brigade it is in) on cleanup.
> I fail to see where your patch comes into play here though, for now.
> I also suspect EOR buckets shouldn't be copyable anyway, and bucketeer
> should do the right thing, still the new filter should probably work
> with the existing...

The core used to inject EOR buckets into the connection filters, bypassing the request filters.
Now that request filters can buffer data, injecting EOR into the connection filters causes
the end of requests to be chopped off, so now EOR is injected at the very end of the last
request filter, as it should have been.

In theory none of this should matter, if EOR is copied it should set up the proper cleanups
to clean up the second copy. A quick look at eor_bucket.c shows the following:

AP_DECLARE_DATA const apr_bucket_type_t ap_bucket_type_eor = {

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 containing the pool) I see nothing that would prevent an attempt
to free the pool twice.


View raw message