Revert "Fix our documentation to not show the expression in Require expr... #9

ghost · 2014-04-08T01:44:49Z

... as quoted."

This reverts commit 407db4e.

…xpr as quoted." This reverts commit 407db4e.

MPMs event and worker both need a dedicated pool to handle the creation of the threads (listener, workers) and synchronization objects (queues, pollset, mutexes...) in the start_threads() thread, with at least the lifetime of the connections they handle, and thus survive pchild destruction (notably in ONE_PROCCESS mode, but SIG_UNGRACEFUL is concerned too). For instance, without this fix, the below backtrace can happen in ONE_PROCCESS mode and a signal/^C is received (with active connections): Thread 1 "httpd" received signal SIGSEGV, Segmentation fault. (gdb) bt #0 <BOOM> #1 0x00007ffff7c7e016 in apr_file_write (thefile=0x0, ...) ^ NULL (cleared) at file_io/unix/readwrite.c:230 #2 0x00007ffff7c7e4a7 in apr_file_putc (ch=1 '\001', thefile=0x0) ^ NULL (cleared) at file_io/unix/readwrite.c:377 #3 0x00007ffff7c8da4a in apr_pollset_wakeup (pollset=0x55555568b870) ^ already destroyed by pchild at poll/unix/pollset.c:224 #4 0x00007ffff7fc16c7 in decrement_connection_count (cs_=0x7fff08000ea0) at event.c:811 #5 0x00007ffff7c83e15 in run_cleanups (cref=0x7fffe4002b78) at memory/unix/apr_pools.c:2672 #6 0x00007ffff7c82c2f in apr_pool_destroy (pool=0x7fffe4002b58) ^ master_conn at memory/unix/apr_pools.c:1007 #7 0x00007ffff7c82c12 in apr_pool_destroy (pool=0x7fff08000c28) ^ ptrans at memory/unix/apr_pools.c:1004 #8 0x00007ffff7c82c12 in apr_pool_destroy (pool=0x555555638698) ^ pconf at memory/unix/apr_pools.c:1004 #9 0x00007ffff7c82c12 in apr_pool_destroy (pool=0x555555636688) ^ pglobal at memory/unix/apr_pools.c:1004 #10 0x00005555555f4709 in ap_terminate () at unixd.c:522 #11 0x00007ffff6dbc8f1 in __run_exit_handlers (...) at exit.c:108 #12 0x00007ffff6dbc9ea in __GI_exit (status=<optimized out>) at exit.c:139 #13 0x00007ffff7fc1616 in clean_child_exit (code=0) at event.c:774 ^ pchild already destroyed here #14 0x00007ffff7fc5ae4 in child_main (child_num_arg=0, child_bucket=0) at event.c:2869 ... While at it, add comments about the lifetimes of MPMs pools and their objects, and give each pool a tag (e.g. "pchild" accordingly to other MPMs). git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@1835845 13f79535-47bb-0310-9956-ffa450edef68

MPMs event and worker both need a dedicated pool to handle the creation of the threads (listener, workers) and synchronization objects (queues, pollset, mutexes...) in the start_threads() thread, with at least the lifetime of the connections they handle, and thus survive pchild destruction (notably in ONE_PROCCESS mode, but SIG_UNGRACEFUL is concerned too). For instance, without this fix, the below backtrace can happen in ONE_PROCCESS mode and a signal/^C is received (with active connections): Thread 1 "httpd" received signal SIGSEGV, Segmentation fault. (gdb) bt #0 <BOOM> #1 0x00007ffff7c7e016 in apr_file_write (thefile=0x0, ...) ^ NULL (cleared) at file_io/unix/readwrite.c:230 #2 0x00007ffff7c7e4a7 in apr_file_putc (ch=1 '\001', thefile=0x0) ^ NULL (cleared) at file_io/unix/readwrite.c:377 #3 0x00007ffff7c8da4a in apr_pollset_wakeup (pollset=0x55555568b870) ^ already destroyed by pchild at poll/unix/pollset.c:224 #4 0x00007ffff7fc16c7 in decrement_connection_count (cs_=0x7fff08000ea0) at event.c:811 #5 0x00007ffff7c83e15 in run_cleanups (cref=0x7fffe4002b78) at memory/unix/apr_pools.c:2672 #6 0x00007ffff7c82c2f in apr_pool_destroy (pool=0x7fffe4002b58) ^ master_conn at memory/unix/apr_pools.c:1007 #7 0x00007ffff7c82c12 in apr_pool_destroy (pool=0x7fff08000c28) ^ ptrans at memory/unix/apr_pools.c:1004 #8 0x00007ffff7c82c12 in apr_pool_destroy (pool=0x555555638698) ^ pconf at memory/unix/apr_pools.c:1004 #9 0x00007ffff7c82c12 in apr_pool_destroy (pool=0x555555636688) ^ pglobal at memory/unix/apr_pools.c:1004 #10 0x00005555555f4709 in ap_terminate () at unixd.c:522 #11 0x00007ffff6dbc8f1 in __run_exit_handlers (...) at exit.c:108 #12 0x00007ffff6dbc9ea in __GI_exit (status=<optimized out>) at exit.c:139 #13 0x00007ffff7fc1616 in clean_child_exit (code=0) at event.c:774 ^ pchild already destroyed here #14 0x00007ffff7fc5ae4 in child_main (child_num_arg=0, child_bucket=0) at event.c:2869 ... While at it, add comments about the lifetimes of MPMs pools and their objects, and give each pool a tag (e.g. "pchild" accordingly to other MPMs). (follow up for event_pollset in r1835846). git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@1835845 13f79535-47bb-0310-9956-ffa450edef68

