Re: check_hostalias/server_addr_rec segfault (segfault type #4)

[Greg Ames <gr...@remulak.net>]

Cliff Woolley wrote:
> 
> httpd.core.7 is another new kind of segfault, caused by a null server_addr_rec
> pointer:
> 

/usr/local/apache2/corefiles/httpd.core.16 is more of the same:

(gdb) frame 0
#0  check_hostalias (r=0x81ca03c) at vhost.c:891
891             if (sar->host_port != 0 && port != sar->host_port) {
(gdb) list 888
883
884         for (src = r->connection->vhost_lookup_data; src; src =
src->next) {
885             server_addr_rec *sar;
886
887             /* We only consider addresses on the name_chain which
have a matching
888              * port
889              */
890             sar = src->sar;
891             if (sar->host_port != 0 && port != sar->host_port) {
892                 continue;
(gdb) p (name_chain)r->connection->vhost_lookup_data
$1 = {next = 0x8163f14, sar = 0x813003c, server = 0x813005c}
(gdb) p *((name_chain)r->connection->vhost_lookup_data).sar
$2 = {next = 0x813000c, host_addr = 0xb, host_port = 92,
  virthost = 0x813009c "\f"}
(gdb) p *src
$3 = {next = 0x80b107c, sar = 0x0, server = 0x80b5d54}
(gdb) p src
$4 = (name_chain *) 0x810f064 

Looks like the very first sar on the chain is already bogus.  The r
looks fine, and so does r->headers_in.  I suspect the vhost chain got
clobbered by a previous request, and this request is an innocent
victim.  

Since this seg fault is infrequent and there is some evidence of
overlaid memory in the more frequent assert dumps, Plan A is to ignore
this symptom and hope it goes away once we fix the more frequent
errors.  Plan B is to stick some debug code in the tail end of request
processing which verifies that the vhost lookup structures are still
intact before going on to the next requst.

Greg