On Mon, Aug 12, 2019 at 12:32 PM Don Poitras <don.poit...@sas.com> 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
