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.<br>
<br><div class="gmail_quote">On Wed, Aug 4, 2010 at 11:02 AM, umit sivri <span dir="ltr"><<a href="mailto:sivrumit@yahoo.com">sivrumit@yahoo.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div><div style="font-family:times new roman,new york,times,serif;font-size:12pt"><div><br>test6.cpp rises segfault at the end of try block. here is gdb output:<br><br>------------------------------------------------------------------------<br>
Creating "muxed.mkv"<br><br>Program received signal SIGSEGV, Segmentation fault.<br>0x0000000000000071 in ?? ()<br>(gdb) back<br>#0  0x0000000000000071 in ?? ()<br>#1  0x00007f65b84fe0b8 in ~EbmlMaster (this=0x7fffff1accd0) at workspace/libebml_svn/make/linux/../../src/EbmlMaster.cpp:81<br>
#2  0x0000000000408f86 in ~KaxCluster (this=0x7fffff1accd0) at workspace/libmatroska_svn/make/linux/../../matroska/KaxCluster.h:52<br>#3  0x0000000000407a90 in main (argc=1, argv=0x7fffff1ad788) at
 workspace/libmatroska_svn/make/linux/../../test/mux/test6.cpp:398<br>------------------------------------------------------------------------<br><br></div><div style="font-family:times new roman,new york,times,serif;font-size:12pt">
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.<br>Making variables pointer and not deallocating prevents segfault but rises memleaks which was the main problem to begin with.<br>
Besides, deleting lines which deallocate allocated KaxBlockBlobs in test code also prevents segfaults but then again memleak occurs.<br>Could you verify this?<br><br>ps: libebml and libmatroska are latest revisions (386 & 453) at the time of post.<br>
<br><br><br><br><div style="font-family:times new roman,new york,times,serif;font-size:12pt"><font face="Tahoma" size="2"><div class="im"><hr size="1"><b><span style="font-weight:bold">From:</span></b> Steve Lhomme <<a href="mailto:slhomme@matroska.org" target="_blank">slhomme@matroska.org</a>><br>
<b><span style="font-weight:bold">To:</span></b> Discussion about the current and future development of Matroska <<a href="mailto:matroska-devel@lists.matroska.org" target="_blank">matroska-devel@lists.matroska.org</a>><br>
</div><b><span style="font-weight:bold">Sent:</span></b> Thu, July 29, 2010 10:07:29 PM<div class="im"><br><b><span style="font-weight:bold">Subject:</span></b> Re: [Matroska-devel] memory leak in libmatroska::KaxCues::AddBlockGroup<br>
</div></font><div><div></div><div class="h5"><br>
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.<br><br><div class="gmail_quote">

On Thu, Jul 29, 2010 at 8:52 PM, Steve Lhomme <span dir="ltr"><<a rel="nofollow" href="mailto:slhomme@matroska.org" target="_blank">slhomme@matroska.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204, 204, 204);padding-left:1ex">

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...<div>

<br></div><div>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.</div>

<div>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,</div>

<div><br><div class="gmail_quote">On Thu, Jul 29, 2010 at 9:34 AM, Moritz Bunkus <span dir="ltr"><<a rel="nofollow" href="mailto:moritz@bunkus.org" target="_blank">moritz@bunkus.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204, 204, 204);padding-left:1ex">

Hey,<br>
<div><br>
On Thursday 29 July 2010 08:14:24 umit sivri wrote:<br>
<br>
> I searched all mkvtoolnix sources for the method usage I specified and<br>
> could not find any usage of KaxCues::AddBlockGroup.<br>
<br>
</div>src/merge/cluster_helper.cpp, line 422:<br>
<br>
        g_kax_cues->AddBlockBlob(*new_block_group);<br>
<br>
AddBlockBlob() does indeed not call AddBlockGroup(), and AddBlockGroup()<br>
allocates a new instance of KaxBlockBlob(). That instance is pushed onto<br>
the reference array, and that array does not delete the instances. It<br>
must not delete them as AddBlockBlob() pushes pointers it doesn't have<br>
ownership over onto the same array. So yeah, there is a memory leak in<br>
the library.<br>
<br>
Regards,<br>
Mosu<br>
<font color="#888888"><br>
--<br>
If Darl McBride was in charge, he'd probably make marriage<br>
unconstitutional too, since clearly it de-emphasizes the commercial<br>
nature of normal human interaction, and probably is a major impediment<br>
to the commercial growth of prostitution. - Linus Torvalds<br>
</font><br>_______________________________________________<br>
Matroska-devel mailing list<br>
<a rel="nofollow" href="mailto:Matroska-devel@lists.matroska.org" target="_blank">Matroska-devel@lists.matroska.org</a><br><span>
<a href="http://lists.matroska.org/cgi-bin/mailman/listinfo/matroska-devel" target="_blank">http://lists.matroska.org/cgi-bin/mailman/listinfo/matroska-devel</a></span><br><span>
Read Matroska-Devel on GMane: <a href="http://dir.gmane.org/gmane.comp.multimedia.matroska.devel" target="_blank">http://dir.gmane.org/gmane.comp.multimedia.matroska.devel</a></span><br></blockquote></div><br></div></blockquote>

</div><br>
</div></div></div></div>
</div><br>

      </div><br>_______________________________________________<br>
Matroska-devel mailing list<br>
<a href="mailto:Matroska-devel@lists.matroska.org">Matroska-devel@lists.matroska.org</a><br>
<a href="http://lists.matroska.org/cgi-bin/mailman/listinfo/matroska-devel" target="_blank">http://lists.matroska.org/cgi-bin/mailman/listinfo/matroska-devel</a><br>
Read Matroska-Devel on GMane: <a href="http://dir.gmane.org/gmane.comp.multimedia.matroska.devel" target="_blank">http://dir.gmane.org/gmane.comp.multimedia.matroska.devel</a><br></blockquote></div><br>