Mailing-List: contact bugs-help@httpd.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Apache HTTPD Bugs Notification List" <bugs@httpd.apache.org>
From: bugzilla@apache.org
To: bugs@httpd.apache.org
Subject: DO NOT REPLY [Bug 35974]  -
    Occasional seg fault/bus error in NFS hosted includes-parsed files
Message-Id: <20050802153958.52D79E0@ajax.apache.org>
Date: Tue,  2 Aug 2005 17:39:58 +0200 (CEST)

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG�
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://issues.apache.org/bugzilla/show_bug.cgi?id=35974>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND�
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=35974


------- Additional Comments From stuart@terminus.co.uk  2005-08-02 17:39 -------
Quick response - thanks. :)

(In reply to comment #4)
> #1  0xff3676a0 in apr_brigade_create (p=0x0, list=0x3c7ef0) at apr_brigade.c:67
>         b = (apr_bucket_brigade *) 0x3c8c80
> #2  0x000d17e0 in core_output_filter (f=0x3c3f10, b=0x3f4130) at core.c:4047
> 
> the p = NULL bit looks like the problem, unless that's a side-effect of stack
> corruption.  In gdb if you "up 2" into core_output_filter, what does
> 
>   p *f
>   p *f->conn

Indeed - meant to mention that's what seems to be the issue (though how it's
happened...). Anyway:

(gdb) up 2
#4  0x0007c494 in chunk_filter (f=0x3df960, b=0x3f0b70) at http_core.c:218
218             rv = ap_pass_brigade(f->next, b);
(gdb) p *f
$1 = {frec = 0x1cd638, ctx = 0x0, next = 0x3c3f10, r = 0x3c9f30, c = 0x3c3b80}
(gdb) p *f->conn
There is no member named conn.

But ITYM:

(gdb) p *f->c
$2 = {pool = 0x0, base_server = 0x0, vhost_lookup_data = 0x0, local_addr =
0x3c3ae0, remote_addr = 0x0, 
  remote_ip = 0x3c3ed8 "85.164.244.5", remote_host = 0x0, remote_logname = 0x0,
aborted = 0, 
  keepalive = AP_CONN_CLOSE, double_reverse = 0, keepalives = 0, local_ip =
0x3c3ec8 "212.187.153.30", 
  local_host = 0x0, id = 14, conn_config = 0x3c3bd8, notes = 0x3c3d70,
input_filters = 0x3c3ef8, 
  output_filters = 0x3c3f10, sbh = 0x3c1ac8, bucket_alloc = 0x3c7ef0}

> If the pool really is NULL this could just be a symptom of hitting an
> out-of-memory condition - is that plausible for this system?  (httpd should be
> calling abort() in that case but actually doesn't)

Incredibly unlikely. top claims:

load averages:  1.29,  1.38,  1.21                                     16:37:17
124 processes: 123 sleeping, 1 on cpu
CPU states: 50.0% idle,  0.0% user, 50.0% kernel,  0.0% iowait,  0.0% swap
Memory: 2048M real, 908M free, 768M swap in use, 1727M swap free

vmstat gives similar numbers. The system is so busy because we're deliberately
overloading that server in an attempt to reproduce the problem.

One other thing that's worth mentioning is another server that has the same
apache binary and mostly the same modules loaded has had no errors - but that
does not have a NFS docroot (it serves purely dynamic requests).

Cheers

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

---------------------------------------------------------------------
To unsubscribe, e-mail: bugs-unsubscribe@httpd.apache.org
For additional commands, e-mail: bugs-help@httpd.apache.org