Bug 151733 - Amarok crashes when parsing WMA tags
Summary: Amarok crashes when parsing WMA tags
Status: RESOLVED FIXED
Alias: None
Product: amarok
Classification: Applications
Component: general (show other bugs)
Version: 1.4.7
Platform: Fedora RPMs Linux
: NOR crash
Target Milestone: ---
Assignee: Amarok Developers
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2007-11-02 10:46 UTC by Julian Sikorski
Modified: 2007-11-29 11:45 UTC (History)
4 users (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Julian Sikorski 2007-11-02 10:46:55 UTC
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)
Comment 1 Dan Meltzer 2007-11-07 18:57:51 UTC
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?
Comment 2 Julian Sikorski 2007-11-08 15:30:54 UTC
Nothing unusual, the label is: Danny Bond vol. 34
Comment 3 Julian Sikorski 2007-11-12 21:58:51 UTC
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. 
Comment 4 Andy 2007-11-13 22:47:26 UTC
Yup, same here.  All WMA crash collection scanner!  The Fedora 7 rpm worked fine on the exact same files.
Comment 5 Julian Sikorski 2007-11-13 23:07:30 UTC
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?
Comment 6 Harald Sitter 2007-11-14 16:43:25 UTC
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).
Comment 7 Rex Dieter 2007-11-14 17:30:08 UTC
afaict, nothing in taglib svn refers to anything wma or mp4.  (A quick recursive grep for 'wma' or 'mp4' was empty). ??
Comment 8 Rex Dieter 2007-11-14 17:47:55 UTC
Or, are you perhaps refering to tunepimp plugins?
Comment 9 Harald Sitter 2007-11-14 18:17:58 UTC
Ok, that was really just wrong, taglib SVN doesn't include WMA. Still this is some weird issue with the fedora taglib. 
Comment 10 Rex Dieter 2007-11-14 21:00:53 UTC
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.
Comment 11 Rex Dieter 2007-11-14 21:53:49 UTC
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. :)
Comment 12 Rex Dieter 2007-11-14 21:54:41 UTC
time to start diffing taglib headers to see what changed.
Comment 13 Rex Dieter 2007-11-15 14:37:43 UTC
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?
Comment 14 Andy 2007-11-15 14:42:11 UTC
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.
Comment 15 Rex Dieter 2007-11-15 14:45:19 UTC
See my comment #11.  amarok built against stock taglib-1.4 is fine (which matches your finding that F7 version of amarok works).
Comment 16 Andy 2007-11-15 14:52:34 UTC
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.
Comment 17 Andy 2007-11-15 15:37:02 UTC
OK, forget tonight!

Built Taglib 1.4, then built Amarok SVN, no luck on the x64 system.  Same problem.
Comment 18 Andy 2007-11-18 21:51:23 UTC
Perhaps not only a 64bit issue, some on 32bit as well.

http://forums.fedoraforum.org/showthread.php?t=171684&page=1&pp=15
Comment 19 Scott Wheeler 2007-11-19 14:28:06 UTC
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.)
Comment 20 Scott Wheeler 2007-11-19 15:51:51 UTC
Adding Lucas to the CC since this seems to exist in his source tree as well.
Comment 21 Scott Wheeler 2007-11-19 15:59:28 UTC
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.)
Comment 22 Julian Sikorski 2007-11-21 14:50:16 UTC
For reference, update to the new Fedora taglib, namely taglib-1.5-0.6.20071111svn.fc8 does not help here.
Comment 23 Scott Wheeler 2007-11-29 04:53:55 UTC
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.
Comment 24 Jeff Mitchell 2007-11-29 09:27:23 UTC
Should be fixed as of stable branch r742872.  If it's not, please re-open.
Comment 25 Julian Sikorski 2007-11-29 11:45:33 UTC
Confirmed, latest subversion works.