I'm using Live555 to realize a C++ RTPS client for IP cameras. I'm using most of the testRTSPClient code.
I used Poco library and Poco::Thread class too.
In other words any client for each camera runs in a separate thread tha owns his instance of Live555 objects (as live555-devel suggests, any thread uses an instance with his UsageEnvironment and TaskScheduler.). This to avoid shared variables and synchronization stuff. It seems to works well and fast.
My runnable (following the Poco library requirements) object IPCamera has the run method as simple as:
void IPCamera::run()
{
openURL(_myEnv, "", _myRtspCommand.c_str(), *this); //taken from the testRTSPClient example
_myEnv->TaskScheduler().doEventLoop(&_watchEventLoopVariable);
//it runs until _watchEventLoopVariable change to a value != 0
//exit from the run;
}
When the run is finished I call join() to close the thread (by the way I figured that if I don't call myThread->join(), the memory is not freed totally).
Upon shutdown, following the requirements in Live555-devel I put in my code:
void IPCamera::shutdown()
{
...
_myEnv->reclaim();
delete _myScheduler;
}
Using Valgrind to detect memory leaks I saw a strange behaviour:
1) case: Run the program - Close the program with all the IPCameras that run in the proper manner.
a) At the end of the program all the destructors are invoked.
b) exit from doEventLoop().
c) join the thread (actually is terminated because it exits from run method.
d) destroy the _myEnv and _myScheduler as showed.
e) destroy all the others objects, including IPCamera and Thread associated.
-> no memory leaks are found by Valgrind. Ok
Now comes the problem.
2) case: I'm implementing a use case where a Poco::Timer checks every X seconds if the camera is alive using ICMP ping. It raises an event (using Poco events) in case it doesn't answer because the network is down and I do the follow:
IPCamera down :
a) put the _watchEventLoopVariable = 1 to exit from the run method;
b) shutdown the client associated to the IPCamera as showed
c) join the thread
I don't destroy the thread because I would like to reuse it when the network is up again and the camera works again.And in that case: a)I set the _eventWatchVariable = 0. b) Let start again the thread with: myThread->run()
Valgrind tells me that memory leaks are found: 60 bytes direct, 20.000 indirect bytes are lost in the thread, in the H264BufferdPackedFactory::createNewPacket(...), a class of Live555.
SOLVED I found out that the problem was the tunneling over TCP. In LIVE55 you can select the kind of protocol. If I select:
I don't have any leak. I used many times Valgrind to be sure (it discovered the problem).
If I use TCP then the above problem is manifested.