Memory Leak problem with Pool

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

 



Taylor Boyko wrote:
> I'm encountering a memory leak problem.  It seems that whenever a call  
> is received by my application, memory leaks.  More specifically,  
> running pjsip_endpt_resolve() seems to have something to do with the  
> memory growing, because if I loop the execution of this function, my  
> application balloons in size.
>
> I've spent about two days trying to track down these leaks.  Using the  
> built in dbgheap utilities in Visual Studio, I found some of my own  
> "new char[]" calls that weren't being freed.  However, after fixing  
> those, I am still having a substantial amount of memory leakage.  From  
> what I can tell, and from what the debug is telling me, it looks like  
> memory that is being allocated at line 45 of pool_policy_malloc.c "(p  
> = malloc(size+(SIG_SIZE << 1));" is where the leaking memory is being  
> initialized.  I suppose it isn't being freed correctly somewhere else.
>
> I'd imagine that the likelihood of this problem is that I've done  
> something wrong at some point and am not running a needed cleanup  
> function.  Or, perhaps I've encountered some sort of bug with the pool.
>
> I'd appreciate any assistance or insight on this one, as I'm running  
> out of ideas.
>
> Thanks!
>
> Taylor
>
> _______________________________________________
> 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
>   

Hi Taylor,

I have noticed that my application memory grows with each call as well.

I am not 100% certain but I believe it is the main pjsua pool that keeps 
expanding. Of course this pool is never freed until shutdown.

Just grep'ing through the source I can see a couple places where it 
looks like call specific memory is allocated to this pool. I don't know 
how easy this is to fix, though. Obviously, we would need an 
alternative, call specific memory pool to allocate on.


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




[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