httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefan Eissing <stefan.eiss...@greenbytes.de>
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 <ylavic.dev@gmail.com>:
> 
> On Mon, Aug 15, 2016 at 4:49 AM,  <bugzilla@apache.org> wrote:
>> https://bz.apache.org/bugzilla/show_bug.cgi?id=59840
>> 
>> --- Comment #10 from Konstantin J. Chernov <k.j.chernov@gmail.com> ---
>> 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
>> libaprutil-1.so.0.5.4`apr_brigade_cleanup+0x43()
>> libaprutil-1.so.0.5.4`brigade_cleanup+0x18()
>> libapr-1.so.0.5.2`run_cleanups+0x3c()
>> libapr-1.so.0.5.2`apr_pool_destroy+0x57()
>> eor_bucket_destroy+0x2a()
>> libaprutil-1.so.0.5.4`apr_brigade_cleanup+0x60()
>> ap_process_request_after_handler+0xc6()
>> ap_process_async_request+0x79f()
>> ap_process_request+0x24()
>> mod_http2.so`h2_task_process_request+0x3fd()
>> mod_http2.so`h2_task_process_conn+0x228()
>> ap_run_process_connection+0x61()
>> mod_http2.so`h2_task_do+0x5e2()
>> mod_http2.so`execute+0x50()
>> libapr-1.so.0.5.2`dummy_worker+0x30()
>> libc.so.1`_thr_setup+0x5b()
>> libc.so.1`_lwp_start()
> 
> 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>


Mime
View raw message