apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Greg Stein <gst...@lyra.org>
Subject Re: Pools rewrite [4]
Date Thu, 13 Dec 2001 07:39:57 GMT
On Wed, Dec 12, 2001 at 11:17:46AM -0800, Brian Pane wrote:
> IMHO, it makes sense to have a couple of different versions
> of debug functionality, like you've suggested.  Here are the
> two versions that I think might be useful:
>   1. Based on the production code, except that the each
>      apr_palloc'ed block of memory has guard bands before
>      and after it that are filled with 0x5a (or some other
>      pattern).  The pool code can check for overwrites during
>      standard pool operations:

Not needed.

The guards are for testing overwrites and underwrites. You do not need to
use the production pool code for seeking out those bugs.

>      Note: If possible, I think it's good for this type of debug
>      code to be based on the production code (asuming we can
>      implement it cleanly.  My rationale is that, if it's similar
>      in implementation to the production code, it can be used to
>      debug corruption problems that involve race conditions (because
>      the timing and object-adjacency properties of the debug code
>      will be similar to the production code).

I don't follow what kinds of problems you're describing here.

>   2. The "extreme" version that does a malloc for each apr_palloc.
>      This is the version for use with Purify, Electric Fence, et al.
>      (Note: I'm of the opinion that we shouldn't put memprotect
>      support into the pools code itself, because by doing so we're
>      just duplicating the work of 3rd-party memory debuggers.  Does
>      anybody have an alternate perspective on this issue?)

I think that all debug versions would be doing this. The debug version would
also want to do lifetime tracking so it would know to free() all the items
that were malloc'd "by a pool".

The main point is that the debug pool code is for finding problems in the
*application*. We classify those types of problems and build the debug code
to locate them. Even easier, we just defer to standard malloc/free and plug
in trackers like Electric Fence.


Greg Stein, http://www.lyra.org/

View raw message