![[APACHE DOCUMENTATION]](../images/sub.gif)
The allocation mechanism's within APR have a number of debugging modes that can be used to assist in finding memory problems. This document describes the modes available and gives instructions on activating them.
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.
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.
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 apr_table_t they're being placed in. It currently only works with the unix multiprocess model, but could be extended to others.
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: apr_table_t created by 0x804d874 hit limit of 10
Use "l *0x804d874" to find the source that corresponds to. It indicates that a apr_table_t allocated by a call at that address has possibly too small an initial apr_table_t size guess.
Provide some statistics on the cost of allocations.
This requires a bit of an understanding of how allocHTTP/1.1 200 OK Date: Mon, 07 Jul 2025 09:21:55 GMT Server: Apache/2.0.42 (Win32) PHP/5.2.10 Accept-Ranges: bytes Content-Length: 7531 Keep-Alive: timeout=15, max=100 Connection: Keep-Alive Content-Type: text/html; charset=ISO-8859-1
The allocation mechanism's within APR have a number of debugging modes that can be used to assist in finding memory problems. This document describes the modes available and gives instructions on activating them.
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.
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.
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 apr_table_t they're being placed in. It currently only works with the unix multiprocess model, but could be extended to others.
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: apr_table_t created by 0x804d874 hit limit of 10
Use "l *0x804d874" to find the source that corresponds to. It indicates that a apr_table_t allocated by a call at that address has possibly too sma