Return-Path: Delivered-To: apmail-new-httpd-archive@apache.org Received: (qmail 70448 invoked by uid 500); 4 Apr 2001 15:21:18 -0000 Mailing-List: contact new-httpd-help@apache.org; run by ezmlm Precedence: bulk Reply-To: new-httpd@apache.org list-help: list-unsubscribe: list-post: Delivered-To: mailing list new-httpd@apache.org Received: (qmail 70433 invoked from network); 4 Apr 2001 15:21:17 -0000 Sender: gregames@basto.stsn.com Message-ID: <3ACB3B39.81BF1D93@remulak.net> Date: Wed, 04 Apr 2001 11:18:17 -0400 From: Greg Ames X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.2.17-21mdk i686) X-Accept-Language: en MIME-Version: 1.0 To: new-httpd@apache.org Subject: core dump on daedalus Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Rating: h31.sny.collab.net 1.6.2 0/1000/N We had a seg fault last night with our new tarball on apache.org . We've seen this one before: #0 0x806724c in check_hostalias (r=0x820a03c) at vhost.c:891 891 if (sar->host_port != 0 && port != sar->host_port) { Last time I dug thru one of these, I concluded that the vhost data structures were stomped on by an earlier request, and hoped this symptom would go away if we fixed the other bugs. Unfortunately, it looks like it's time for Plan B, which is write an assert() trap that verifies that the vhost structures are still good at the tail end of request processing. Then we will know which request did the dastardly deed, and hopefully be able to recreate it by replaying the input buffers. If you want to know more gory details, the core dump is in /usr/local/apache2b/corefiles/httpd.core.1 Greg