Taglib crash with a flac file

[Stéphane Guillou]

Hi there

I have had this problem for a while, and it has happened to me with versions 1.10.1, 1.11.0 and the master build I am using currently (mixxx_1.12.0-alpha-git5124~master-git5124-ppa1~trusty1_trusty_amd64.deb).

The issue is that, when I start a fresh database (by removing or renaming my current mixxxdb.sqlite), Mixxx crashes while scanning my (rather large) library. I noticed that it happened on the same folder every time (I sometimes can see what folder it was scanning when it got stuck, but other times the windows close straight away) , so I removed that folder, but then it started doing it on a different one, etc.

Because of that problem, I have been using the same database for a while, but I would like to start clean because I noticed some albums do not appear in the library, even after a rescan. (A problem I have been talking about on the forum: http://www.mixxx.org/forums/viewtopic.php?f=3&t=6575)

When it crashes, the only extra line in the terminal is: "Segmentation fault (core dumped)"

I used the command "gdb --eval-command=run mixxx" and I get the following extra lines when Mixxx crashes:

[Thread 0x7fffd3392700 (LWP 7112) exited]
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7ffeff170700 (LWP 7120)]
__memcpy_sse2_unaligned ()
    at ../sysdeps/x86_64/multiarch/memcpy-sse2-unaligned.S:36
36 ../sysdeps/x86_64/multiarch/memcpy-sse2-unaligned.S: No such file or directory.

I then use the command "thread apply all bt" in gdb, and I get the following:

Thread 34 (Thread 0x7ffefe96f700 (LWP 7121)):
#0 0x00007ffff1884bad in poll () at ../sysdeps/unix/syscall-template.S:81
#1 0x00007ffff7bbd9b8 in ?? ()
   from /usr/lib/x86_64-linux-gnu/libportaudio.so.2
#2 0x00007ffff7bbe5e0 in ?? ()
   from /usr/lib/x86_64-linux-gnu/libportaudio.so.2
#3 0x00007ffff2fcf182 in start_thread (arg=0x7ffefe96f700)
    at pthread_create.c:312
#4 0x00007ffff1891efd in clone ()
    at ../sysdeps/unix/sysv/linux/x86_64/clone.S:111

Thread 33 (Thread 0x7ffeff170700 (LWP 7120)):
#0 __memcpy_sse2_unaligned ()
    at ../sysdeps/x86_64/multiarch/memcpy-sse2-unaligned.S:36
#1 0x00007ffff3f139aa in TagLib::ByteVector::replace(TagLib::ByteVector const&, TagLib::ByteVector const&) () from /usr/lib/x86_64-linux-gnu/libtag.so.1
#2 0x00007ffff3ee5d69 in TagLib::ID3v2::SynchData::decode(TagLib::ByteVector const&) () from /usr/lib/x86_64-linux-gnu/libtag.so.1
#3 0x00007ffff3ee541d in TagLib::ID3v2::FrameFactory::createFrame(TagLib::ByteVector const&, TagLib::ID3v2::Header*) const ()
   from /usr/lib/x86_64-linux-gnu/libtag.so.1
#4 0x00007ffff3ee984f in TagLib::ID3v2::Tag::parse(TagLib::ByteVector const&)

