Received: (from majordom@localhost)
	by hyperreal.org (8.8.5/8.8.5) id XAA00204;
	Fri, 12 Sep 1997 23:40:23 -0700 (PDT)
Received: (from gnats@localhost)
	by hyperreal.org (8.8.5/8.8.5) id XAA29954;
	Fri, 12 Sep 1997 23:40:02 -0700 (PDT)
Date: Fri, 12 Sep 1997 23:40:02 -0700 (PDT)
Message-Id: <199709130640.XAA29954@hyperreal.org>
To: apache-bugdb@apache.org
Cc: apache-bugdb@apache.org
From: Marc Slemko <marcs@znep.com>
Subject: Re: general/1073: http core dumps with SIGSEGV
Reply-To: Marc Slemko <marcs@znep.com>
Sender: apache-bugdb-owner@apache.org
Precedence: bulk

The following reply was made to PR general/1073; it has been noted by GNATS.

From: Marc Slemko <marcs@znep.com>
To: dgaudet@hyperreal.org
Subject: Re: general/1073: http core dumps with SIGSEGV
Date: Sat, 13 Sep 1997 00:32:26 -0600 (MDT)

 
 This is a dupe of PR#1064.  The problem is that he is running in inetd
 mode.  There is another PR around from someone else that describes the
 problem.  ISTR that in inetd mode current_conn is NULL but the longjmp is
 bogus since it was never set.
 
 On Fri, 12 Sep 1997 dgaudet@hyperreal.org wrote:
 
 > Synopsis: http core dumps with SIGSEGV
 > 
 > State-Changed-From-To: open-analyzed
 > State-Changed-By: dgaudet
 > State-Changed-When: Fri Sep 12 23:24:19 PDT 1997
 > State-Changed-Why:
 > This is really odd ... if you look at timeout() a little further
 > down you'll see that it tests current_conn != NULL and if it's
 > NULL then it siglongjmps (hidden in the ap_longjmp macro) back to
 > the main loop where it starts cleanup.  It shouldn't get to
 > the get_remote_host() call in that case.
 > 
 > Does this occur frequently for you?
 > 
 > Dean
 >