Return-Path: Delivered-To: apmail-httpd-dev-archive@httpd.apache.org Received: (qmail 10547 invoked by uid 500); 21 Oct 2001 13:59:34 -0000 Mailing-List: contact dev-help@httpd.apache.org; run by ezmlm Precedence: bulk Reply-To: dev@httpd.apache.org list-help: list-unsubscribe: list-post: Delivered-To: mailing list dev@httpd.apache.org Received: (qmail 10528 invoked from network); 21 Oct 2001 13:59:29 -0000 Message-ID: <3BD2C7B1.9060200@cisco.com> Date: Sun, 21 Oct 2001 07:03:45 -0600 From: Sunitha Kumar Organization: Cisco Systems User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:0.9.1) Gecko/20010607 Netscape6/6.1b1 X-Accept-Language: en-us MIME-Version: 1.0 To: Greg Stein CC: dev@httpd.apache.org Subject: Re: Leaks in 2.0.16 beta References: <3BD074B4.EC627F88@cisco.com> <20011019193328.F4216@lyra.org> Content-Type: multipart/alternative; boundary="------------040705020402040200010509" X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N --------------040705020402040200010509 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Greg, Thanks much for your response. I looked through the Changes file for 2.0.16 beta, and there are no dates there, apart from older release dates. Are there other pointers? Also, where can I find the archives of commits? thanks, sunitha Greg Stein wrote: >We don't make the individual fixes available. Our only real mechanism for >distributing changes is to say, "get an updated version." Otherwise, you can >crawl through the CVS repository to find the related changes. I'd recommend >looking at when the CHANGES file was modified each time; you should be able >to find the related commits near those dates. > >I'm not sure offhand, but I believe we make available archives of the commit >mailing list. That would probably be even easier to scan through to find the >actual changes/commits. > >Cheers, >-g > >On Fri, Oct 19, 2001 at 11:45:08AM -0700, Sunitha Kumar wrote: > >>Folks, >>I saw these were fixed in 2.0.18 ( in the Changes file), How can I get >>these fixes, individually. >>thanks, >> >>Fixed potential FILE* leak in http_main.c [Ben Laurie] >> >>Don't leak the DIR * on HEAD request for a directory. [Robert Thau] >> >>Create Files, and thus MMAPs, out of the request pool, not the >> connection pool. This solves a small resource leak that had us >> not closing files until a connection was closed. In order to do >> this, at the end of the core_output_filter, we loop through the >> brigade and convert any data we have into a single HEAP bucket >> that we know will survive clearing the request_rec. >> [Ryan Bloom, Justin Erenkrantz , >> Cliff Woolley] >> >>-- >>Sunitha Kumar >>http://www.cisco.com >> > --------------040705020402040200010509 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Greg,
Thanks much for your response.
I looked through the Changes file for 2.0.16 beta, and there are no dates there, apart from older release dates. Are there other pointers?
Also, where can I find the archives of commits?

thanks,
sunitha

Greg Stein wrote:

We don't make the individual fixes available. Our only real mechanism for
distributing changes is to say, "get an updated version." Otherwise, you can
crawl through the CVS repository to find the related changes. I'd recommend
looking at when the CHANGES file was modified each time; you should be able
to find the related commits near those dates.

I'm not sure offhand, but I believe we make available archives of the commit
mailing list. That would probably be even easier to scan through to find the
actual changes/commits.

Cheers,
-g

On Fri, Oct 19, 2001 at 11:45:08AM -0700, Sunitha Kumar wrote:

Folks,
I saw these were fixed in 2.0.18 ( in the Changes file), How can I get
these fixes, individually.
thanks,

Fixed potential FILE* leak in http_main.c [Ben Laurie]

Don't leak the DIR * on HEAD request for a directory. [Robert Thau]

Create Files, and thus MMAPs, out of the request pool, not the
     connection pool.  This solves a small resource leak that had us
     not closing files until a connection was closed.  In order to do
     this, at the end of the core_output_filter, we loop through the
     brigade and convert any data we have into a single HEAP bucket
     that we know will survive clearing the request_rec.
     [Ryan Bloom, Justin Erenkrantz <jerenkrantz@ebuilt.com>,
      Cliff Woolley]

--
Sunitha Kumar
http://www.ci!
sco.com

--------------040705020402040200010509--