These tests were made with mixxx_1.12.0-alpha-git5124~master-git5124 on Ubuntu 14.04, on an Asus x201ep.
Attached is a log of when the crash happens (but I don't think it contains anything interesting).

[Stéphane Guillou (stephane-guillou)]

I tried to scan the same music folder (a copy of it on an external hard drive) with a fresh install of 1.11.0 on a different computer (a Samsung N310 with Ubuntu Studio 14.04.1) and I get a crash with the following error message:
"mixxx crashed with SIGABRT in __libc_message()"

The scan stalled on a different track though, but I am not sure how relevant this is.

[Stéphane Guillou (stephane-guillou)]

I just gave it another go and it crashed on the same track, which is a similar behaviour.

If I put the track it crashes on in a folder, on its own, and use this folder as Mixxx's library, then rescan, it does indeed crash again.

Could there be something wrong with my files? Or is it likely to be something that Mixxx does not lilke in those files?
It happens with files in different formats, with nothing special in the file names, they play fine in different players (Totem, Clementine...), the tags don't look weird at all...

I tried renaming the file, or removing all tags, to no avail. It still crashes on that particular file.

[Stéphane Guillou (stephane-guillou)]

Interestingly, still with the testing on my Samsung N310, I removed the album that was making it crash, and now it scanned the whole library without a problem!
So I can say that on that second computers, the scan does not crash on the same files that made the first computer crash! Very confusing.
I tested that particular album on the first computer though, and it does make the scan crash. So at least that particular album (the only one that makes Mixxx crash on the Samsung N310) also makes Mixxx crash on the first computer.

I am planning to do a clean OS install on the first computer (the one that I actually use for DJing, the Asus x201ep, currently with Mixxx 1.12.0-alpha (build master r5167)) and a clean stable Mixxx install and see how it goes. I will keep you posted of any development.

For the time being, here is one track from the album that made Mixxx crash on both computer.

[Daniel Schürmann (daschuer)]

Can confirm it on Ubuntu Precise.

An other reason for a quarantine process for reading tags ..

[Daniel Schürmann (daschuer)]

As well on Ubuntu Trusty

[Stéphane Guillou (stephane-guillou)]

OK, I have some more info.

On the first computer (Asus x201ep, Ubuntu 14.04, Mixxx 1.12.0-alpha (build master r5167)) I deleted the mixxxdb.sqlite to do a clean scan of the copy of my library on my external hard drive (the same folder that I used as a library on the Samsung N310) and it worked fine without that particular album (of which I attached that track above). I did not encounter any of the issues I listed in the bug description (a large number of problematic files).

My understanding is that there are two problems:
- the one with Mixxx always crashing when scanning the track I attached to this bug report;
- the one with Mixxx crashing when analysing several different files only when they are on my laptop hard drive (even though it is an exact copy of the library on the external hard drive).

[Stéphane Guillou (stephane-guillou)]

I am now on a clean install of KXstudio 14.04 64bits, with the Mixxx PPA to have 1.11.0.

I just did a first scan of my library and I have the same issue, with another FLAC file, interestingly from the same album as the audio file I attached above.

The results are similar. When using the command:
gdb --eval-command=run mixxx

I get the following:
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7fffb1ffb700 (LWP 5072)]
__memcpy_sse2_unaligned () at ../sysdeps/x86_64/multiarch/memcpy-sse2-unaligned.S:36
36 ../sysdeps/x86_64/multiarch/memcpy-sse2-unaligned.S: No such file or directory.

And after that, if I use the following command inside dbg:
thread apply all bt

I get the attached output.

I hope this helps.
Please let me know if I can help in any way to get this fixed for 1.12.0! Maybe we can end up with something that would bypass the problematic files and report graphically which ones they are?
By the way, do you know what the issue might be with those problematic files?

[Vladimír Dudr (vlada-dudr)]

I got similar problem. ChakraOS "Euler", Lenovo Thinkpad T520.

It crashes with:
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7ffef3fff700 (LWP 19751)]
0x00007ffff072e638 in __memcpy_avx_unaligned () from /usr/lib/libc.so.6

When I am rescanning library with my main database (I am using it for my sets), mixxx rescans without problem, than the scanner says "Scanning for cover art (Safe to cancel)" and than it crashes with same error.

Both bts are in attached file.

And all the way around it throws this warning:
Warning [Thread (pooled)]: libpng warning: iCCP: known incorrect sRGB profile

tried today with git branch 1.12 and compiled with faad=1 and tuned=1

[Sébastien BLAISOT (sblaisot)]

Do you have opus files in your library ?
I wonder if it could be related to https://bugs.launchpad.net/mixxx/+bug/1458380

