2026N/A<!
DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" 2026N/A <
title>Debugging Memory Allocation in APR</
title>
2026N/A <!-- Background white, links blue (unvisited), navy (visited), red (active) --> 2026N/A <
body bgcolor="#FFFFFF" text="#000000" link="#0000FF" 2026N/A vlink="#000080" alink="#FF0000">
2026N/A <
h1 align="center">Debugging Memory Allocation in APR<
br />
2026N/A <
p>The allocation mechanism's within APR have a number of
2026N/A debugging modes that can be used to assist in finding memory
2026N/A problems. This document describes the modes available and gives
2026N/A instructions on activating them.</
p>
2026N/A <
li><
a href="#options">Available debugging options</
a></
li>
2026N/A <
li><
a href="#combo">Allowable combinations</
a></
li>
2026N/A <
li><
a href="#howto">How to activate debugging</
a></
li>
2026N/A <
h2>Allocation Debugging</
h2>
2026N/A <
p><
em>Debugging support: Define this to enable code which
2026N/A helps detect re-use of freed memory and other such
2026N/A <
p>The theory is simple. The FILL_BYTE (0xa5) is written over
2026N/A all malloc'd memory as we receive it, and is written over
2026N/A everything that we free up during a clear_pool. We check that
2026N/A blocks on the free list always have the FILL_BYTE in them, and
2026N/A we check during palloc() that the bytes still have FILL_BYTE in
2026N/A them. If you ever see garbage URLs or whatnot containing lots
2026N/A of 0xa5s then you know something used data that's been freed or
2026N/A <
p><
em>If defined all allocations will be done with malloc and
2026N/A free()d appropriately at the end.</
em></
p>
2026N/A <
p>This is intended to be used with something like Electric
2026N/A Fence or Purify to help detect memory problems. Note that if
2026N/A you're using efence then you should also add in ALLOC_DEBUG.
2026N/A But don't add in ALLOC_DEBUG if you're using Purify because
2026N/A ALLOC_DEBUG would hide all the uninitialized read errors that
2026N/A <
p><
em>This is intended to detect cases where the wrong pool is
2026N/A used when assigning data to an object in another pool.</
em></
p>
2026N/A <
p>In particular, it causes the table_{set,add,merge}n routines
2026N/A to check that their arguments are safe for the apr_table_t
2026N/A they're being placed in. It currently only works with the unix
2026N/A multiprocess model, but could be extended to others.</
p>
2026N/A <
h3>MAKE_TABLE_PROFILE</
h3>
2026N/A <
p><
em>Provide diagnostic information about make_table() calls
2026N/A which are possibly too small.</
em></
p>
2026N/A <
p>This requires a recent gcc which supports
2026N/A __builtin_return_address(). The error_log output will be a
2026N/Atable_push: apr_table_t created by 0x804d874 hit limit of 10
2026N/A <
p>Use "<
em><
strong>l *0x804d874</
strong></
em>" to find the
2026N/A source that corresponds to. It indicates that a apr_table_t
2026N/A allocated by a call at that address has possibly too small an
2026N/A initial apr_table_t size guess.</
p>
2026N/A <
h2>Allocation Statistics</
h2>
2026N/A <
p><
em>Provide some statistics on the cost of
2026N/A <
h2>Allowable Combinations</
h2>
2026N/A <
p>Not all the options outlined above can be activated at the
2026N/A same time. the following table gives more information.</
p>
2026N/A <
th width="25%">Option 1</
th>
2026N/A <
th width="15%">ALLOC<
br />
2026N/A <
th width="15%">ALLOC<
br />
2026N/A <
th width="15%">ALLOC<
br />
2026N/A <
td bgcolor="#ff0000"> </
td>
2026N/A <
td align="center">Yes</
td>
2026N/A <
td align="center">Yes</
td>
2026N/A <
td align="center">Yes</
td>
2026N/A <
td bgcolor="#ff0000"> </
td>
2026N/A <
td align="center">Yes</
td>
2026N/A <
td bgcolor="#ff0000"> </
td>
2026N/A <
td align="center">Yes</
td>
2026N/A <
td align="center">Yes</
td>
2026N/A <
td align="center">Yes</
td>
2026N/A <
td align="center">Yes</
td>
2026N/A <
td bgcolor="#ff0000"> </
td>
2026N/A <
td align="center">Yes</
td>
2026N/A <
td align="center">Yes</
td>
2026N/A <
td align="center">Yes</
td>
2026N/A <
td align="center">Yes</
td>
2026N/A <
td bgcolor="#ff0000"> </
td>
2026N/A <
p>Additionally the debugging options are not suitable for
2026N/A multi-threaded versions of the server. When trying to debug
2026N/A with these options the server should be started in single
2026N/A <
h2>Activating Debugging Options</
h2>
2026N/A <
p>The various options for debugging memory are now enabled in
2026N/A enabled by uncommenting the define for the option you wish to
2026N/A use. The section of the code currently looks like this
2026N/A struct process_chain *subprocesses;
2026N/A struct ap_pool_t *sub_pools;
2026N/A struct ap_pool_t *sub_next;
2026N/A struct ap_pool_t *sub_prev;
2026N/A int (*apr_abort)(int retcode);
2026N/A struct datastruct *prog_data;
2026N/A <
p>To enable allocation debugging simply move the #define
2026N/A ALLOC_DEBUG above the start of the comments block and rebuild
2026N/A <
strong>NB. In order to use the various options the server MUST
2026N/A be rebuilt after editing the header file.</
strong>