[Matroska-devel] memory leak in libmatroska::KaxCues::AddBlockGroup

umit sivri sivrumit at yahoo.com
Fri Aug 6 09:44:14 CEST 2010

Blob4 is not a kaxcluster but Clust1 and Clust2 are. In my previous post I 
wanted to tell segfault occurs with Clust1 or Clust2(both actually) destructors, 
not blob4.
kaxcluster, which is an ebmlmaster has a destructor: "~ebmlmaster".
As to why segfault not occurs for you, my guess is that, it occurs but you could 
not detect (which was the case in my first execution of the code) since it 
occurs at the end of try block which everything actually happens.
For being sure, I'd recommend adding a printf-cout just before "return 0;" after 
the try-catch block, and see if it actually prints. You may have already done 
something like this but Im writing just to make sure.

I found the fix for the segfault, too.
changing kaxblockblob destructor from:

    ~KaxBlockBlob() {
        if (bUseSimpleBlock)
            delete Block.simpleblock;
            delete Block.group;


    ~KaxBlockBlob() { }

in kaxblock.h, starting from line 323, prevents segfault I mentioned and my code 
works without any memleaks and segfaults.
Not sure whether my fix is the right way for all usages, but it serves my 

From: Steve Lhomme <slhomme at matroska.org>
To: Discussion about the current and future development of Matroska 
<matroska-devel at lists.matroska.org>
Sent: Thu, August 5, 2010 9:26:58 PM
Subject: Re: [Matroska-devel] memory leak in libmatroska::KaxCues::AddBlockGroup

I don't know how this is possible. I'm not using gcc or gdb, but a (logical) 
segfault should happen the same way on any platform and I get nothing. Also 
Blob4 is not a KaxCluster but a KaxBlockBlob. So I don't know how you get the 
KaxCluster to be called when calling "delete Blob4". And on top of that 
KaxCluster doesn't have a destructor. So maybe your code is not linked with the 
right library.

On Wed, Aug 4, 2010 at 11:02 AM, umit sivri <sivrumit at yahoo.com> wrote:

>test6.cpp rises segfault at the end of try block. here is gdb output:
>Creating "muxed.mkv"
>Program received signal SIGSEGV, Segmentation fault.
>0x0000000000000071 in ?? ()
>(gdb) back
>#0  0x0000000000000071 in ?? ()
>#1  0x00007f65b84fe0b8 in ~EbmlMaster (this=0x7fffff1accd0) at 
>#2  0x0000000000408f86 in ~KaxCluster (this=0x7fffff1accd0) at 
>#3  0x0000000000407a90 in main (argc=1, argv=0x7fffff1ad788) at  
>Even though problem line shows "delete Blob4;", I found that segfault rises in 
>kaxcluster destructor which was declared as a variable, not a pointer and came 
>to its lifetime end with block end.
>Making variables pointer and not deallocating prevents segfault but rises 
>memleaks which was the main problem to begin with.
>Besides, deleting lines which deallocate allocated KaxBlockBlobs in test code 
>also prevents segfaults but then again memleak occurs.
>Could you verify this?
>ps: libebml and libmatroska are latest revisions (386 & 453) at the time of 
From: Steve Lhomme <slhomme at matroska.org>
>To: Discussion about the current and future development of Matroska 
><matroska-devel at lists.matroska.org>
>Sent: Thu, July 29, 2010 10:07:29 PM
>Subject: Re: [Matroska-devel] memory leak in 
>I made the changes in SVN KaxCues::AddBlockGroup() was simply removed and 
>replaced in mux6 with a working version of the code. There might still be leaks 
>in there but at least not this one anymore.
>On Thu, Jul 29, 2010 at 8:52 PM, Steve Lhomme <slhomme at matroska.org> wrote:
>OK, I'm looking at that antic code right now. KaxCues::AddBlockGroup() is broken 
>anyway. At least the part where it allocates KaxBlockBlob to test if the 
>KaxBlockGroup being added is not already in the array. It tries to find out 
>using pointers, which obviously are never going to be true since the pointer is 
>brand new...
>>Now KaxCues don't "own" the block they are given to reference. There is no smart 
>>pointer here or anything, so it's up to the code that passed the pointers to 
>>references to kill the references themselves.
>>But then it allocates a new KaxBlockBlob that noone really owns. This is 
>>inconsistent. So I suggest marking this function as deprecated so that noone 
>>uses it and coders actually use KaxCues::AddBlockBlob(const KaxBlockBlob & 
>>BlockReference) instead and are held responsible for their reference. bool 
>>KaxCues::AddBlockGroup(const KaxBlockGroup & BlockRef) was just added as a 
>>helper. But it's too broken and would need bigger changes to fix this,
>>On Thu, Jul 29, 2010 at 9:34 AM, Moritz Bunkus <moritz at bunkus.org> wrote:
>>>On Thursday 29 July 2010 08:14:24 umit sivri wrote:
>>>> I searched all mkvtoolnix sources for the method usage I specified and
>>>> could not find any usage of KaxCues::AddBlockGroup.
>>>src/merge/cluster_helper.cpp, line 422:
>>>       g_kax_cues->AddBlockBlob(*new_block_group);
>>>AddBlockBlob() does indeed not call AddBlockGroup(), and AddBlockGroup()
>>>allocates a new instance of KaxBlockBlob(). That instance is pushed onto
>>>the reference array, and that array does not delete the instances. It
>>>must not delete them as AddBlockBlob() pushes pointers it doesn't have
>>>ownership over onto the same array. So yeah, there is a memory leak in
>>>the library.
>>>If Darl McBride was in charge, he'd probably make marriage
>>>unconstitutional too, since clearly it de-emphasizes the commercial
>>>nature of normal human interaction, and probably is a major impediment
>>>to the commercial growth of prostitution. - Linus Torvalds
>>>Matroska-devel mailing list
>>>Matroska-devel at lists.matroska.org
>>>Read Matroska-Devel on GMane: 
>Matroska-devel mailing list
>Matroska-devel at lists.matroska.org
>Read Matroska-Devel on GMane: 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.matroska.org/pipermail/matroska-devel/attachments/20100806/a797e6f5/attachment.html>

More information about the Matroska-devel mailing list