Hi Don, can you try this very similar patch? I applied yours to my sandbox to get more context and made a few minor changes (including pre-existing stuff that looked misleading)
http://people.apache.org/~covener/trunk-proxy-segv.diff On Mon, Aug 12, 2019 at 2:43 PM Eric Covener <[email protected]> wrote: > > On Mon, Aug 12, 2019 at 2:37 PM Eric Covener <[email protected]> wrote: > > > > On Mon, Aug 12, 2019 at 12:32 PM Don Poitras <[email protected]> wrote: > > > > > > Eric, > > > The global mutex only serializes concurrent calls to > > > ap_proxy_initialize_worker(). The worker pool is also used when the > > > proxy_handler() is called from a thread kicked off from a _previous_ call > > > to ap_proxy_initialize_worker() . Turning on the pool concurrency check > > > shows this happening: > > > > > > pool concurrency check: pool 0xa04348(proxy_worker_cp), thread cur > > > 7f25a21fc700 in use by 7f2598bed700, state in use -> in use > > > > > > 172256 . Thawed libc:gsignal (+0x37) > > > <--- abort > > > 1 libc:gsignal (+0x37) > > > 2 libc:abort (+0x143) > > > 3 libapr-1:\apr_pools\pool_concurrency_abort 768 > > > 4 libapr-1:\apr_pools\apr_palloc 778 (+0xA) > > > 5 libapr-1:\thread_cond\apr_thread_cond_create 44 > > > 6 libaprutil-1:\apr_reslist\apr_reslist_create 299 (+0x9) > > > 7 mod_proxy:\proxy_util\ap_proxy_initialize_worker 2013 (+0x2F) > > > 8 mod_proxy:\mod_proxy\proxy_handler 1176 (+0xE) > > > 9 httpd:UNKNOWN at 0x00000000004543A0 > > > > > > Here's the thead the diagnostic said had the pool 'in use' when > > > apr_palloc() was called: > > > > > > 172271 Thawed libc:__GI_strncmp (+0x1680) > > > <-- in use > > > 1 libc:__GI_strncmp (+0x1680) > > > 2 libc:getenv (+0xBD) > > > 3 libc:__nscd_getai (+0x3D3) > > > 4 libc:gaih_inet.constprop.8 (+0x15F2) > > > 5 libc:getaddrinfo (+0x11F) > > > 6 libapr-1:\sockaddr\call_resolver 397 (+0x10) > > > 7 mod_proxy:\proxy_util\ap_proxy_determine_connection 2506 (+0x15) > > > 8 mod_proxy_http:\mod_proxy_http\proxy_http_handler 1956 (+0x1D) > > > 9 mod_proxy:\mod_proxy\proxy_run_scheme_handler 3063 (+0x18) > > > 10 mod_proxy:\mod_proxy\proxy_handler 1250 (+0x16) > > > 11 httpd:UNKNOWN at 0x00000000004543A0 > > > > Thanks, I feel like I understand a bit more now at least about the > > apr_reslist_acquire() vs. DNS lookups cases. > > > > I guess in the above case ap_proxy_initialize_worker() has some funny > > business where the state is checked outside of the global mutex and if > > a 2nd thread sneaks in they will reuse worker->cp->pool > > Whoops, gmail ate a bunch of keystrokes and sent prematurely when I > tried to paste.: > > if (worker->cp == NULL) > init_conn_pool(p, worker); > > But then will create a new reslist with the old pool that is already > being used in thread 1 that has gotten farther into the handler. > I don't totally follow how the patch in BZ is fixing this one if > that's what's happening. > > -- > Eric Covener > [email protected] -- Eric Covener [email protected]
