> From: Brian Pane [mailto:[EMAIL PROTECTED] > 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