[Daniel Schürmann (daschuer)]

Can confirm with current master and current 1.12 running on Ubuntu Trusty

[Stéphane Guillou (stephane-guillou)]

I just wanted to say that I do not have this problem anymore on my system, I am now on KXStudio 14.04 64 bits and a clean scan of my library works fine, using 1.11 or the 1.12 from the beta PPA.

The only thing I can think of is that on my previous install, my library was in my encrypted home folder... Could that be why there was an issue?

[Daniel Schürmann (daschuer)]

> Could that be why there was an issue

I am afraid not. Since I can reproduce it on an unencrypted drive.

It looks like the bug is somewhere inside taglib
On my 64 bit system it is
libtag1-vanilla 1.9.1-2

What is yours?

[Stéphane Guillou (stephane-guillou)]

> It looks like the bug is somewhere inside taglib
> On my 64 bit system it is
> libtag1-vanilla 1.9.1-2

I've got libtag1-vanilla 1.9.1-2 too, so that doesn't look like it.

[Daniel Schürmann (daschuer)]

Strange. What else coud be the reason that it does not crash anymore?

[Daniel Schürmann (daschuer)]

Just filed a Taglib bug: https://github.com/taglib/taglib/issues/635

[Daniel Schürmann (daschuer)]

Got an answere!

We see here a bug that is already fixed upstream in taglib.
https://github.com/taglib/taglib/pull/309

@rryan: Can you give an update. You have cherry picked the fix into our buildserver repro. But the code is gone.
Is it time to Include Taglib into the Mixxx source tree or schould we provide a ppa containing the patched version?

[Ilya Kotov (forkotov02)]

PPA with taglib from git: https://launchpad.net/~forkotov02/+archive/ubuntu/ppa

See my bugreport https://bugs.launchpad.net/ubuntu/+source/taglib/+bug/1353988

[Daniel Schürmann (daschuer)]

Cool Thank you for the info.

I think this is the best solution for the Mixxx PPA, just adding our own taglib deb.

@Ilya: do you use any special scrips or such to setup the ppa version. Is there something we can re-use?

@rryan: @nschloe: Can I help you to make it happen?

[Owen Williams (ywwg)]

we have upgraded the version of taglib to be included with mixxx, maybe this bug has gone away in recent builds?

[Daniel Schürmann (daschuer)]

It will be gone for Mac and Windows, but it persists on Linux.
We need to advance the requirement to Taglib 1.10 and provide it along with Mixxx

[Daniel Schürmann (daschuer)]

@Owen @RJ
It would be nice to know you opinion about fixing this issue for Linux.
Is advancing the requirement to taglib 1.10 a good idea?

[RJ Skerry-Ryan (rryan)]

It's hard to tell what the scope of this bug (and other TagLib 1.9 bugs we see) are in terms of users affected. So I'm not really able to determine a priority for whether I should spend time working on this. In general I'm not opposed if we have a strong reason to believe it's worth it. If someone can provide me a source package for TagLib 1.10 that supports Wily, Precise and Trusty -- I can push it to our PPAs.

I have a general concern about publishing other libraries to our PPA. I think most likely we'll push the library once and then forget about it (we still have a lost and forgotten portaudiov19 in our lp:mixxx/mixxx PPA from the one time we did this in the past!). What happens in this case? Is the user stuck on our old version when their distro offers a newer package?

[Daniel Schürmann (daschuer)]

You find the taglib source in the taglib repro on github.
If we reuse the Debian files from the system packages. A user will receive the taglib package from our ppa, as long as the default packages have not been updated.
If we provide mixxx along with a suitable taglib package. We have no maintained issue.
The main work will be signing an upload a source package.
I can do this, if I have access to our ppa.

[Sean M. Pappalardo (pegasus-renegadetech)]

