Return-Path: 
 <apreq-dev-return-1501-apmail-httpd-apreq-dev-archive=httpd.apache.org@httpd.apache.org>
Delivered-To: apmail-httpd-apreq-dev-archive@www.apache.org
Received: (qmail 79204 invoked from network); 13 Nov 2003 04:27:28 -0000
Received: from daedalus.apache.org (HELO mail.apache.org) (208.185.179.12)
  by minotaur-2.apache.org with SMTP; 13 Nov 2003 04:27:28 -0000
Received: (qmail 24258 invoked by uid 500); 13 Nov 2003 04:27:09 -0000
Delivered-To: apmail-httpd-apreq-dev-archive@httpd.apache.org
Received: (qmail 24179 invoked by uid 500); 13 Nov 2003 04:27:08 -0000
Mailing-List: contact apreq-dev-help@httpd.apache.org; run by ezmlm
Precedence: bulk
List-Post: <mailto:apreq-dev@httpd.apache.org>
List-Help: <mailto:apreq-dev-help@httpd.apache.org>
List-Unsubscribe: <mailto:apreq-dev-unsubscribe@httpd.apache.org>
List-Subscribe: <mailto:apreq-dev-subscribe@httpd.apache.org>
Delivered-To: mailing list apreq-dev@httpd.apache.org
Received: (qmail 24166 invoked from network); 13 Nov 2003 04:27:08 -0000
Received: from unknown (HELO main.gmane.org) (80.91.224.249)
  by daedalus.apache.org with SMTP; 13 Nov 2003 04:27:08 -0000
Received: from list by main.gmane.org with local (Exim 3.35 #1 (Debian))
	id 1AK94f-0001zC-00
	for <apreq-dev@httpd.apache.org>; Thu, 13 Nov 2003 05:27:17 +0100
Mail-Followup-To: apreq-dev@httpd.apache.org
X-Injected-Via-Gmane: http://gmane.org/
To: apreq-dev@httpd.apache.org
Received: from sea.gmane.org ([80.91.224.252])
	by main.gmane.org with esmtp (Exim 3.35 #1 (Debian))
	id 1AK94d-0001z4-00
	for <gmane-comp-apache-apreq@m.gmane.org>; Thu, 13 Nov 2003 05:27:15 +0100
Received: from news by sea.gmane.org with local (Exim 3.35 #1 (Debian))
	id 1AK94d-0004Vk-00
	for <gmane-comp-apache-apreq@m.gmane.org>; Thu, 13 Nov 2003 05:27:15 +0100
From: Joe Schaefer <joe+gmane@sunstarsys.com>
Subject: Re: [MP1] Apache segfault after serving request
Date: 12 Nov 2003 23:27:09 -0500
Lines: 34
Message-ID: <m38ymk99lu.fsf@sol.sunstarsys.com>
References: <1068492137.24138.34.camel@ooghij> <3FAFEEE4.5030807@stason.org>
 <1068497656.24138.41.camel@ooghij> <3FB0139F.7050003@stason.org>
 <1068565301.7738.16.camel@ooghij> <3FB2D76C.4020708@stason.org>
 <3FB2E614.1030100@stason.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Complaints-To: usenet@sea.gmane.org
Mail-Copies-To: never
User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2
Sender: news <news@sea.gmane.org>
Cc: modperl@perl.apache.org
X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N
X-Spam-Rating: minotaur-2.apache.org 1.6.2 0/1000/N

Stas Bekman <stas@stason.org> writes:

[...]

> It seems that your global $GlobalS var contains a reference to an
> Apache::Request table, but A-R object is not global, so when the scope
> of the handler is exited A-R object gets destroyed, leaving $GlobalS
> containting a pointer to a black hole. That black hole is req->parms
> in Request.xs in libapreq.

<yack>
Yup- the request pool's cleanup hook has already come through and
reclaimed all those C data structures.  Unfortunately the perl glue
isn't aware that this happened.  

I think the basic assumption is that the request pool's lifetime must
be longer than any perl scalar glued to a per-request struct.  Of
course, that assumption doesn't appear to be valid in this situation 
(a global Apache::Table object is alive, but the associated C table was
freed). Not sure what to do about it right now.
</yack>

[...]

> Joe, any ideas on this one? (we are talking about libapreq1/mp1) May
> be we should just assume that it's OK that the A-R table was already
> freed?  Does this patch introduce a leak?

I don't know- I'll try to think about it more carefully before the week
is over.

Thanks, Stas.
-- 
Joe Schaefer