apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Brian Pane <brian.p...@cnet.com>
Subject Re: Pools rewrite [4]
Date Wed, 12 Dec 2001 19:17:46 GMT
Sander Striker wrote:

>>From: Brian Pane [mailto:bpane@pacbell.net]
>>Sent: 11 December 2001 18:21
>>Sander Striker wrote:
>>>>From: Brian Pane [ mailto:bpane@pacbell.net]
>>>>Sent: 10 December 2001 22:36
>>>>Sander Striker wrote:
>>>>>This is the code with the latest changes based on comments
>>>>>from various people.
>>>>>I have yet to begin to start coding/migrating the debug
>>>>>code.  I won't have time to complete that until at least
>>>>>next week.  Bill (wrowe) can you live without that for
>>>>>a little while?  I specifically ask because you have
>>>>>recently added a bunch of debug code to pools.
>>>>I can try to add in the debug code this week. 
>>>Could we sync thoughts on how to do it?
>>>I would very much like to split out the common code between
>>>debug and production into a seperate file, and have both the
>>>debug specific and the production only code in another.
>>>This hopefully keeps the production code clean and readable.
>>Good point, and now that I've had a chance to study
>>the debug code some more, I think it will take some
>>more planning to add it into the new pools code.  The
>>problem is that a lot of the debug code for joining
>>pools is dependent on having a single free list.  Do
>>you have a design in mind for making the debug code
>>work with the new allocator system?
>I had the idea to not use the allocator system or any of the
>production pools code while debugging.  The debug code
>will just use malloc/free instead.  In debug mode speed
>isn't important anyway :)
>Hmm, we could opt for two versions: let node_malloc
>and node_free just do malloc and free, and let apr_palloc
>and apr_pool_clear/apr_pool_destroy use malloc/free.
>I do realise that this will leave the regular pools code
>untouched while debugging, which is the downside to doing
>it that way.
>What are your thoughts on the matter?

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:
       - When doing an apr_palloc, check the guard bands of
         the last few pieces of memory apr_palloc'ed from that
         block, and throw an exception (so to speak) if any
         of them have been overwritten.  (This requires that
         we store some metadata in the guard band to identify
         the location of the previous allocation within the block.)
       - When clearing a pool, cycle through all the allocations
         within each block
     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).

  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?)


View raw message