httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefan Eissing <>
Subject Re: h2 EOC (was: [Bug 59840] Segmentation fault during the request processing)
Date Thu, 25 Aug 2016 12:43:04 GMT
While the patch looks fine, the backtrace points to termination
on a slave connection, not the main one.

The cleanup of the EOR bucket is triggered by the cleanup in ap_process_request_after_handler.
This happens only if the ap_pass_brigade() before that did not actually move the EOR bucket.
Hmm. That may happen if there was an error writing to the slave connection, e.g. a timeout
or the main connection being aborted. But I still do not see how that crashes things...

Some more wild test cases needed, it seems.

> Am 25.08.2016 um 14:28 schrieb Yann Ylavic <>:
> On Mon, Aug 15, 2016 at 4:49 AM,  <> wrote:
>> --- Comment #10 from Konstantin J. Chernov <> ---
>> Right after enabling http2 again, got a few more segfaults :(
>> Here's the latest one (+2 more with the same backtraces as in my previous
>> comments):
>>> ::stack
>> eor_bucket_destroy+0x2a()
>> ap_process_request_after_handler+0xc6()
>> ap_process_async_request+0x79f()
>> ap_process_request+0x24()
>> ap_run_process_connection+0x61()
> I wonder if this crash (and some others in the same 59840) could be
> caused by how we flush the h2_bucket_eoc in
> h2_conn_io.c::pass_output().
> Currently the flush_bucket follows h2_bucket_eoc, so possibly the
> buckets could be flushed after eoc/io is freed, with dangling buckets?
> Maybe someting like the attached patch is safer, by first flushing
> (and cleanup the brigade for any leftover), and then send the eoc
> bucket alone?
> Regards,
> Yann.
> <h2_eoc.patch>

View raw message