When enabling client authentication for proxy (SSLProxyMachineCertificateFile), the client certificate callback function ssl_callback_proxy_cert uses another reference count locking type then one that is used by the caller function when trying to free the private key afterwards by using EVP_PKEY_free. This can lead to a race-condition on pkey->references resulting in a double free error. On my system, the error occurs sporadically when threaded health checking (mod_watchdog) forces two threads competing for the client's private key. For example, see following two backtraces of a coredump where thread 1 and thread 15 both run into CRYPTO_free(). Actually, the private key should never be freed during run-time nor should two threads ever enter CRYPTO_free() concurrently. (gdb) t 1 [Switching to thread 1 (Thread 0xb2cfbb40 (LWP 16054))] #0 0xf7f3f329 in __kernel_vsyscall () (gdb) bt #0 0xf7f3f329 in __kernel_vsyscall () #1 0xf7cec9e7 in raise () from /lib32/libc.so.6 #2 0xf7cedfb9 in abort () from /lib32/libc.so.6 #3 0xf7d2a14d in ?? () from /lib32/libc.so.6 #4 0xf7d2fd27 in ?? () from /lib32/libc.so.6 #5 0xf7d3047d in ?? () from /lib32/libc.so.6 #6 0x08499c70 in CRYPTO_free (str=0x93376b0) at mem.c:434 #7 0x084cc063 in EVP_PKEY_free (x=0x93376b0) at p_lib.c:406 #8 0x08463917 in ssl3_send_client_certificate (s=0xad21f070) at s3_clnt.c:3475 #9 0x0845d62c in ssl3_connect (s=0xad21f070) at s3_clnt.c:426 #10 0x08484213 in SSL_connect (s=0xad21f070) at ssl_lib.c:1008 #11 0x0846f9c8 in ssl23_get_server_hello (s=0xad21f070) at s23_clnt.c:832 #12 0x0846ea45 in ssl23_connect (s=0xad21f070) at s23_clnt.c:231 #13 0x08484213 in SSL_connect (s=0xad21f070) at ssl_lib.c:1008 #14 0x08261e73 in ssl_io_filter_handshake (filter_ctx=0xb4d3f450) at ssl_engine_io.c:1245 #15 0x08263ba6 in ssl_io_filter_output (f=0xb4d3f480, bb=0xacc079a0) at ssl_engine_io.c:1760 #16 0x080ea2c9 in ap_pass_brigade (next=0xb4d3f480, bb=0xacc079a0) at util_filter.c:590 #17 0x08263b07 in ssl_io_filter_coalesce (f=0xb4d3f468, bb=0xacc079a0) at ssl_engine_io.c:1728 #18 0x080ea2c9 in ap_pass_brigade (next=0xb4d3f468, bb=0xacc079a0) at util_filter.c:590 #19 0x08251658 in hc_send (r=0xacc069b0, out=0x8c25ec8 "GET /hcheck HTTP/1.0\r\nHost: XXX\r\n\r\n", bb=0xacc079a0) at mod_proxy_hcheck.c:664 #20 0x08251eb3 in hc_check_http (baton=0xacc068d8) at mod_proxy_hcheck.c:806 #21 0x08252653 in hc_check (thread=0x8cc6b10, b=0xacc068d8) at mod_proxy_hcheck.c:870 #22 0x08383185 in thread_pool_func (t=0x8cc6b10, param=0x8c245e0) at misc/apr_thread_pool.c:266 #23 0x083baef6 in dummy_worker (opaque=0x8cc6b10) at threadproc/unix/thread.c:142 #24 0xf7ec615f in start_thread () from /lib32/libpthread.so.0 #25 0xf7da862e in clone () from /lib32/libc.so.6 (gdb) t 15 [Switching to thread 15 (Thread 0xb44feb40 (LWP 16049))] #0 0xf7dd90a5 in _dl_addr () from /lib32/libc.so.6 (gdb) bt #0 0xf7dd90a5 in _dl_addr () from /lib32/libc.so.6 #1 0xf7db610c in backtrace_symbols_fd () from /lib32/libc.so.6 #2 0xf7cd89ab in ?? () from /lib32/libc.so.6 #3 0xf7d2a148 in ?? () from /lib32/libc.so.6 #4 0xf7d2fd27 in ?? () from /lib32/libc.so.6 #5 0xf7d3047d in ?? () from /lib32/libc.so.6 #6 0x08499c70 in CRYPTO_free (str=0x93376b0) at mem.c:434 #7 0x084cc063 in EVP_PKEY_free (x=0x93376b0) at p_lib.c:406 #8 0x08463917 in ssl3_send_client_certificate (s=0xacf1baa0) at s3_clnt.c:3475 #9 0x0845d62c in ssl3_connect (s=0xacf1baa0) at s3_clnt.c:426 #10 0x08484213 in SSL_connect (s=0xacf1baa0) at ssl_lib.c:1008 #11 0x0846f9c8 in ssl23_get_server_hello (s=0xacf1baa0) at s23_clnt.c:832 #12 0x0846ea45 in ssl23_connect (s=0xacf1baa0) at s23_clnt.c:231 #13 0x08484213 in SSL_connect (s=0xacf1baa0) at ssl_lib.c:1008 #14 0x08261e73 in ssl_io_filter_handshake (filter_ctx=0xb4d37430) at ssl_engine_io.c:1245 #15 0x08263ba6 in ssl_io_filter_output (f=0xb4d37460, bb=0xad101588) at ssl_engine_io.c:1760 #16 0x080ea2c9 in ap_pass_brigade (next=0xb4d37460, bb=0xad101588) at util_filter.c:590 #17 0x08263b07 in ssl_io_filter_coalesce (f=0xb4d37448, bb=0xad101588) at ssl_engine_io.c:1728 #18 0x080ea2c9 in ap_pass_brigade (next=0xb4d37448, bb=0xad101588) at util_filter.c:590 #19 0x08251658 in hc_send (r=0xad100598, out=0x8c25898 "GET /hcheck HTTP/1.0\r\nHost: XXX\r\n\r\n", bb=0xad101588) at mod_proxy_hcheck.c:664 #20 0x08251eb3 in hc_check_http (baton=0xad1004c0) at mod_proxy_hcheck.c:806 #21 0x08252653 in hc_check (thread=0x8cc6ab0, b=0xad1004c0) at mod_proxy_hcheck.c:870 #22 0x08383185 in thread_pool_func (t=0x8cc6ab0, param=0x8c245e0) at misc/apr_thread_pool.c:266 #23 0x083baef6 in dummy_worker (opaque=0x8cc6ab0) at threadproc/unix/thread.c:142 #24 0xf7ec615f in start_thread () from /lib32/libpthread.so.0 #25 0xf7da862e in clone () from /lib32/libc.so.6 Many thanks to Armin for finding this. Github: closes #129 Submitted by: Armin Abfalterer (arminabf) Reviewed by: ylavic git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@1879179 13f79535-47bb-0310-9956-ffa450edef68

