[Flac-dev] Memory leak using libflac++

Stephen F. Booth me at sbooth.org
Fri Jun 10 18:49:58 PDT 2011


> 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


More information about the Flac-dev mailing list