apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sander Striker" <stri...@apache.org>
Subject RE: Pools rewrite [4]
Date Wed, 12 Dec 2001 23:03:33 GMT
> From: Brian Pane [mailto:brian.pane@cnet.com]
> Sent: 12 December 2001 20:18

[...]
>> 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

Nice.  Usefull feature.

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

Yes, I agree with that.

>   2. The "extreme" version that does a malloc for each apr_palloc.
>      This is the version for use with Purify, Electric Fence, et al.

+1

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

I would also like to have a lifetime tracker.  If one uses a pool
that doesn't exist anymore, it should tell where/when it was
destroyed.  While this is certainly implementable, it is no
priority item, that's for sure.

Sander


Mime
View raw message