[Flac-dev] Flac-dev Digest, Vol 79, Issue 3
Tarun Chauhan
tarunchauhan580 at gmail.com
Sat Jun 11 12:01:06 PDT 2011
On Sun, Jun 12, 2011 at 12:30 AM, <flac-dev-request at xiph.org> wrote:
> Send Flac-dev mailing list submissions to
> flac-dev at xiph.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
> http://lists.xiph.org/mailman/listinfo/flac-dev
> or, via email, send a message with subject or body 'help' to
> flac-dev-request at xiph.org
>
> You can reach the person managing the list at
> flac-dev-owner at xiph.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of Flac-dev digest..."
>
>
> Today's Topics:
>
> 1. Memory leak using libflac++ (Andy Hawkins)
> 2. Re: Memory leak using libflac++ (Stephen F. Booth)
> 3. Re: Memory leak using libflac++ (Andy Hawkins)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Fri, 10 Jun 2011 15:39:41 +0000 (UTC)
> From: Andy Hawkins <andy at gently.org.uk>
> Subject: [Flac-dev] Memory leak using libflac++
> To: flac-dev at xiph.org
> Message-ID: <slrniv4elt.uti.andy at atom.gently.org.uk>
> Content-Type: text/plain; charset=us-ascii
>
> Hi all,
>
> I'm the author of flactag, a utility for tagging whole-album FLAC files
> with
> embedded CUE sheets using data from the MusicBrainz servers.
>
> I've recently run it through valgrind, and I'm seeing memory leaks like the
> following:
>
> 12 bytes in 1 blocks are definitely lost in loss record 1 of 5
> at 0x402377E: operator new(unsigned) (vg_replace_malloc.c:224)
> by 0x41448A8: FLAC::Metadata::local::construct_block(FLAC__StreamMetadata*)
> (in /usr/lib/libFLAC++.so.6.2.0) by 0x41455D7:
> FLAC::Metadata::Iterator::get_block() (in /usr/lib/libFLAC++.so.6.2.0)
> by 0x8072CB5: CFlacInfo::Read() (FlacInfo.cc:154)
> by 0x8054BF4: CFlacTag::LoadData() (flactag.cc:543)
> by 0x8058D45: CFlacTag::CFlacTag(CCommandLine const&) (flactag.cc:134)
> by 0x805D4E2: main (flactag.cc:66)
>
> In my code, the offending line is:
>
> m_PictureBlock=(FLAC::Metadata::Picture*)Iterator.get_block();
>
> (m_PictureBlock is a pointer to a FLAC::Metadata::Picture object).
>
> The documentation seems to imply that you don't need to delete the pointer
> that is returned here, but the memory leak report seems to contradict that.
>
> Can anyone tell me if I should be deleteing this point? Or is there
> something else I should be doing to clean up?
>
> Thanks
>
> Andy
>
>
>
> ------------------------------
>
> Message: 2
> Date: Fri, 10 Jun 2011 21:49:58 -0400
> From: "Stephen F. Booth" <me at sbooth.org>
> Subject: Re: [Flac-dev] Memory leak using libflac++
> To: flac-dev at xiph.org
> Message-ID: <BANLkTi=L+XNe3zVRoVMzSYvCwVhtpNh7xQ at mail.gmail.com>
> Content-Type: text/plain; charset=ISO-8859-1
>
> > I've recently run it through valgrind, and I'm seeing memory leaks like
> the
> > following:
> >
> > 12 bytes in 1 blocks are definitely lost in loss record 1 of 5
> > at 0x402377E: operator new(unsigned) (vg_replace_malloc.c:224)
> > by 0x41448A8:
> FLAC::Metadata::local::construct_block(FLAC__StreamMetadata*)
> > (in /usr/lib/libFLAC++.so.6.2.0) ? by 0x41455D7:
> > FLAC::Metadata::Iterator::get_block() (in /usr/lib/libFLAC++.so.6.2.0)
> > by 0x8072CB5: CFlacInfo::Read() (FlacInfo.cc:154)
> > by 0x8054BF4: CFlacTag::LoadData() (flactag.cc:543)
> > by 0x8058D45: CFlacTag::CFlacTag(CCommandLine const&) (flactag.cc:134)
> > by 0x805D4E2: main (flactag.cc:66)
> >
> > In my code, the offending line is:
> >
> > m_PictureBlock=(FLAC::Metadata::Picture*)Iterator.get_block();
>
> I've never used the C++ API, but the source for get_block() is just:
>
> return
> local::construct_block(::FLAC__metadata_simple_iterator_get_block(iterator_));
>
> and construct_block() looks like (simplified for the picture case):
>
> Prototype *ret = 0;
> ret = new Picture(object, /*copy=*/false);
> return ret;
>
> So I don't see any way this couldn't be a leak if you aren't deleting
> the pointer returned from get_block().
>
> The documentation says:
>
> * The ownership of pointers in the C++ layer follows that in
> * the C layer, i.e.
> * - The objects returned by get_block() are yours to
> * modify, but changes are not reflected in the FLAC file
> * until you call set_block(). The objects are also
> * yours to delete; they are not automatically deleted
> * when passed to set_block() or insert_block_after().
>
> So I think it will be necessary for you to delete the object manually.
>
> Stephen
>
>
> ------------------------------
>
> Message: 3
> Date: Sat, 11 Jun 2011 11:22:28 +0000 (UTC)
> From: Andy Hawkins <andy at gently.org.uk>
> Subject: Re: [Flac-dev] Memory leak using libflac++
> To: flac-dev at xiph.org
> Message-ID: <slrniv6jvk.joo.andy at atom.gently.org.uk>
> Content-Type: text/plain; charset=us-ascii
>
> Hi,
>
> In article <BANLkTi=L+XNe3zVRoVMzSYvCwVhtpNh7xQ at mail.gmail.com>,
> Stephen F. Booth<me at sbooth.org> wrote:
> > I've never used the C++ API, but the source for get_block() is just:
> >
> > return
> local::construct_block(::FLAC__metadata_simple_iterator_get_block(iterator_));
> >
> > and construct_block() looks like (simplified for the picture case):
> >
> > Prototype *ret = 0;
> > ret = new Picture(object, /*copy=*/false);
> > return ret;
> >
> > So I don't see any way this couldn't be a leak if you aren't deleting
> > the pointer returned from get_block().
> >
> > The documentation says:
> >
> > * The ownership of pointers in the C++ layer follows that in
> > * the C layer, i.e.
> > * - The objects returned by get_block() are yours to
> > * modify, but changes are not reflected in the FLAC file
> > * until you call set_block(). The objects are also
> > * yours to delete; they are not automatically deleted
> > * when passed to set_block() or insert_block_after().
> >
> > So I think it will be necessary for you to delete the object manually.
>
> Thanks for that. Can't find all of that in the documentation I'm looking
> at:
>
> http://flac.sourceforge.net/api/index.html
>
> However, it does all make sense and ties in with my reading of the library
> source too.
>
> Thanks a lot for the response.
>
> Andy
>
>
>
> ------------------------------
>
> _______________________________________________
> Flac-dev mailing list
> Flac-dev at xiph.org
> http://lists.xiph.org/mailman/listinfo/flac-dev
>
>
> End of Flac-dev Digest, Vol 79, Issue 3
> ***************************************
>
--
Thanks & Regards
Tarun Chauhan
+91 - 9266858589
+91 - 8447763691
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.xiph.org/pipermail/flac-dev/attachments/20110612/4517f06d/attachment.htm
More information about the Flac-dev
mailing list