You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@apr.apache.org by Blair Zajac <bl...@orcaware.com> on 2002/04/07 07:04:45 UTC
Runaway SSL httpd server processes
I'm getting a bunch of runaway apache 2.0 processes on my RedHat 7.2.93
(skipjack) box. I'm running Apache as an svn server with the svn
repository <Location> in a virtual SSL server.
Apache is built from HEAD from 20 minutes ago.
All I have to do is browse the home page of the SSL site with Netscape
4.79 and quickly there are a bunch of httpd's chewing up my CPU.
Quitting Netscape to close the sockets does not stop the runaway processes.
Here's the output from pstack:
18366: /opt/i386-linux/installed/apache-2.0-cvs-2002040601/bin/httpd
----- Thread 18366 -----
0x402cb5d1: char_buffer_read + 0xa1 (8132538, 813256c, bffece18, 402cbe6c, 4212e3c0, 4212dfe0) + 20
0x402cbebe: ssl_io_input_getline + 0x5e (8132538, 813256c, bffece58, 402cc06c, 8125ab8, 4212e3b0) + 20
0x402cc19f: ssl_io_filter_Input + 0x13f (8134570, 814f3a0, 1, 0, 0, 4212dfa0) + 10
0x08072028: ap_get_brigade + 0x28 (8134570, 814f3a0, 1, 0, 0, 20) + 20
0x0807ae35: net_time_filter + 0x135 (814f340, 814f3a0, 1, 0, 0, 40027bb0) + 10
0x08072028: ap_get_brigade + 0x28 (814f340, 814f3a0, 1, 0, 0, 812d528) + 60
0x0807330b: ap_rgetline_core + 0x6b (814ec28, 2000, bffecfbc, 814ec10, 0, 814ec10) + 30
0x08073ab7: read_request_line + 0x47 (814ec10, 5, 0, 81212c0, 0, 0) + 10
0x08074154: ap_read_request + 0x1c4 (8123448, 5, bffed028, 805d11f, 80cfc00, 8135578)
0x0805d06b: ap_process_http_connection + 0x2b (8123448, 8123378, bffed058, 806bc22, 378, 81233a8) + 10
0x0806fc0f: ap_run_process_connection + 0x5f (8123448, 8123378, bffed0d8, 8063baf, 8123340, 80a1c30)
0x0806ffce: ap_process_connection + 0x3e (8123448, 8123378, 8123340, 0, 0, 0) + 40
0x08063bc9: child_main + 0x499 (0, 1, bffed0f8, 8063cbd, 0, 0)
0x08063d55: make_child + 0x125 (80a1c30, 0, 0, 0, 0, 0)
0x08063dd1: startup_children + 0x51 (1, 2, bffed168, 80641e4, 0, 4004b970) + 30
0x0806422c: ap_mpm_run + 0x1cc (809fee0, 80c9f88, 80a1c30, 806a77b, 42130f50, 4000b086) + 40
0x0806a78c: main + 0x7cc (1, bffed234, bffed23c, 805a862, 8089cf0, 0) + 20
0x420174d9: __libc_start_main + 0x95 (8069fc0, 1, bffed234, 805a84c, 8089cf0, 4000b974) + 40012dd8
The top functions change, but the one that doesn't is
0x08072028: ap_get_brigade + 0x28 (8134570, 814f3a0, 1, 0, 0, 20) + 20
Best,
Blair
--
Blair Zajac <bl...@orcaware.com>
Web and OS performance plots - http://www.orcaware.com/orca/
Re: Runaway SSL httpd server processes
Posted by Blair Zajac <bl...@orcaware.com>.
Doug MacEachern wrote:
>
> i haven't been able to reproduce this, but the patch below (also in
> cvs) may fix. seeing that ssl_io_hook_read sets rc = 0 if SSL_read
> returns -1 and SSL_get_error is SSL_ERROR_WANT_READ. ssl_io_input_read
> was *always* returning APR_SUCCESS if it got 0 bytes. now it only does so
> if SSL_ERROR_WANT_READ was the reason, otherwise returns APR_EOF.
>
> Index: modules/ssl/ssl_engine_io.c
> ===================================================================
> RCS file: /home/cvs/httpd-2.0/modules/ssl/ssl_engine_io.c,v
> retrieving revision 1.72
> diff -u -r1.72 ssl_engine_io.c
> --- modules/ssl/ssl_engine_io.c 5 Apr 2002 07:31:44 -0000 1.72
> +++ modules/ssl/ssl_engine_io.c 7 Apr 2002 06:25:36 -0000
> @@ -485,7 +485,7 @@
>
> rc = SSL_read(ssl, buf, len);
>
> - if (rc < 0) {
> + if (rc <= 0) {
> int ssl_err = SSL_get_error(ssl, rc);
>
> if (ssl_err == SSL_ERROR_WANT_READ) {
> @@ -673,6 +673,10 @@
> if (ctx->inbio.mode == AP_MODE_SPECULATIVE) {
> char_buffer_write(&ctx->cbuf, buf, rc);
> }
> + }
> + else if ((rc == 0) && (errno != EINTR)) {
> + /* something other than SSL_ERROR_WANT_READ */
> + return APR_EOF;
> }
> else if ((rc == -1) && (ctx->inbio.rc == APR_SUCCESS)) {
> /*
Doug,
Thanks. This patch did the trick. I'm not seeing any runaway processes
processes any more.
Best,
Blair
--
Blair Zajac <bl...@orcaware.com>
Web and OS performance plots - http://www.orcaware.com/orca/
Re: Runaway SSL httpd server processes
Posted by Doug MacEachern <do...@covalent.net>.
i haven't been able to reproduce this, but the patch below (also in
cvs) may fix. seeing that ssl_io_hook_read sets rc = 0 if SSL_read
returns -1 and SSL_get_error is SSL_ERROR_WANT_READ. ssl_io_input_read
was *always* returning APR_SUCCESS if it got 0 bytes. now it only does so
if SSL_ERROR_WANT_READ was the reason, otherwise returns APR_EOF.
Index: modules/ssl/ssl_engine_io.c
===================================================================
RCS file: /home/cvs/httpd-2.0/modules/ssl/ssl_engine_io.c,v
retrieving revision 1.72
diff -u -r1.72 ssl_engine_io.c
--- modules/ssl/ssl_engine_io.c 5 Apr 2002 07:31:44 -0000 1.72
+++ modules/ssl/ssl_engine_io.c 7 Apr 2002 06:25:36 -0000
@@ -485,7 +485,7 @@
rc = SSL_read(ssl, buf, len);
- if (rc < 0) {
+ if (rc <= 0) {
int ssl_err = SSL_get_error(ssl, rc);
if (ssl_err == SSL_ERROR_WANT_READ) {
@@ -673,6 +673,10 @@
if (ctx->inbio.mode == AP_MODE_SPECULATIVE) {
char_buffer_write(&ctx->cbuf, buf, rc);
}
+ }
+ else if ((rc == 0) && (errno != EINTR)) {
+ /* something other than SSL_ERROR_WANT_READ */
+ return APR_EOF;
}
else if ((rc == -1) && (ctx->inbio.rc == APR_SUCCESS)) {
/*
Re: Runaway SSL httpd server processes
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
Blair... dev@apr.apache.org is for the APR library development;
I've forwarded your report to dev@httpd.apache.org ... the Apache HTTP
server development list.
At 11:04 PM 4/6/2002, Blair Zajac wrote:
>I'm getting a bunch of runaway apache 2.0 processes on my RedHat 7.2.93
>(skipjack) box. I'm running Apache as an svn server with the svn
>repository <Location> in a virtual SSL server.
>
>Apache is built from HEAD from 20 minutes ago.
>
>All I have to do is browse the home page of the SSL site with Netscape
>4.79 and quickly there are a bunch of httpd's chewing up my CPU.
>
>Quitting Netscape to close the sockets does not stop the runaway processes.
>
>Here's the output from pstack:
>
>18366: /opt/i386-linux/installed/apache-2.0-cvs-2002040601/bin/httpd
>----- Thread 18366 -----
>0x402cb5d1: char_buffer_read + 0xa1 (8132538, 813256c, bffece18, 402cbe6c,
>4212e3c0, 4212dfe0) + 20
>0x402cbebe: ssl_io_input_getline + 0x5e (8132538, 813256c, bffece58,
>402cc06c, 8125ab8, 4212e3b0) + 20
>0x402cc19f: ssl_io_filter_Input + 0x13f (8134570, 814f3a0, 1, 0, 0,
>4212dfa0) + 10
>0x08072028: ap_get_brigade + 0x28 (8134570, 814f3a0, 1, 0, 0, 20) + 20
>0x0807ae35: net_time_filter + 0x135 (814f340, 814f3a0, 1, 0, 0, 40027bb0) + 10
>0x08072028: ap_get_brigade + 0x28 (814f340, 814f3a0, 1, 0, 0, 812d528) + 60
>0x0807330b: ap_rgetline_core + 0x6b (814ec28, 2000, bffecfbc, 814ec10, 0,
>814ec10) + 30
>0x08073ab7: read_request_line + 0x47 (814ec10, 5, 0, 81212c0, 0, 0) + 10
>0x08074154: ap_read_request + 0x1c4 (8123448, 5, bffed028, 805d11f,
>80cfc00, 8135578)
>0x0805d06b: ap_process_http_connection + 0x2b (8123448, 8123378, bffed058,
>806bc22, 378, 81233a8) + 10
>0x0806fc0f: ap_run_process_connection + 0x5f (8123448, 8123378, bffed0d8,
>8063baf, 8123340, 80a1c30)
>0x0806ffce: ap_process_connection + 0x3e (8123448, 8123378, 8123340, 0, 0,
>0) + 40
>0x08063bc9: child_main + 0x499 (0, 1, bffed0f8, 8063cbd, 0, 0)
>0x08063d55: make_child + 0x125 (80a1c30, 0, 0, 0, 0, 0)
>0x08063dd1: startup_children + 0x51 (1, 2, bffed168, 80641e4, 0, 4004b970)
>+ 30
>0x0806422c: ap_mpm_run + 0x1cc (809fee0, 80c9f88, 80a1c30, 806a77b,
>42130f50, 4000b086) + 40
>0x0806a78c: main + 0x7cc (1, bffed234, bffed23c, 805a862, 8089cf0, 0) + 20
>0x420174d9: __libc_start_main + 0x95 (8069fc0, 1, bffed234, 805a84c,
>8089cf0, 4000b974) + 40012dd8
>
>The top functions change, but the one that doesn't is
>
>0x08072028: ap_get_brigade + 0x28 (8134570, 814f3a0, 1, 0, 0, 20) + 20
>
>Best,
>Blair
>
>--
>Blair Zajac <bl...@orcaware.com>
>Web and OS performance plots - http://www.orcaware.com/orca/