> From: ranier [mailto:[EMAIL PROTECTED]
> Sent: Monday, June 30, 2003 7:29 PM
> Sander Striker wrote:
>
>> Using pools debug mode in combination with tools like valgrind
>> have worked wonders. I personally don't think this will add extra
>> value.
>
> Why not use all weapons? Bugs exist and will be found, but not in
> automatic way!
> What I am considering is to add tools to find bugs in automatic way.
>
> The biggest utility in destroying the memory set free, it is not to lose
> time in finding errors in structures apparently perfect, but obviously
> garbage!
The third party tools available to detect this are so much better than
we can provide and are willing to maintain. There's electric fence,
valgrind, purify and a bunch of others all with there own strength
and level of complexity. Using the memset trick doesn't tell you
_where_ things went wrong, only that you are looking at free'd memory.
As for the asserts, you can replace all of them by adding a few lines
to apr_pool_check_integrity:
Index: srclib/apr/memory/unix/apr_pools.c
===================================================================
RCS file: /home/cvs/apr/memory/unix/apr_pools.c,v
retrieving revision 1.196
diff -u -r1.196 apr_pools.c
--- srclib/apr/memory/unix/apr_pools.c 28 May 2003 04:39:42 -0000 1.196
+++ srclib/apr/memory/unix/apr_pools.c 2 Jul 2003 23:01:10 -0000
@@ -1212,6 +1212,10 @@
if (pool == global_pool || global_pool == NULL)
return;
+ /* A NULL pool?! */
+ if (!pool)
+ abort();
+
/* Lifetime
* This basically checks to see if the pool being used is still
* a relative to the global pool. If not it was previously
Sander
