Bug 306680 - Regression in libkactivities: caching disrupts communication between KWin and kactivitymanagerd
Summary: Regression in libkactivities: caching disrupts communication between KWin and...
Alias: None
Product: frameworks-kactivities
Classification: Unclassified
Component: general (show other bugs)
Version: unspecified
Platform: openSUSE RPMs Linux
: NOR normal
Target Milestone: ---
Assignee: Ivan Čukić
: 310850 (view as bug list)
Depends on:
Reported: 2012-09-12 14:46 UTC by Luca Beltrame
Modified: 2016-02-28 10:24 UTC (History)
4 users (show)

See Also:
Latest Commit:
Version Fixed In:

Plasma crash backtrace (5.25 KB, application/octet-stream)
2012-09-27 15:01 UTC, Hrvoje Senjan
activity settings (1.02 KB, application/octet-stream)
2012-12-16 17:11 UTC, Thomas Lübking
convenience script to manage activities (3.48 KB, text/plain)
2012-12-16 17:12 UTC, Thomas Lübking

Note You need to log in before you can comment on or make changes to this bug.
Description Luca Beltrame 2012-09-12 14:46:51 UTC
With recent (2 days old) git master, logging out and then back in will cause many features of activities to become non-functional. 
In detail:

- Stopped activities cannot be started again and switching to them does not work;
- It is not possible to associate applications to specific activities via KWin; the menu selection stays on "All activities" and no changes occur
- Starting stopped activities via DBus does not work.

The only solution to solve the problem is to clone the activities, but then the issue will reappear during the subsequent login/logout cycle.

Reproducible: Always

Steps to Reproduce:
1. Create activities using the Activity Manager
2. Logoff
3. Login
4. Stop one activity
5. Start the stopped activity or switch to it
Actual Results:  
The desktop is not switched to the correct activity (brief flicker of the screen does occur)

Expected Results:  
Activity is switched.

This happens on an openSUSE Factory machine, with kdebase-workspace and kactivities from 2 days ago.
Comment 1 Luca Beltrame 2012-09-12 14:49:48 UTC
A snippet from the debug output when clicking on an activity it doesn't open:

kactivitymanagerd(15938) Jobs::General::Call::start: >>> Calling the method "emitCurrentActivityChanged" with "1f0db545-22a7-40a6-b3aa-66c9d18b08c0"
kactivitymanagerd(15938) RankingsUpdateThread::run: This is the activity we want the results for: "1f0db545-22a7-40a6-b3aa-66c9d18b08c0"
kactivitymanagerd(15938) RankingsUpdateThread::run: "SELECT targettedResource, cachedScore FROM kext_ResourceScoreCache WHERE usedActivity = '1f0db545-22a7-40a6-b3aa-66c9d18b08c0' AND cachedScore > 0 ORDER BY cachedScore DESC LIMIT 30"
QFileSystemWatcher: failed to add paths: /home/einar/.kde4/share/config/activitymanager-pluginsrc
kactivitymanagerd(15938) Jobs::Schedulers::Abstract::Private::jobFinished: Job has finished with this result 0
kactivitymanagerd(15938) Jobs::Schedulers::Ordered::jobFinished: no error, no jobs
Comment 2 Luca Beltrame 2012-09-13 13:54:38 UTC
I did some more digging. The issue manifests itself when kwin is restarted. Also, if I create a new activity, KWin's activity context menu shows double the entries as normal. They are "back to normal" if KWin is restarted, but in that moment the problem manifests itself.
Comment 3 Luca Beltrame 2012-09-13 14:06:44 UTC
Further investigation shows that KActivities, before the KWin restart, reports duplicated activities. This happens with 3 running activities:

kwin(27514) KActivities::Consumer::listActivities: Returning the running activities ("301a9cf9-82e2-4ccb-b24b-c9facc6a4ef1", "42c47e52-2898-41af-8cc2-014347aabafc", "42c47e52-2898-41af-8cc2-014347aabafc", "f3d7acbe-f1d1-4b4f-968f-03cb4bc93d14", "f3d7acbe-f1d1-4b4f-968f-03cb4bc93d14")
Comment 4 Luca Beltrame 2012-09-15 13:48:55 UTC
I have to amend the d behavior: it's not that you can't switch to activities, rather than the stopped activity is started and then immediately stopped.
Comment 5 Luca Beltrame 2012-09-15 15:41:19 UTC
I did quite a lot of debugging and bisecting and I found the problematic commit:
f150230436ba950b18bb163bed80c508501e7936 in kactivities.

This is the commit that introduced caching for listing activities: if it is reverted, everything works as it should.

Investigation showed that if this commit is not reverted, allActivities_ in KWin's startActivity method (allActivities_ got from KActivities:Consumer:listActivities)  will only contain activities added during the session. If KWin is restarted, the list will be empty:

kwin(13498) KActivities::Consumer::listActivities: Returning listActivities ()

the check in startActivity (KWin side) will return false and nothing will be done.
Comment 6 Luca Beltrame 2012-09-15 16:03:44 UTC
It appears I messed up with git-bisect.... The real first bad commit is 74f0cbffc9c2be2f2108691876b6b312d6fe7561 in kactivities.
Comment 7 Luca Beltrame 2012-09-26 21:19:18 UTC
The more time passes the more I'm puzzled. Even with the offending commit removed, there's something else contributing to the issue because I need to rebuild kactivitymanagerd every time I update KDE from git, or the issue appears again.
Comment 8 Hrvoje Senjan 2012-09-27 15:01:02 UTC
Created attachment 74193 [details]
Plasma crash backtrace

