< Previous by Date Date Index Next by Date >
< Previous in Thread Thread Index  

Re: [reSIProcate] SipStack memory leak


Changes for these leaks have been committed to SVN main line.  Thanks for reporting them.

Scott

On Tue, Dec 11, 2012 at 3:54 PM, Scott Godin <sgodin@xxxxxxxxxxxxxxx> wrote:
...inline...

On Mon, Dec 10, 2012 at 4:23 AM, Shypytiak Taras <p-aladin@xxxxxxxxx> wrote:
Hi, developer's team,
I'm using resiprocate-1.8.5 and I have observed a fiew memory leak issues:

1)  When we use SipStack::postMs. but thi leak happens only if applications stops nad is caused by resip/stack/TimerQueue.hxx:55.

virtual ~TimerQueue()
      {
         while (!mTimers.empty())
         {
            mTimers.pop();
         }
      }
Could you please implement explicit  destruction?

[Scott]  Not too sure what you are suggesting here.  TimeQueue is a templatized class - we are not storing pointers in the priority_queue.  Even the while loop isn't necessary, since the priority_queue and all it's items should be destroyed when the mTimers member goes out of scope anyway.  Perhaps one of the classes used in the T template parameter is not properly cleaning up in it's destructor.  The TimerWithPayload class appears to be a potential culprit.
 
2) Next issue is cause by resip/stack/ParserContainerBase.hxx:61( ParserContainerBase::clear )

inline void clear() {mParsers.clear();}
In this case freeParser is not called and we have memory leak .
And this leak is more dangerous as ParserContainerBase::clear is called from  number of places(  MasterProfile::clearSupportedMethods for example ).
Could you please implement proper ParserContainerBase::clear, through ParserContainerBase::pop_front for example?

[Scott]  Nice catch - I will fix this.  Thanks!
 
Sincerely,
Taras.
_______________________________________________
resiprocate-devel mailing list
resiprocate-devel@xxxxxxxxxxxxxxx
https://list.resiprocate.org/mailman/listinfo/resiprocate-devel