apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sander Striker" <stri...@apache.org>
Subject RE: [PACTH] debug ideas for memory allocation
Date Wed, 02 Jul 2003 23:06:23 GMT
> From: ranier [mailto:ranier@cultura.com.br]
> 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)

+    /* 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


View raw message