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 > >
