the place in the code where the particular function was called
#define APR_POOL_DEBUG 0
Pool debug levels
| 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 |
---------------------------------
| | | | | | | | x | General debug code enabled (useful in
combination with --with-efence).
| | | | | | | x | | Verbose output on stderr (report
CREATE, CLEAR, DESTROY).
| | | | x | | | | | Verbose output on stderr (report
PALLOC, PCALLOC).
| | | | | | x | | | Lifetime checking. On each use of a
pool, check its lifetime. If the pool
is out of scope, abort().
In combination with the verbose flag
above, it will output LIFE in such an
event prior to aborting.
| | | | | x | | | | Pool owner checking. On each use of a
pool, check if the current thread is the
pools owner. If not, abort(). In
combination with the verbose flag above,
it will output OWNER in such an event
prior to aborting. Use the debug
function apr_pool_owner_set() to switch
a pools ownership.
When no debug level was specified, assume general debug mode.
If level 0 was specified, debugging is switched off
Set the function to be called when an allocation failure occurs.
Remarks:
If the program wants APR to exit on a memory allocation error, then this function can be called to set the callback to use (for performing cleanup and then exiting). If this function is not called, then APR will return an error and expect the calling program to deal with the error accordingly.
Where the function is called from. This is usually APR_POOL__FILE_LINE__.
Remarks:
Only available when APR_POOL_DEBUG is defined. Call this directly if you have you apr_pool_clear calls in a wrapper function and wish to override the file_line argument to reflect the caller of your wrapper function. If you do not have apr_pool_clear in a wrapper, trust the macro and don't call apr_pool_destroy_clear directly.
The parent pool. If this is NULL, the new pool is a root pool. If it is non-NULL, the new pool will inherit all of its parent pool's attributes, except the apr_pool_t will be a sub-pool.
Remarks:
This function is thread-safe, in the sense that multiple threads can safely create subpools of the same parent pool concurrently. Similarly, a subpool can be created by one thread at the same time that another thread accesses the parent pool.
The parent pool. If this is NULL, the new pool is a root pool. If it is non-NULL, the new pool will inherit all of its parent pool's attributes, except the apr_pool_t will be a sub-pool.
abort_fn
A function to use if the pool cannot allocate more memory.
allocator
The allocator to use with the new pool. If NULL the allocator of the parent pool will be used.
Remarks:
This function is thread-safe, in the sense that multiple threads can safely create subpools of the same parent pool concurrently. Similarly, a subpool can be created by one thread at the same time that another thread accesses the parent pool.
Where the function is called from. This is usually APR_POOL__FILE_LINE__.
Remarks:
Only available when APR_POOL_DEBUG is defined. Call this directly if you have you apr_pool_create_ex calls in a wrapper function and wish to override the file_line argument to reflect the caller of your wrapper function. If you do not have apr_pool_create_ex in a wrapper, trust the macro and don't call apr_pool_create_ex_debug directly.
A function to use if the pool cannot allocate more memory.
allocator
The allocator to use with the new pool. If NULL a new allocator will be crated with newpool as owner.
Remarks:
An unmanaged pool is a special pool without a parent; it will NOT be destroyed upon apr_terminate. It must be explicitly destroyed by calling apr_pool_destroy, to prevent memory leaks. Use of this function is discouraged, think twice about whether you really really need it.
Where the function is called from. This is usually APR_POOL__FILE_LINE__.
Remarks:
Only available when APR_POOL_DEBUG is defined. Call this directly if you have you apr_pool_create_unmanaged_ex calls in a wrapper function and wish to override the file_line argument to reflect the caller of your wrapper function. If you do not have apr_pool_create_core_ex in a wrapper, trust the macro and don't call apr_pool_create_core_ex_debug directly.
Where the function is called from. This is usually APR_POOL__FILE_LINE__.
Remarks:
Only available when APR_POOL_DEBUG is defined. Call this directly if you have you apr_pool_destroy calls in a wrapper function and wish to override the file_line argument to reflect the caller of your wrapper function. If you do not have apr_pool_destroy in a wrapper, trust the macro and don't call apr_pool_destroy_debug directly.
True if a is an ancestor of b, NULL is considered an ancestor of all pools.
Remarks:
if compiled with APR_POOL_DEBUG, this function will also return true if A is a pool which has been guaranteed by the caller (using apr_pool_join) to have a lifetime at least as long as some ancestor of pool B.
The cleanup program to use to cleanup the data (NULL if none)
pool
The current pool
Warning:
The data to be attached to the pool should have a life span at least as long as the pool it is being attached to.
Users of APR must take EXTREME care when choosing a key to use for their data. It is possible to accidentally overwrite data by choosing a key that another part of the program is using. Therefore it is advised that steps are taken to ensure that unique keys are used for all of the userdata objects in a particular pool (the same key in two different pools or a pool and one of its subpools is okay) at all times. Careful namespace prefixing of key names is a typical way to help ensure this uniqueness.
The cleanup program to use to cleanup the data (NULL if none)
pool
The current pool
Note:
same as apr_pool_userdata_set(), except that this version doesn't make a copy of the key (this function is useful, for example, when the key is a string literal)
Warning:
This should NOT be used if the key could change addresses by any means between the apr_pool_userdata_setn() call and a subsequent apr_pool_userdata_get() on that key, such as if a static string is used as a userdata key in a DSO and the DSO could be unloaded and reloaded between the _setn() and the _get(). You MUST use apr_pool_userdata_set() in such cases.
More generally, the key and the data to be attached to the pool should have a life span at least as long as the pool itself.