You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by Brian Behlendorf <br...@collab.net> on 2001/02/01 06:35:45 UTC
Re: apache 2.0 on apache.org status
apache 2.0 built as of this afternoon now running on apache.org. A few
corefiles so far in /usr/local/apache2/corefiles, but less frequent than
before. Looks like at least 2-3 different problems.
Brian
Re: apache 2.0 on apache.org status
Posted by Jeff Trawick <tr...@bellsouth.net>.
Greg Ames <gr...@raleigh.ibm.com> writes:
> Jeff, why don't you commit this patch with the change suggested by Bill,
> since there's no other objections? or do you want me to run it
> first?
I'll go ahead and commit with Bill's suggestion.
--
Jeff Trawick | trawickj@bellsouth.net | PGP public key at web site:
http://www.geocities.com/SiliconValley/Park/9289/
Born in Roswell... married an alien...
Re: apache 2.0 on apache.org status
Posted by Greg Ames <gr...@raleigh.ibm.com>.
Bill Stoddard wrote:
>
> I'd make the messages info rather than error. My .02...
>
> > I think we need to run with this patch and see what we get. Obviously
> > the other MPMs would need to be updated as well.
> >
> > Any concerns with this code before I commit? Hopefully the code for
> > other MPMs is easily modified to implement the same check.
> >
> > Index: server/mpm/prefork/prefork.c
Jeff, why don't you commit this patch with the change suggested by Bill,
since there's no other objections? or do you want me to run it first?
Greg
Re: apache 2.0 on apache.org status
Posted by Bill Stoddard <bi...@wstoddard.com>.
I'd make the messages info rather than error. My .02...
Bill
> "Bill Stoddard" <bi...@wstoddard.com> writes:
>
> > > I would guess that the connection was dropped before
> > > ap_new_connection() called apr_get_sockaddr(,APR_LOCAL,), thus
> > > getsockname() (called by get_local_addr()) failed.
> > >
> > > We ignored the return code and the rest is history.
> > >
> > > Any ideas for verifying this hypothesis further?
> >
> > Only the obvious. Add a check for the return code and log the error when
it
> > happens.
>
> Yeah, I think my tests to try to get getsockname() to fail were flawed
> as I was unable to generate a TCP RST from the client (vs. TCP fin).
>
> When I load the core into emacs I see
>
> "4.yamato.ibm.com:8080 (Squid[Wed Jan 31 21:28:06 2001] [warn]
> (54)Connection reset by peer: setsockopt: (TCP_NODELAY)"
>
> (those IBM jerks :) )
>
> We do this setsockopt just before the getsockname().
>
> I think we need to run with this patch and see what we get. Obviously
> the other MPMs would need to be updated as well.
>
> Any concerns with this code before I commit? Hopefully the code for
> other MPMs is easily modified to implement the same check.
>
> Index: server/mpm/prefork/prefork.c
> ===================================================================
> RCS file: /home/cvspublic/httpd-2.0/server/mpm/prefork/prefork.c,v
> retrieving revision 1.149
> diff -u -r1.149 prefork.c
> --- server/mpm/prefork/prefork.c 2001/01/31 02:15:12 1.149
> +++ server/mpm/prefork/prefork.c 2001/02/01 14:48:41
> @@ -1048,9 +1048,10 @@
>
> current_conn = ap_new_connection(ptrans, ap_server_conf, csd,
> my_child_num);
> -
> - ap_process_connection(current_conn);
> - ap_lingering_close(current_conn);
> + if (current_conn) {
> + ap_process_connection(current_conn);
> + ap_lingering_close(current_conn);
> + }
> }
> clean_child_exit(0);
> }
> Index: server/connection.c
> ===================================================================
> RCS file: /home/cvspublic/httpd-2.0/server/connection.c,v
> retrieving revision 1.70
> diff -u -r1.70 connection.c
> --- server/connection.c 2001/01/19 22:32:15 1.70
> +++ server/connection.c 2001/02/01 14:48:42
> @@ -67,6 +67,7 @@
> #include "mpm_status.h"
> #include "http_config.h"
> #include "http_vhost.h"
> +#include "http_log.h"
> #include "util_filter.h"
>
> #ifdef HAVE_NETINET_IN_H
> @@ -270,6 +271,7 @@
> apr_socket_t *inout, long id)
> {
> conn_rec *conn = (conn_rec *) apr_pcalloc(p, sizeof(conn_rec));
> + apr_status_t rv;
>
> /* Got a connection structure, so initialize what fields we can
> * (the rest are zeroed out by pcalloc).
> @@ -279,9 +281,21 @@
> conn->notes = apr_make_table(p, 5);
>
> conn->pool = p;
> - apr_get_sockaddr(&conn->local_addr, APR_LOCAL, inout);
> + if ((rv = apr_get_sockaddr(&conn->local_addr, APR_LOCAL, inout))
> + != APR_SUCCESS) {
> + ap_log_error(APLOG_MARK, APLOG_ERR, rv, server,
> + "apr_get_sockaddr(APR_LOCAL)");
> + apr_close_socket(inout);
> + return NULL;
> + }
> apr_get_ipaddr(&conn->local_ip, conn->local_addr);
> - apr_get_sockaddr(&conn->remote_addr, APR_REMOTE, inout);
> + if ((rv = apr_get_sockaddr(&conn->remote_addr, APR_REMOTE, inout))
> + != APR_SUCCESS) {
> + ap_log_error(APLOG_MARK, APLOG_ERR, rv, server,
> + "apr_get_sockaddr(APR_REMOTE)");
> + apr_close_socket(inout);
> + return NULL;
> + }
> apr_get_ipaddr(&conn->remote_ip, conn->remote_addr);
> conn->base_server = server;
> conn->client_socket = inout;
>
> --
> Jeff Trawick | trawickj@bellsouth.net | PGP public key at web site:
> http://www.geocities.com/SiliconValley/Park/9289/
> Born in Roswell... married an alien...
>
Re: apache 2.0 on apache.org status
Posted by Jeff Trawick <tr...@bellsouth.net>.
"Bill Stoddard" <bi...@wstoddard.com> writes:
> > I would guess that the connection was dropped before
> > ap_new_connection() called apr_get_sockaddr(,APR_LOCAL,), thus
> > getsockname() (called by get_local_addr()) failed.
> >
> > We ignored the return code and the rest is history.
> >
> > Any ideas for verifying this hypothesis further?
>
> Only the obvious. Add a check for the return code and log the error when it
> happens.
Yeah, I think my tests to try to get getsockname() to fail were flawed
as I was unable to generate a TCP RST from the client (vs. TCP fin).
When I load the core into emacs I see
"4.yamato.ibm.com:8080 (Squid[Wed Jan 31 21:28:06 2001] [warn]
(54)Connection reset by peer: setsockopt: (TCP_NODELAY)"
(those IBM jerks :) )
We do this setsockopt just before the getsockname().
I think we need to run with this patch and see what we get. Obviously
the other MPMs would need to be updated as well.
Any concerns with this code before I commit? Hopefully the code for
other MPMs is easily modified to implement the same check.
Index: server/mpm/prefork/prefork.c
===================================================================
RCS file: /home/cvspublic/httpd-2.0/server/mpm/prefork/prefork.c,v
retrieving revision 1.149
diff -u -r1.149 prefork.c
--- server/mpm/prefork/prefork.c 2001/01/31 02:15:12 1.149
+++ server/mpm/prefork/prefork.c 2001/02/01 14:48:41
@@ -1048,9 +1048,10 @@
current_conn = ap_new_connection(ptrans, ap_server_conf, csd,
my_child_num);
-
- ap_process_connection(current_conn);
- ap_lingering_close(current_conn);
+ if (current_conn) {
+ ap_process_connection(current_conn);
+ ap_lingering_close(current_conn);
+ }
}
clean_child_exit(0);
}
Index: server/connection.c
===================================================================
RCS file: /home/cvspublic/httpd-2.0/server/connection.c,v
retrieving revision 1.70
diff -u -r1.70 connection.c
--- server/connection.c 2001/01/19 22:32:15 1.70
+++ server/connection.c 2001/02/01 14:48:42
@@ -67,6 +67,7 @@
#include "mpm_status.h"
#include "http_config.h"
#include "http_vhost.h"
+#include "http_log.h"
#include "util_filter.h"
#ifdef HAVE_NETINET_IN_H
@@ -270,6 +271,7 @@
apr_socket_t *inout, long id)
{
conn_rec *conn = (conn_rec *) apr_pcalloc(p, sizeof(conn_rec));
+ apr_status_t rv;
/* Got a connection structure, so initialize what fields we can
* (the rest are zeroed out by pcalloc).
@@ -279,9 +281,21 @@
conn->notes = apr_make_table(p, 5);
conn->pool = p;
- apr_get_sockaddr(&conn->local_addr, APR_LOCAL, inout);
+ if ((rv = apr_get_sockaddr(&conn->local_addr, APR_LOCAL, inout))
+ != APR_SUCCESS) {
+ ap_log_error(APLOG_MARK, APLOG_ERR, rv, server,
+ "apr_get_sockaddr(APR_LOCAL)");
+ apr_close_socket(inout);
+ return NULL;
+ }
apr_get_ipaddr(&conn->local_ip, conn->local_addr);
- apr_get_sockaddr(&conn->remote_addr, APR_REMOTE, inout);
+ if ((rv = apr_get_sockaddr(&conn->remote_addr, APR_REMOTE, inout))
+ != APR_SUCCESS) {
+ ap_log_error(APLOG_MARK, APLOG_ERR, rv, server,
+ "apr_get_sockaddr(APR_REMOTE)");
+ apr_close_socket(inout);
+ return NULL;
+ }
apr_get_ipaddr(&conn->remote_ip, conn->remote_addr);
conn->base_server = server;
conn->client_socket = inout;
--
Jeff Trawick | trawickj@bellsouth.net | PGP public key at web site:
http://www.geocities.com/SiliconValley/Park/9289/
Born in Roswell... married an alien...
Re: apache 2.0 on apache.org status
Posted by Bill Stoddard <bi...@wstoddard.com>.
> Brian Behlendorf <br...@collab.net> writes:
>
> > apache 2.0 built as of this afternoon now running on apache.org. A few
> > corefiles so far in /usr/local/apache2/corefiles, but less frequent than
> > before. Looks like at least 2-3 different problems.
>
> Problem one looks like:
>
> #0 0x808e89d in apr_get_ipaddr (addr=0x8130118, sockaddr=0x0) at
../unix/sa_common.c:119
> 119 *addr = apr_palloc(sockaddr->pool, sockaddr->addr_str_len);
> (gdb) bt
> #0 0x808e89d in apr_get_ipaddr (addr=0x8130118, sockaddr=0x0) at
../unix/sa_common.c:119
> #1 0x806da60 in ap_new_connection (p=0x813000c, server=0x80b4514,
inout=0x813003c, id=117) at connection.c:283
> #2 0x80644f5 in child_main (child_num_arg=117) at prefork.c:1049
> #3 0x8064631 in make_child (s=0x80b4514, slot=117, now=981016492) at
prefork.c:1124
> #4 0x8064838 in perform_idle_server_maintenance () at prefork.c:1267
> #5 0x8064bb1 in ap_mpm_run (_pconf=0x80b400c, plog=0x80de00c, s=0x80b4514)
at prefork.c:1455
> #6 0x806931c in main (argc=3, argv=0xbfbffa6c) at main.c:431
> #7 0x8058401 in _start ()
> (gdb) up
> #1 0x806da60 in ap_new_connection (p=0x813000c, server=0x80b4514,
inout=0x813003c, id=117) at connection.c:283
> 283 apr_get_ipaddr(&conn->local_ip, conn->local_addr);
> (gdb) p conn->local_addr
> $1 = (apr_sockaddr_t *) 0x0
> (gdb) p *conn
> $2 = {pool = 0x813000c, base_server = 0x0, vhost_lookup_data = 0x0,
client_socket = 0x0, local_addr = 0x0,
> remote_addr = 0x0, remote_ip = 0x0, remote_host = 0x0, remote_logname =
0x0, aborted = 0, keepalive = 0, keptalive = 0,
> double_reverse = 0, keepalives = 0, local_ip = 0x0, local_host = 0x0, id =
0, conn_config = 0x813013c,
> notes = 0x81302cc, input_filters = 0x0, output_filters = 0x0, remain = 0}
> (gdb) p inout
> $3 = (apr_socket_t *) 0x813003c
> (gdb) p *inout
> $4 = {cntxt = 0x813000c, socketdes = 10, local_addr = 0x813005c, remote_addr
= 0x813009c, timeout = -1,
> local_port_unknown = 0, local_interface_unknown = 1, netmask = 0}
>
> I would guess that the connection was dropped before
> ap_new_connection() called apr_get_sockaddr(,APR_LOCAL,), thus
> getsockname() (called by get_local_addr()) failed.
>
> We ignored the return code and the rest is history.
>
> Any ideas for verifying this hypothesis further?
Only the obvious. Add a check for the return code and log the error when it
happens.
Bill
Re: apache 2.0 on apache.org status
Posted by Jeff Trawick <tr...@bellsouth.net>.
Brian Behlendorf <br...@collab.net> writes:
> apache 2.0 built as of this afternoon now running on apache.org. A few
> corefiles so far in /usr/local/apache2/corefiles, but less frequent than
> before. Looks like at least 2-3 different problems.
Problem one looks like:
#0 0x808e89d in apr_get_ipaddr (addr=0x8130118, sockaddr=0x0) at ../unix/sa_common.c:119
119 *addr = apr_palloc(sockaddr->pool, sockaddr->addr_str_len);
(gdb) bt
#0 0x808e89d in apr_get_ipaddr (addr=0x8130118, sockaddr=0x0) at ../unix/sa_common.c:119
#1 0x806da60 in ap_new_connection (p=0x813000c, server=0x80b4514, inout=0x813003c, id=117) at connection.c:283
#2 0x80644f5 in child_main (child_num_arg=117) at prefork.c:1049
#3 0x8064631 in make_child (s=0x80b4514, slot=117, now=981016492) at prefork.c:1124
#4 0x8064838 in perform_idle_server_maintenance () at prefork.c:1267
#5 0x8064bb1 in ap_mpm_run (_pconf=0x80b400c, plog=0x80de00c, s=0x80b4514) at prefork.c:1455
#6 0x806931c in main (argc=3, argv=0xbfbffa6c) at main.c:431
#7 0x8058401 in _start ()
(gdb) up
#1 0x806da60 in ap_new_connection (p=0x813000c, server=0x80b4514, inout=0x813003c, id=117) at connection.c:283
283 apr_get_ipaddr(&conn->local_ip, conn->local_addr);
(gdb) p conn->local_addr
$1 = (apr_sockaddr_t *) 0x0
(gdb) p *conn
$2 = {pool = 0x813000c, base_server = 0x0, vhost_lookup_data = 0x0, client_socket = 0x0, local_addr = 0x0,
remote_addr = 0x0, remote_ip = 0x0, remote_host = 0x0, remote_logname = 0x0, aborted = 0, keepalive = 0, keptalive = 0,
double_reverse = 0, keepalives = 0, local_ip = 0x0, local_host = 0x0, id = 0, conn_config = 0x813013c,
notes = 0x81302cc, input_filters = 0x0, output_filters = 0x0, remain = 0}
(gdb) p inout
$3 = (apr_socket_t *) 0x813003c
(gdb) p *inout
$4 = {cntxt = 0x813000c, socketdes = 10, local_addr = 0x813005c, remote_addr = 0x813009c, timeout = -1,
local_port_unknown = 0, local_interface_unknown = 1, netmask = 0}
I would guess that the connection was dropped before
ap_new_connection() called apr_get_sockaddr(,APR_LOCAL,), thus
getsockname() (called by get_local_addr()) failed.
We ignored the return code and the rest is history.
Any ideas for verifying this hypothesis further?
--
Jeff Trawick | trawickj@bellsouth.net | PGP public key at web site:
http://www.geocities.com/SiliconValley/Park/9289/
Born in Roswell... married an alien...
Re: apache 2.0 on apache.org status
Posted by Cliff Woolley <cl...@yahoo.com>.
--- Jeff Trawick <tr...@bellsouth.net> wrote:
> no useful info about the request :(
> I don't know what else to look for...
I like the Electric Fence idea... that ought to simplify things. We could chase dead
ends for days or weeks without more information. Thanks for the data structures info,
though... I'll stare at it for a while and see if anything more jumps out at me.
--Cliff
__________________________________________________
Get personalized email addresses from Yahoo! Mail - only $35
a year! http://personal.mail.yahoo.com/
Re: apache 2.0 on apache.org status
Posted by Jeff Trawick <tr...@bellsouth.net>.
Cliff Woolley <cl...@yahoo.com> writes:
> Most likely. Deferred errors are a PITA. When you get a second, can you post a
> structures dump for this core file like you did for the one in Problem Two? I'll try and
> track it down, but without more information about the request itself, I probably wouldn't
> get very far.
no useful info about the request :(
(gdb) p *(request_rec *)0x81d503c
$4 = {pool = 0x81d500c, connection = 0x81300ec, server = 0x8104b64,
next = 0x0, prev = 0x0, main = 0x0, the_request = 0x0, assbackwards = 0,
proxyreq = 0, header_only = 0, protocol = 0x0, proto_num = 0,
hostname = 0x0, request_time = 0, status_line = 0x0, status = 408,
method = 0x0, method_number = 0, allowed = 0, allowed_xmethods = 0x0,
allowed_methods = 0x81d51bc, sent_bodyct = 0, bytes_sent = 0, mtime = 0,
chunked = 0, boundary = 0x0, range = 0x0, clength = 0, remaining = 0,
read_length = 0, read_body = 0, read_chunked = 0, expecting_100 = 0,
headers_in = 0x81d51e4, headers_out = 0x81d5534,
err_headers_out = 0x81d55ac, subprocess_env = 0x81d538c, notes = 0x81d55ec,
content_type = 0x0, handler = 0x0, content_encoding = 0x0,
content_language = 0x0, content_languages = 0x0, vlist_validator = 0x0,
user = 0x0, ap_auth_type = 0x0, no_cache = 0, no_local_copy = 0,
unparsed_uri = 0x0, uri = 0x0, filename = 0x0, path_info = 0x0, args = 0x0,
finfo = {cntxt = 0x0, valid = 0, protection = 0, filetype = APR_NOFILE,
user = 0, group = 0, inode = 0, device = 0, nlink = 0, size = 0,
csize = 0, atime = 0, mtime = 0, ctime = 0, fname = 0x0, name = 0x0,
filehand = 0x0}, parsed_uri = {scheme = 0x0, hostinfo = 0x0, user = 0x0,
password = 0x0, hostname = 0x0, port_str = 0x0, path = 0x0, query = 0x0,
fragment = 0x0, hostent = 0x0, port = 0, is_initialized = 0,
dns_looked_up = 0, dns_resolved = 0}, per_dir_config = 0x81548a4,
request_config = 0x81d562c, htaccess = 0x0, output_filters = 0x81d57e4,
input_filters = 0x813033c, eos_sent = 0}
nothing in the header tables
(gdb) p *r->connection
$7 = {pool = 0x813000c, base_server = 0x8104b64,
vhost_lookup_data = 0x8154aa4, client_socket = 0x813003c,
local_addr = 0x813005c, remote_addr = 0x813009c,
remote_ip = 0x8130313 "213.240.37.225", remote_host = 0x0,
remote_logname = 0x0, aborted = 0, keepalive = 0, keptalive = 1,
double_reverse = 0, keepalives = 3, local_ip = 0x80b1873 "64.208.42.41",
local_host = 0x0, id = 52, conn_config = 0x813013c, notes = 0x81302cc,
input_filters = 0x813033c, output_filters = 0x813036c, remain = 0}
(gdb)
Maybe this isn't the first request on this connection, cause there is
some evidence that this process talked to that client machine before:
[Wed Jan 31 21:39:39 2001] [error] [client 213.\240.37.225] (20514)End
of file found: mod_mime_magic: read failed
/www/www.apache.org/mail/current-testers/200012.gz, referer:
http://www\.apache.org:80/mail/* (followed in memory by garbage)
huh? That is 17 minutes after the last entry in error_log...
I don't know what else to look for...
--
Jeff Trawick | trawickj@bellsouth.net | PGP public key at web site:
http://www.geocities.com/SiliconValley/Park/9289/
Born in Roswell... married an alien...
Re: apache 2.0 on apache.org status
Posted by Cliff Woolley <cl...@yahoo.com>.
--- Jeff Trawick <tr...@bellsouth.net> wrote:
> Problem three (example: httpd.core.7) looks like:
>
> #0 0x281491e1 in isatty () from /usr/lib/libc.so.4
> (gdb) bt
> #0 0x281491e1 in isatty () from /usr/lib/libc.so.4
> #1 0x2814955d in isatty () from /usr/lib/libc.so.4
> #2 0x28149c69 in malloc () from /usr/lib/libc.so.4
> #3 0x807648d in socket_read (a=0x80aa520, str=0xbfbfd694, len=0xbfbfd69c,
[snip]
>
> more evidence of malloc corruption???????
Most likely. Deferred errors are a PITA. When you get a second, can you post a
structures dump for this core file like you did for the one in Problem Two? I'll try and
track it down, but without more information about the request itself, I probably wouldn't
get very far.
Thanks,
Cliff
__________________________________________________
Get personalized email addresses from Yahoo! Mail - only $35
a year! http://personal.mail.yahoo.com/
Re: apache 2.0 on apache.org status
Posted by Jeff Trawick <tr...@bellsouth.net>.
Brian Behlendorf <br...@collab.net> writes:
> apache 2.0 built as of this afternoon now running on apache.org. A few
> corefiles so far in /usr/local/apache2/corefiles, but less frequent than
> before. Looks like at least 2-3 different problems.
Problem three (example: httpd.core.7) looks like:
#0 0x281491e1 in isatty () from /usr/lib/libc.so.4
(gdb) bt
#0 0x281491e1 in isatty () from /usr/lib/libc.so.4
#1 0x2814955d in isatty () from /usr/lib/libc.so.4
#2 0x28149c69 in malloc () from /usr/lib/libc.so.4
#3 0x807648d in socket_read (a=0x80aa520, str=0xbfbfd694, len=0xbfbfd69c, block=APR_BLOCK_READ) at apr_buckets_socket.c:74
#4 0x805d751 in ap_http_filter (f=0x813033c, b=0x81d57c4, mode=AP_MODE_BLOCKING) at http_protocol.c:1015
#5 0x806e7b9 in ap_get_brigade (next=0x813033c, bb=0x81d57c4, mode=AP_MODE_BLOCKING) at util_filter.c:215
#6 0x805d886 in ap_getline (s=0xbfbfd768 "", n=8192, r=0x81d503c, fold=0) at http_protocol.c:1067
#7 0x805db6a in read_request_line (r=0x81d503c) at http_protocol.c:1255
#8 0x805e031 in ap_read_request (conn=0x81300ec) at http_protocol.c:1439
#9 0x806d9ac in ap_process_http_connection (c=0x81300ec) at connection.c:259
#10 0x806d77c in ap_run_process_connection (c=0x81300ec) at connection.c:85
#11 0x806d904 in ap_process_connection (c=0x81300ec) at connection.c:221
#12 0x8064500 in child_main (child_num_arg=52) at prefork.c:1052
#13 0x8064631 in make_child (s=0x80b4514, slot=52, now=981005029) at prefork.c:1124
#14 0x8064838 in perform_idle_server_maintenance () at prefork.c:1267
#15 0x8064bb1 in ap_mpm_run (_pconf=0x80b400c, plog=0x80de00c, s=0x80b4514) at prefork.c:1455
#16 0x806931c in main (argc=3, argv=0xbfbffa6c) at main.c:431
#17 0x8058401 in _start ()
more evidence of malloc corruption???????
--
Jeff Trawick | trawickj@bellsouth.net | PGP public key at web site:
http://www.geocities.com/SiliconValley/Park/9289/
Born in Roswell... married an alien...
Re: apache 2.0 on apache.org status
Posted by Jeff Trawick <tr...@bellsouth.net>.
Ben Laurie <be...@algroup.co.uk> writes:
> Jeff Trawick wrote:
> > (gdb) dump_table r->headers_in
> > [0] 'Accept'='*/*'
> > [1] 'Cache-Control'='max-age=259200'
> > [2] 'Connection'='keep-alive'
> > [3] 'Host'='www.apache.org:80'
> > [4] 'Referer'='http://www.apache.org:80/mail/current-testers/?D=A'
> > [5] 'User-Agent'='Wget/1.5.3'
> > [6] 'Via'='1.0 proxy.ftn.ns.ac.yu:8080 (Squid/2.2.STABLE4)'
> > [7] 'X-Forwarded-For'='147.91.173.27'
>
> Ooo! How do you do this bit of magic?
I feel better now... I guess I'm not the only loser^H^H^H^H^Hastute
programmer that didn't know about the dump_table macro. As Ryan
pointed out to me a few days back, it lives in httpd-2.0/.gdbinit.
See that for details.
Have fun,
--
Jeff Trawick | trawickj@bellsouth.net | PGP public key at web site:
http://www.geocities.com/SiliconValley/Park/9289/
Born in Roswell... married an alien...
Re: apache 2.0 on apache.org status
Posted by Ben Laurie <be...@algroup.co.uk>.
Jeff Trawick wrote:
> (gdb) dump_table r->headers_in
> [0] 'Accept'='*/*'
> [1] 'Cache-Control'='max-age=259200'
> [2] 'Connection'='keep-alive'
> [3] 'Host'='www.apache.org:80'
> [4] 'Referer'='http://www.apache.org:80/mail/current-testers/?D=A'
> [5] 'User-Agent'='Wget/1.5.3'
> [6] 'Via'='1.0 proxy.ftn.ns.ac.yu:8080 (Squid/2.2.STABLE4)'
> [7] 'X-Forwarded-For'='147.91.173.27'
Ooo! How do you do this bit of magic?
Cheers,
Ben.
--
http://www.apache-ssl.org/ben.html
"There is no limit to what a man can do or how far he can go if he
doesn't mind who gets the credit." - Robert Woodruff
Re: apache 2.0 on apache.org status
Posted by Jeff Trawick <tr...@bellsouth.net>.
Jeff Trawick <tr...@bellsouth.net> writes:
> Problem two looks like this (example: httpd.core.8)
>
> #0 0x28149964 in isatty () from /usr/lib/libc.so.4
...
more info from httpd.core.8... we can try to recreate later with
apache-2.0 running on port 8092...
(gdb) p *r
$1 = {pool = 0x81f800c, connection = 0x81300ec, server = 0x81102a4,
next = 0x0, prev = 0x0, main = 0x0,
the_request = 0x81f882c "GET /mail/current-testers/?D=D HTTP/1.0",
assbackwards = 0, proxyreq = 0, header_only = 0,
protocol = 0x81f88bc "HTTP/1.0", proto_num = 1000,
hostname = 0x81f8b84 "www.apache.org", request_time = 981006003315646,
status_line = 0x809693b "200 OK", status = 200, method = 0x81f8854 "GET",
method_number = 0, allowed = 1, allowed_xmethods = 0x0,
allowed_methods = 0x81f81bc, sent_bodyct = 1, bytes_sent = 2661,
mtime = 978336180000000, chunked = 0, boundary = 0x0, range = 0x0,
clength = 2661, remaining = 0, read_length = 0, read_body = 0,
read_chunked = 0, expecting_100 = 0, headers_in = 0x81f81e4,
headers_out = 0x81f8534, err_headers_out = 0x81f85ac,
/1.1" 206 225 "-" "-"é7akarta-tomcat/release/v3.2.1/ HTTP/1.1" 206 221 "-" "-" content_type = 0x28195795 "text/html", handler = 0x0,
content_encoding = 0x0, content_language = 0x0, content_languages = 0x0,
vlist_validator = 0x0, user = 0x0, ap_auth_type = 0x0, no_cache = 0,
no_local_copy = 0, unparsed_uri = 0x81f887c "/mail/current-testers/?D=D",
uri = 0x81f889c "/mail/current-testers/",
filename = 0x81f31ac "/www/www.apache.org/mail/current-testers/",
path_info = 0x81f8cd4 "/", args = 0x81f88b4 "D=D", finfo = {
cntxt = 0x81f800c, valid = 7598448, protection = 1909, filetype = APR_DIR,
user = 500, group = 5008, inode = 2904604, device = 134412, nlink = 2,
size = 512, csize = 0, atime = 978199107000000, mtime = 978336180000000,
ctime = 978336180000000,
fname = 0x81f8ca4 "/www/www.apache.org/mail/current-testers", name = 0x0,
filehand = 0x0}, parsed_uri = {scheme = 0x0, hostinfo = 0x0, user = 0x0,
password = 0x0, hostname = 0x0, port_str = 0x0,
path = 0x81f889c "/mail/current-testers/", query = 0x81f88b4 "D=D",
fragment = 0x0, hostent = 0x0, port = 0, is_initialized = 1,
dns_looked_up = 0, dns_resolved = 0}, per_dir_config = 0x81f8e84,
request_config = 0x81f862c, htaccess = 0x81f300c,
output_filters = 0x81f33a4, input_filters = 0x813033c, eos_sent = 1}
(gdb) dump_table r->headers_in
[0] 'Accept'='*/*'
[1] 'Cache-Control'='max-age=259200'
[2] 'Connection'='keep-alive'
[3] 'Host'='www.apache.org:80'
[4] 'Referer'='http://www.apache.org:80/mail/current-testers/?D=A'
[5] 'User-Agent'='Wget/1.5.3'
[6] 'Via'='1.0 proxy.ftn.ns.ac.yu:8080 (Squid/2.2.STABLE4)'
[7] 'X-Forwarded-For'='147.91.173.27'
(gdb) dump_table r->headers_out
[0] 'Cache-Control'='max-age=0'
[1] 'Expires'='Thu, 01 Feb 2001 05:40:03 GMT'
[2] 'Last-Modified'='Mon, 01 Jan 2001 08:03:00 GMT'
[3] 'ETag'='"2c521c-200-a47ad500"'
[4] 'Content-Length'='2661'
[5] 'Keep-Alive'='timeout=5, max=99'
[6] 'Connection'='Keep-Alive'
[7] 'Content-Type'='text/html'
(gdb) dump_table r->err_headers_out
(gdb)
--
Jeff Trawick | trawickj@bellsouth.net | PGP public key at web site:
http://www.geocities.com/SiliconValley/Park/9289/
Born in Roswell... married an alien...
Re: apache 2.0 on apache.org status
Posted by Jeff Trawick <tr...@bellsouth.net>.
Brian Behlendorf <br...@collab.net> writes:
> apache 2.0 built as of this afternoon now running on apache.org. A few
> corefiles so far in /usr/local/apache2/corefiles, but less frequent than
> before. Looks like at least 2-3 different problems.
Problem two looks like this (example: httpd.core.8)
#0 0x28149964 in isatty () from /usr/lib/libc.so.4
(gdb) bt
#0 0x28149964 in isatty () from /usr/lib/libc.so.4
#1 0x28149d49 in free () from /usr/lib/libc.so.4
#2 0x281363b2 in closedir () from /usr/lib/libc.so.4
#3 0x808c8ac in dir_cleanup (thedir=0x81f31f4) at dir.c:68
#4 0x808832e in run_cleanups (c=0x81f3fdc) at apr_pools.c:625
#5 0x808842b in apr_clear_pool (a=0x81f800c) at apr_pools.c:729
#6 0x8088487 in apr_destroy_pool (a=0x81f800c) at apr_pools.c:758
#7 0x806d997 in ap_process_http_connection (c=0x81300ec) at connection.c:255
#8 0x806d77c in ap_run_process_connection (c=0x81300ec) at connection.c:85
#9 0x806d904 in ap_process_connection (c=0x81300ec) at connection.c:221
#10 0x8064500 in child_main (child_num_arg=209) at prefork.c:1052
#11 0x8064631 in make_child (s=0x80b4514, slot=209, now=981005281) at prefork.c:1124
#12 0x8064838 in perform_idle_server_maintenance () at prefork.c:1267
#13 0x8064bb1 in ap_mpm_run (_pconf=0x80b400c, plog=0x80de00c, s=0x80b4514) at prefork.c:1455
#14 0x806931c in main (argc=3, argv=0xbfbffa6c) at main.c:431
#15 0x8058401 in _start ()
I don't know why free() would call isatty(), but perhaps it is a weird
path (i.e., error path) caused by memory corruption? Maybe we called
closedir() twice for same data? Just a silly idea...
--
Jeff Trawick | trawickj@bellsouth.net | PGP public key at web site:
http://www.geocities.com/SiliconValley/Park/9289/
Born in Roswell... married an alien...
Re: apache 2.0 on apache.org status
Posted by Greg Ames <gr...@raleigh.ibm.com>.
I have a new build running on apache.org:8092. It looks good to me so
far. Please try to break it if you have the time, and let us know about
any problems.
Thanks,
Greg
Re: apache 2.0 on apache.org status
Posted by Brian Behlendorf <br...@collab.net>.
On Wed, 31 Jan 2001, Brian Behlendorf wrote:
> apache 2.0 built as of this afternoon now running on apache.org. A few
> corefiles so far in /usr/local/apache2/corefiles, but less frequent than
> before. Looks like at least 2-3 different problems.
No longer running, after the -WINCH I started seeing a spate of core dumps
and feared the WINCH was a result. If people want to take a what at them
with gdb, /usr/local/apache2/corefiles is where the party's at; the httpd
binary has been copied over to that dir as well.
Brian