Displaying 3 results from an estimated 3 matches for "m_pictureblock".
2011 Jun 10
2
Memory leak using libflac++
...ator::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 sh...
2011 Jun 11
0
Flac-dev Digest, Vol 79, Issue 3
...++.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.
>...
2011 Jun 11
0
Memory leak using 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 *r...