https://bz.apache.org/bugzilla/show_bug.cgi?id=63503
--- Comment #10 from Ruediger Pluem <[email protected]> --- (In reply to Ruediger Pluem from comment #9) > (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. Here I suspect a double initialization issue. Can you please revert r1865938 and add the patch I will add here next? If I am correct, it should fix the above issue. The second example will not be fixed by this. BTW: I am not sure if we can backport the volatile change in mod_proxy.h. I guess it is needed, to ensure that we really recheck, but this can be discussed later. > > > > > 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. The connection pool uses the global pool allocator and this allocator has a mutex. Hence creation of the subpool and allocating memory in the pool is thread safe in the sense that parent and subpool can be used concurrently in different threads. So a subpool would be an option here as well. -- 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]
