Bug 1675

I use amarok with sqlite. I haven't seen any crashes here. I don't use dynamic playlist but I play all of my music from m3u playlists. I will try to test with dynamic random playlist.

For the past half-hour I have been playing a dynamic random playlist with no crashing. The playlist is auto-updating as well. Slackware 14, packages from git of Sept. 27.

(Odpověď na komentář #2)
> For the past half-hour I have been playing a dynamic random playlist with no
> crashing. The playlist is auto-updating as well. Slackware 14, packages from
> git of Sept. 27.

Do you have enabled setting Retrieve similar artists?
In ~/.trinity/share/config/amarokrc:

[Scrobbler]
RetrieveSimilarArtists=true

It is interesting that sometimes Amarok plays a long time without a crash. But with some songs crash immediately and repeatedly after the track starts.

I don't use scrobbling. My test was with all locally installed music files.

Perhaps then the crash is related to scrobbling?

(Odpověď na komentář #4)
> I don't use scrobbling. My test was with all locally installed music files.
> 
> Perhaps then the crash is related to scrobbling?

So far I have not examined the problem - similar artists is one of things that appear on the 'context tab'. Therefore, it may be related.

Note: Similar artists may be allowed even if the user not have a profile on last.fm. Checkbox in settings should be available, even if not specified last.fm profile informations.

Created attachment 1544 [details]
Fix availibility scrobbler services settings

The patch does not have a direct connection with this reported crash. Only again makes available settings that should be available always ... and which may be related to this reported crash.

In testing I'm in the console during the crash saw the following:

tdeio_http_debug: WARNING: (8298) closeCacheEntry: error renaming cache entry. (/var/tmp/tdecache-slavek.banko/http/s/ws.audioscrobbler.com_1.0_artist_Luca Turilli_similar.xml_2ece4af5.new -> /var/tmp/tdecache-slavek.banko/http/s/ws.audioscrobbler.com_1.0_artist_Luca Turilli_similar.xml_2ece4af5)
tdeio_http_debug: WARNING: (8298) closeCacheEntry: error closing cache entry. (/var/tmp/tdecache-slavek.banko/http/s/ws.audioscrobbler.com_1.0_artist_Luca Turilli_similar.xml_2ece4af5.new)
tdeio_http_debug: WARNING: (8303) closeCacheEntry: error renaming cache entry. (/var/tmp/tdecache-slavek.banko/http/s/ws.audioscrobbler.com_1.0_artist_Freedom Call_similar.xml_25642a12.new -> /var/tmp/tdecache-slavek.banko/http/s/ws.audioscrobbler.com_1.0_artist_Freedom Call_similar.xml_25642a12)
tdeio_http_debug: WARNING: (8303) closeCacheEntry: error closing cache entry. (/var/tmp/tdecache-slavek.banko/http/s/ws.audioscrobbler.com_1.0_artist_Freedom Call_similar.xml_25642a12.new)
[kcrash] TDECrash: Application 'amarokapp' crashing...
_artist_Freedom\ Call_similar.xml_25642a12 /ws.audioscrobbler.com_1.0_

It looks that it really can be associated with finding similar artists.

Comment on attachment 1544 [details]
Fix availibility scrobbler services settings

Pushed to GIT in hash 90583bb.

Created attachment 1548 [details]
Disable cross-thread event posting in scrobbler class

This looks like it is related to the threading changes in TQt3.  Try the attached patch and see if it fixes the problem.

Thanks!

Tim

Created attachment 1549 [details]
amarok crash with disabled cross-thread event posting

$ tdeio_http_debug: WARNING: (2528) closeCacheEntry: error renaming cache entry. (/var/tmp/tdecache-slavek.banko/http/s/ws.audioscrobbler.com_1.0_artist_Nick Cave & Die Haut_similar.xml_0e2c8574.new -> /var/tmp/tdecache-slavek.banko/http/s/ws.audioscrobbler.com_1.0_artist_Nick Cave & Die Haut_similar.xml_0e2c8574)
tdeio_http_debug: WARNING: (2528) closeCacheEntry: error closing cache entry. (/var/tmp/tdecache-slavek.banko/http/s/ws.audioscrobbler.com_1.0_artist_Nick Cave & Die Haut_similar.xml_0e2c8574.new)
[kcrash] TDECrash: Application 'amarokapp' crashing...

Interestingly, that report about cache was not related to the immediately preceding or following track.

Created attachment 1550 [details]
amarok crash with disabled cross-thread event posting (1)

further testing, further crash

$ [kcrash] TDECrash: Application 'amarokapp' crashing...
tdeio (TDEIOConnection): ERROR: Header read failed, errno=104
tdeio (TDEIOConnection): ERROR: Header has invalid size (-1)
tdeio (TDEIOConnection): ERROR: Could not write data

(In reply to comment #11)
> Created attachment 1550 [details]
> amarok crash with disabled cross-thread event posting (1)
> 
> further testing, further crash
> 
> $ [kcrash] TDECrash: Application 'amarokapp' crashing...
> tdeio (TDEIOConnection): ERROR: Header read failed, errno=104
> tdeio (TDEIOConnection): ERROR: Header has invalid size (-1)
> tdeio (TDEIOConnection): ERROR: Could not write data

OK, so in other words my patch did nothing. :-)

I still suspect cross-thread event posting to be the culprit, the only problem I have is narrowing down which class(es) are the culprit.

> tdeio (TDEIOConnection): ERROR: Header read failed, errno=104
> tdeio (TDEIOConnection): ERROR: Header has invalid size (-1)
> tdeio (TDEIOConnection): ERROR: Could not write data

Those messages were also reported in bug report 1655. Hopefully we kill two birds with one stone?

Created attachment 1558 [details]
Disable cross-thread event posting in all EngineObserver classes

I have not yet been able to replicate this crash on my development system.  The attached patch disables cross-thread event posting in all EngineObserver classes; can you see if it helps at all with the crashing?

Thanks!

Created attachment 1559 [details]
amarok crash with disabled cross-thread event posting in all EngineObserver classes

I'm sorry, but after some time of playing again occured the same crash.

Created attachment 1565 [details]
Disble cross-thread event posting in tdeio DataSlave class

Can you try the attached patch for tdelibs in addition to the earlier patch disabling cross-thread event posting in Amarok?  I am able to sporadically replicate two distinct crashes in Amarok, but need to know if this patch solves one of them on your system or not.

Thanks!

Created attachment 1566 [details]
Crash with disbled cross-thread event posting in tdeio DataSlave class

At first look, the crash is still the same.
Tested with patched Amarok and tdelibs.

OK, I will need a more reliable method of triggering the crash to resolve this issue.  Basically I need it to crash while running under Valgrind to know what is happening.

Can you try running amarokapp with valgrind to see if it will crash?  If it does, please post the valgrind output to this report.

(Odpověď na komentář #18)
> OK, I will need a more reliable method of triggering the crash to resolve this
> issue.  Basically I need it to crash while running under Valgrind to know what
> is happening.
> 
> Can you try running amarokapp with valgrind to see if it will crash?  If it
> does, please post the valgrind output to this report.

Valgrind with some extra parameters?

Created attachment 1567 [details]
amarok crash valgrind

(In reply to comment #20)
> Created attachment 1567 [details]
> amarok crash valgrind

Great!  Unfortunately this didn't reveal much about the origin of the threading failure, so I need the output of two other valgrind runs:
valgrind --track-origins=yes amarokapp &> valgrind1.log
valgrind --tool=drd amarokapp &> valgrind2.log

Fundamentally this crash is caused by the TDEIO job being deleted before all of the metadata has been retrieved; I just don't know *what* is deleting the object early.  Hopefully DRD will shed some light on this.

Thanks!

Tim

Created attachment 1568 [details]
amarok-valgrind1

It was difficult. Along with the already proposed patches crashes are less frequent. Combined with the memory consumption during run through valgrind and low power of testing machine ... but I succeeded - crash occurred :)

Created attachment 1569 [details]
amarok-valgrind2

Running with --tool=drd amarok only consumed cpu and memory, but did not open the GUI. After a while I stopped it.

I have traced this into the Amarok threading system; it appears that Amarok calls TDEIO:get() from the scrobbler, which executes in a secondary thread.  As the TDEIO slave objects execute in the main GUI thread, cross-thread event posting is triggered, setting up a deletion race condition and causing the crash.

I am working on a way to fix this.

This should (finally!) be fixed in GIT hash 69eb063.  The problem boiled down to a secondary thread (CollectionDB-related) directly calling the Scrobbler::similarArtists() method after the Scrobbler class instance had been created in the main GUI thread.  This violated the TQt/TDE threading rules and led to a situation where the Scrobbler class created TDEIO objects in the secondary thread, even though the Scrobbler class was part of the main thread.

This was hard to track down as the bug would only show up (sporadically!) on the first load of artist information from last.fm, therefore I ended up using a track for testing that had no artists match on last.fm, forcing a Scrobbler reload attempt each time it was played.

Incidentally, Amarok still uses its own thread manager, which might be the source of some of these unusual threading problems.  The TQt3 thread manager is more robust overall, and I would eventually like to see Amarok use it instead.  In this particular case, however, the crash would have occurred regardless of the thread manager in use.  The TQt3 cross-thread signal/slot mechanism allowed the easy fix mentioned above in GIT hash 69eb063. :-)

Let me know if this fixes the bug on your end for good...

Thanks!

Comment on attachment 1558 [details]
Disable cross-thread event posting in all EngineObserver classes

Not needed

Comment on attachment 1565 [details]
Disble cross-thread event posting in tdeio DataSlave class

Not needed

> Incidentally, Amarok still uses its own thread manager, which might be the
> source of some of these unusual threading problems.  The TQt3 thread manager
> is more robust overall, and I would eventually like to see Amarok use it
> instead.

Should we open a bug report to track that desire? Perhaps a generic report for other apps that might also have their own thread manager?

I am thoroughly tested Amarok all day (without music I just can not work :) ) and without any crash! A great result. Thank you Tim.

Since bug from this report is fixed, this bug report can be now closed. Task to replace thread management, should be as separate bug report.

(In reply to comment #28)
> > Incidentally, Amarok still uses its own thread manager, which might be the
> > source of some of these unusual threading problems.  The TQt3 thread manager
> > is more robust overall, and I would eventually like to see Amarok use it
> > instead.
> 
> Should we open a bug report to track that desire? Perhaps a generic report for
> other apps that might also have their own thread manager?

Yes, an enhancement request might be a good idea in case someone wants to hack on it. :-)

Done: bug report 1691.

(Odpověď na komentář #31)
> Done: bug report 1691.

By the way, if you skip the word "report",
bugzilla automatically converts bug 1691 into link.

Yeah, I know. :-) I'm a technical writer. Not my fault the bugzilla developers are grammatically incorrect. :-)