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]