I can reproduce the reported issue with the following:
Create new activity
Switch back to 'main' one
Restart kwin
Stop newly created activity
Try to start it --> can't be done, also, plasma crashes in the process
Comment 9 Luca Beltrame 2012-11-18 13:34:44 UTC
Fixed for a while, closing.
Comment 10 Thomas Lübking 2012-12-16 13:30:24 UTC
with kdelibs 4.10, kactivities master and kwin master i do still observe issues

1. activities but the default one are stopped and cannot be started (using dbus directly!) - no matter what (i tried to investigate on preserving window attachment across sessions)

2. we still get an undeduplicated list for at least the openactivities (at least for activities added after the re-login / kwin restart), see bug #310850

Assigning windows to running activities works, but if you got 

and "dummy #2" is actually "dummy #1", assigning a window to Default and dummy (#1) will oc. also asign it to dummy (#2) thus "ALL" activities.

From what i can say this bug essentially is very apparent and i could at bes workaround issue (2) but not (1) and that might actually be the more severe one (right now, i've got kwrite/sm.cpp on dummy & dummy2 (yeah, actual dummy2, not dummy #2 ;-) and no way to access it (unless i would of course know how to manipulate xproperties directly ;-)

Good part is that the session crossing attachment actually sees to work (bug body =)
Comment 11 Thomas Lübking 2012-12-16 13:30:38 UTC
gah, blast!
Comment 12 Thomas Lübking 2012-12-16 13:51:38 UTC
PS: the current activity "Default" is not member of the openActivities return list.
Comment 13 Ivan Čukić 2012-12-16 15:09:02 UTC
@Thomas You need to send me the config files for activities. I can not reproduce this issue.
Comment 14 Thomas Lübking 2012-12-16 17:11:15 UTC
Created attachment 75868 [details]
activity settings

It seems to affect activities with clients on (exclusively) them, but not being the active one - just a gut feeling atm, though.


238d4803-a10b-4279-9be2-c516b8d0c7b0 ("dummy2") : Stopped
abcd24bc-aa4d-4c7e-bb11-ae8c3ffb2dce ("Default") : Running
da2b49ef-5344-4d76-a3da-44c2bc0160c4 ("dummy") : Stopped

This does not change, no matter how often i try to start/stop/start an activity

The list of openactivities is count 1 for kwin unless i either
a) add an activity (running, shows up twice, but not present ones, iirc. not even if running)
b) restart kwin (clears the stage)
Comment 15 Thomas Lübking 2012-12-16 17:12:36 UTC
Created attachment 75869 [details]
convenience script to manage activities

managing scripts for more comfort - utilizing dbus and hashes directly does not change anything (the script does work ;-)
Comment 16 Thomas Lübking 2012-12-16 21:59:36 UTC
random guess: setActivityState is called during a pending dbus call or somehow else before addActivity adds it (and only checks for listActivities presence, while the state setter only checks the runningActivities presence?)
Comment 17 Thomas Lübking 2012-12-16 22:03:39 UTC

void ConsumerPrivate::setActivityState(const QString & activity, int state)
    if (!listActivities.contains(activity)) {
        qWarning("trying to alter state of unknown activity!!");
        return; // denied

fixes it (and i get the warning)
Comment 18 Thomas Lübking 2012-12-16 22:08:07 UTC
Next question (sorry) - what is the "nulluuid" supposed to be good for (it's currently not handled in kwin and i twice or thrice ran into it being the only activity windows being assigned to (ie. they were always hidden)

Either we treat it as "junk" in kwin (remove it from the list to add windows to) or as "ask me again later" hint?!
Comment 19 Thomas Lübking 2012-12-16 22:11:17 UTC
*** Bug 310850 has been marked as a duplicate of this bug. ***
Comment 20 Thomas Lübking 2012-12-17 19:32:45 UTC
Catching the dupes does not fix unstartable activations.
Can you reproduce that one?
Comment 21 Ivan Čukić 2012-12-18 08:40:53 UTC
nulluuid is for when the activity manager service is not running. So that clients don't need to handle special cases when they get an empty list of activities.

I can reproduce duplicates, will be fixed soon.

I can not reproduce the unable-to-start activiites. Will need more testing :/
Comment 22 Thomas Lübking 2012-12-31 18:39:30 UTC
Reopening as *cough* reminder, because yesterday evening i could not spot any fix.

Do 3. Jan 00:59:00 CET 2013      :  KDE SC 4.10 Tagging Freeze for Release Candidate 2
Comment 23 Ivan Čukić 2013-01-02 11:11:55 UTC
Git commit 9edd34f978627a94b6f5f0c6a88f6c00eec21cc5 by Ivan Čukić.
Committed on 02/01/2013 at 12:10.
Pushed by ivan into branch 'KDE/4.10'.

Ignores state changes for unknown activities

Patch by Thomas Luebking

M  +5    -0    src/lib/core/consumer.cpp

Comment 24 Ivan Čukić 2013-01-02 11:13:59 UTC
Thanks for the reminder - forgot to push the change ARGH