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); 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.pjsip.org/pipermail/pjsip_lists.pjsip.org/attachments/20080328/8279aa5c/attachment-0001.html
