[Live-devel] Enumerate all 'clients' and memory leak

ЗвягинцевАнтон zvyagintsev at atlantis.ru
Thu Sep 20 06:08:35 PDT 2012


Ross Finlayson <finlayson at ...> writes:


> My ptable pointer allocated in MediaLookupTable::ourMedia but never deleted
> No, that's incorrect - it *will* get deleted, if/when all "Medium" objects end
up getting deleted (so there's no memory leak here).

Both VLD (visual leak detector) and ms crt debug runtime reports leaks in that
code. (Yep, i am still with windows - just doing my job, even after that
rtp-over-tcp bug and two days of debugging live555 code :))

If i understand you correctly the only way this leaks possible if the internal
container not empty when my program is terminated.

BTW, i also interested in removing UsageEnvironment object too. In the sample
code you are advised termination code looks like this:

pliveenvironment->reclaim();
delete m_plivetaskscheduller;

But nobody take care about pliveenvironment itself. So this dynamically
allocated memory also reported as a memory leak at the program termination.
And again, i can't delete UsageEnvironment myself - destructor is not accessible.

> 
> Out of curiosity, though: Why do you want to "enumerate all RTSPClients"?
> 

To properly shutdown all my RTSPClients. Honestly speaking i have only one
RTSPClient running at once :) Anyway i dont want to store my clients in global
pointers/another containers/etc because AFAIK live555 already do this. It is
enough to work just with callback functions. The only problem is forcible
termination from my ('client') side.

And one more question, in the samples and the library itself many places in the
code looks like this:

  RTSPClient* rtspClient = ourRTSPClient::createNew(env, rtspURL,
RTSP_CLIENT_VERBOSITY_LEVEL, progName);

  if (rtspClient == NULL) {

createNew() just a wrapper over the standard operator new (not overloaded, not a
`nothrow` version). But according the c++ standard operator new is never return
NULL, but throws bad_alloc on error. Why we need to check the return value? 


WBR,
Anton



More information about the live-devel mailing list