Bug 314575

I only can reproduce it with large folders (e.g. /usr/lib64)
Seems to be kactivities-related:

(gdb) bt
#0  0x00007fbdc7f3fad3 in __GI___poll (fds=<optimized out>, nfds=<optimized out>, timeout=<optimized out>) at ../sysdeps/unix/sysv/linux/poll.c:87
#1  0x00007fbdc45e0320 in socket_do_iteration (transport=0x1473880, flags=6, timeout_milliseconds=<optimized out>) at /var/tmp/paludis/sys-apps-dbus-1.6.8-r1/work/dbus-1.6.8/dbus/dbus-transport-socket.c:1125
#2  0x00007fbdc45df1fd in _dbus_transport_do_iteration (transport=0x1473880, flags=<optimized out>, timeout_milliseconds=<optimized out>)
    at /var/tmp/paludis/sys-apps-dbus-1.6.8-r1/work/dbus-1.6.8/dbus/dbus-transport.c:976
#3  0x00007fbdc45cde45 in _dbus_connection_do_iteration_unlocked (connection=0x1473d10, pending=<optimized out>, flags=6, timeout_milliseconds=25000)
    at /var/tmp/paludis/sys-apps-dbus-1.6.8-r1/work/dbus-1.6.8/dbus/dbus-connection.c:1234
#4  0x00007fbdc45ced0f in _dbus_connection_block_pending_call (pending=0x2b1fc90) at /var/tmp/paludis/sys-apps-dbus-1.6.8-r1/work/dbus-1.6.8/dbus/dbus-connection.c:2415
#5  0x00007fbdc6825bf7 in q_dbus_pending_call_block (pending=<optimized out>) at qdbus_symbols_p.h:309
#6  QDBusConnectionPrivate::waitForFinished (this=0x146d180, pcall=0x2b1bfa0) at qdbusintegrator.cpp:1781
#7  0x00007fbdc6865c67 in QDBusPendingCallPrivate::waitForFinished (this=0x2b1bfa0) at qdbuspendingcall.cpp:245
#8  0x00007fbdbc1867c0 in operator= (pcall=..., this=0x7fffa430f0a0) at /usr/include/qt4/QtDBus/qdbusreply.h:88
#9  QDBusReply (reply=..., this=0x7fffa430f0a0) at /usr/include/qt4/QtDBus/qdbusreply.h:93
#10 KActivities::Consumer::isResourceLinkedToActivity (this=<optimized out>, uri=..., activityId=...) at /var/tmp/paludis/kde-base-kactivities-4.10.0/work/kactivities-4.10.0/src/lib/core/consumer.cpp:195
#11 0x00007fbdba9ea4fa in FileItemLinkingPlugin::actions (this=0x2b26d30, fileItemInfos=..., parentWidget=<optimized out>)
    at /var/tmp/paludis/kde-base-kactivities-4.10.0/work/kactivities-4.10.0/src/workspace/fileitemplugin/FileItemLinkingPlugin.cpp:121
#12 0x00007fbdbc5f92db in DolphinContextMenu::addFileItemPluginActions (this=0x2a32be0) at /var/tmp/paludis/kde-base-dolphin-4.10.0/work/dolphin-4.10.0/dolphin/src/dolphincontextmenu.cpp:500
#13 0x00007fbdbc5f9bad in DolphinContextMenu::openItemContextMenu (this=0x2a32be0) at /var/tmp/paludis/kde-base-dolphin-4.10.0/work/dolphin-4.10.0/dolphin/src/dolphincontextmenu.cpp:277

Nepomuk is spiking up to 100-150% CPU.

Created attachment 76963 [details]
kactivitymanger bt

