httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Yann Ylavic <>
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 13:32:09 GMT
On Sun, Oct 4, 2015 at 12:10 PM,  <> wrote:
> Author: minfrin
> Date: Sun Oct  4 10:10:51 2015
> New Revision: 1706669
> URL:
> Log:
> core: Extend support for asynchronous write completion from the
> network filter to any connection or request filter.

Just wanted to run the tests framework on trunk for a local change but
it seems that this commit (bisected to) makes many tests to segfault.

Here is the backtrace:

Program terminated with signal 6, Aborted.
(gdb) bt
#0  0x00007f1984bd1ed5 in *__GI_raise (sig=<optimized out>) at
#1  0x00007f1984bd4ce0 in *__GI_abort () at abort.c:92
#2  0x00007f1984c0b9db in __libc_message (do_abort=<optimized out>,
fmt=<optimized out>) at ../sysdeps/unix/sysv/linux/libc_fatal.c:189
#3  0x00007f1984c15236 in malloc_printerr (action=3,
str=0x7f1984ccce7e "corrupted double-linked list", ptr=<optimized
out>) at malloc.c:6296
#4  0x00007f1984c1566d in malloc_consolidate (av=<optimized out>) at
#5  0x00007f1984c16b78 in _int_free (av=0x7f1984f04e40, p=0xc9f140) at
#6  0x00007f1984c1a01c in *__GI___libc_free (mem=<optimized out>) at
#7  0x00007f19859dad6f in allocator_free (allocator=0x9cf580,
node=0xc9f150) at memory/unix/apr_pools.c:474
#8  0x00007f19859db527 in apr_pool_destroy (pool=0xc91108) at
#9  0x0000000000459dcf in eor_bucket_destroy (data=0xc91180) at eor_bucket.c:90
#10 0x00007f19859a6517 in apr_brigade_cleanup (data=0xc99b40) at
#11 0x0000000000488c20 in ap_process_request_after_handler
(r=0xc91180) at http_request.c:283
#12 0x0000000000488f2c in ap_process_async_request (r=0xc91180) at
#13 0x0000000000488f58 in ap_process_request (r=0xc91180) at http_request.c:381
#14 0x0000000000485190 in ap_process_http_sync_connection (c=0xb21168)
at http_core.c:210
#15 0x000000000048529e in ap_process_http_connection (c=0xb21168) at
#16 0x0000000000478bf5 in ap_run_process_connection (c=0xb21168) at
#17 0x00000000004790d7 in ap_process_connection (c=0xb21168,
csd=0xb20f50) at connection.c:206
#18 0x00007f197bb3b8fb in process_socket (thd=0x944940, p=0xb20ec8,
sock=0xb20f50, my_child_num=0, my_thread_num=0, bucket_alloc=0xc4aed8)
at worker.c:632
#19 0x00007f197bb3c576 in worker_thread (thd=0x944940, dummy=0x9c8b90)
at worker.c:992
#20 0x00007f19859ea6af in dummy_worker (opaque=0x944940) at
#21 0x00007f198533b8ca in start_thread (arg=<optimized out>) at
#22 0x00007f1984c7608d in clone () at
#23 0x0000000000000000 in ?? ()
(gdb) frame 11
#11 0x0000000000488c20 in ap_process_request_after_handler
(r=0xc91180) at http_request.c:283
283         apr_brigade_cleanup(bb);
(gdb) l 280
275         ap_pass_brigade(r->output_filters, bb);
277         /* The EOR bucket has either been handled by an output filter (eg.
278          * deleted or moved to a buffered_bb => no more in bb), or an error
279          * occured before that (eg. c->aborted => still in bb) and we ought
280          * to destroy it now. So cleanup any remaining bucket along with
281          * the orphan request (if any).
282          */
283         apr_brigade_cleanup(bb);

So it seems to relate to the EOR bucket, first not being passed
through, and second leading to a double-free or alike.

Did not investigate further...


View raw message