Bug 214024

Created attachment 38237 [details]
"amarok -m -d --nofork" &> amarok_debug_d.txt

Is this still valid with current Amarok 2.2.1?

Yes. 

I upgraded a fedora 11 to KDE 4.3.3 and Amarok 2.2.1  this morning, and got this bug. Didn't have any problems with KDE 4.3.2 / Amarok 2.2.0.

I'm using rpms from http://apt.kde-redhat.org/apt/kde-redhat/fedora/mirrors-unstable

Created attachment 38308 [details]
Crash report. Fedora 11, KDE 4.3.3, Amarok 2.2.1

Sorry, Andreas, but what you attached is not a debug output, it's the konsole output when starting Amarok. You could have removed the 10.000 identical lines at the end...

Also I presume you are not the same person as the original reporter :)

Here is the relevant part:

amarok:   BEGIN: void ScanResultProcessor::processDirectory(const QList<QMap<QString, QVariant> >&) 
amarok:     BEGIN: void ScanResultProcessor::setupDatabase() 
amarok:     END__: void ScanResultProcessor::setupDatabase() - Took 4.2e-05s 
amarok:   END__: void ScanResultProcessor::processDirectory(const QList<QMap<QString, QVariant> >&) - Took 0.0042s 
amarok:   BEGIN: bool PlaylistManager::import(const QString&) 
amarok:     BEGIN: virtual bool PlaylistFileProvider::import(const KUrl&) 
amarok:        Importing playlist file  KUrl("") 
amarok:       BEGIN: void ProgressBar::setDescription(const QString&) 
amarok:       END__: void ProgressBar::setDescription(const QString&) - Took 8.6e-05s 
amarok:       BEGIN: void CompoundProgressBar::addProgressBar(ProgressBar*, QObject*) 
QObject::setParent: Cannot set parent, new parent is in a different thread
QObject::setParent: Cannot set parent, new parent is in a different thread

(In reply to comment #5)
> Sorry, Andreas, but what you attached is not a debug output, it's the konsole
> output when starting Amarok. 

Yes, with debug flag enabled. Ran it through gdb now according to description in the forum mentioned above, with asfar as I can tell identical output. I'm more than willing to supply whatever output you'd like.

> You could have removed the 10.000 identical lines
> at the end...

Of course. Sorry about that :-(

> 
> Also I presume you are not the same person as the original reporter :)

No, but since the bugs we're experiencing seems very similar (on closer look I realize they're not identical) it seemed a better idea to report in this already existing bug rather than creating a new, possibly superfluous, bug report.

/Anders
not Andreas, but you're excused since I know my name creates semantic confusion for you german speaking ;-)

