On Sun, Mar 30, 2008 at 11:06 PM, Taylor Boyko <taylor.boyko at pacificswell.com> wrote: > Ok, so I double checked and found the following in my program: > > 1) in the command "query_job = PJ_POOL_ZALLOC_T(pool, > pj_dns_srv_resolver_job);", pool has a memory address of 0x003a9078 . > I can also drill down and look at its factory.capacity key value and > see how large it is. I place five calls or so, and each time that > this line is executed, pool's factory.capacity key increases by 4000. > > 2) The reason I believe that this pool is the "pept" one is that I run > a pj_pool_factory_dump(endpt->pf, TRUE) at one point (as Benny > suggested), and I get an output of all of the caching pools. There is > an entry like so: > > "cachpool pept03A9078 611920 of 620096 (98%) used" > > The 620096 corresponds to the factory.capacity value I was looking at > before, as well as the more obvious tie between the full name of the > "pept" pool and the memory location I was seeing it at above. The best way to identify pool is probably is to check for it's object name (pool->obj_name). This should rather uniquely identify the pool and you will know for sure which one it Here the pool that is used in ""query_job = PJ_POOL_ZALLOC_T(pool, pj_dns_srv_resolver_job);" line above points to a transmit data pool (txdata->pool), not endpoint's pool. > Perhaps the wrong pool is being used in the PJ_POOL_ZALLOC_T() > method? I'm not sure how this would have gotten confused though. I really don't see endpoint's pool being used to allocate DNS query record here, so I'm totally confused. > Ideas? > Probably you can try the same setting with pjsua (the latest from SVN) and see if it has the same problem. Cheers Benny