EVP_PKEY_up_ref(): fix ref count locking type for proxy EVP pkey When enabling client authentication for proxy (SSLProxyMachineCertificateFile), the client certificate callback function ssl_callback_proxy_cert uses another reference count locking type then one that is used by the caller function when trying to free the private key afterwards by using EVP_PKEY_free. This can lead to a race-condition on pkey->references resulting in a double free error. On my system, the error occurs sporadically when threaded health checking (mod_watchdog) forces two threads competing for the client's private key. For example, see following two backtraces of a coredump where thread 1 and thread 15 both run into CRYPTO_free(). Actually, the private key should never be freed during run-time nor should two threads ever enter CRYPTO_free() concurrently. (gdb) t 1 [Switching to thread 1 (Thread 0xb2cfbb40 (LWP 16054))] #0 0xf7f3f329 in __kernel_vsyscall () (gdb) bt #0 0xf7f3f329 in __kernel_vsyscall () #1 0xf7cec9e7 in raise () from /lib32/libc.so.6 #2 0xf7cedfb9 in abort () from /lib32/libc.so.6 #3 0xf7d2a14d in ?? () from /lib32/libc.so.6 #4 0xf7d2fd27 in ?? () from /lib32/libc.so.6 #5 0xf7d3047d in ?? () from /lib32/libc.so.6 #6 0x08499c70 in CRYPTO_free (str=0x93376b0) at mem.c:434 #7 0x084cc063 in EVP_PKEY_free (x=0x93376b0) at p_lib.c:406 #8 0x08463917 in ssl3_send_client_certificate (s=0xad21f070) at s3_clnt.c:3475 #9 0x0845d62c in ssl3_connect (s=0xad21f070) at s3_clnt.c:426 #10 0x08484213 in SSL_connect (s=0xad21f070) at ssl_lib.c:1008 #11 0x0846f9c8 in ssl23_get_server_hello (s=0xad21f070) at s23_clnt.c:832 #12 0x0846ea45 in ssl23_connect (s=0xad21f070) at s23_clnt.c:231 #13 0x08484213 in SSL_connect (s=0xad21f070) at ssl_lib.c:1008 #14 0x08261e73 in ssl_io_filter_handshake (filter_ctx=0xb4d3f450) at ssl_engine_io.c:1245 #15 0x08263ba6 in ssl_io_filter_output (f=0xb4d3f480, bb=0xacc079a0) at ssl_engine_io.c:1760 #16 0x080ea2c9 in ap_pass_brigade (next=0xb4d3f480, bb=0xacc079a0) at util_filter.c:590 #17 0x08263b07 in ssl_io_filter_coalesce (f=0xb4d3f468, bb=0xacc079a0) at ssl_engine_io.c:1728 #18 0x080ea2c9 in ap_pass_brigade (next=0xb4d3f468, bb=0xacc079a0) at util_filter.c:590 #19 0x08251658 in hc_send (r=0xacc069b0, out=0x8c25ec8 "GET /hcheck HTTP/1.0\r\nHost: XXX\r\n\r\n", bb=0xacc079a0) at mod_proxy_hcheck.c:664 #20 0x08251eb3 in hc_check_http (baton=0xacc068d8) at mod_proxy_hcheck.c:806 #21 0x08252653 in hc_check (thread=0x8cc6b10, b=0xacc068d8) at mod_proxy_hcheck.c:870 #22 0x08383185 in thread_pool_func (t=0x8cc6b10, param=0x8c245e0) at misc/apr_thread_pool.c:266 #23 0x083baef6 in dummy_worker (opaque=0x8cc6b10) at threadproc/unix/thread.c:142 #24 0xf7ec615f in start_thread () from /lib32/libpthread.so.0 #25 0xf7da862e in clone () from /lib32/libc.so.6 (gdb) t 15 [Switching to thread 15 (Thread 0xb44feb40 (LWP 16049))] #0 0xf7dd90a5 in _dl_addr () from /lib32/libc.so.6 (gdb) bt #0 0xf7dd90a5 in _dl_addr () from /lib32/libc.so.6 #1 0xf7db610c in backtrace_symbols_fd () from /lib32/libc.so.6 #2 0xf7cd89ab in ?? () from /lib32/libc.so.6 #3 0xf7d2a148 in ?? () from /lib32/libc.so.6 #4 0xf7d2fd27 in ?? () from /lib32/libc.so.6 #5 0xf7d3047d in ?? () from /lib32/libc.so.6 #6 0x08499c70 in CRYPTO_free (str=0x93376b0) at mem.c:434 #7 0x084cc063 in EVP_PKEY_free (x=0x93376b0) at p_lib.c:406 #8 0x08463917 in ssl3_send_client_certificate (s=0xacf1baa0) at s3_clnt.c:3475 #9 0x0845d62c in ssl3_connect (s=0xacf1baa0) at s3_clnt.c:426 #10 0x08484213 in SSL_connect (s=0xacf1baa0) at ssl_lib.c:1008 #11 0x0846f9c8 in ssl23_get_server_hello (s=0xacf1baa0) at s23_clnt.c:832 #12 0x0846ea45 in ssl23_connect (s=0xacf1baa0) at s23_clnt.c:231 #13 0x08484213 in SSL_connect (s=0xacf1baa0) at ssl_lib.c:1008 #14 0x08261e73 in ssl_io_filter_handshake (filter_ctx=0xb4d37430) at ssl_engine_io.c:1245 #15 0x08263ba6 in ssl_io_filter_output (f=0xb4d37460, bb=0xad101588) at ssl_engine_io.c:1760 #16 0x080ea2c9 in ap_pass_brigade (next=0xb4d37460, bb=0xad101588) at util_filter.c:590 #17 0x08263b07 in ssl_io_filter_coalesce (f=0xb4d37448, bb=0xad101588) at ssl_engine_io.c:1728 #18 0x080ea2c9 in ap_pass_brigade (next=0xb4d37448, bb=0xad101588) at util_filter.c:590 #19 0x08251658 in hc_send (r=0xad100598, out=0x8c25898 "GET /hcheck HTTP/1.0\r\nHost: XXX\r\n\r\n", bb=0xad101588) at mod_proxy_hcheck.c:664 #20 0x08251eb3 in hc_check_http (baton=0xad1004c0) at mod_proxy_hcheck.c:806 #21 0x08252653 in hc_check (thread=0x8cc6ab0, b=0xad1004c0) at mod_proxy_hcheck.c:870 #22 0x08383185 in thread_pool_func (t=0x8cc6ab0, param=0x8c245e0) at misc/apr_thread_pool.c:266 #23 0x083baef6 in dummy_worker (opaque=0x8cc6ab0) at threadproc/unix/thread.c:142 #24 0xf7ec615f in start_thread () from /lib32/libpthread.so.0 #25 0xf7da862e in clone () from /lib32/libc.so.6 Many thanks to Armin for finding this. Github: closes #129 Submitted by: Armin Abfalterer (arminabf) Reviewed by: ylavic Follow up to r1879179: CHANGES entry. Reviewed by: ylavic, jorton, rpluem git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/branches/2.4.x@1879224 13f79535-47bb-0310-9956-ffa450edef68

