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. 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. Ideas? On Mar 30, 2008, at 8:46 AM, Benny Prijono wrote: > On Sat, Mar 29, 2008 at 1:11 AM, Taylor Boyko > <taylor.boyko at pacificswell.com> wrote: >> I already contacted Benny with this information, but figured I >> would send it >> out here as well in case anyone had any insight into the problems I'm >> finding >> >> In my previous emails, I mentioned that I am experiencing a problem >> with my >> program memory size growing each time a call is received and then >> hung up. >> In other words, I have a leak. I narrowed the leak down to a >> particular >> pool in PJSIP called pept, which continues to grow as my program >> accepts and >> closes calls. I spent quite a bit of time with the debugger and >> found out >> the following........ >> >> It turns out that the place where extra memory is being allocated >> is in the >> pj_dns_srv_resolve() function in srv_resolver.c, line 114: >> >> query_job = PJ_POOL_ZALLOC_T(pool, pj_dns_srv_resolver_job); > > I'm probably missing something, but here my pept pool doesn't grow > even a bit across calls. And looking at the code, query is allocated > from transmit data pool (txdata, pool name is "dta%p") and not from > endpoint's pool and the txdata will be destroyed once the transaction > is terminated of course. So I'm not sure why you see that. > > Cheers > Benny > > >> So, each time we run pjsip_endpt_resolve(), which we run during >> on_incoming_call() and startAgent() function, it calls >> pjsip_resolve() which >> ultimately calls pj_dns_srv_resolve(). >> >> This seems like a bug to me. We shouldn't keep eating up memory just >> because we are resolving again and again. I figure that if it is a >> bug of >> sorts, or a problem with the architecture, then there are two ways >> to fix >> it: >> >> 1) Free the memory once we're done resolving >> 2) Reuse the same block of memory each time >> >> I was told by someone on the mailing list that the pools don't >> allow you to >> free() memory that has been malloc'd, and that the only option is >> to free >> memory by deleting a pool. Since I don't think this is a choice in >> our >> case, I'd imagine we have to go with the latter solution. >> >> I tried implementing this on my own by creating a static pointer in >> pj_dns_srv_resolve() named query_job. The first time the method is >> run, I >> allocate the space as normal. Every time after that, I check >> whether the >> space has already been allocated, and if so, I reuse the same >> allocated >> space/structure. This, unfortunately, didn't work. Our program >> gets stuck >> in the on_incoming_call() method while it waits for the token- >> >status of >> pjsip_endpt_resolve() to equal 0x12345678, which I assume means >> that the DNS >> resolver has resolved. >> >> Now, the above was just a brain dump on my part and may not be a >> fix to the >> problem at all. If anyone has any suggestions or advice, I would >> really, >> really appreciate it! >> >> Taylor >> >> >> >> >> >> >> On Mar 27, 2008, at 1:13 PM, Benny Prijono wrote: >> >> >> On Thu, Mar 27, 2008 at 6:35 PM, Taylor Boyko >> <taylor.boyko at pacificswell.com> wrote: >> I see. Is this architecture such for performance reasons? >> Portability? Why wouldn't PJSIP just use memory allocation like all >> other programs do? >> >> It's for both performance and portability reasons. Long time ago >> memory allocation used to have serious issues with performance, hence >> we have so many malloc backends (at least on Linux or glibc) all of >> them claims to have the best performance. With using pool, I saw it >> can speed up memory operations by up to 30 times, which is massive! >> >> From portability side, the motivation with pjlib is that it was >> designed to run on systems without OS or libc. With the pool factory, >> one can just reserve some RAM area for the pool and the whole >> application will get its heap from this area. No malloc backend is >> needed. >> >> Also if we tailor the pool sizes carefully, potentially we can save >> memory usage for very small memory devices, since with pool there is >> no bookkeeping records needed for each memory chunk. >> >> Another reason is for fun. Malloc() is soo boring. :) >> >> For more rationales please see >> http://www.pjsip.org/pjlib/docs/html/group__PJ__POOL__GROUP.htm >> >> I suppose the next step, then, is to do what you were proposing >> initially, which is to create a separate pool for the call data and >> clean it up on call termination. I'm going to dig around and see how >> this can be done. Do you have any experience with it? >> >> >> There is one example here: >> http://trac.pjsip.org/repos/wiki/FAQ#pjsua-lib-perf >> >> 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 >> >> > > _______________________________________________ > 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
