Two threads are leaked after invite

[Philippe Torrelli]

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