You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by Graham Leggett <mi...@sharp.fm> on 2013/05/14 20:54:37 UTC
proxy segfault in httpd-trunk
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
--
Re: proxy segfault in httpd-trunk
Posted by Thomas Eckert <th...@gmail.com>.
> 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 <rp...@apache.org> 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
> > --
> >
> >
>
Re: proxy segfault in httpd-trunk
Posted by Ruediger Pluem <rp...@apache.org>.
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
> --
>
>
Re: proxy segfault in httpd-trunk
Posted by Jim Jagielski <ji...@jaguNET.com>.
On May 16, 2013, at 4:19 AM, Thomas Eckert <th...@gmail.com> wrote:
> > Just wondering if we also have a problem with the pool
> > as well... if base doesn't have a proxy, we don't have
> > the subpool.
>
> Looks like it. At least I don't see a reason why Nick's reasoning would apply to the mutex but not to the pool.
>
>
Hold on a tic... the server-conf is created for each server and
it's a *module* level action. It happens whether the top-level
server uses a proxy-or-not. That is, create_server_config
is done on each and every server, regardless of whether
that server *uses* mod_proxy at all. So base->pool and base->mutex
will always line up with a created subpool and mutex since
base is *guaranteed* to exist and base-><field> is guaranteed
to have been created (if done so in create_server_config).
Even with all that, I like Graham's mutex impl better and
with http://svn.apache.org/r1483190 we now ensure child processes
have access to it (which is likely what the orig issue really
was)
Re: proxy segfault in httpd-trunk
Posted by Thomas Eckert <th...@gmail.com>.
> Just wondering if we also have a problem with the pool
> as well... if base doesn't have a proxy, we don't have
> the subpool.
Looks like it. At least I don't see a reason why Nick's reasoning would
apply to the mutex but not to the pool.
> BTW, wondering if instead of leaking proxy_mutex we
> could set ps->mutex = proxy_mutex in mod_proxy.c when
> we merge. We could then make proxy_mutex static...?
I must admit I'm not familiar enough with the httpd modules at large to be
an expert here but to me it *feels* weird to put such a central piece of
module management outside the module's config structure. It would solve the
problem with create_config/merge_config though and it's also a bit better
performance wise (see Graham's commit). Hm, maybe it doesn't feel so weird
after all ...
> Hmmm... The other idea is to keep it as it was,
> stick pconf back in conf->pool but just always create
> a sub-pool before conf->pool is used. This *looks*
> like it removes the need for a mutex...
I thought about this as well but decided against it because I figured
creating those sub pools would be a much larger performance hit then just
having a locking mechanism in place. It'd be a different matter with sub
pools being pre-allocated, 'swapped' into place when needed, etc. This
feels like going way overboard though.
On Thu, May 16, 2013 at 5:20 AM, Jim Jagielski <ji...@jagunet.com> wrote:
> Hmmm... The other idea is to keep it as it was,
> stick pconf back in conf->pool but just always create
> a sub-pool before conf->pool is used. This *looks*
> like it removes the need for a mutex...
>
> On May 15, 2013, at 7:37 PM, Jim Jagielski <ji...@jaguNET.com> wrote:
>
> > Just wondering if we also have a problem with the pool
> > as well... if base doesn't have a proxy, we don't have
> > the subpool.
> >
> > BTW, wondering if instead of leaking proxy_mutex we
> > could set ps->mutex = proxy_mutex in mod_proxy.c when
> > we merge. We could then make proxy_mutex static...?
> >
> > On May 15, 2013, at 7:27 PM, Graham Leggett <mi...@sharp.fm> wrote:
> >
> >> On 16 May 2013, at 1:25 AM, Jim Jagielski <ji...@jaguNET.com> wrote:
> >>
> >>> Ugg. You're 100% right. We need to create a global.
> >>
> >> Here is one I made earlier: http://svn.apache.org/r1482859
> >>
> >> Regards,
> >> Graham
> >> --
> >>
> >
>
>
Re: proxy segfault in httpd-trunk
Posted by Jim Jagielski <ji...@jaguNET.com>.
Hmmm... The other idea is to keep it as it was,
stick pconf back in conf->pool but just always create
a sub-pool before conf->pool is used. This *looks*
like it removes the need for a mutex...
On May 15, 2013, at 7:37 PM, Jim Jagielski <ji...@jaguNET.com> wrote:
> Just wondering if we also have a problem with the pool
> as well... if base doesn't have a proxy, we don't have
> the subpool.
>
> BTW, wondering if instead of leaking proxy_mutex we
> could set ps->mutex = proxy_mutex in mod_proxy.c when
> we merge. We could then make proxy_mutex static...?
>
> On May 15, 2013, at 7:27 PM, Graham Leggett <mi...@sharp.fm> wrote:
>
>> On 16 May 2013, at 1:25 AM, Jim Jagielski <ji...@jaguNET.com> wrote:
>>
>>> Ugg. You're 100% right. We need to create a global.
>>
>> Here is one I made earlier: http://svn.apache.org/r1482859
>>
>> Regards,
>> Graham
>> --
>>
>
Re: proxy segfault in httpd-trunk
Posted by Jim Jagielski <ji...@jaguNET.com>.
Just wondering if we also have a problem with the pool
as well... if base doesn't have a proxy, we don't have
the subpool.
BTW, wondering if instead of leaking proxy_mutex we
could set ps->mutex = proxy_mutex in mod_proxy.c when
we merge. We could then make proxy_mutex static...?
On May 15, 2013, at 7:27 PM, Graham Leggett <mi...@sharp.fm> wrote:
> On 16 May 2013, at 1:25 AM, Jim Jagielski <ji...@jaguNET.com> wrote:
>
>> Ugg. You're 100% right. We need to create a global.
>
> Here is one I made earlier: http://svn.apache.org/r1482859
>
> Regards,
> Graham
> --
>
Re: proxy segfault in httpd-trunk
Posted by Graham Leggett <mi...@sharp.fm>.
On 16 May 2013, at 1:25 AM, Jim Jagielski <ji...@jaguNET.com> wrote:
> Ugg. You're 100% right. We need to create a global.
Here is one I made earlier: http://svn.apache.org/r1482859
Regards,
Graham
--
Re: proxy segfault in httpd-trunk
Posted by Jim Jagielski <ji...@jaguNET.com>.
Ugg. You're 100% right. We need to create a global.
On May 14, 2013, at 3:35 PM, Nick Kew <ni...@webthing.com> wrote:
>
> On 14 May 2013, at 19:54, 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:
>
> http://svn.eu.apache.org/viewvc?view=revision&revision=1480627
>
> The logic looks screwed to me: it's in create_proxy_config, and
> the merge just copies from base. If there's no proxy in the first
> vhost then you're likely in trouble!
>
> Should presumably be created server-wide in post- (or pre-)config
> and attached in child_init, if memory serves.
>
> --
> Nick Kew
Re: proxy segfault in httpd-trunk
Posted by Nick Kew <ni...@webthing.com>.
On 14 May 2013, at 19:54, 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:
http://svn.eu.apache.org/viewvc?view=revision&revision=1480627
The logic looks screwed to me: it's in create_proxy_config, and
the merge just copies from base. If there's no proxy in the first
vhost then you're likely in trouble!
Should presumably be created server-wide in post- (or pre-)config
and attached in child_init, if memory serves.
--
Nick Kew