Unknown Address Fault for APIC.toBase64().data()

Антон Сергунов setosha at gmail.com
Fri Aug 25 06:37:22 UTC 2017


Exactly. .data() returns just raw pointer. Each call to .toBase64()
generates new buffer object. It's better to calculate it once and reuse.

const auto& base64 = picture.toBase64();
const auto* ptr = base64.data(); // valid while base64 alive

On пт, 25 авг. 2017 г., 7:52 Michael Pyne <mpyne at kde.org> wrote:

> On Thu, Aug 24, 2017 at 12:46:23PM -0400, Timothy Stoyanovski wrote:
> > Hello,
> >
> > I'm having an interesting issue with 1 particular mp3. Below is my code:
> >
> > TagLib::ID3v2::AttachedPictureFrame * frame =
> > (TagLib::ID3v2::AttachedPictureFrame *)(*it);
> >
> > if (frame!=nullptr && frame->size() > 0) {
> >
> >     auto len = frame->picture().toBase64().size();
> >
> >     if (len) { // size: 741376
> >
> >         outfile << "generated apic" << '\n';
> >
> >         outfile << frame->picture().toBase64() << '\n';  // <—— is okay
> >
> >         outfile << frame->picture().toBase64().data() << '\n'; <—— CRASH
> >
> > Is there any way to identify why this crashes, and why does .data() cause
> > the crash?
>
> I can never get C++ lifetime rules fully memorized, but I think it is
> likely that the temporary ByteVector returned by
> frame->picture().toBase64() is deleted automatically in between the
> .data() call and the output to outfile.  That is, the compiler
> rearranges that crashing line to something like:
>
> {
>   // ...
>   const char * dataPtr;
>   {
>     const ByteVector vector = frame->picture().toBase64();
>     dataPtr = vector.data();
>   }
>   // vector destructed here, dataPtr not safe to use
>   outfile.operator<<(dataPtr); // crash
> }
>
> If you do something like
>
>         const auto &temp = frame->picture().toBase64();
>         outfile << temp.data() << '\n';
>
> and that works, then it's probably this issue.
>
> Regards,
>  - Michael Pyne
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/taglib-devel/attachments/20170825/1c0b6fc6/attachment.html>


More information about the taglib-devel mailing list