httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From <>
Subject Re: file/mmap buckets, subrequests, pools, 2.0.18
Date Fri, 01 Jun 2001 18:00:08 GMT
On Fri, 1 Jun 2001, Jeff Trawick wrote:

> Greg Ames put together a 2.0.18 build for the purposes of running on
> but we were never able to switch over to it from 2.0.16
> because of a hard failure with certain types of requests.
> The problem, trying to simplify a bit:
> In a subrequest, default_handler opens a file using the pool
> associated with the subrequest and creates a file bucket.
> After the subrequest is over, we still have the file bucket with the
> apr_file_t that had the now-destroyed pool.  Any references to the
> apr_file_t are broken because the pool was destroyed.
> We finally died back in the main request processing because we
> referenced an mmap bucket whose apr_mmap_t used the same pool as the
> apr_file_t.  The apr_mmap_t had been overlaid because the storage was
> released at the end of the main request and subsequently reused for
> some other purpose.
> We have never hit this problem with 2.0.16 and we always hit this
> problem with 2.0.18, leading me to believe that the problem was
> affected by recent code changes, even though it seems to be a basic
> design issue.
> Any ideas about what recent changes might have introduced or exposed
> this problem?

This is realitively simple.  A while ago, I changed the default handler to
use the connection pool to fix this problem.  A couple of months ago, Dean
pointed out that this was a major resource leak.  After 2.0.16, somebody
(Roy?) pointed out that this was a pretty big problem when serving a lot
of very large files on the same connection.

The solution was a simple loop at the end of the core_output_filter that
reads in the data from the file to memory.  This is okay to do, because we
are garuanteed to have less than 9k of data.  It sounds like the problem
is that we don't read in the data if we have an MMAP, or we may not be
getting into the loop on sub-requests.


Ryan Bloom               
406 29th St.
San Francisco, CA 94131

View raw message