https://bz.apache.org/bugzilla/show_bug.cgi?id=63503
--- Comment #9 from Ruediger Pluem <[email protected]> --- (In reply to Eric Covener from comment #8) > from the thread: > > 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. My current gut feeling is that there is something rotten elsewhere and that adding the locks just fixes the results of this with a performance penalty. But I would need to investigate closer. > > Maybe an alternative would be to use a subpool for the resolver calls? I will investigate this option, but I need to study first which allocators are used. -- You are receiving this mail because: You are the assignee for the bug. --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
