On Wed, Feb 17, 2010 at 12:17 PM, harish kulkarni <[email protected]> wrote: > if you are seeing leaks while using apr memory allocation, it's better to > use apache pool debug > i am just pasting some portion of the debug logs which i used to debug > issue, this might help you. > In the following "request" means that you are allocated memory from request > processing for given connection. > "proxy_conn_pool" means allocation happened from proxy connection pool. > I have found this is best approach to find leaks or allocation procedure of > apache.
> POOL DEBUG: [14983/3058834320] PALLOC ( 4463/ 4463/ 143668) > 0x80ffee0 "request" <strings/apr_strings.c:149> (67/67/0) > POOL DEBUG: [14983/3058834320] PALLOC ( 81/ 81/ 143685) > 0x814c038 "proxy_conn_pool" <strings/apr_strings.c:78> (2/7/1) > POOL DEBUG: [14983/3058834320] PCALLOC ( 249/ 249/ 143853) Thanks; I had largely forgotten about the nature of these logs. That makes it trivial to see when objects are allocated from the wrong pool, or find when some structure which has been unexpectedly reused/overlaid was originally allocated (and from which pool). I can't say for sure without being in a specific debug situation, but I'd probably start with finding what was calling brk() then if pool use seemed to be involved (vs. direct calls to the heap or apr allocator) and/or I got stuck and/or needed this kind of picture of pool use I'd rebuild/retest with pool debug and have a look at the log. (And that requires being able to reproduce it myself on my own binaries.)
