Version: 1.4.7 (using KDE KDE 3.5.8) Installed from: Fedora RPMs OS: Linux This bug was originally reported at Red Hat bugzilla under #346011, but since Aurelien seems to be busy, I am forwarding it here. The problem is that Amarok segfaults when trying to parse WMA tags, which work perfectly fine under Windows. I have the following packages installed: amarok-1.4.7-7.fc8.x86_64 taglib-1.5-0.5.20070924svn.fc8.x86_64 I have installed more debuginfo packages, so here goes the more complete backtrace: Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 1136695632 (LWP 6999)] String (this=0x43c07e10, s=@0x12ce2f8) at /usr/src/debug/taglib/taglib/toolkit/taglib.h:68 68 void ref() { refCount++; } (gdb) bt #0 String (this=0x43c07e10, s=@0x12ce2f8) at /usr/src/debug/taglib/taglib/toolkit/taglib.h:68 #1 0x000000340d5137f1 in TagLib::WMA::Attribute::toString ( this=<value optimized out>) at wmaattribute.cpp:128 #2 0x000000340d51279c in TagLib::WMA::Tag::album (this=0x1221480) at wmatag.cpp:65 #3 0x000000340d36150c in MetaBundle::readTags (this=0x43c08830, readStyle=<value optimized out>, images=0x0) at metabundle.cpp:516 #4 0x000000340d363247 in MetaBundle (this=0x43c08830, url=@0x43c08b70, noCache=false, readStyle=TagLib::AudioProperties::Fast, images=0x0) at metabundle.cpp:234 #5 0x000000340d26d0a7 in CollectionDB::bundlesByUrls (this=0x340d878240, urls=@0x43c08e70) at collectiondb.cpp:3550 #6 0x000000340d40ee00 in UrlLoader::doJob (this=0x121a920) at playlistloader.cpp:222 #7 0x000000340d483cd5 in ThreadManager::Thread::run (this=0xc043f0) at threadmanager.cpp:302 #8 0x000000373a4fb915 in QThreadInstance::start (_arg=0xc07f08) at kernel/qthread_unix.cpp:119 #9 0x0000003287a06407 in start_thread () from /lib64/libpthread.so.0 #10 0x0000003286ed4b0d in clone () from /lib64/libc.so.6 (gdb)
Hi, The line it crashes on is: return d->attributeMap["WM/AlbumTitle"].toString(); When it tries to convert the value of AlbumTitle to a string. What is the title of the album for a song it crashes on?
Nothing unusual, the label is: Danny Bond vol. 34
The collection scanner fails on all WMA files, including those that have worked before. What is more, adding some of them to playlist crashes amarok completely, while some others only bring up mutt. I suspect that code in amarok responsible for WMA is incompatible with taglib snapshot.
Yup, same here. All WMA crash collection scanner! The Fedora 7 rpm worked fine on the exact same files.
Would it be possible to merge the WMA code into taglib to possibly avoid such problems in the future? Or is the maintainer reluctant to do that?
As far as we know, it already got into taglib's SVN. Now, fedora8 ships a SVN snapshot of taglib (taglib-1.5-0.5.20070924svn.fc8.src.rpm) therefore we suspect a symbol collision (as theoretically there are 2 WMA plugins on fedora now). So please tell the Amarok maintainer to remove all of our taglib plugins (wma and mp4 IIRC).
afaict, nothing in taglib svn refers to anything wma or mp4. (A quick recursive grep for 'wma' or 'mp4' was empty). ??
Or, are you perhaps refering to tunepimp plugins?
Ok, that was really just wrong, taglib SVN doesn't include WMA. Still this is some weird issue with the fedora taglib.
Mind if we keep this open, at least for awhile, until we have a better handle on what exactly is going wrong and where? I'll continue my debugging efforts.
OK, here's the scoop: 1. amarok built against stock taglib-1.4 works as advertised. 2. amarok built against svn checkout of trunk/kdesupport/taglib fails as described here. amarok built from 1. continues to function after taglib is upgraded to 2. what's all that mean? not sure yet exactly. :)
time to start diffing taglib headers to see what changed.
Cc'ing Scott Wheeler. Scott, do you have any insight to help here? Or did we just f***-up messing with trying to use taglib svn atm?
Moving some comments from the mailing list to here: Rex, if I run the Sept 28 build of Amarok (was an F7 version) with the Fedora 8 taglib everything works fine. Would seem to point towards Amarok not Taglib. Also i386 F8 and taglib work as normal. Appears to be a problem with the x64 stuff.
See my comment #11. amarok built against stock taglib-1.4 is fine (which matches your finding that F7 version of amarok works).
Possible I did this: Built Amarok SVN -Crash Build Taglib SVN -Amarok still crash Installed F7 Taglib 1.4 -Amarok still crash Reinstalled F8 rpm Installed Sept 28 Amarok -Everything Works! Perhaps I should have: Built Taglib 1.4, then built Amarok. The key being building Amarok after the installation of taglib 1.4. I'll try it tonight on x64 and report back.
OK, forget tonight! Built Taglib 1.4, then built Amarok SVN, no luck on the x64 system. Same problem.
Perhaps not only a 64bit issue, some on 32bit as well. http://forums.fedoraforum.org/showthread.php?t=171684&page=1&pp=15
My guess after looking a little at the amarok code in SVN is that the problem is that WMA code is using its WMA::Attribute class in a map, where it will be used as a value type, but it's creating its private storage class with new / delete and doesn't have appropriate assignment operator / copy constructor stuff to make sure that said pointer stays valid. (The code there is certainly wrong, whether it's the particular wrong that leads to the crash isn't clear.)
Adding Lucas to the CC since this seems to exist in his source tree as well.
Oops -- I was looking at the wrong web-svn. It seems the current implementation is here: http://codebrowse.launchpad.net/~taglib-developers/taglib/taglib.ext/files/lalinsky%40gmail.com-20071012144334-hn5ljxpxz19rrn68?file_id=asf-20070204095823-f7vw175lbc96valm-1 And from looking it does not have the same problem. (I haven't compiled any of thementioned code.)
For reference, update to the new Fedora taglib, namely taglib-1.5-0.6.20071111svn.fc8 does not help here.
Just to be clear on my comment above -- the "wrong web-svn" means "it is fixed in Lucas's tree, but the fixed version is not in Amarok's svn". I don't expect this has anything to do with the TagLib version; what might make a difference as to whether the crash shows up or not is the STL version that it's compiled against.
Should be fixed as of stable branch r742872. If it's not, please re-open.
Confirmed, latest subversion works.