…illed. There shouldn't be any worker thread active when pchild is destroyed (thus each thread's pool), so register workers_pool_cleanup as a pre_cleanup of pchild. This is to avoid races like the below stacktrace, where slot_run() threads are still running when clean_child_exit() is called. Thread 23 (Thread 0x7f4865b79800 (LWP 3740)): #0 0x00007f4864dec449 in pthread_cond_destroy@@GLIBC_2.3.2 () from /lib/x86_64-linux-gnu/libpthread.so.0 #1 0x00007f4865020117 in run_cleanups (cref=<optimized out>) at memory/unix/apr_pools.c:2629 #2 pool_clear_debug (pool=pool@entry=0x558a5297e4a0, file_line=0x558a5237456b "event.c:757") at memory/unix/apr_pools.c:1830 #3 0x00007f486501ffee in pool_destroy_debug (pool=0x558a5297e4a0, file_line=<optimized out>) at memory/unix/apr_pools.c:1915 #4 0x00007f48650200f0 in pool_clear_debug (pool=pool@entry=0x558a52a41070, file_line=0x558a5237456b "event.c:757") at memory/unix/apr_pools.c:1827 #5 0x00007f486501ffee in pool_destroy_debug (pool=0x558a52a41070, file_line=<optimized out>) at memory/unix/apr_pools.c:1915 #6 0x00007f486502085c in apr_pool_destroy_debug (pool=<optimized out>, file_line=<optimized out>) at memory/unix/apr_pools.c:1957 #7 0x0000558a52326cfc in clean_child_exit (code=0) at event.c:757 #8 0x0000558a52327969 in child_main (child_num_arg=child_num_arg@entry=1, child_bucket=child_bucket@entry=0) at event.c:2926 #9 0x0000558a52327ce5 in make_child (s=0x558a52c9f840, slot=slot@entry=1, bucket=0) at event.c:2992 #10 0x0000558a52327d4c in startup_children (number_to_start=2, number_to_start@entry=3) at event.c:3015 #11 0x0000558a523289ac in event_run (_pconf=<optimized out>, plog=0x558a5273ce00, s=0x558a52c9f840) at event.c:3374 #12 0x0000558a5233e91e in ap_run_mpm (pconf=0x558a5270cbe0, plog=0x558a5273ce00, s=0x558a52c9f840) at mpm_common.c:100 #13 0x0000558a5231b763 in main (argc=<optimized out>, argv=<optimized out>) at main.c:844 Thread 2 (Thread 0x7f4840b70700 (LWP 3836)): #0 0x00007f4864dec9f3 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/x86_64-linux-gnu/libpthread.so.0 #1 0x00007f486501f65d in apr_thread_cond_wait (cond=<optimized out>, mutex=<optimized out>) at locks/unix/thread_cond.c:68 #2 0x00007f484e14ae4a in get_next (slot=0x558a528d5fe0) at h2_workers.c:209 #3 slot_run (thread=0x558a52828b30, wctx=0x558a528d5fe0) at h2_workers.c:228 #4 0x00007f4864de66db in start_thread () from /lib/x86_64-linux-gnu/libpthread.so.0 #5 0x00007f4864b0f88f in clone () from /lib/x86_64-linux-gnu/libc.so.6 Thread 1 (Thread 0x7f4841b72700 (LWP 3834)): #0 0x00007f4864a2ce97 in raise () from /lib/x86_64-linux-gnu/libc.so.6 #1 0x00007f4864a2e801 in abort () from /lib/x86_64-linux-gnu/libc.so.6 #2 0x00007f4865020865 in apr_pool_destroy_debug (pool=<optimized out>, file_line=<optimized out>) at memory/unix/apr_pools.c:1955 #3 0x00007f486502b536 in apr_thread_exit (thd=thd@entry=0x558a52ba8980, retval=retval@entry=0) at threadproc/unix/thread.c:206 #4 0x00007f484e14aec6 in slot_run (thread=0x558a52ba8980, wctx=0x558a528d6060) at h2_workers.c:248 #5 0x00007f4864de66db in start_thread () from /lib/x86_64-linux-gnu/libpthread.so.0 #6 0x00007f4864b0f88f in clone () from /lib/x86_64-linux-gnu/libc.so.6 While at it, rename server_pool as pchild in h2_workers_create(), to make it clear which pool it is. git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@1883675 13f79535-47bb-0310-9956-ffa450edef68

…illed. There shouldn't be any worker thread active when pchild is destroyed (thus each thread's pool), so register workers_pool_cleanup as a pre_cleanup of pchild. This is to avoid races like the below stacktrace, where slot_run() threads are still running when clean_child_exit() is called. Thread 23 (Thread 0x7f4865b79800 (LWP 3740)): #0 0x00007f4864dec449 in pthread_cond_destroy@@GLIBC_2.3.2 () from /lib/x86_64-linux-gnu/libpthread.so.0 #1 0x00007f4865020117 in run_cleanups (cref=<optimized out>) at memory/unix/apr_pools.c:2629 #2 pool_clear_debug (pool=pool@entry=0x558a5297e4a0, file_line=0x558a5237456b "event.c:757") at memory/unix/apr_pools.c:1830 #3 0x00007f486501ffee in pool_destroy_debug (pool=0x558a5297e4a0, file_line=<optimized out>) at memory/unix/apr_pools.c:1915 #4 0x00007f48650200f0 in pool_clear_debug (pool=pool@entry=0x558a52a41070, file_line=0x558a5237456b "event.c:757") at memory/unix/apr_pools.c:1827 #5 0x00007f486501ffee in pool_destroy_debug (pool=0x558a52a41070, file_line=<optimized out>) at memory/unix/apr_pools.c:1915 #6 0x00007f486502085c in apr_pool_destroy_debug (pool=<optimized out>, file_line=<optimized out>) at memory/unix/apr_pools.c:1957 #7 0x0000558a52326cfc in clean_child_exit (code=0) at event.c:757 #8 0x0000558a52327969 in child_main (child_num_arg=child_num_arg@entry=1, child_bucket=child_bucket@entry=0) at event.c:2926 #9 0x0000558a52327ce5 in make_child (s=0x558a52c9f840, slot=slot@entry=1, bucket=0) at event.c:2992 #10 0x0000558a52327d4c in startup_children (number_to_start=2, number_to_start@entry=3) at event.c:3015 #11 0x0000558a523289ac in event_run (_pconf=<optimized out>, plog=0x558a5273ce00, s=0x558a52c9f840) at event.c:3374 #12 0x0000558a5233e91e in ap_run_mpm (pconf=0x558a5270cbe0, plog=0x558a5273ce00, s=0x558a52c9f840) at mpm_common.c:100 #13 0x0000558a5231b763 in main (argc=<optimized out>, argv=<optimized out>) at main.c:844 Thread 2 (Thread 0x7f4840b70700 (LWP 3836)): #0 0x00007f4864dec9f3 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/x86_64-linux-gnu/libpthread.so.0 #1 0x00007f486501f65d in apr_thread_cond_wait (cond=<optimized out>, mutex=<optimized out>) at locks/unix/thread_cond.c:68 #2 0x00007f484e14ae4a in get_next (slot=0x558a528d5fe0) at h2_workers.c:209 #3 slot_run (thread=0x558a52828b30, wctx=0x558a528d5fe0) at h2_workers.c:228 #4 0x00007f4864de66db in start_thread () from /lib/x86_64-linux-gnu/libpthread.so.0 #5 0x00007f4864b0f88f in clone () from /lib/x86_64-linux-gnu/libc.so.6 Thread 1 (Thread 0x7f4841b72700 (LWP 3834)): #0 0x00007f4864a2ce97 in raise () from /lib/x86_64-linux-gnu/libc.so.6 #1 0x00007f4864a2e801 in abort () from /lib/x86_64-linux-gnu/libc.so.6 #2 0x00007f4865020865 in apr_pool_destroy_debug (pool=<optimized out>, file_line=<optimized out>) at memory/unix/apr_pools.c:1955 #3 0x00007f486502b536 in apr_thread_exit (thd=thd@entry=0x558a52ba8980, retval=retval@entry=0) at threadproc/unix/thread.c:206 #4 0x00007f484e14aec6 in slot_run (thread=0x558a52ba8980, wctx=0x558a528d6060) at h2_workers.c:248 #5 0x00007f4864de66db in start_thread () from /lib/x86_64-linux-gnu/libpthread.so.0 #6 0x00007f4864b0f88f in clone () from /lib/x86_64-linux-gnu/libc.so.6 git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@1884170 13f79535-47bb-0310-9956-ffa450edef68

