Based on Stefan's reply I replaced mod_proxy's config pool with a sub-pool and wrapped a mutex around the pool usage. Basic testing went well but I have to do some more thorough parallel testing.
One thing which had me confused was the balancers. In ap_proxy_define_balancer() they are handed a pointer to mod_proxy's config (via balancer->sconf). So I also had to check whether the pool is ever accessed via a balancer but to my surprise that pointer is never used at all. I suggest removing the balancers' reference to mod_proxy's configuration pool, since that makes managing that pool a lot eaiser in the future. It's really only 2 lines that have to be edited. On Sat, May 4, 2013 at 8:20 PM, Micha Lenk <mi...@lenk.info> wrote: > Hi Stefan, > > Am 03.05.2013 14:09, schrieb Stefan Fritsch: > > On Thursday 02 May 2013, Thomas Eckert wrote: > >> > Lately, I've been seeing httpd/mod_proxy seg faulting in reverse > >> > proxy setups, frequency increasing. > > > > I am pretty sure that this is a thread-unsafe pool usage. > > create_proxy_config() puts the global config pool into > > (proxy_server_conf)->pool. It is later (during request processing) > > used all over the place without further locking. This must be a sub- > > pool instead, and it must be protected with a mutex. Or new sub-pools > > must be created wherever conf->pool is used. > > Can you please elaborate the problem of thread-unsafe pool usage a bit > more so that we can better understand why this is causing a segmentation > fault? Or alternatively, do you have any pointer to documentation, > mailinglists, what ever, where to read more about it? > > Thanks in advance, > Micha >
fix_mod_proxy_thread_unsafety.patch
Description: Binary data
remove_obselete_balancer_pointer.patch
Description: Binary data
