> BTW: I ask myself why we need a global mutex to protect a pool. Wouldn't a thread mutex be sufficient?
I figured accessing a pool inside a module config is something that needs to be protected across process boundaries, hence the global lock. Are module configs not globally unique in the sense that they are not copied into every process ? > I guess a call to apr_global_mutex_child_init is missing in the child_init hook of mod_proxy. Can't we fix the code in merge_proxy_config with something like mutex = overrides->mutex ? base->mutex ? create_mutex() for which we don't need to make use of another hook. On Tue, May 14, 2013 at 9:36 PM, Ruediger Pluem <[email protected]> wrote: > I guess a call to apr_global_mutex_child_init is missing in the > child_init hook of mod_proxy. > BTW: I ask myself why we need a global mutex to protect a pool. Wouldn't a > thread mutex be sufficient? > Plus why are we not using the httpd mutex API to make the mutex method > configurable? > > Regards > > Rüdiger > > Graham Leggett wrote: > > Hi all, > > > > I am currently getting a segfault in the proxy during httpd-test, it > looks like conf->mutex is being used before being initialised: > > > > Program received signal EXC_BAD_ACCESS, Could not access memory. > > Reason: KERN_INVALID_ADDRESS at address: 0x0000000000000010 > > 0x00000001007cc8c0 in apr_global_mutex_lock (mutex=0x0) at > global_mutex.c:97 > > 97 if (mutex->thread_mutex) { > > (gdb) bt > > #0 0x00000001007cc8c0 in apr_global_mutex_lock (mutex=0x0) at > global_mutex.c:97 > > #1 0x0000000100159709 in ap_proxy_initialize_worker > (worker=0x10108f460, s=0x10104cae0, p=0x101051228) at proxy_util.c:1734 > > > > Not sure if this rings a bell for anyone? > > > > Regards, > > Graham > > -- > > > > >
