Just saw that pjsua_resolve_stun_server() is called only once in the beginning. ----- Original Message ----- From: "Anshuman S. Rawat" <arawat@xxxxxxxxxxx> To: "pjsip list" <pjsip at lists.pjsip.org> Cc: "Sirish Bajpai" <sbajpai at 3clogic.com> Sent: Monday, March 31, 2008 1:09 PM Subject: Re: Memory Leak problem with Pool >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 > > > _______________________________________________ > 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 >
