Yes. At that time I wrote a test app which only use malloc/free to repeat small size memory block allocation. The program would get 4k mem per block and total 1G RAM at a batch.And then it will release all blocks. If we loop above action and the looping number is very big, for example 1 million, the test app memory size( from "top") wouldn't be changed to reasonable value after all blocks were released.It would always be 1G after long time waiting. regards, Gang On Mon, Jan 19, 2009 at 8:27 PM, Benny Prijono <bennylp at teluu.com> wrote: > On Mon, Jan 19, 2009 at 12:06 PM, Mark Webster < > mark.webster+pjsip at gmail.com <mark.webster%2Bpjsip at gmail.com>> wrote: > >> Yeah, I was pretty sure that's what the caching pool does. I'm going to >> have to go through the code carefully to find out why my silly pool caching >> algorithm seems to "hide" the problem. I've been running it live for a while >> now and the memory usage seems very stable, compared to last week when I >> experienced this crash the first time. >> >> Anyway I'll take your advice and try to get to the bottom of this. I'll >> get back to the list with my findings later in the week. >> >> > A bit more info from me. Gang Liu and I discussed this few months back > here: > http://lists.pjsip.org/pipermail/pjsip_lists.pjsip.org/2008-September/004728.html > > In the end, we concluded that it was LIBC that does the caching and not > PJLIB, so this may also be the case yours. If so, then perhaps it'll be more > appropriate to let PJLIB's caching pool to do the caching by setting it's > cache value to some high number. > > 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/20090119/8ba288a4/attachment.html>
