You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by Lukasz Engel <Lu...@softax.pl> on 2002/10/17 18:31:52 UTC
Apache 1.3.27 bad (?) signal handling on Tru64 5.1
Hello everybody,
It's my first deeper contact with apache sources (excluding
"./configure; make; make install" ;) ).
I am trying to run apache 1.3.27 (with mod_perl and EAPI, but I think it
doesn't matter) on Try64 5.1 box and I got SEGVs (every time from the
same place).
After some tracing I think I found the problem:
While reading client's request line SIGALRM accurs (meaning some timeout
- I don't know exactly). Then in signal handler (in function timeout
(http_main.c)) longjmp to mail loop is done and apache continues
processing.
But on my Tru64 I can see that signal handler for SIGALRM is called in
different thread (created implicit by libc ?).
After first SIGALRM all is working, but when second SIGALRM arrives
(some time later) things go worse:
- Main thread (let's call it "thread 1") calls read
- read call is interrupted by SIGALRM
- thread 1 is suspended
- signal handler is called in different thread (let's call it "thread
2")
- thread 2 countinues processing, does longjmp to mail loop
- in main loop thread 2 cleans context (frees pool used to handle
interrupted request)
- thread 2 hangs on accept call
- in this moment thread 1 is activated (!!!) - read call returns (with
result indicating that some bytes were read)
- thread 1 countinues processing in context which was freed by thread 2
and soon we got SIGSEGV :(
In man page for longjmp on Tru64 5.1 I've read:
"(...) However, if the longjmp() function is invoked from a nested
signal handler (that is, from a function invoked as a result of a signal
raised during the handling of another signal), the behavior is
undefined."
In our case SIGALRM handler never returns, so second SIGALRM generates
"nested signal".
Did someone else have the same problem or have some suggestions how to
make my apache work stable?
regards,
Lukasz Engel
-------
What we in debugger after SIGSEGV (look at threads 0x9 ("thread 1") and
0x3 ("thread 2")):
thread 0x9 signal Segmentation fault at [ap_palloc:932 ,0x12007ab58]
char *first_avail = blok->h.first_avail;
(dbx) where
> 0 ap_palloc(a = 0x14199b820, reqsize = 5) ["alloc.c":932,
0x12007ab58]
1 ap_getword_white(atrans = 0x14199b820, line = 0x11fff9de0)
["util.c":723, 0x120089e04]
2 read_request_line(r = 0x14199b868) ["http_protocol.c":1059,
0x1200930d8]
3 ap_read_request(conn = 0x141995028) ["http_protocol.c":1247,
0x120093d94]
(dbx) tstack
Thread 0x3:
> 0 __accept(0x0, 0x0, 0x1200709fc, 0x0, 0x3ffc008a2e0) [0x3ff800e4538]
1 child_main(child_num_arg = 0) ["http_main.c":4487, 0x120070a18]
2 make_child(s = 0x140046068, slot = 0, now = 1034863953)
["http_main.c":4857, 0x1200714b0]
3 startup_children(number_to_start = 10) ["http_main.c":4939,
0x120071694]
4 standalone_main(argc = 4, argv = 0x11fffc018) ["http_main.c":5247,
0x120071f6c]
5 main(argc = 4, argv = 0x11fffc018) ["http_main.c":5610,
0x12007298c]
Thread 0x9:
> 0 ap_palloc(a = 0x14199b820, reqsize = 5) ["alloc.c":932,
0x12007ab58]
1 ap_getword_white(atrans = 0x14199b820, line = 0x11fff9de0)
["util.c":723, 0x120089e04]
2 read_request_line(r = 0x14199b868) ["http_protocol.c":1059,
0x1200930d8]
3 ap_read_request(conn = 0x141995028) ["http_protocol.c":1247,
0x120093d94]
Thread 0x6:
> 0 __nxm_thread_block(0x30003031f88, 0x20000507600, 0x1, 0x3daec6c4,
0xd0ff6b0) [0x3000303d3b8]
1 (unknown)() [0x30003032058]
2 __thdBase(0x0, 0x0, 0x0, 0x0, 0x0) [0x3000304a218]
Thread 0xb:
More (n if no)?
> 0 __hstQueueUnblockAndTerminate(0x3ff800f6244, 0x0, 0x3ff800ea784,
0x141c25970, 0x3ff800b7010) [0x3000303cfcc]
1 __hstSaveUnblockContext(0x3000302ccf8, 0x20000000000,
0x30003054334, 0x30042c44000, 0x30042c44000) [0x30003023d20]
2 __dspReadyList(0x3ff801b9654, 0x3ffc00800c0, 0x3ffc008a2e0,
0x140060908, 0x140060888) [0x3000302240c]
3 __upcUpcall(0x140060888, 0x2000, 0x3ff800d7cc4, 0x3ffc00800c0,
0x3ff800d7d04) [0x3000303d1e8]
4 fflush(0x3ff800d7d04, 0x0, 0x14199b868, 0x140060908, 0x140060888)
[0x3ff800d7d00]
Thread 0xd:
> 0 __hstQueueUnblockAndTerminate(0x12006c78c, 0x1ffffffff,
0x11fff9e00, 0x12006c9e4, 0xe) [0x3000303cfcc]
1 __hstSaveUnblockContext(0x3000302ccf8, 0x20000000000,
0x30003054334, 0x20000ad1600, 0x20000ad1600) [0x30003023d20]
2 __dspReadyList(0x3134313d2932322c, 0xa303238623939, 0x0,
0xfffffc000efa2cc0, 0xfffffc0013138d48) [0x3000302240c]
3 __upcUpcall(0xfffffc0013138d48, 0x5260de00, 0x8, 0x0,
0xfffffffffffffff7) [0x3000303d1e8]
8<==========================================
config.status:
CC="cc" \
CFLAGS=" -std -fprm d -ieee -D_INTRINSICS -I/usr/local/include
-DLANGUAGE_C" \
SSL_BASE="/opt/igowwwroot/tools/openssl" \
./configure \
"--with-layout=Apache" \
"--activate-module=src/modules/perl/libperl.a" \
"--disable-rule=EXPAT" \
"--enable-module=so" \
"--enable-module=access" \
"--enable-shared=access" \
"--enable-module=actions" \
"--enable-shared=actions" \
"--enable-module=alias" \
"--enable-shared=alias" \
"--enable-module=asis" \
"--enable-shared=asis" \
"--enable-module=auth" \
"--enable-shared=auth" \
"--enable-module=auth_anon" \
"--enable-shared=auth_anon" \
"--enable-module=auth_db" \
"--enable-shared=auth_db" \
"--enable-module=auth_dbm" \
"--enable-shared=auth_dbm" \
"--enable-module=autoindex" \
"--enable-shared=autoindex" \
"--enable-module=cern_meta" \
"--enable-shared=cern_meta" \
"--enable-module=cgi" \
"--enable-shared=cgi" \
"--enable-module=digest" \
"--enable-shared=digest" \
"--enable-module=dir" \
"--enable-shared=dir" \
"--enable-module=env" \
"--enable-shared=env" \
"--enable-module=example" \
"--enable-shared=example" \
"--enable-module=expires" \
"--enable-shared=expires" \
"--enable-module=headers" \
"--enable-shared=headers" \
"--enable-module=imap" \
"--enable-shared=imap" \
"--enable-module=include" \
"--enable-shared=include" \
"--enable-module=info" \
"--enable-shared=info" \
"--enable-module=log_agent" \
"--enable-shared=log_agent" \
"--enable-module=log_config" \
"--enable-shared=log_config" \
"--enable-module=log_referer" \
"--enable-shared=log_referer" \
"--enable-module=mime" \
"--enable-shared=mime" \
"--enable-module=mime_magic" \
"--enable-shared=mime_magic" \
"--enable-module=mmap_static" \
"--enable-shared=mmap_static" \
"--enable-module=negotiation" \
"--enable-shared=negotiation" \
"--enable-module=proxy" \
"--enable-shared=proxy" \
"--enable-module=rewrite" \
"--enable-shared=rewrite" \
"--enable-module=setenvif" \
"--enable-shared=setenvif" \
"--enable-module=speling" \
"--enable-shared=speling" \
"--enable-module=status" \
"--enable-shared=status" \
"--enable-module=unique_id" \
"--enable-shared=unique_id" \
"--enable-module=userdir" \
"--enable-shared=userdir" \
"--enable-module=usertrack" \
"--enable-shared=usertrack" \
"--enable-module=vhost_alias" \
"--enable-shared=vhost_alias" \
"--enable-module=ssl" \
"--enable-shared=ssl" \
"--enable-module=proxy" \
"--enable-module=perl" \
"--enable-shared=proxy" \
"--prefix=/opt/igowwwroot/tools/apache" \
"$@"
Re: Apache 1.3.27 bad (?) signal handling on Tru64 5.1
Posted by Lukasz Engel <Lu...@softax.pl>.
On Thu, 2002-10-17 at 18:50, Jeff Trawick wrote:
> Lukasz Engel <Lu...@softax.pl> writes:
>
> > Hello everybody,
> >
> > It's my first deeper contact with apache sources (excluding
> > "./configure; make; make install" ;) ).
> >
> > I am trying to run apache 1.3.27 (with mod_perl and EAPI, but I think it
> > doesn't matter) on Try64 5.1 box and I got SEGVs (every time from the
> > same place).
> > After some tracing I think I found the problem:
> [..]
>
> I've seen this before with threaded 3rd party modules. Apache 1.3 is
> not designed to work in such an environment without special
> precautions.
>
> [...]
> If you have 3rd party modules loaded, the maintainers need to make
> sure they follow this rule. If you don't have 3rd party modules
> loaded and it really is a system library creating a thread with
> inappropriate signal mask (maybe because Apache links against
> libpthread to pick up support for cross-process pthread mutexes?), you
> may need to experiment with which libraries are linked to avoid this
> behavior.
Thanks for quick response.
In fact, one of our perl modules used library (some commercial software)
which was linked with pthreads. Fortunately we had both multi- and
single-threaded version of the library, so I only had to relink with
proper version and all seems to work properly :)
--
Lukasz Engel
Re: Apache 1.3.27 bad (?) signal handling on Tru64 5.1
Posted by Jeff Trawick <tr...@attglobal.net>.
Lukasz Engel <Lu...@softax.pl> writes:
> Hello everybody,
>
> It's my first deeper contact with apache sources (excluding
> "./configure; make; make install" ;) ).
>
> I am trying to run apache 1.3.27 (with mod_perl and EAPI, but I think it
> doesn't matter) on Try64 5.1 box and I got SEGVs (every time from the
> same place).
> After some tracing I think I found the problem:
>
> While reading client's request line SIGALRM accurs (meaning some timeout
> - I don't know exactly). Then in signal handler (in function timeout
> (http_main.c)) longjmp to mail loop is done and apache continues
> processing.
> But on my Tru64 I can see that signal handler for SIGALRM is called in
> different thread (created implicit by libc ?).
I've seen this before with threaded 3rd party modules. Apache 1.3 is
not designed to work in such an environment without special
precautions.
Any thread other than the thread Apache runs on (call it "main
thread") must block SIGALRM and any other non-synchronous signals used
by Apache. Apache is written to assume that its signal handlers will
run on the main thread.
If you have 3rd party modules loaded, the maintainers need to make
sure they follow this rule. If you don't have 3rd party modules
loaded and it really is a system library creating a thread with
inappropriate signal mask (maybe because Apache links against
libpthread to pick up support for cross-process pthread mutexes?), you
may need to experiment with which libraries are linked to avoid this
behavior.
--
Jeff Trawick | trawick@attglobal.net
Born in Roswell... married an alien...