Memory Leak problem with Pool

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



I see.  Is this architecture such for performance reasons?   
Portability?  Why wouldn't PJSIP just use memory allocation like all  
other programs do?

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?




On Mar 27, 2008, at 11:13 AM, Michael Broughton wrote:

> Taylor Boyko wrote:
>> My knowledge on this is a little fuzzy.  It's been a while since
>> school when I was digging around in C memory land.
>>
>> From my understanding, PJSIP has it's own dynamic memory allocation
>> mechanism, meaning that it doesn't rely on the traditional c
>> libraries.  In other words, when malloc is run, it is managed by
>> PJSIP, not the system.  Does this sound right?
>>
>> If that's the case, then why is the pool continuously malloc'ing more
>> space?  It must be because objects are being created in the heap and
>> then aren't being cleaned up (either from falling out of context, or
>> being free'd/delete'd).  So, is the problem with the pool, or is the
>> problem appearing in the pool because of poor code elsewhere?
>>
>> You mention pjsua_dump.  I'll play around with this and see what I  
>> can
>> find from it.  I'm fairly determined to get this working, so I'm  
>> going
>> to take it as far as I can, knowledge wise.
>>
>>
>
> PJ pools are a little different. Basically you can use them to  
> allocate
> memory onto the heap. That memory is associated with its pool, and  
> does
> not get free'd until the entire pool is free'd. So if you do many
> allocations on a particular pool, there is no way to selectively free
> one of those allocations. You have to free the entire pool.
>
> -- 
> Michael Broughton, Advanis
>
> Unintended Recipient & Unauthorized Use of E-Mail:
> This message and attachments may contain confidential or privileged
> information that is intended only for the named recipient of this
> e-mail. Any unauthorized use or distribution is not permitted. If you
> have received this e-mail in error, deleting the e-mail and notifying
> the sender would be appreciated. Thank you.
>
>
> _______________________________________________
> 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




[Index of Archives]     [Asterisk Users]     [Asterisk App Development]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Security]     [Bugtraq]     [Linux]     [Linux OMAP]     [Linux MIPS]     [Linux API]
  Powered by Linux