You are viewing a plain text version of this content. The canonical link for it is here.
Posted to cvs@httpd.apache.org by dr...@locus.apache.org on 2000/06/18 12:58:22 UTC
cvs commit: apache-2.0/src/lib/apr/lib apr_pools.c
dreid 00/06/18 03:58:21
Modified: src/lib/apr/include apr_general.h
src/lib/apr/lib apr_pools.c
Log:
Tidy up the debugging documentation.
Revision Changes Path
1.36 +1 -1 apache-2.0/src/lib/apr/include/apr_general.h
Index: apr_general.h
===================================================================
RCS file: /home/cvs/apache-2.0/src/lib/apr/include/apr_general.h,v
retrieving revision 1.35
retrieving revision 1.36
diff -u -r1.35 -r1.36
--- apr_general.h 2000/06/17 11:51:36 1.35
+++ apr_general.h 2000/06/18 10:58:19 1.36
@@ -249,7 +249,7 @@
/* Memory allocation/Pool debugging options...
*
- * Look in ap_pools.c for definitions of what these mean/do
+ * Look in the developer documentation for details of what these do.
*
* NB These should ALL normally be commented out unless you REALLY
* need them!!
1.58 +3 -58 apache-2.0/src/lib/apr/lib/apr_pools.c
Index: apr_pools.c
===================================================================
RCS file: /home/cvs/apache-2.0/src/lib/apr/lib/apr_pools.c,v
retrieving revision 1.57
retrieving revision 1.58
diff -u -r1.57 -r1.58
--- apr_pools.c 2000/06/17 11:51:37 1.57
+++ apr_pools.c 2000/06/18 10:58:21 1.58
@@ -97,64 +97,9 @@
#include <malloc.h>
#endif
-/*
- * Debugging support: Define this to enable code which helps detect re-use
- * of freed memory and other such nonsense.
- *
- * The theory is simple. The FILL_BYTE (0xa5) is written over all malloc'd
- * memory as we receive it, and is written over everything that we free up
- * during a clear_pool. We check that blocks on the free list always
- * have the FILL_BYTE in them, and we check during palloc() that the bytes
- * still have FILL_BYTE in them. If you ever see garbage URLs or whatnot
- * containing lots of 0xa5s then you know something used data that's been
- * freed or uninitialized.
- */
-/* #define ALLOC_DEBUG */
-
-/*
- * Debugging support: If defined all allocations will be done with
- * malloc and free()d appropriately at the end. This is intended to be
- * used with something like Electric Fence or Purify to help detect
- * memory problems. Note that if you're using efence then you should also
- * add in ALLOC_DEBUG. But don't add in ALLOC_DEBUG if you're using Purify
- * because ALLOC_DEBUG would hide all the uninitialized read errors that
- * Purify can diagnose.
- */
-/* #define ALLOC_USE_MALLOC */
-
-/*
- * Pool debugging support: This is intended to detect cases where the
- * wrong pool is used when assigning data to an object in another pool.
- * In particular, it causes the table_{set,add,merge}n routines to check
- * that their arguments are safe for the ap_table_t they're being placed in.
- * It currently only works with the unix multiprocess model, but could
- * be extended to others.
- */
-/* #define POOL_DEBUG */
-
-/*
- * Provide diagnostic information about make_table() calls which are
- * possibly too small. This requires a recent gcc which supports
- * __builtin_return_address(). The error_log output will be a
- * message such as:
- * table_push: ap_table_t created by 0x804d874 hit limit of 10
- * Use "l *0x804d874" to find the source that corresponds to. It
- * indicates that a ap_table_t allocated by a call at that address has
- * possibly too small an initial ap_table_t size guess.
- */
-/* #define MAKE_TABLE_PROFILE */
-
-/*
- * Provide some statistics on the cost of allocations. It requires a
- * bit of an understanding of how alloc.c works.
- */
-/* #define ALLOC_STATS */
-
-
-/* used to guarantee to the ap_pool_t debugging code that the sub ap_pool_t will not be
- * destroyed before the parent pool
- */
-
+/* Details of the debugging options can now be found in the developer
+ * section of the documentaion. */
+
#ifdef POOL_DEBUG
/* first do some option checking... */
#ifdef ALLOC_USE_MALLOC