@RJ: As long as the package naming convention is respected, the apt system will install the latest version of a given package regardless of which source supplies it. So in the case of an old PortAudio, people on the older version of the OS would have our PA version since it's named newer than what the OS supplies, but those that have upgraded will get the OS version since it's newer than ours. Again, package version numbering is critical to this working correctly. (https://www.debian.org/doc/debian-policy/ch-controlfields.html#s-f-Version)

[RJ Skerry-Ryan (rryan)]

> You find the taglib source in the taglib repro on github.

I don't see a Debian source package in their repository.

I'm asking for a Debian source package that I can sign with our Mixxx master key and dput to our PPA.

[Owen Williams (ywwg)]

I believe deb does the right thing and will not hold a user back on an old version of a library if a newer one is available from a different repo. I think we can recommend taglib 1.10, but I wouldn't require it. My first preference is to file a bug with the ubuntu packagers and ask them to update taglib rather than try to roll our own.

[Daniel Schürmann (daschuer)]

Yes, we can ask them, since the serious falc crasher will effect almost all other media applications.
I experienced taglib related crasher in clementine and rhythembox as well, but they are less annoying there because of the caranteine process they use.

I am only afraid that this discussion my delay our release. So putting taglib 1.10 in out ppa in the meantime is my preferred solution.

I would really prefer to require taglib 1.10. It will be rely no fun to being blamed for 1.9 crashes in upcoming press reviews. This will also equalize the situation for all our target.

[Daniel Schürmann (daschuer)]

@rryan:
I have build a trusty taglib deb here:
https://launchpad.net/~daschuer/+archive/ubuntu/mixxx/+packages

[Daniel Schürmann (daschuer)]

The Taglib binary was successfully tested on Ubuntu Precise and Trusty

[Daniel Schürmann (daschuer)]

Here is an example how other apps handle this:
https://launchpad.net/~forkotov02/+archive/ubuntu/ppa
The provide also opus for Precise.

I think we should do the same. Any thoughts?

[Owen Williams (ywwg)]

Daniel you've committed a change that requires taglib >=1.10 even in old versions of ubuntu, do you even know if old versions of ubuntu have access to that version?

[Daniel Schürmann (daschuer)]

I have don this by accident, but it is not bad at all. See my comments here:
https://github.com/mixxxdj/mixxx/commit/7858be0e938e79c64ac1aa203c00920203a00a88

[RJ Skerry-Ryan (rryan)]

Thanks for the package Daniel, hopefully I did this right:

https://launchpad.net/~mixxx/+archive/ubuntu/mixxxbetas/+packages

I uploaded it for Precise. Does it need to be explicitly uploaded for Trusty/Vivid/Wily/Xenial?

[Daniel Schürmann (daschuer)]

I would say yes, however the must be a chance to get around it.
The Precise package will work on all version but I have not managed, to auto-update it.
Is the a way to make a package without a target version?

[RJ Skerry-Ryan (rryan)]

Received confirmation from a forum user that the PPA automatically upgraded their taglib package to 1.10.

Our mixxx/mixxx and mixxx/mixxxbetas PPA has the taglib 1.10 package.

[Daniel Schürmann (daschuer)]

Sorry, I cannot confirm.
My Trusty installation does not receive the Precise 1.10 libtag package.
We need to provide it for every single edition.

[Daniel Schürmann (daschuer)]

This issue is still pending!
@rryan would you mind to upload the taglib version for the other Ubuntu versions as well?
Otherwise all users of a recent Ubuntu will still suffer this bug.

Thank you.

[Daniel Schürmann (daschuer)]

Alternatively, I can do it, once I have write access ;-)
Since this can be a party stopper, we should not delay a solution too long.

[RJ Skerry-Ryan (rryan)]

Trusty, Utopic, Vivid, and Wily are up now

[Daniel Schürmann (daschuer)]

Confirmed

[Swiftb0y (swiftb0y)]

Mixxx now uses GitHub for bug tracking. This bug has been migrated to:
https://github.com/mixxxdj/mixxx/issues/7811