Two threads are leaked after invite

[Philippe Torrelli]

Hello, 

(Sorry for the long post, I spent more time investigating on my thread leak)

For the rtpreceiver thread that is leaked after every sip call, the leak is
still here after the session destructor is called because there remains a
reference to this object in the list of media streams hold by
session->callRecorder, and the thread only terminates when this list is
empty. 
Session->stop() sets the callRecorder to NULL but it is not enough ... 
So maybe it shouldn't be start('ed) in the constructor, or stopped when the
session is stopped ? 

Or should minisip_textui send a "call_recorder_start_stop" before it hangs
up ( seems weird to me )... Or did I miss something  ?

---
For the other thread leaked, in short, now the session destructor is called,
the thread->Stop should do the job ...
I meet a problem with the thread running ' SipCommandDispatcher::run '
locked in "join" but it seems to only happen when I'm stepping into
minisip_textui with the debugger, and I reach breakpoints in this thread. 

In short: (ahem)

If I start minisip_textui, do three time ( call a peer +  hangup ), then
attach a debugger, I find three leaked threads in RtpReceiver::Run 
running
ret = select( socket->getFd() + 1, &rfds, NULL, NULL, &tv );
with 
tv_sec = 0, tv_usec= 100000
socket has a valid fd.

On the other side If I run minisip from the debugger, and have some break
points ( around the destructors of Session and SipDialogVoIp) and do the
same thing, I call a peer then hangup, after the hangup the thread running
SipCommandDispatcher::run is blocked in  ( pseudo dump of the stack : )

>Thread::join(const ThreadHandle & handle={...})  
>Thread::join()  
>TimeoutProvider<DtmfEvent *,MRef<DtmfSender *> >::stopThread()  
>Session::~Session()
....

The thread running timeout provider is in 
CondVar::wait ..
TimeOutProvider::sleep
With 3600000 ms and the TimeOutProvider::stop is set to true.


It looks like ( when stepped into / stepped over  from the debugger ) the
CondVar::broadcast method that is called in the StopThread function fails to
wake up the TimeOutProvider thread.


Found on the net that PulseEvent or SetEvent+ResetEvent can fail to wake
other thread waiting on the event, so I guess it's the problem I face here
- I suppose stepping into minisip with the debugger causes the special
conditions that are described in 
http://blogs.msdn.com/oldnewthing/archive/2005/01/05/346888.aspx .

I guess this 'problem' is minor  although annoying when debugging ..
Do you think it makes sense to try to use CondVarPosix instead of
CondVarWin32 ? Or maybe implement the broadcast /wait functionality in
another way ? 


Philippe Torrelli