httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Yann Ylavic <ylavic....@gmail.com>
Subject Re: svn commit: r1707087 - /httpd/httpd/trunk/modules/debugging/mod_bucketeer.c
Date Tue, 14 Feb 2017 13:02:41 GMT
Hi Jacob,

On Wed, Feb 8, 2017 at 2:16 AM, Jacob Champion <champion.p@gmail.com> wrote:
> On 10/06/2015 09:30 AM, ylavic@apache.org wrote:
>>
>> Author: ylavic
>> Date: Tue Oct  6 16:30:53 2015
>> New Revision: 1707087
>>
>> URL: http://svn.apache.org/viewvc?rev=1707087&view=rev
>> Log:
>> mod_bucketeer: cleanup properly on EOS and write.
>
>
> Hey Yann,
>
> I've started testing reallyall builds of trunk, which are currently
> segfaulting in the middle of mod_info tests.

Hmm, mod_bucketeer is not involved for me in mod_info's test, strange...

> A bisect points to this commit
> to mod_bucketeer, back in 2015. Reverting it makes everything run smoothly.

This commits looks good to me, once the buckets are passed down the
chain they can be normally be cleared (it's up to the next filters to
copy/setaside if they need to).
If this new "apr_brigade_cleanup(ctx->bb);" raises the crash
(indirectly?), there is something very wrong in the filter chain.

>
> Any idea what's going wrong? Seems like mod_bucketeer is messing with the
> brigade in a way mod_info doesn't expect.

I can't reproduce unfortunately, and my breakpoint(s) in mod_bucketeer
don't show up with mod_info test.

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 like that with
gdb, though)...

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 shouldn't be an issue since anyway nothing should
use them once the request is destroyed.

Do you have a backtrace of the crash (and/or a breakpoint in
bucketeer_out_filter() for the test)?
It would be interesting to "dump_brigade bb" there before it happens,
which bucket(s) from where are involved/cleared...

We could probably patch some places to safely clear passed out
brigades, but it would be nice to determine first where this failure
comes from...


Thanks,
Yann.

Mime
View raw message