Sander Striker wrote:
From: Brian Pane [mailto:[EMAIL PROTECTED]
Sent: 11 December 2001 18:21
Sander Striker wrote:
From: Brian Pane [ mailto:[EMAIL PROTECTED]
Sent: 10 December 2001 22:36
Sander Striker wrote:
Hi,
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?)
--Brian