(In reply to comment #2)
> Is this still valid with current Amarok 2.2.1?

I can't say. Because i didn't find a amarok 2.2.1 rpm for my opensuse 11.1.
I pulled the sources from git repository this morning.
~> git clone git://gitorious.org/amarok/amarok.git
~> cd amarok/build
~> cmake .. -DCMAKE_INSTALL_PREFIX=`kde4-config --prefix`
~> make (several warnings)
~> sudo make install

~> amarok -v
Qt: 4.5.3
KDE: 4.3.3 (KDE 4.3.3) "release 1"
Amarok: 2.2-GIT

Amarok ChangeLog
================
(C) 2002-2009 the Amarok authors.
VERSION 2.2.2

Created attachment 38317 [details]
"amarok -m -d --nofork" &> filename.txt

it's from amarok 2.2-git 14.09.2009

(In reply to comment #7)
> (In reply to comment #2)

Forget to write: the bug already exists.

Regards
rws

(In reply to comment #7)
> (In reply to comment #2)
> > Is this still valid with current Amarok 2.2.1?
> 
> I can't say. Because i didn't find a amarok 2.2.1 rpm for my opensuse 11.1.
> I pulled the sources from git repository this morning.
> ~> git clone git://gitorious.org/amarok/amarok.git
> ~> cd amarok/build
> ~> cmake .. -DCMAKE_INSTALL_PREFIX=`kde4-config --prefix`
sorry, but of cause i compiled with debug enabled
~> cmake .. -DCMAKE_INSTALL_PREFIX=`kde4-config --prefix` -DCMAKE_BUILD_TYPE=debugfull

Regards
rws

Since I can't reproduce this with current git, I wonder if this is not configuration specific.:
 *Do you guys use some specific scripts?
 *Did you both try removing your default settings (in $HOME/.kde/share/config/amarok*) and start with an empty database (located in $HOME/.kde/share/apps/amarok/, don't forget a backup before erasing)?

I've got the culprit. :-))

In /home/r006/.kde4/share/apps/amarok/current.xspf
i have had this title
    <track>
      <location>http://metafiles.gl-systemhaus.de/hr/hrinfo_1.asx</location>
      <identifier>http://metafiles.gl-systemhaus.de/hr/hrinfo_1.asx</identifier>
      <title>HR info</title>
      <creator>Hessischer Rundfunk</creator>
    </track>
After removing this entry. Voila.. amarok works fine again.
What do you think. Is the stream-type (.asx) the error?

thank you all for your patience.

BTW. 
after quiting amarok i see this lines on the console:
Object::disconnect: Unexpected null parameter
Object::disconnect: Unexpected null parameter
Object::disconnect: Unexpected null parameter
QCoreApplication::postEvent: Unexpected null receiver

Is this because i use git?

Regards
rws

Apparently the link for the podcast is not valid anymore, but this should not trigger a crash on startup.
I reopen this and subscribe our podcast specialist for more information.

After having completely removed my amarok configuration I can load one directory tree with music, but when I try to load my main collection I still get a segfault in the end. Will try some splitting it tomorrow to try to see where exactly the problem lies.
It seems as it's not a problem with amarok per se, but is somehow related to part of my music collection.

http://metafiles.gl-systemhaus.de/hr/hrinfo_1.asx is not a podcast, it's a stream. We don't support ASX files in recent versions (since 2.0).

The QObject warnings are just that, harmless warnings the causes of which we should fix at one time. I don't see any sign of a crash either.

Need more info: a way to reproduce or a stacktrace.

(In reply to comment #15)
> http://metafiles.gl-systemhaus.de/hr/hrinfo_1.asx is not a podcast, it's a
> stream. We don't support ASX files in recent versions (since 2.0).
> 
> The QObject warnings are just that, harmless warnings the causes of which we
> should fix at one time. I don't see any sign of a crash either.
> 
> Need more info: a way to reproduce or a stacktrace.

To reproduce the crash look at my post comment #12.
How can i do a stacktrace (backtrace with gdb gave "no stack". Look at the very first post).

Regards
rws

I too have found the culprit for my crashes. By using interval halving I finally found one single m3u playlist that always would result in an amarok crash if it was included in the collection file tree. Remove this file (which isn't used anyway) and the problem is gone.

Observations:

* The specific m3u has been part of my collection since late august and never before induced this type of crash. It only happened as I updated to 2.2.1 on a fedora machine last week.

* I use the same (mirrored) collection on two different computer configurations, AMD64 Debian Sid with UTF-8 character coding where I didn't experience any crashes when upgrading to 2.2.1, and an i386 Fedora 11 with iso 8859-1 (due to stubborn admins) which do crash.

I'll attach the m3u for reference if anyone wants to look at it. I guess it's some kind of character coding problem which isn't handled in a robust way.

Created attachment 38369 [details]
Problem causing playlist file

A playlist file causing crashes when included in collection on machine using iso 8859 coding. File was created on machine using utf-8

(In reply to comment #17)
> I too have found the culprit for my crashes. By using interval halving I
> finally found one single m3u playlist that always would result in an amarok
> crash if it was included in the collection file tree. Remove this file (which
> isn't used anyway) and the problem is gone.
> 
I can confirm this. It seems that the filename, not the contends makes amarok crashes at startup.

After downloading your attachment i got this file
Clarinet Concerto (Martin FrÃ.¶stâÂ.Â.).m3u.
in hex: 43 6C 61 72 69 6E 65 74 20 43 6F 6E 63 65 72 74 6F 20 28 4D 61 72 74 69 6E 20 46 72 C3 83 C2 B6 73 74 C3 A2 C2 80 C2 8E 29 2E 6D 33 75.

On my machine it helped to rename the filename (removing the strange characters, hex > 7F) to run amarok run properly.

Regards
rws

(In reply to comment #19)
> (In reply to comment #17)
> > I too have found the culprit for my crashes. 
> I can confirm this. It seems that the filename, 
> not the contends makes amarok
> crashes at startup.
> 
> After downloading your attachment i got this file
> Clarinet Concerto (Martin FrÃ.¶stâÂ.Â.).m3u.

should be
Clarinet Concerto (Martin Fröst).m3u
in UTF-8

> in hex: 43 6C 61 72 69 6E 65 74 20 43 6F 6E 63 65 72 74 6F 20 28 4D 61 72 74 69
> 6E 20 46 72 C3 83 C2 B6 73 74 C3 A2 C2 80 C2 8E 29 2E 6D 33 75.
> 
> On my machine it helped to rename the filename (removing the strange
> characters, hex > 7F) to run amarok run properly.

I think it's both. I tried renaming it clarinet.m3u and still got crashes, probably from broken filenames inside.


regards,
Anders

Bart, any news on this?

Same here - amarok crashes on a .m3u file starting from 2.2.1
2.2.0 is unaffected

(In reply to comment #22)
> Same here - amarok crashes on a .m3u file starting from 2.2.1
> 2.2.0 is unaffected

Well, then please give us a backtrace. We are still waiting for a usable backtrace, since this bug was opened. It's really pointless telling us that it crashes without giving that essential information.

Closing for lack of feedback.