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

umit sivri sivrumit at yahoo.com
Wed Aug 4 11:02:15 CEST 2010

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 libmatroska::KaxCues::AddBlockGroup

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: 

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

More information about the Matroska-devel mailing list