apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Graham Leggett <minf...@sharp.fm>
Subject Re: [long] problems with brigade handling and thread safety
Date Thu, 03 Dec 2009 13:24:34 GMT
Edgar Frank wrote:

> I'm writing an Apache module which holds some number of
> persistent connections to a backend server and hands them out to
> each request (via an apr_reslist). The reslist holds sockes
> and bucket brigades with a socket bucket in it (allocated on
> the child pool).

As soon as I read this the first thing that leaped to mind was "pool

Bucket brigades are allocated from a pool, and your bucket brigade will
be cleaned up when the pool is destroyed.

There will be two pools you have to care about. The first pool belongs
to the request, and is cleaned out when the request ends. The second
pool you care about is the one that the reslist is handled from, and is
likely to live for a very long time - definitely far longer than a request.

If you accidentally refer to data allocated from the request pool, and
place it into your reslist, that data will vanish when the request ends,
and you will have dangling pointers and crashes.

If you accidentally refer to data allocated from the reslist pool, and
place it into your request, that data will vanish when the reslist is
cleaned up, and if this happens during a request, that request will crash.

What you need to ensure you do is respect the pool boundaries at all
times. If two pools have completely unrelated lifetimes (as in this
example), you need to be careful to copy data from the one pool into new
memory allocated from the other pool. Alternatively if sockets are
involved, you might dup the socket from the old pool to the new pool.

While it may be tempting to just copy the buckets over, you'll doom
yourself to all sorts of weirdness as the request dies unexpectedly,
corrupting the reslist, or the reslist is reaped unexpectedly,
corrupting the request.


View raw message