On 06 Oct 2015, at 5:22 PM, Yann Ylavic <ylavic....@gmail.com> 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 = {
"EOR", 5, APR_BUCKET_METADATA,
eor_bucket_destroy,
eor_bucket_read,
apr_bucket_setaside_noop,
apr_bucket_split_notimpl,
apr_bucket_simple_copy
};
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.
Regards,
Graham
—
