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

Steve Lhomme slhomme at matroska.org
Thu Aug 5 20:26:58 CEST 2010


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
> workspace/libebml_svn/make/linux/../../src/EbmlMaster.cpp:81
> #2  0x0000000000408f86 in ~KaxCluster (this=0x7fffff1accd0) at
> workspace/libmatroska_svn/make/linux/../../matroska/KaxCluster.h:52
> #3  0x0000000000407a90 in main (argc=1, argv=0x7fffff1ad788) at
> workspace/libmatroska_svn/make/linux/../../test/mux/test6.cpp:398
> ------------------------------------------------------------------------
>
> 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
> post.
>
>
>
>
> ------------------------------
> *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:
>>
>>> Hey,
>>>
>>> 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.
>>>
>>> Regards,
>>> Mosu
>>>
>>> --
>>> 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
>>> http://lists.matroska.org/cgi-bin/mailman/listinfo/matroska-devel
>>> Read Matroska-Devel on GMane:
>>> http://dir.gmane.org/gmane.comp.multimedia.matroska.devel
>>>
>>
>>
>
>
> _______________________________________________
> Matroska-devel mailing list
> Matroska-devel at lists.matroska.org
> http://lists.matroska.org/cgi-bin/mailman/listinfo/matroska-devel
> Read Matroska-Devel on GMane:
> http://dir.gmane.org/gmane.comp.multimedia.matroska.devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.matroska.org/pipermail/matroska-devel/attachments/20100805/9f7b1753/attachment.html>


More information about the Matroska-devel mailing list