httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Cliff Woolley <>
Subject Re: mod_include regression (stable release SHOWSTOPPER)
Date Sat, 16 Nov 2002 16:50:44 GMT
On 16 Nov 2002, Jeff Trawick wrote:

> I don't understand why mmap_bucket_cleanup zeros out the pointer to
> the apr_mmap_t with no regards to the refcount.  That act, or the need
> to do that, seems to be the heart of the matter.

As the comment says:

    /* the mmap has disappeared out from under us.  we have no choice
     * but to invalidate this bucket.  from now on, all you can do to this
     * bucket is destroy it, not read from it.

This was a fix for some NASTY segfaults we experienced a while back.
Basically what happens is that if we have an apr_mmap_t and a brigade
containing an MMAP bucket that points to that apr_mmap_t in the same pool
(let's say r->pool), and the brigade was created *before* the apr_mmap_t,
then the apr_mmap_t gets cleaned up first; we subsequently clean up the
brigade and destroy all the buckets in it... so when we get around to that
MMAP bucket, we think the apr_mmap_t still exists and try to call
apr_mmap_delete() on it, which segfaults.

In other words, the refcount is pointless by the time
mmap_bucket_cleanup() gets called because the mmap has already been


So my guess as to essentially what's happening is that you've got an
apr_mmap_t that is in r->pool initially and an mmap bucket that is the
"owner" bucket is in a brigade also attached to r->pool.  The owner bucket
is discarded, meaning that even though the a copy of the mmap bucket might
get setaside into, say, c->pool, the apr_mmap_t dies when the owner bucket
dies.  In this case, the owner bucket would likely be the mmap bucket
representing the beginning of the file (the first-created of the mmap

I agree that this seems broken in several ways... but I'll have to put
some thought into it to figure out how to fix it.  I'll be on a plane to
Vegas in roughly five hours, so I'll think on it then.  :-)

First, how is the server supposed to keep track of which of the n copies
of the mmap bucket is the owner and to make sure it lives at least as long
as all of the rest?  It can't.

Second, let's say the owner bucket is destroyed before the non-owner
buckets -- in mmap_bucket_destroy(), the refcount will prevent us from
killing the pool cleanup and deleting the mmap, so the apr_mmap_t will be
killed off when r->pool is cleaned up anyway.



View raw message