On Sun, Oct 4, 2015 at 12:10 PM, <[email protected]> wrote: > Author: minfrin > Date: Sun Oct 4 10:10:51 2015 > New Revision: 1706669 > > URL: http://svn.apache.org/viewvc?rev=1706669&view=rev > 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 ../nptl/sysdeps/unix/sysv/linux/raise.c:64 #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 malloc.c:5174 #5 0x00007f1984c16b78 in _int_free (av=0x7f1984f04e40, p=0xc9f140) at malloc.c:5047 #6 0x00007f1984c1a01c in *__GI___libc_free (mem=<optimized out>) at malloc.c:3739 #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 memory/unix/apr_pools.c:1016 #9 0x0000000000459dcf in eor_bucket_destroy (data=0xc91180) at eor_bucket.c:90 #10 0x00007f19859a6517 in apr_brigade_cleanup (data=0xc99b40) at buckets/apr_brigade.c:51 #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 http_request.c:371 #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 http_core.c:251 #16 0x0000000000478bf5 in ap_run_process_connection (c=0xb21168) at connection.c:41 #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 threadproc/unix/thread.c:145 #21 0x00007f198533b8ca in start_thread (arg=<optimized out>) at pthread_create.c:300 #22 0x00007f1984c7608d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:112 #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); 276 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); 284 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... Regards, Yann.