mod_http2: Rename server_pool as pchild in h2_workers_create() To clarify which parent pool the workers threads have. And add a comment about workers_pool_cleanup()'s role and when it runs. No functional change. mod_http2: stop/wait the workers threads before their pool is killed. There shouldn't be any worker thread active when pchild is destroyed (thus each thread's pool), so register workers_pool_cleanup as a pre_cleanup of pchild. This is to avoid races like the below stacktrace, where slot_run() threads are still running when clean_child_exit() is called. Thread 23 (Thread 0x7f4865b79800 (LWP 3740)): #0 0x00007f4864dec449 in pthread_cond_destroy@@GLIBC_2.3.2 () from /lib/x86_64-linux-gnu/libpthread.so.0 #1 0x00007f4865020117 in run_cleanups (cref=<optimized out>) at memory/unix/apr_pools.c:2629 #2 pool_clear_debug (pool=pool@entry=0x558a5297e4a0, file_line=0x558a5237456b "event.c:757") at memory/unix/apr_pools.c:1830 #3 0x00007f486501ffee in pool_destroy_debug (pool=0x558a5297e4a0, file_line=<optimized out>) at memory/unix/apr_pools.c:1915 #4 0x00007f48650200f0 in pool_clear_debug (pool=pool@entry=0x558a52a41070, file_line=0x558a5237456b "event.c:757") at memory/unix/apr_pools.c:1827 #5 0x00007f486501ffee in pool_destroy_debug (pool=0x558a52a41070, file_line=<optimized out>) at memory/unix/apr_pools.c:1915 #6 0x00007f486502085c in apr_pool_destroy_debug (pool=<optimized out>, file_line=<optimized out>) at memory/unix/apr_pools.c:1957 #7 0x0000558a52326cfc in clean_child_exit (code=0) at event.c:757 #8 0x0000558a52327969 in child_main (child_num_arg=child_num_arg@entry=1, child_bucket=child_bucket@entry=0) at event.c:2926 #9 0x0000558a52327ce5 in make_child (s=0x558a52c9f840, slot=slot@entry=1, bucket=0) at event.c:2992 #10 0x0000558a52327d4c in startup_children (number_to_start=2, number_to_start@entry=3) at event.c:3015 #11 0x0000558a523289ac in event_run (_pconf=<optimized out>, plog=0x558a5273ce00, s=0x558a52c9f840) at event.c:3374 #12 0x0000558a5233e91e in ap_run_mpm (pconf=0x558a5270cbe0, plog=0x558a5273ce00, s=0x558a52c9f840) at mpm_common.c:100 #13 0x0000558a5231b763 in main (argc=<optimized out>, argv=<optimized out>) at main.c:844 Thread 2 (Thread 0x7f4840b70700 (LWP 3836)): #0 0x00007f4864dec9f3 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/x86_64-linux-gnu/libpthread.so.0 #1 0x00007f486501f65d in apr_thread_cond_wait (cond=<optimized out>, mutex=<optimized out>) at locks/unix/thread_cond.c:68 #2 0x00007f484e14ae4a in get_next (slot=0x558a528d5fe0) at h2_workers.c:209 #3 slot_run (thread=0x558a52828b30, wctx=0x558a528d5fe0) at h2_workers.c:228 #4 0x00007f4864de66db in start_thread () from /lib/x86_64-linux-gnu/libpthread.so.0 #5 0x00007f4864b0f88f in clone () from /lib/x86_64-linux-gnu/libc.so.6 Thread 1 (Thread 0x7f4841b72700 (LWP 3834)): #0 0x00007f4864a2ce97 in raise () from /lib/x86_64-linux-gnu/libc.so.6 #1 0x00007f4864a2e801 in abort () from /lib/x86_64-linux-gnu/libc.so.6 #2 0x00007f4865020865 in apr_pool_destroy_debug (pool=<optimized out>, file_line=<optimized out>) at memory/unix/apr_pools.c:1955 #3 0x00007f486502b536 in apr_thread_exit (thd=thd@entry=0x558a52ba8980, retval=retval@entry=0) at threadproc/unix/thread.c:206 #4 0x00007f484e14aec6 in slot_run (thread=0x558a52ba8980, wctx=0x558a528d6060) at h2_workers.c:248 #5 0x00007f4864de66db in start_thread () from /lib/x86_64-linux-gnu/libpthread.so.0 #6 0x00007f4864b0f88f in clone () from /lib/x86_64-linux-gnu/libc.so.6 Submitted by: ylavic Reviewed by: ylavic, jorton, covener git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/branches/2.4.x@1884318 13f79535-47bb-0310-9956-ffa450edef68

When the session pool is destroyed, so is the beam's pool so we don't want to run the beam cleanup twice. ASan is reporting something like this: ================================================================= ==81201==ERROR: AddressSanitizer: heap-use-after-free on address 0x603000080ce8 at pc 0x7fdc78962cc9 bp 0x7fdc731ff4f0 sp 0x7fdc731ff4e8 READ of size 8 at 0x603000080ce8 thread T11 #0 0x7fdc78962cc8 in recv_buffer_cleanup /home/yle/src/ylavic/httpd/modules/http2/h2_bucket_beam.c:279 apache#1 0x7fdc78962fdc in beam_cleanup /home/yle/src/ylavic/httpd/modules/http2/h2_bucket_beam.c:306 apache#2 0x7fdc7896300c in beam_pool_cleanup /home/yle/src/ylavic/httpd/modules/http2/h2_bucket_beam.c:313 apache#3 0x7fdc7c5a8239 in run_cleanups memory/unix/apr_pools.c:2689 apache#4 0x7fdc7c5a50f9 in pool_clear_debug memory/unix/apr_pools.c:1867 apache#5 0x7fdc7c5a562e in pool_destroy_debug memory/unix/apr_pools.c:1965 apache#6 0x7fdc7c5a5179 in pool_clear_debug memory/unix/apr_pools.c:1880 apache#7 0x7fdc7c5a562e in pool_destroy_debug memory/unix/apr_pools.c:1965 apache#8 0x7fdc7c5a5179 in pool_clear_debug memory/unix/apr_pools.c:1880 apache#9 0x7fdc7c5a562e in pool_destroy_debug memory/unix/apr_pools.c:1965 apache#10 0x7fdc7c5a5179 in pool_clear_debug memory/unix/apr_pools.c:1880 apache#11 0x7fdc7c5a562e in pool_destroy_debug memory/unix/apr_pools.c:1965 apache#12 0x7fdc7c5a5827 in apr_pool_destroy_debug memory/unix/apr_pools.c:2014 apache#13 0x7fdc789aeaa5 in h2_session_pre_close /home/yle/src/ylavic/httpd/modules/http2/h2_session.c:1934 apache#14 0x7fdc7896a20e in h2_c1_pre_close /home/yle/src/ylavic/httpd/modules/http2/h2_c1.c:188 apache#15 0x7fdc7896b538 in h2_c1_hook_pre_close /home/yle/src/ylavic/httpd/modules/http2/h2_c1.c:308 apache#16 0x5596139aeb28 in ap_run_pre_close_connection /home/yle/src/ylavic/httpd/server/connection.c:45 apache#17 0x5596139af353 in ap_prep_lingering_close /home/yle/src/ylavic/httpd/server/connection.c:128 apache#18 0x5596139af3f2 in ap_start_lingering_close /home/yle/src/ylavic/httpd/server/connection.c:154 apache#19 0x7fdc7835bdf0 in process_lingering_close /home/yle/src/ylavic/httpd/server/mpm/event/event.c:1999 apache#20 0x7fdc78359ccb in process_socket /home/yle/src/ylavic/httpd/server/mpm/event/event.c:1540 apache#21 0x7fdc783608d7 in worker_thread /home/yle/src/ylavic/httpd/server/mpm/event/event.c:2756 apache#22 0x7fdc7c5d3e57 in dummy_worker threadproc/unix/thread.c:153 apache#23 0x7fdc7c441d7f in start_thread nptl/pthread_create.c:481 apache#24 0x7fdc7c337bde in clone (/lib/x86_64-linux-gnu/libc.so.6+0xfcbde) 0x603000080ce8 is located 8 bytes inside of 32-byte region [0x603000080ce0,0x603000080d00) freed by thread T11 here: #0 0x7fdc7c887f07 in __interceptor_free ../../../../src/libsanitizer/asan/asan_malloc_linux.cc:122 apache#1 0x7fdc7c5a5420 in pool_clear_debug memory/unix/apr_pools.c:1906 apache#2 0x7fdc7c5a562e in pool_destroy_debug memory/unix/apr_pools.c:1965 apache#3 0x7fdc7c5a5179 in pool_clear_debug memory/unix/apr_pools.c:1880 apache#4 0x7fdc7c5a562e in pool_destroy_debug memory/unix/apr_pools.c:1965 apache#5 0x7fdc7c5a5827 in apr_pool_destroy_debug memory/unix/apr_pools.c:2014 apache#6 0x7fdc789aeaa5 in h2_session_pre_close /home/yle/src/ylavic/httpd/modules/http2/h2_session.c:1934 apache#7 0x7fdc7896a20e in h2_c1_pre_close /home/yle/src/ylavic/httpd/modules/http2/h2_c1.c:188 apache#8 0x7fdc7896b538 in h2_c1_hook_pre_close /home/yle/src/ylavic/httpd/modules/http2/h2_c1.c:308 apache#9 0x5596139aeb28 in ap_run_pre_close_connection /home/yle/src/ylavic/httpd/server/connection.c:45 apache#10 0x5596139af353 in ap_prep_lingering_close /home/yle/src/ylavic/httpd/server/connection.c:128 apache#11 0x5596139af3f2 in ap_start_lingering_close /home/yle/src/ylavic/httpd/server/connection.c:154 apache#12 0x7fdc7835bdf0 in process_lingering_close /home/yle/src/ylavic/httpd/server/mpm/event/event.c:1999 apache#13 0x7fdc78359ccb in process_socket /home/yle/src/ylavic/httpd/server/mpm/event/event.c:1540 apache#14 0x7fdc783608d7 in worker_thread /home/yle/src/ylavic/httpd/server/mpm/event/event.c:2756 apache#15 0x7fdc7c5d3e57 in dummy_worker threadproc/unix/thread.c:153 apache#16 0x7fdc7c441d7f in start_thread nptl/pthread_create.c:481 previously allocated by thread T11 here: #0 0x7fdc7c8882b8 in __interceptor_malloc ../../../../src/libsanitizer/asan/asan_malloc_linux.cc:144 apache#1 0x7fdc7c5a4d00 in pool_alloc memory/unix/apr_pools.c:1787 apache#2 0x7fdc7c5a507a in apr_palloc_debug memory/unix/apr_pools.c:1828 apache#3 0x7fdc7c4d8160 in apr_brigade_create buckets/apr_brigade.c:90 apache#4 0x7fdc7c4d82d8 in apr_brigade_split_ex buckets/apr_brigade.c:107 apache#5 0x7fdc78967f7c in h2_beam_receive /home/yle/src/ylavic/httpd/modules/http2/h2_bucket_beam.c:729 apache#6 0x7fdc789b65f0 in buffer_output_receive /home/yle/src/ylavic/httpd/modules/http2/h2_stream.c:847 apache#7 0x7fdc789bb655 in h2_stream_read_output /home/yle/src/ylavic/httpd/modules/http2/h2_stream.c:1372 apache#8 0x7fdc789aa155 in on_stream_output /home/yle/src/ylavic/httpd/modules/http2/h2_session.c:1313 apache#9 0x7fdc789956ba in mplx_pollset_poll /home/yle/src/ylavic/httpd/modules/http2/h2_mplx.c:1299 apache#10 0x7fdc7898deb8 in h2_mplx_c1_poll /home/yle/src/ylavic/httpd/modules/http2/h2_mplx.c:532 apache#11 0x7fdc789ae04b in h2_session_process /home/yle/src/ylavic/httpd/modules/http2/h2_session.c:1863 apache#12 0x7fdc78969b0f in h2_c1_run /home/yle/src/ylavic/httpd/modules/http2/h2_c1.c:138 apache#13 0x7fdc7896b302 in h2_c1_hook_process_connection /home/yle/src/ylavic/httpd/modules/http2/h2_c1.c:286 apache#14 0x5596139ae4b6 in ap_run_process_connection /home/yle/src/ylavic/httpd/server/connection.c:43 apache#15 0x7fdc78358d67 in process_socket /home/yle/src/ylavic/httpd/server/mpm/event/event.c:1353 apache#16 0x7fdc783608d7 in worker_thread /home/yle/src/ylavic/httpd/server/mpm/event/event.c:2756 apache#17 0x7fdc7c5d3e57 in dummy_worker threadproc/unix/thread.c:153 apache#18 0x7fdc7c441d7f in start_thread nptl/pthread_create.c:481 Thread T11 created by T2 here: #0 0x7fdc7c7baa22 in __interceptor_pthread_create ../../../../src/libsanitizer/asan/asan_interceptors.cc:208 apache#1 0x7fdc7c5d4534 in apr_thread_create threadproc/unix/thread.c:228 apache#2 0x7fdc7836273d in start_threads /home/yle/src/ylavic/httpd/server/mpm/event/event.c:3035 apache#3 0x7fdc7c5d3e57 in dummy_worker threadproc/unix/thread.c:153 apache#4 0x7fdc7c441d7f in start_thread nptl/pthread_create.c:481 Thread T2 created by T0 here: #0 0x7fdc7c7baa22 in __interceptor_pthread_create ../../../../src/libsanitizer/asan/asan_interceptors.cc:208 apache#1 0x7fdc7c5d4534 in apr_thread_create threadproc/unix/thread.c:228 apache#2 0x7fdc78363d9f in child_main /home/yle/src/ylavic/httpd/server/mpm/event/event.c:3262 apache#3 0x7fdc7836483b in make_child /home/yle/src/ylavic/httpd/server/mpm/event/event.c:3421 apache#4 0x7fdc78364b89 in startup_children /home/yle/src/ylavic/httpd/server/mpm/event/event.c:3444 apache#5 0x7fdc78368abc in event_run /home/yle/src/ylavic/httpd/server/mpm/event/event.c:3932 apache#6 0x5596139b6d18 in ap_run_mpm /home/yle/src/ylavic/httpd/server/mpm_common.c:101 apache#7 0x55961399098b in main /home/yle/src/ylavic/httpd/server/main.c:880 apache#8 0x7fdc7c2627ec in __libc_start_main ../csu/libc-start.c:332 SUMMARY: AddressSanitizer: heap-use-after-free /home/yle/src/ylavic/httpd/modules/http2/h2_bucket_beam.c:279 in recv_buffer_cleanup Shadow bytes around the buggy address: 0x0c0680008140: fa fa 00 00 00 00 fa fa fd fd fd fa fa fa fd fd 0x0c0680008150: fd fd fa fa fd fd fd fd fa fa fd fd fd fd fa fa 0x0c0680008160: fd fd fd fd fa fa fd fd fd fd fa fa fd fd fd fd 0x0c0680008170: fa fa fd fd fd fd fa fa fd fd fd fd fa fa fd fd 0x0c0680008180: fd fd fa fa fd fd fd fd fa fa fd fd fd fa fa fa =>0x0c0680008190: fd fd fd fa fa fa fd fd fd fa fa fa fd[fd]fd fd 0x0c06800081a0: fa fa fd fd fd fd fa fa fd fd fd fd fa fa fd fd 0x0c06800081b0: fd fd fa fa fd fd fd fd fa fa fd fd fd fd fa fa 0x0c06800081c0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x0c06800081d0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x0c06800081e0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa Shadow byte legend (one shadow byte represents 8 application bytes): Addressable: 00 Partially addressable: 01 02 03 04 05 06 07 Heap left redzone: fa Freed heap region: fd Stack left redzone: f1 Stack mid redzone: f2 Stack right redzone: f3 Stack after return: f5 Stack use after scope: f8 Global redzone: f9 Global init order: f6 Poisoned by user: f7 Container overflow: fc Array cookie: ac Intra object redzone: bb ASan internal: fe Left alloca redzone: ca Right alloca redzone: cb Shadow gap: cc ==81201==ABORTING

When the session pool is destroyed, so is the beam's pool so we don't want to run the beam cleanup twice. ASan is reporting something like this (APR_POOL_DEBUG): ================================================================= ==81201==ERROR: AddressSanitizer: heap-use-after-free on address 0x603000080ce8 at pc 0x7fdc78962cc9 bp 0x7fdc731ff4f0 sp 0x7fdc731ff4e8 READ of size 8 at 0x603000080ce8 thread T11 #0 0x7fdc78962cc8 in recv_buffer_cleanup ~httpd/modules/http2/h2_bucket_beam.c:279 #1 0x7fdc78962fdc in beam_cleanup ~httpd/modules/http2/h2_bucket_beam.c:306 #2 0x7fdc7896300c in beam_pool_cleanup ~httpd/modules/http2/h2_bucket_beam.c:313 #3 0x7fdc7c5a8239 in run_cleanups memory/unix/apr_pools.c:2689 #4 0x7fdc7c5a50f9 in pool_clear_debug memory/unix/apr_pools.c:1867 #5 0x7fdc7c5a562e in pool_destroy_debug memory/unix/apr_pools.c:1965 #6 0x7fdc7c5a5179 in pool_clear_debug memory/unix/apr_pools.c:1880 #7 0x7fdc7c5a562e in pool_destroy_debug memory/unix/apr_pools.c:1965 #8 0x7fdc7c5a5179 in pool_clear_debug memory/unix/apr_pools.c:1880 #9 0x7fdc7c5a562e in pool_destroy_debug memory/unix/apr_pools.c:1965 #10 0x7fdc7c5a5179 in pool_clear_debug memory/unix/apr_pools.c:1880 #11 0x7fdc7c5a562e in pool_destroy_debug memory/unix/apr_pools.c:1965 #12 0x7fdc7c5a5827 in apr_pool_destroy_debug memory/unix/apr_pools.c:2014 #13 0x7fdc789aeaa5 in h2_session_pre_close ~httpd/modules/http2/h2_session.c:1934 #14 0x7fdc7896a20e in h2_c1_pre_close ~httpd/modules/http2/h2_c1.c:188 #15 0x7fdc7896b538 in h2_c1_hook_pre_close ~httpd/modules/http2/h2_c1.c:308 #16 0x5596139aeb28 in ap_run_pre_close_connection ~httpd/server/connection.c:45 #17 0x5596139af353 in ap_prep_lingering_close ~httpd/server/connection.c:128 #18 0x5596139af3f2 in ap_start_lingering_close ~httpd/server/connection.c:154 #19 0x7fdc7835bdf0 in process_lingering_close ~httpd/server/mpm/event/event.c:1999 #20 0x7fdc78359ccb in process_socket ~httpd/server/mpm/event/event.c:1540 #21 0x7fdc783608d7 in worker_thread ~httpd/server/mpm/event/event.c:2756 #22 0x7fdc7c5d3e57 in dummy_worker threadproc/unix/thread.c:153 #23 0x7fdc7c441d7f in start_thread nptl/pthread_create.c:481 #24 0x7fdc7c337bde in clone (/lib/x86_64-linux-gnu/libc.so.6+0xfcbde) 0x603000080ce8 is located 8 bytes inside of 32-byte region [0x603000080ce0,0x603000080d00) freed by thread T11 here: #0 0x7fdc7c887f07 in __interceptor_free ../../../../src/libsanitizer/asan/asan_malloc_linux.cc:122 #1 0x7fdc7c5a5420 in pool_clear_debug memory/unix/apr_pools.c:1906 #2 0x7fdc7c5a562e in pool_destroy_debug memory/unix/apr_pools.c:1965 #3 0x7fdc7c5a5179 in pool_clear_debug memory/unix/apr_pools.c:1880 #4 0x7fdc7c5a562e in pool_destroy_debug memory/unix/apr_pools.c:1965 #5 0x7fdc7c5a5827 in apr_pool_destroy_debug memory/unix/apr_pools.c:2014 #6 0x7fdc789aeaa5 in h2_session_pre_close ~httpd/modules/http2/h2_session.c:1934 #7 0x7fdc7896a20e in h2_c1_pre_close ~httpd/modules/http2/h2_c1.c:188 #8 0x7fdc7896b538 in h2_c1_hook_pre_close ~httpd/modules/http2/h2_c1.c:308 #9 0x5596139aeb28 in ap_run_pre_close_connection ~httpd/server/connection.c:45 #10 0x5596139af353 in ap_prep_lingering_close ~httpd/server/connection.c:128 #11 0x5596139af3f2 in ap_start_lingering_close ~httpd/server/connection.c:154 #12 0x7fdc7835bdf0 in process_lingering_close ~httpd/server/mpm/event/event.c:1999 #13 0x7fdc78359ccb in process_socket ~httpd/server/mpm/event/event.c:1540 #14 0x7fdc783608d7 in worker_thread ~httpd/server/mpm/event/event.c:2756 #15 0x7fdc7c5d3e57 in dummy_worker threadproc/unix/thread.c:153 #16 0x7fdc7c441d7f in start_thread nptl/pthread_create.c:481 previously allocated by thread T11 here: #0 0x7fdc7c8882b8 in __interceptor_malloc ../../../../src/libsanitizer/asan/asan_malloc_linux.cc:144 #1 0x7fdc7c5a4d00 in pool_alloc memory/unix/apr_pools.c:1787 #2 0x7fdc7c5a507a in apr_palloc_debug memory/unix/apr_pools.c:1828 #3 0x7fdc7c4d8160 in apr_brigade_create buckets/apr_brigade.c:90 #4 0x7fdc7c4d82d8 in apr_brigade_split_ex buckets/apr_brigade.c:107 #5 0x7fdc78967f7c in h2_beam_receive ~httpd/modules/http2/h2_bucket_beam.c:729 #6 0x7fdc789b65f0 in buffer_output_receive ~httpd/modules/http2/h2_stream.c:847 #7 0x7fdc789bb655 in h2_stream_read_output ~httpd/modules/http2/h2_stream.c:1372 #8 0x7fdc789aa155 in on_stream_output ~httpd/modules/http2/h2_session.c:1313 #9 0x7fdc789956ba in mplx_pollset_poll ~httpd/modules/http2/h2_mplx.c:1299 #10 0x7fdc7898deb8 in h2_mplx_c1_poll ~httpd/modules/http2/h2_mplx.c:532 #11 0x7fdc789ae04b in h2_session_process ~httpd/modules/http2/h2_session.c:1863 #12 0x7fdc78969b0f in h2_c1_run ~httpd/modules/http2/h2_c1.c:138 #13 0x7fdc7896b302 in h2_c1_hook_process_connection ~httpd/modules/http2/h2_c1.c:286 #14 0x5596139ae4b6 in ap_run_process_connection ~httpd/server/connection.c:43 #15 0x7fdc78358d67 in process_socket ~httpd/server/mpm/event/event.c:1353 #16 0x7fdc783608d7 in worker_thread ~httpd/server/mpm/event/event.c:2756 #17 0x7fdc7c5d3e57 in dummy_worker threadproc/unix/thread.c:153 #18 0x7fdc7c441d7f in start_thread nptl/pthread_create.c:481 Thread T11 created by T2 here: #0 0x7fdc7c7baa22 in __interceptor_pthread_create ../../../../src/libsanitizer/asan/asan_interceptors.cc:208 #1 0x7fdc7c5d4534 in apr_thread_create threadproc/unix/thread.c:228 #2 0x7fdc7836273d in start_threads ~httpd/server/mpm/event/event.c:3035 #3 0x7fdc7c5d3e57 in dummy_worker threadproc/unix/thread.c:153 #4 0x7fdc7c441d7f in start_thread nptl/pthread_create.c:481 Thread T2 created by T0 here: #0 0x7fdc7c7baa22 in __interceptor_pthread_create ../../../../src/libsanitizer/asan/asan_interceptors.cc:208 #1 0x7fdc7c5d4534 in apr_thread_create threadproc/unix/thread.c:228 #2 0x7fdc78363d9f in child_main ~httpd/server/mpm/event/event.c:3262 #3 0x7fdc7836483b in make_child ~httpd/server/mpm/event/event.c:3421 #4 0x7fdc78364b89 in startup_children ~httpd/server/mpm/event/event.c:3444 #5 0x7fdc78368abc in event_run ~httpd/server/mpm/event/event.c:3932 #6 0x5596139b6d18 in ap_run_mpm ~httpd/server/mpm_common.c:101 #7 0x55961399098b in main ~httpd/server/main.c:880 #8 0x7fdc7c2627ec in __libc_start_main ../csu/libc-start.c:332 SUMMARY: AddressSanitizer: heap-use-after-free ~httpd/modules/http2/h2_bucket_beam.c:279 in recv_buffer_cleanup Shadow bytes around the buggy address: 0x0c0680008140: fa fa 00 00 00 00 fa fa fd fd fd fa fa fa fd fd 0x0c0680008150: fd fd fa fa fd fd fd fd fa fa fd fd fd fd fa fa 0x0c0680008160: fd fd fd fd fa fa fd fd fd fd fa fa fd fd fd fd 0x0c0680008170: fa fa fd fd fd fd fa fa fd fd fd fd fa fa fd fd 0x0c0680008180: fd fd fa fa fd fd fd fd fa fa fd fd fd fa fa fa =>0x0c0680008190: fd fd fd fa fa fa fd fd fd fa fa fa fd[fd]fd fd 0x0c06800081a0: fa fa fd fd fd fd fa fa fd fd fd fd fa fa fd fd 0x0c06800081b0: fd fd fa fa fd fd fd fd fa fa fd fd fd fd fa fa 0x0c06800081c0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x0c06800081d0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x0c06800081e0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa Shadow byte legend (one shadow byte represents 8 application bytes): Addressable: 00 Partially addressable: 01 02 03 04 05 06 07 Heap left redzone: fa Freed heap region: fd Stack left redzone: f1 Stack mid redzone: f2 Stack right redzone: f3 Stack after return: f5 Stack use after scope: f8 Global redzone: f9 Global init order: f6 Poisoned by user: f7 Container overflow: fc Array cookie: ac Intra object redzone: bb ASan internal: fe Left alloca redzone: ca Right alloca redzone: cb Shadow gap: cc ==81201==ABORTING git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@1897868 13f79535-47bb-0310-9956-ffa450edef68

Revert "Fix our documentation to not show the expression in Require e…

ca8dc87

…xpr as quoted." This reverts commit 407db4e.

asfgit force-pushed the trunk branch 2 times, most recently from 1a6ba48 to f0abf76 Compare October 5, 2019 02:54

arminabf mentioned this pull request Jun 25, 2020

fix race condition leading to double free error #129

Closed

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Revert "Fix our documentation to not show the expression in Require expr... #9

Revert "Fix our documentation to not show the expression in Require expr... #9

ghost commented Apr 8, 2014

Revert "Fix our documentation to not show the expression in Require expr... #9

Are you sure you want to change the base?

Revert "Fix our documentation to not show the expression in Require expr... #9

Conversation

ghost commented Apr 8, 2014