[Live-devel] Problem releasing Matroska demuxer

[PROMONET Michel]

            Hi Ross,

Thanks a lot for your great support.

Demuxing a matroska file, I meet problem releasing the memory.
Because the medium table is not empty, the reclaim of UsageEnvironment doesnot delete it.

I made investigations with valgrind running on the following code that extract the first stream from test.mkv:
#include "liveMedia.hh"
#include "BasicUsageEnvironment.hh"
static char watchVariable = 0;
static MatroskaFile* matroskaFile = NULL;
static void onMatroskaFileCreation(MatroskaFile* newFile, void* /*clientData*/)
{
            matroskaFile = newFile;
            watchVariable = 1;
}

static void afterPlaying(void* clientData)
{
            watchVariable = 1;
}

int main(int argc, char** argv)
{
            TaskScheduler* scheduler = BasicTaskScheduler::createNew();
            UsageEnvironment* env = BasicUsageEnvironment::createNew(*scheduler);

            // Open a Matroska file:
            char const* inputFileName = "test.mkv";
            MatroskaFile::createNew(*env, inputFileName, onMatroskaFileCreation, NULL);
            env->taskScheduler().doEventLoop(&watchVariable);

            // Create a demultiplexor from the file:
            MatroskaDemux* demux = matroskaFile->newDemux();

            // And start copying each track:
            unsigned trackNumber = 0;
            FramedSource* source = demux->newDemuxedTrack(trackNumber);
            MediaSink* sink = FileSink::createNew(*env, "track", 300000, False);
            sink->startPlaying(*source,afterPlaying,NULL);

            // Print medium names
            fprintf(stderr, "Medium name MkvFile:%s Demux:%s Source:%s Sink:%s\n", matroskaFile->name(), demux->name(), source->name(), sink->name());

            watchVariable = 0;
            env->taskScheduler().doEventLoop(&watchVariable);

            // Clean up
            Medium::close(source);
            Medium::close(sink);
// Released in MatroskaDemux::removeTrack        Medium::close(demux);
            Medium::close(matroskaFile);

            // Check Media table
            _Tables* ourTables = _Tables::getOurTables(*env, false);
            if (ourTables != NULL)
            {
                        fprintf(stderr, "Private structure are not empty\n");
                        HashTable::Iterator* iter = HashTable::Iterator::create(ourTables->mediaTable->getTable());
                        char const* key = NULL;
                        Medium * medium = NULL;
                        while ((medium = (Medium*)(iter->next(key))) != NULL) {
                                   fprintf(stderr, "Still registered %s\n", medium->name());
                        }
                        delete iter;
            }
            else
            {
                        fprintf(stderr, "_Tables are empties\n");
            }

            env->reclaim();
            delete scheduler;

            return 0;
}

It appears that releasing the last source, MatroskaDemux object is deleted, but doesnot remove from the mediaTable, and when the program print demux name, it use memory that is no more allocated.

I made a try modifying MatroskaDemux::removeTrack :
void MatroskaDemux::removeTrack(unsigned trackNumber) {
  fDemuxedTracksTable->Remove((char const*)trackNumber);
  if (fDemuxedTracksTable->numEntries() == 0) {
    // We no longer have any demuxed tracks, so delete ourselves now:
-    delete this;
+      Medium::close(this);
  }
}

With this modification, reclaim on UsageEnvironment delete it and valgrind do not report memory leakage or corruption.
Do you think it could be a way to solve my problem ?

Another way, I find more explicit, could be to not delete the demuxer and let the caller to close it, but this has an impact upgrading library used by legacy code.
This will avoid to manage in a different way when there is no track parsed.

Best Regards,

            Michel.

[@@ THALES GROUP INTERNAL @@]

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.live555.com/pipermail/live-devel/attachments/20140619/3a87ad87/attachment-0001.html>