Ooops... after closing gdb (was on nepomukservicestub - if you are interested in the bt just tell me, it's saved ;)) kactivitymanagerd instantly crashed.

In order to workaround this issue open dolphin settings, go to "Services" and disable "File to activity linking plugin".

I just had a look what kind of queries could there be that nepomuk/kactivitymangerd spiked up - and it's none. The "Activities" submenu only lists available activities and offers the ability to link a file to. I just did that with one single file, go to the activities submenu, again - and it still offers only the option to add this file, I expected to be able to remove it (that would have been an answer to the high CPU usage - determining if the file already is linked to an activity).
And why nepomuk? I thought those activities-related stuff was NOT stored there but in a small sqlite-db.

I already have run nepomuklcleaner twice - once after updating to RC3, once after the update to the final 4.10.0.

Thanks for the bug report and for the analysis, Franz! I can't say much about this issue - forwarding to the Activities/Nepomuk people.

For the time being I'm putting this down to a failed nvidia driver update that put me back on nouveau and I hadn't noticed.
Dolphin seems fine now I have nvidia back properly

But I guess right click should have worked with nouveau.....

Created attachment 77239 [details]
activities sub-menu

I had the same problems - even with single files and don't have an NVidia GPU (using Intel graphics) so I doubt the dependency on nouveau

after upgrading from openSUSE KR410 to KDF, this problem got solved on one of my PCs (though with the same strange activities sub-menu), not on my netbook though - I'll check later whether deactivating the activities menu solves it

indeed de-activating the "File to activity linking plugin" solved the long delay for the popup for me

(In reply to comment #7)
> indeed de-activating the "File to activity linking plugin" solved the long
> delay for the popup for me

Indeed yes

*** Bug 316309 has been marked as a duplicate of this bug. ***

I can reproduce it with any file - right-clicking on it makes dolphin freeze for about 20 seconds, and only then the right-click menu appears. 

Here is what I get in console if I run dolphin from it (my comments in [] brackets):

[right-click]
dolphin(21786) KConfigGroup::readXdgListEntry: List entry MimeType in "/usr/share/kde4/services/ServiceMenus/del.icio.us.desktop" is not compliant with XDG standard (missing trailing semicolon). 
dolphin(21786) KActivities::ConsumerPrivate::ConsumerPrivate: We are checking whether the service is present true
dolphin(21786) KActivities::ConsumerPrivate::initializeCachedData: Locking mutex for currentActivity
dolphin(21786) KActivities::ConsumerPrivate::initializeCachedData: Locking mutex for listActivities
dolphin(21786) KActivities::ConsumerPrivate::initializeCachedData: Locking mutex for runningActivities
[all of the above appear immediatly after right-click, and here the 20 seconds pass; then the following lines (and the menu, finally) appear:]
dolphin(21786) KActivities::Consumer::isResourceLinkedToActivity: d-bus reply was invalid false QDBusError("org.freedesktop.DBus.Error.NoReply", "Did not receive a reply. Possible causes include: the remote application did not send a reply, the message bus security policy blocked the reply, the reply timeout expired, or the network connection was broken.")
dolphin(21786) KActivities::ConsumerPrivate::listActivitiesCallFinished: Unlocked mutex
dolphin(21786) waitForCallFinished: Trying to lock mutex
dolphin(21786) KActivities::Consumer::listActivities: Returning listActivities ()
dolphin(21786) KActivities::ConsumerPrivate::currentActivityCallFinished: Unlocked mutex
dolphin(21786) KActivities::ConsumerPrivate::runningActivitiesCallFinished: Unlocked mutex
[menu appears]

I am running Dolphin 4.10.1 (from ppa) on Kubuntu 12.04, i386 machine.

This bug has been haunting me sporadically, but only now it takes really long - 20 secs., for the menu to appear. It used to be below 10 secs. 

Disabling „File to activity linking plugin“ in Dolphin settings makes the problem go away.

I am marking the bug as confirmed by popular vote.

Since this causes intermittent freezes and hinders smooth work changing importance to major.
Still happens in KDE 4.10.2

*** Bug 305206 has been marked as a duplicate of this bug. ***

*** Bug 318202 has been marked as a duplicate of this bug. ***

Disabling „File to activity linking plugin“ in Dolphin settings makes the problem go away.

this solution work fine.

*** Bug 318697 has been marked as a duplicate of this bug. ***

*** Bug 318697 has been marked as a duplicate of this bug. ***

I am running into this problem as well on Kubuntu 12.04 with KDE 4.10.
Moreover, when right clicking on a window title bar, and moving the mouse over "Activities" in the menu, the window manager hangs for about a minute and I can't do anything.

@Ivan: To be honest, I'm not entirely sure if making synchronous D-Bus calls in a context menu plugin is a good idea. IMHO, all code that context menu plugins execute should be extremely fast and idiot proof. Even more so, if the plugin is installed and enabled for everyone who uses KDE.

What about the following idea: we could add a property "enabledByDefault" to KAbstractFileItemActionPlugin which defaults to true, but which is set to false by your plugin. This would make sure that

(a) everyone who consciously enables the plugin can use it, and
(b) nobody else has to suffer from this bug.

*** Bug 318935 has been marked as a duplicate of this bug. ***

*** Bug 318893 has been marked as a duplicate of this bug. ***

I have tried to remain calm and polite so far, but I must say that I'm getting rather annoyed by this issue now. The plugin interface is a great tool that gives a lot of power to developers who want to add functionality to the context menu. But with great power comes great responsibility. IMHO, plugin developers MUST make sure that they do not put the stability of the host application at risk.

But so far, I have not seen the slightest sign that anyone from Activities cares at all about this issue. The dirty bug triaging work still has to be done by myself and some other people who have nothing to do with the entire Activities business. And for this particular bug, the bug triaging is especially time-consuming and frustrating - you can't just tell users that it's the Activities plugin's fault and be done with it because moist people I talked to don't even realize that this plugin exists.

All the feedback that I got about the Activities plugin has been negative so far - some people even complained to me that the plugin is being shown in the context menu by default (needless to say, this is not Dolphin's fault at all). Some people wonder why "Activitites -> Link to Desktop" does not put a link to the right-clicked file to FolderView - and guess whom they ask for support? I'm starting to think that the D-Bus issue is not the only aspect of the plugin that is broken.

I have proposed a compromise that would at least save people who don't use the plugin from the consequences of this bug, but considering that there seems to be no interest whatsoever to resolve this issue, I will now explore other ways to stop the plugin from annoying people, making Dolphin look bad, and wasting everyone's time. I'll check if there is a good way to implement a Dolphin-internal blacklist of known broken plugins which will be banned from the context menu. I am convinced now that this plugin causes far more harm than good, and causing some inconvenience for people who actually like and use it is a price that I am willing to pay.

The problem is not dbus - it is the speed of communication with nepomuk.

1. If nepomuk is not functioning properly, then it iis broken even for just one selected file and for that I can not do anything.
2. If all is well, it seems that checking the isRelated property for every file is taking much too long.

I've been playing with various possible solutions for 4.11, but the only one that didn't have /any/ downsides is to create a threshold above which the plugin will not check whether the files are already linked or not.

As for 'it doesn't show on Desktop' - it should if the user has a folderview showing the linked files, and not the Desktop / Home folder.

p.s. I tried to make a /loading.../ indicator, and to async load the list, but (1) it didn't work (2) it would still be slow

Thanks Ivan, I appreciate that you finally show some interest in this issue. However, you still haven't commented on my proposal (comment 18) yet.

(In reply to comment #22)
> The problem is not dbus - it is the speed of communication with nepomuk.

As I said earlier, a context menu plugin that communicates with anything via D-Bus (or that does anything else that is not guaranteed to succeed very, very fast) is broken by design IMHO, so the problem is definitely your use of D-Bus from my point of view.

> As for 'it doesn't show on Desktop' - it should if the user has a folderview
> showing the linked files, and not the Desktop / Home folder.

When some users see "Link to Desktop", they think that a symbolic link is created on their desktop. Not everyone is familiar with the "Activities" concept.

Comment 18 is not really a solution - I do like it from my perspective (some freedom to break things without anyone noticing) but if we make it disabled by default, this bug would never be discovered. 

Hmh, maybe having it disabled in the final releases, and enabled in the betas/rcs would be good?

What would be your proposal regarding skipping dbus? The plugin needs to check the data in nepomuk so not to show both link-to and unlink-from for each file.

> Link to Desktop

I do understand, but that problem is (imo) two-fold

(1) A problem of the default activity name. Activities should be user's tasks/projects/etc - nobody's task is 'a desktop'. I've even seen people wondering why would anyone put a string 'Desktop' on the desktop like they didn't know what it is. This should be a separate bug report.

(2) The problem of the default plasma-desktop setup that does not show the activity linked files like pllasma-active does.

I'll start a discussion on the plasma-devel regarding this.

(In reply to comment #25)
> but if we make it disabled by default, this bug would never be discovered. 

So you are saying that it's not enough if the people who use Activities and enable the plugin discover this bug? You want that people who don't care about Activities at all continue to submit Dolphin bug reports about this issue, and that I and some other people deal with the mess?

I will not comment on this attitude, I might say something that I would regret later on.

> Hmh, maybe having it disabled in the final releases, and enabled in the
> betas/rcs would be good?

No. Even if we disregard the fact that changing settings between beta/RC and stable releases is a bad idea (for example, because testers might not like it that installing betas changes their system in subtle ways), I am fed up with doing bug triage and user support for you.

> What would be your proposal regarding skipping dbus? The plugin needs to
> check the data in nepomuk so not to show both link-to and unlink-from for
> each file.

Skipping D-Bus might not be possible with the current design, this is why I proposed the compromise solution at all. Alternatively, you could just open a dialog when the context menu action is clicked and contact the server only *after* the user decided to interact with Activities.

> So you are saying that it's not enough if the people who use Activities and
> enable the plugin discover this bug?

If the discoverability of the plugin is not the issue, then this would work. If not, there will be no users of the plugin, even if they do use activities.

Opening the dialog would be ugly, but if it would satisfy you, it will be done.

(In reply to comment #27)
> > So you are saying that it's not enough if the people who use Activities and
> > enable the plugin discover this bug?
> 
> If the discoverability of the plugin is not the issue, then this would work.
> If not, there will be no users of the plugin, even if they do use activities.

Advertising the plugin and its benefits in a blog post is simple enough, and probably much more effective than just showing it in the context menu for everyone. For example, I never really look at the actions which are shown in the default context menu here. I just had a look - there are some actions that I never used nor noticed at all.

Any further objections to the "not shown by default" approach? If not, I'll try to come up with a patch and submit the proposal to kde-core-devel during the next 2 weeks.

> Any further objections to the "not shown by default" approach?

No other objections.

I'll also start moving everything into a dialogue if I don't find a more optimised and user-friendly solution

Remove subscriber per their request.

Git commit e87f922096e7c1a571a6ee7ed20599210559ad4d by Frank Reininghaus.
Committed on 29/05/2013 at 07:41.
Pushed by freininghaus into branch 'master'.

Do not enable the Activities context menu plugin by default

This is not really a fix for bug 314575, but at least it prevents that
users who do not enable the plugin explicitly suffer from it.

FIXED-IN: 4.11.0

M  +1    -0    src/workspace/fileitemplugin/FileItemLinkingPlugin.cpp

http://commits.kde.org/kactivities/e87f922096e7c1a571a6ee7ed20599210559ad4d

Fixed. The plugin no longer freezes dolphin.

Commit:
http://quickgit.kde.org/?p=kactivities.git&a=commit&h=055328b1ec9852f1b516a8d2bf0a80de00f327e1

*** Bug 320493 has been marked as a duplicate of this bug. ***

I feel like the solution has merely hidden the root issue. See comment 17, for example. I've submitted a new bug to address this aspect of it: https://bugs.kde.org/show_bug.cgi?id=322406