You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by Jeff Trawick <tr...@attglobal.net> on 2001/12/18 12:55:11 UTC
nasty segfault doing sighup with worker MPM
(Yes, this is without any patches :) )
I'll take a look at this after I get to a stopping point with the
server-limit/thread-limit stuff.
It looks like listen_recs aren't allocated from the right pool with
worker? (at least I couldn't reproduce this with prefork)
Program received signal SIGHUP, Hangup.
0x401d654e in __select () from /lib/libc.so.6
(gdb) c
Continuing.
Program received signal SIGTERM, Terminated.
0x401494e1 in __kill () from /lib/libc.so.6
(gdb) c
Continuing.
Program received signal SIGSEGV, Segmentation fault.
0x4003b42b in apr_sockaddr_port_get (port=0xbffffa9a, sockaddr=0x63)
at ../unix/sa_common.c:132
132 *port = ntohs(sockaddr->sa.sin.sin_port);
(gdb) where
#0 0x4003b42b in apr_sockaddr_port_get (port=0xbffffa9a, sockaddr=0x63)
at ../unix/sa_common.c:132
#1 0x80c822e in alloc_listener (process=0x8108900,
addr=0x80f773b "0.0.0.0", port=8080) at listen.c:242
#2 0x80c8638 in ap_set_listener (cmd=0xbffffb78, dummy=0x0,
ips=0x8154348 "8080") at listen.c:367
#3 0x80bc0c4 in invoke_cmd (cmd=0x80fee04, parms=0xbffffb78,
mconfig=0x0, args=0x81445c4 "") at config.c:670
#4 0x80bcf92 in ap_walk_config_sub (current=0x81445a0,
parms=0xbffffb78, section_vector=0x81456a0) at config.c:1016
#5 0x80bd03a in ap_walk_config (current=0x81445a0, parms=0xbffffb78,
section_vector=0x81456a0) at config.c:1053
#6 0x80bdc5f in ap_process_config_tree (s=0x815f4e0,
conftree=0x8143a80, p=0x810a890, ptemp=0x8146980) at config.c:1467
#7 0x80c0756 in main (argc=1, argv=0xbffffc64) at main.c:438
(gdb) up
#1 0x80c822e in alloc_listener (process=0x8108900,
addr=0x80f773b "0.0.0.0", port=8080) at listen.c:242
242 apr_sockaddr_port_get(&oldport, sa);
(gdb) p **walk
$2 = {next = 0x5f646f6d, sd = 0x2e766e65, bind_addr = 0x63,
accept_func = 0, active = 0}
(gdb) p *walk->sd
Cannot access memory at address 0x2e766e65.
--
Jeff Trawick | trawick@attglobal.net | PGP public key at web site:
http://www.geocities.com/SiliconValley/Park/9289/
Born in Roswell... married an alien...
Re: nasty segfault doing sighup with worker MPM
Posted by Jeff Trawick <tr...@attglobal.net>.
Aaron Bannert <aa...@clove.org> writes:
> On Tue, Dec 18, 2001 at 06:55:11AM -0500, Jeff Trawick wrote:
> > (Yes, this is without any patches :) )
> >
> > I'll take a look at this after I get to a stopping point with the
> > server-limit/thread-limit stuff.
> >
> > It looks like listen_recs aren't allocated from the right pool with
> > worker? (at least I couldn't reproduce this with prefork)
>
> [snip]
>
> Does anything interesting show up in your error_log?
nope, just the "SIGHUP received. Attempting to restart" message...
--
Jeff Trawick | trawick@attglobal.net | PGP public key at web site:
http://www.geocities.com/SiliconValley/Park/9289/
Born in Roswell... married an alien...
Re: nasty segfault doing sighup with worker MPM
Posted by Aaron Bannert <aa...@clove.org>.
On Tue, Dec 18, 2001 at 06:55:11AM -0500, Jeff Trawick wrote:
> (Yes, this is without any patches :) )
>
> I'll take a look at this after I get to a stopping point with the
> server-limit/thread-limit stuff.
>
> It looks like listen_recs aren't allocated from the right pool with
> worker? (at least I couldn't reproduce this with prefork)
[snip]
Does anything interesting show up in your error_log?
-aaron
Re: nasty segfault doing sighup with worker MPM
Posted by Jeff Trawick <tr...@attglobal.net>.
Ryan Bloom <rb...@covalent.net> writes:
> The point of the accept abstraction is to allow people to poll on things other
> than regular sockets. The pipe-of-death is just one such example. An SSL
> socket is another, as is a UDP socket, or a hundred other examples. We
> should just move the pipe-of-death to the correct pool.
if we just move it to the right pool we then get to write code to
close the pipe... or maybe the pipe should be in pconf pool and
listen_rec in process pool but then we have a lost listen_rec that we
can't reuse
> Long-term, for threaded MPMs, I want the pipe-of-death to be completely
> separate from the listen_recs, but that is next week's job on my list.
you seem to be planning to restructure it anyway; I'll be happy in the
meantime with a simple fix that let's us restart with no segfaults and
no pipe leaks
--
Jeff Trawick | trawick@attglobal.net | PGP public key at web site:
http://www.geocities.com/SiliconValley/Park/9289/
Born in Roswell... married an alien...
Re: nasty segfault doing sighup with worker MPM
Posted by Ryan Bloom <rb...@covalent.net>.
On Tuesday 18 December 2001 12:52 pm, Jeff Trawick wrote:
> Jeff Trawick <tr...@attglobal.net> writes:
>
> > It looks like listen_recs aren't allocated from the right pool with
> > worker? (at least I couldn't reproduce this with prefork)
>
> And the answer is...
>
> *Most* of the listen_recs are allocated from the right pool. The one
> that isn't is the pipe of death listen_rec allocated by worker MPM and
> placed into the ap_listeners list.
>
> Stuff in ap_listeners list needs to be allocated from the process
> pool so that it survives a restart.
>
> The pipe of death listen_rec is allocated in the pconf pool.
>
> Maybe the pipe of death shouldn't even be in the ap_listeners list. I
> think it would be better if worker.c has its own listeners list. The
> first thing in it is the pipe of death. We set the next pointer in
> that listen_rec to ap_listeners. Thus, we leave the list manipulated
> by listen.c alone but we still have our list to use so we serve fairly
> all the sockets we're polling on.
The point of the accept abstraction is to allow people to poll on things other
than regular sockets. The pipe-of-death is just one such example. An SSL
socket is another, as is a UDP socket, or a hundred other examples. We
should just move the pipe-of-death to the correct pool.
Long-term, for threaded MPMs, I want the pipe-of-death to be completely
separate from the listen_recs, but that is next week's job on my list.
Ryan
______________________________________________________________
Ryan Bloom rbb@apache.org
Covalent Technologies rbb@covalent.net
--------------------------------------------------------------
Re: nasty segfault doing sighup with worker MPM
Posted by Jeff Trawick <tr...@attglobal.net>.
Jeff Trawick <tr...@attglobal.net> writes:
> It looks like listen_recs aren't allocated from the right pool with
> worker? (at least I couldn't reproduce this with prefork)
And the answer is...
*Most* of the listen_recs are allocated from the right pool. The one
that isn't is the pipe of death listen_rec allocated by worker MPM and
placed into the ap_listeners list.
Stuff in ap_listeners list needs to be allocated from the process
pool so that it survives a restart.
The pipe of death listen_rec is allocated in the pconf pool.
Maybe the pipe of death shouldn't even be in the ap_listeners list. I
think it would be better if worker.c has its own listeners list. The
first thing in it is the pipe of death. We set the next pointer in
that listen_rec to ap_listeners. Thus, we leave the list manipulated
by listen.c alone but we still have our list to use so we serve fairly
all the sockets we're polling on.
--
Jeff Trawick | trawick@attglobal.net | PGP public key at web site:
http://www.geocities.com/SiliconValley/Park/9289/
Born in Roswell... married an alien...