On Fri, 16 Nov 2001, Greg Stein wrote:
> > around the reference count. The lock API requires that we create the
> > lock from a pool, but there isn't a really suitable pool from which
> > to allocate the lock, given that its lifetime isn't necessarily tied
> > to that of a request or connection.
>
> The "suitable pool" is that of the apr_mmap_t itself. Note that the file
> cache would be putting that lock into its own long-lived pool.
>
> Not so hard, or I'm missing something :-)
You're missing something. :-)
Let's say you have a pool hierarchy like this:
a
/ \
b c
/
d
You have an apr_mmap_t allocated out of c. You request to dup the mmap
into b. Will b live longer than c? No way to know. Will c live longer
than b? No way to know. So if you've allocated your refcount or the lock
on that refcount out of c, and c goes away before b does, then b has a
reference to no-longer-existing memory.
This is not an odd situation: it's almost exactly what's happening in
mod_file_cache right now. c is the cmd->pool. b is the c->pool. d is
the r->pool. (There might be some pools between a and b for the diagram
to be exactly right, but the hierarchy is essentially correct I believe.)
Granted, in that particular example, c lives much, much longer than b, but
in general that's not at all guaranteed to be the case.
--Cliff
--------------------------------------------------------------
Cliff Woolley
[EMAIL PROTECTED]
Charlottesville, VA
