Two threads are leaked after invite

[Philippe Torrelli]

Well I'm currently testing the fix here, and there is now another problem
because the liberation of the session object causes the thread running
SipStack::run to be locked in Thread::join() again..  ( will try to
investigate tomorrow ).

Philippe Torrelli

-----Message d'origine-----
De : minisip-devel-bounces at minisip.org
[mailto:minisip-devel-bounces at minisip.org] De la part de Erik Eliasson
Envoyé : mardi 7 novembre 2006 17:59
À : minisip developers' mailing list
Objet : RE: Two threads are leaked after invite


That's some mighty fine detective work - Thanks!
The leak has been there since r2088.

I will put in a regression test that checks the number of objects on the
heap after a call has set up and torn down to detect such things
automatically in the future.
--Erik


On Tue, 2006-11-07 at 17:19 +0100, Philippe Torrelli wrote:
> Auto answer... :)
> 
> I think I spotted the problem, since the dialogs and the transactions'
> destructors are never called here. 
> 
> freeStateMachine doesn't solve all the cyclic references, as anyState=NULL
> doesn't decrease the ref count in the StateMachine... 
> 
> in StateMachine::freeStateMachine , added
> 
> 	anyState->freeState(); ...
> 
> before
> 	anyState=NULL;
> 
> 
> Solved the problem for destructors never called.
> Didn't check yet if it solves my 'threads never freed problem'.
> 
> Hope it helps.
> 
> Philippe Torrelli
> 
> 
> -----Message d'origine-----
> De : minisip-devel-bounces at minisip.org
> [mailto:minisip-devel-bounces at minisip.org] De la part de Philippe Torrelli
> Envoyé : jeudi 2 novembre 2006 12:07
> À : 'minisip developers' mailing list'
> Objet : Two threads are leaked after invite 
> 
> Hello,
> 
> 
> Playing with minisip_textui ( 2891 ) again, and found that
>  each time I 'INVITE' a party, even if the call doesn't succeed
> and then hangup, two more thread stay locked forever 
> ( a thread  looping in rtpreceiver->run() and a timeoutprovider thread )
> 
> The debugger show  that the rtpreceiver doesn't leave its 
> "run" loop because since the callRecorder assigned to the session
>  doesn't call rtpReceiver->unregisterMediaStream ..
> 
> Experimentally modified Session::stop this way: 
> added cr->stop() after cr->setAllowStart( false ) 
> to figure out, and now the thread terminates..
> 
> It doesn't solve the leak of the thread created for 
> session::dtmfTOProvider, as the session object is not destroyed..
> ( should be destroyed in SipDialogVoIp destructor )
> It seems to me that the SipVoIpClient should be destroyed somewhere, 
> 
> 
> As far as I understand the code, I suppose it should be destroyed 
>  by the SipLayerDialog::removeTerminatedDialogs function ? ..
> 
> Hope it helps
> 
> Philippe Torrelli
> 
> _______________________________________________
> Minisip-devel mailing list
> Minisip-devel at minisip.org
> http://lists.minisip.org/mailman/listinfo/minisip-devel
> 
> _______________________________________________
> Minisip-devel mailing list
> Minisip-devel at minisip.org
> http://lists.minisip.org/mailman/listinfo/minisip-devel
-- 
Erik Eliasson <eliasson at it.kth.se>

_______________________________________________
Minisip-devel mailing list
Minisip-devel at minisip.org
http://lists.minisip.org/mailman/listinfo/minisip-devel