Bug 138555 - call to kded can hang amarok indefinitely
Summary: call to kded can hang amarok indefinitely
Status: RESOLVED WORKSFORME
Alias: None
Product: amarok
Classification: Applications
Component: general (show other bugs)
Version: unspecified
Platform: Compiled Sources Linux
: NOR normal
Target Milestone: ---
Assignee: Amarok Developers
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2006-12-08 23:53 UTC by Erik Hovland
Modified: 2006-12-14 00:45 UTC (History)
0 users

See Also:
Latest Commit:
Version Fixed In:


Attachments
uses the timeout argument to DCOP::Client::call() (1.23 KB, patch)
2006-12-08 23:57 UTC, Erik Hovland
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Erik Hovland 2006-12-08 23:53:36 UTC
Version:           SVN trunk (using KDE Devel)
Installed from:    Compiled sources
Compiler:          gcc (GCC) 4.0.1 (4.0.1-5mdk for Mandriva Linux release 2006.0) 
OS:                Linux

On my Mandriva 2006.0 linux workstation I experienced a situation where amarok would hang indefinitely. I tracked the problem down to an issue with amarok attempting to communicate to kded through dcop. In amarok/src/devicemanager.cpp there is a line to DCOP::Client::call() which has no timeout specified. If kded is out to lunch, then amarok will hang indefinitely too. In my case there were several kded processes and none of them seem to be cooperating. I was able to fix the problem on my workstation by killing all of the kded, restarting hald and then logging back in (which brought up only one kded). But it would be nice of amarok was able to move on from this problem and report an issue with the dcop call.
Comment 1 Erik Hovland 2006-12-08 23:57:42 UTC
Created attachment 18857 [details]
uses the timeout argument to DCOP::Client::call()

Since kded can hang this DCOP::Client::call() I have augmented the code to use
the timeout argument. This will allow amarok to timeout and attempt to recover
from the failure of this call.
Comment 2 Erik Hovland 2006-12-14 00:45:23 UTC
I committed this patch to svn today.