I think I might have something in this regard. In function pjsua_resolve_stun_server() in pjsua_core.c, pj_dns_srv_resolve() is called and the pjsua_var.pool is passed as an argument. Later in pj_dns_srv_resolve(), 'query_job' is allocated from this pool. AFAIK, pjsau_var's pool is destroyed only when pjsua_destory() is called. So wouldn't this cause memory leak? In our case, we left our client (which uses pjsip) running overnight (for about 12-15hrs) and noticed that memory usage had jumped from about 12K at start to about 54K at the end of the run. We did have network outages too during this run. FYI, we use PJSIP at rev 1538 but I checked the latest rev at 1901 and atleast the code is the same in both. Regards, Anshuman ----- Original Message ----- From: Taylor Boyko To: pjsip list Sent: Monday, March 31, 2008 4:23 AM Subject: Re: Memory Leak problem with Pool I checked the name value, and it is in fact "pept003A9078". This leads me to believe that we are passing the wrong pool value to pjsip_endpt_resolve() at the very beginning, since I believe the pool value we provide there ultimately is passed through methods until it arrives at the PJ_POOL_ZALLOC_T() method. The command I am using is: pjsip_endpt_resolve(endpt, endpt->pool, &dest, &result9, &cb); endpt is a static global pointer that we reuse throughout the program. Before running the above line during an incoming call, we run the following: endpt = pjsua_get_pjsip_endpt(); Are we passing the incorrect pool? If so, how are we supposed to be creating this pool and/or passing it? Thank you! On Mar 30, 2008, at 3:32 PM, Benny Prijono wrote: 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 _______________________________________________ Visit our blog: http://blog.pjsip.org pjsip mailing list pjsip at lists.pjsip.org http://lists.pjsip.org/mailman/listinfo/pjsip_lists.pjsip.org _______________________________________________ Visit our blog: http://blog.pjsip.org pjsip mailing list pjsip at lists.pjsip.org http://lists.pjsip.org/mailman/listinfo/pjsip_lists.pjsip.org No virus found in this incoming message. Checked by AVG. Version: 7.5.519 / Virus Database: 269.22.1/1350 - Release Date: 3/30/2008 12:32 PM
