Same behaviour on Mandriva 32 bit 2010.1

Same behaviour on Mandriva 64 bit 2010.1

Same behaviour on Arch Linux 64 bit (KDE 4.5.0)

Why my post isn't posted?

Same behavior on PCLinuxOS (I'd test for this in Win XP, but KDE 4.5 hasn't been successfully built for Windows yet).  
I'm not sure how it decides to create the new activities.  Most of the time it's created blank activities (named 'unnamed', with ethais background and no widgets), but I have had it duplicate my other activities as well.

I will add one observation to the aforementioned. I'm running Mandriva 2010.1 and had installed KDE 4.5.0 from kde repositories specific to the OS. I have since had to reinstall the system because after a complete removal of all kde and qt fro the system and reverting the 4.4.3 the system was still unusable, locking hard every 20 min or so.

I saw the desktops reverting to wrong settings etc, and I tried running 8 workspaces on one activity, and running one 'desktop' each in eight activities.

Either way, I saw a proliferation of activities between log ins. At one point, after having started with one activity, I began deleting a slew of them that had spawned themselves. I counted up to 48 I had deleted before the system locked hard. It appeared I was nowhere near the end of them from the looks of it.

This occurred under a totally new user as well so it is not a matter of an old settings incompatibility.

Also at one point when there were a mere 26 activities I noticed the ones that were "on" were random. 8 of them were on as I had originally set, but they were (for instance) activities 1, 9, 13, 15, 18, 19, 22 ans 24. The next log in I would have perhaps hundreds of activities and the random sequence of the 8 active would be different, although #1 was always one of the active ones.

I also get a lot of activities when right clicking on a window titlebar and selecting Activities. Most of them are "Unnamed", some "The name org.kde.ActivityManager was not provided by any .service files". I never used activities myself...
activitymanagerrc has 120+ (total 125 line).

I fixed it for me by deleting plasma settings: I deleted 
plasma-desktop-appletsrc and activitymanagerrc in my ~/.kde4/share/config/ folder.

(In reply to comment #8)
> I fixed it for me by deleting plasma settings: I deleted 
> plasma-desktop-appletsrc and activitymanagerrc in my ~/.kde4/share/config/
> folder.

This did not work for me. I deleted the entire ~/.kde4 folder and started with a default setup at least 3 times. It also occurred in a new user account I made for testing.

Does the problem persist in KDE 4.5.1?
I us

Does the problem persist in KDE 4.5.1?
I use Arch Linux 64bit.

The problem persists in KDE 4.5.1 (4:4.5.1-0ubuntu1~lucid1~ppa2).

Can we vote this into confirmed state to get some attention? I think 100 votes are necessary, which means only another 40 votes / 2 people.

*** This bug has been confirmed by popular vote. ***

I actually got the problem to go away.  I had to manually delete the extra activities in both plasma-desktop-appletsrc as well as what looked like cached versions of the activities in ~/.kde4/share/apps/plasma-desktop/activities/.  
I don't remember if I cleaned out that last directory before or after upgrading to 4.5.1, but I haven't seen the bad activities being created since.

voting isn't going to help get this any more attention. what will is a set of detailed steps for how to reproduce. e.g. a specific activitymanagerrc file, or a specific plasma-desktop-appletsrc (and/or plasma-desktoprc) file .. if you can confirm that it is a specific file that is producing it (e.g. stop plasma-desktop, move the file(s) away, start plasma-desktop, find the issue doesn't show up; stop plasma-desktop, move the file(s) back, start plasma-desktop, find the issue re-appears), then attach the files to the report.

the idea is to give the devs enough information to track down the problem, and the more accurate information you can give us, the better the chances are we will be able to fix it. and when we can fix it, then it gets attention.

Created attachment 51377 [details]
~/.kde4/share/config/{activitymanagerrc,plasma-desktop-appletsrc,plasma-desktoprc}

So far I have not found one machine where this behaviour does not appear. But in case someone posseses such a machine, I attach my configs.

P.S: The difference between comment #9 and comment #15 seems to be that Eric did not delete the *entire* file, but only a few lines in it. Maybe that's the key to happyness in this case.

@Dennis: did you perform the experiment i described in comment #16 before uploading these files?

(In reply to comment #19)
> @Dennis: did you perform the experiment i described in comment #16 before
> uploading these files?
I performed the experiment:
$ killall plasma-desktop
$ mv .kde4/share/config/activitymanagerrc .kde4/share/config/plasma-desktop-appletsrc .kde4/share/config/plasma-desktoprc activities.bkp/
$ plasma-desktop 

But immediately after executing plasma-desktop the broken activities are already back in the list. Hence I was not able to produce a case where the issue does not show up.

ok, so the files you uploaded are of no interest since they are not the cause of the bug you are seeing. thanks for the effort, though i did try and save us all unnecessary effort by noting that only if the experiment i outlined worked should one upload their files. :/

something else to try:

quit plasma-desktop (`kquitapp plasma-destop` is the preferred way), then open the "Service Manager" control panel and uncheck the "Activity Manager" entry; hit Apply and ensure that this worked by running "qdbus org.kde.kded /modules/activitymanager" in a konsole window. if it complains that there is no such object path, it has worked. then (re)move the activitymanagerrc file, re-check "Activity Manager" in the control panel, hit Apply again and start plasma-desktop.

(In reply to comment #21)
I did as you said:
---
kquitapp plasma-desktop
systemsettings -> System management -> Start and stop -> Service manager ...
qdbus org.kde.kded /modules/activitymanager
rm .kde/share/config/activitymanagerrc
systemsettings ...
qdbus org.kde.kded /modules/activitymanager
plasma-desktop
---

I checked the desktop right after starting plasma-desktop: The newspaper activity I had setup and was using before was still present and fully configured (i.e. location for wheather was set, etc). I opened the activity management thing and it displayed no activities. I tried to create one, but it did not show up in the (emtpy) list. I restarted KDE and was put to a blank activity. I check the activity manager and all the previous (junk) activities are back, including my own newspaper activity.

What I noticed after executing "plasma-desktop" on the console:
---
plasma-desktop(3544) KActivityConsumer::availableActivities: d-bus reply was invalid () QDBusError("org.freedesktop.DBus.Error.UnknownObject", "No such object path '/ActivityManager'")
plasma-desktop(3544) KActivityConsumer::currentActivity: d-bus reply was invalid "" QDBusError("org.freedesktop.DBus.Error.UnknownObject", "No such object path '/ActivityManager'")
---
The 2nd line is repeated *a lot*, first about 5 times and later again several times.

(In reply to comment #22)
P.S: Trying to create an activity after starting plasma-desktop after deleting the file has no influence on the junk activities being created.

ok, so the problem is somewhere in the activity manager, or in communication between plasma-desktop and the activity manager.

so... with the activity manager running, let's try this:

0) from a konsole, run: qdbus org.kde.ActivityManager /modules/activitymanager AvailableActivities
1) delete all unwanted activities first via plasma-desktop
2) again run:  qdbus org.kde.ActivityManager /modules/activitymanager AvailableActivities

the list in step #2 should be shorter than in step #0. if it isn't, then we can try removing them from the command line. but let's try first.

something else to try while we're in the testing mood:

from a konsole, do:

> activityUID=`qdbus org.kde.ActivityManager /modules/activitymanager AddActivity "Testing"`

we now have the id of the activity in activityUID, and we can see it with:

> echo $activityUID

if that doesn't have a value in it, or isn't something that looks like "dab6341f-5a90-4773-b9f3-a6f5bbeac0ca" then that call has failed and we can stop right there.

if it did succeed (and it should), then we can do:

> grep $activityUID `kde4-config --localprefix`/share/config/activitymanagerrc

this should give us a line that looks something like "dab6341f-5a90-4773-b9f3-a6f5bbeac0ca=Testing". if it doesn't, something's wrong.

now let's remove it:

> qdbus org.kde.ActivityManager /modules/activitymanager RemoveActivity $activityUID

this will return silently (no output). now, we re-grep:

> grep $activityUID `kde4-config --localprefix`/share/config/activitymanagerrc

and this time there should be no output (it having been removed from the file)

(In reply to comment #24)
After deleting 5 activities the list is reduced by 5, from 18 to 13.
(In reply to comment #25)
This test succeeds. The activity is added and then removed.

Wild guess: Could it be that on KDE start something tries to "repair" the activities by restoring them from some location?

(In reply to comment #26)
> Wild guess: Could it be that on KDE start something tries to "repair" the
> activities by restoring them from some location?

.kde/share/apps/plasma-desktop/activities/, which someone mentioned before, lists 50 activities. I ran the proceedure mentioned in comment #21 / 22 again, extended by also deleting the contents of this folder. After restarting the activitymanager and plasma-desktop the folder stayed empty. It was still empty after restarting KDE several times. However, the activity list and activitymanager still list 18 activities (again, after deleting 5 of them in comment #26).

To elaborate on what I did when I discovered the activities being cached in .kde/share/apps/plasma-desktop/activities/:
After discovering the various junk activities (and deleting them using the activity manager), I logged out of KDE, opened plasma-desktop-appletsrc, identified all of the containments that I had set up and deleted all of the ones that I hadn't.  I noted that the largest ID for any of the containments was around 105.  I logged back into KDE and found still more activities.  Inspecting plasma-desktop-appletsrc, I found that the new junk activities had IDs above 105, meaning that they were being generated from some other source.  I then did some grepping and found the activity definitions in .kde/share/apps/plasma-desktop/activities/ with one file (the name being some hash or unique ID) for each activity, the contents matching what was in plasma-desktop-appletsrc.  I then logged out of KDE, deleted the files in that directory and removed the offending definitions in plasma-desktop-appletsrc.  I haven't seen any junk activities since (I don't think the upgrade to 4.5.1 made any difference).

.kde/share/apps/plasma-desktop/activities/ seems to be a red-herring. i also had a bunch of stale files in there and they were not causing any problem. plasma-desktop does not reference that directory for any listings anywhere in its code, either.

on the positive side of looking into it, i fixed plasma-desktop so it does remove those files as well when the activity is destroyed. yes, including backporting it to the 4.5 branch :)

but we still haven't found the conditions for this issue.

@Dennis Schridde: thank you for performing those tests. so we know that the process is working in activitymanager. 

let's move on to the next possibilities then! from a konsole, do:

qdbus org.kde.ActivityManager /modules/activitymanager AvailableActivities | wc -l

now remove an activity using the Activity Manager UI in plasma-desktop. then repeat the above command and the number that it returns should be one less than on the first run.

if that works, then we know it isn't in plasma-desktop and its communication with activitymanager.

if the numbers are equal, however, then we've found the source of the problem.

assuming this succeeds, let's try one more thing for fun:

open up the Desktop Search (nepomuk) control panel in System Settings. disable the Nepomuk system. check to make sure after doing this that no nepomuk process are running. stop plasma-desktop and start it again -> if the junk activities do not return this time, we've identified the source of the problem. to verify, turn Nepomuk back on and then do the plasma-desktop restart and if the junk comes back -> ta-da!

(In reply to comment #29)
> qdbus org.kde.ActivityManager /modules/activitymanager AvailableActivities
This works as expected, the number of activities is reduced from the original 8.

> disable the Nepomuk system.

I disabled the service as you said, however nepomukserver was still running, so I quit it:
$ kquitapp NepomukServer

I also quit Akonadi to prevent it from autostarting Nepomuk:
$ akonadictl stop

This didnt survive KDE restarts, nepomukserver was still being autostarted by Akonadi, so I deleted all Akonadi stuff:
$ akonadictl stop
$ rm -r .kde4/share/config/akonadi* .config/akonadi/ .local/share/akonadi/
$ akonadictl start
$ akonadiconsole -> delete Contact Feeder        

Finally Nepomuk was not starting anymore:  
$ ps aux | grep nepo
> shows only the grep line

Experiment begins:
$ kquitapp plasma-desktop
$ plasma-desktop  
# deleted all but one activity
$ qdbus org.kde.ActivityManager /modules/activitymanager AvailableActivities | wc -l
> 1
$ kquitapp plasma-desktop
$ qdbus org.kde.ActivityManager /modules/activitymanager AvailableActivities | wc -l
> 1
$ plasma-desktop
$ qdbus org.kde.ActivityManager /modules/activitymanager AvailableActivities | wc -l
> 9

So during my experiments (deleting all activities several times, restarting KDE once in between), the number of junk activities increased from 7 to 8 (1 activity is actually configured by me -> total of 8 activities before and 9 after the tests).

Under Session Management, do you have it set for KDE to Restore Previous Session or Start with an empty session?  I have mine set to start with an empty session, and deleting the activities in Activity Manager plus clearing out the cached files in .kde/share/apps/plasma-desktop/activities/ seems to have fixed the issue for me.

mike: I'm 99.9% certain session management isn't related to this bug.

dennis: are you using newspaper containments, or does this happen with desktop or folderview too?

this is kinda messed up... when plasma starts up, it must be deciding one of your containments doesn't really belong to any activity, and reassigning it to a new one - and then of course it has to create a new containment for the original activity once it realizes it does exist. o.0
doesn't make much sense really. I've never had this happen here.

it'd be nice to see the debug output from plasma as it starts up (boy I hope I left some debug statements in that code..)
...but, not compressed please! I've never seen a .tar.xz file before and Ark doesn't know how to open it :/

Created attachment 51748 [details]
startup log

(In reply to comment #32)
> dennis: are you using newspaper containments, or does this happen with desktop
> or folderview too?
Computer 1:
The real activity is a Desktop, all newly created ones are "unnamed" Search&Execute.
Computer 2:
Real is newspaper, "unnamed" new are Desktop. There is one named "Start" (I once had a S&E of that name) which also shows a newspaper, and one with that name being Desktop.

> it'd be nice to see the debug output from plasma as it starts up (boy I hope I
> left some debug statements in that code..)
Done

merf. nothing interesting in that output :/
could you start kdebugdialog, search for plasma, and make sure all boxes are checked? if you have to check any there then a new round of debug output could be useful :)

(In reply to comment #34)
> merf. nothing interesting in that output :/
> could you start kdebugdialog, search for plasma, and make sure all boxes are
> checked? if you have to check any there then a new round of debug output could
> be useful :)
Wow, that's a cool tool! :)
Plasma was already fully enable there, though.

But now I disabled everything. Hopefully that will prevent further disk-full problems with 10G of ~/.xsession-errors. :)

(In reply to comment #35)
> (In reply to comment #34)
> > merf. nothing interesting in that output :/
> > could you start kdebugdialog, search for plasma, and make sure all boxes are
> > checked? if you have to check any there then a new round of debug output could
> > be useful :)
> Wow, that's a cool tool! :)
> Plasma was already fully enable there, though.
P.S: kde-base/plasma-workspace has a mergetime of 6.5 minutes -> I'd be willing to test patches that produce more debug output on my Gentoo machine.

hey guys... do you have your desktop locked? have you deleted activities while it's locked?

'cause I just figured out how to reproduce :)

for now, unlock your desktop before deleting or stopping activities. I'll work on a fix this weekend. :)

FWIW I made sure I tried it both ways, locked and unlocked and it made no difference.

I even tried logging out with it locked and unlocked to see if that made a difference when logging back in. If it did I couldn't tell, both ways the activities proliferated. I never had any way of accurately counting how many there were.

cliff: well, if you're not sure... here's what I suggest:
1. unlock widgets
2. bring up the activitymanager, remove (that's stop *and* delete) every single unwanted activity (yes, I know it's tedious), so that they're down to a countable number
3. open a terminal, kquitapp plasma-desktop
4. after giving it a few seconds to finish quitting, run plasma-desktop again

if they really respawn after *that*, then send me your plasma-desktop-appletsrc and activitymanagerrc and the debug output from starting plasma-desktop.

SVN commit 1180338 by chani:

exportLayout function to go with importLayout
also, deprecated the old importLayout in favour of one that only accepts
kconfiggroup.
CCBUG: 248386


 M  +43 -5     corona.cpp  
 M  +22 -1     corona.h  


WebSVN link: http://websvn.kde.org/?view=rev&revision=1180338

SVN commit 1180339 by chani:

use the new exportLayout function

BUG: 248386

 M  +3 -16     activity.cpp  


WebSVN link: http://websvn.kde.org/?view=rev&revision=1180339

there we go, fixed in trunk. :)
aaron'll have a patch for 4.5 later - hmm, but 4.5.2 is being tagged today, so that'll likely be in 4.5.3

(In reply to comment #39)
> cliff: well, if you're not sure... here's what I suggest:
> 1. unlock widgets
> 2. bring up the activitymanager, remove (that's stop *and* delete) every single
> unwanted activity (yes, I know it's tedious), so that they're down to a
> countable number
> 3. open a terminal, kquitapp plasma-desktop
> 4. after giving it a few seconds to finish quitting, run plasma-desktop again
I tried that. It works remarkably well. :) All "unnamed" activities are and stay gone now. What's left is 5 activities named "Start". 4 of them seem to be empty newspapers, 1 is a newspaper with content. They always (re)appear at the end of the list, not also on the beginning like the "unnamed" ones did.

> if they really respawn after *that*, then send me your plasma-desktop-appletsrc
> and activitymanagerrc and the debug output from starting plasma-desktop.
Will do that, but do not have time before tomorrow. I'll also test this on the other computer then.

Created attachment 52109 [details]
e/share/config/{plasma-desktop-appletsrc,activitymanagerrc}

(In reply to comment #43)
> (In reply to comment #39)
> > cliff: well, if you're not sure... here's what I suggest:
> > 1. unlock widgets
> > 2. bring up the activitymanager, remove (that's stop *and* delete) every single
> > unwanted activity (yes, I know it's tedious), so that they're down to a
> > countable number
> > 3. open a terminal, kquitapp plasma-desktop
> > 4. after giving it a few seconds to finish quitting, run plasma-desktop again
> I tried that. It works remarkably well. :) All "unnamed" activities are and
> stay gone now. What's left is 5 activities named "Start". 4 of them seem to be
> empty newspapers, 1 is a newspaper with content. They always (re)appear at the
> end of the list, not also on the beginning like the "unnamed" ones did.
Correction: After a reboot the order of the activities is randomised again.
1) "Start" - Newspaper with content like my "News" activity, correct layout, but wrong contents of RSS plasmoid
2) "Start" - Empty newspaper
3) "Start" - S&E as I configured it
4) "Start" - Empty newspaper
5) "Start" - Empty newspaper
6) "News" - Newspaper as I configured, broken layout (Facebook plasmoid content is compressed to the size of a stamp and displayed outside of the container-widget), RSS plasmoid shows the correct feeds (none)
7) "Start" - Empty newspaper

Created attachment 52110 [details]
plasma-desktop debug / console output

(In reply to comment #44)
> 6) "News" - Newspaper as I configured, broken layout (Facebook plasmoid content
> is compressed to the size of a stamp and displayed outside of the
> container-widget), RSS plasmoid shows the correct feeds (none)
Sorry, this information is slightly wrong: I did not add the RSS plasmoid again after deleting all activities and adding the new ones (comment #43): There is no RSS plasmoid in the "News" activity.

that's very weird.
I can't open the attachment you posted, though... can you give me plasma-desktop-appletsrc, *uncompressed*?

Created attachment 52149 [details]
plasma-desktop-appletsrc

(In reply to comment #47)
> that's very weird.
> I can't open the attachment you posted, though...
You might have to install tar and gzip. I assumed they were part of the standard setup in all distros these days.

they are; Ark thinks it's corrupted and tar does too.

tar: This does not look like a tar archive
tar: Skipping to next header
tar: Exiting with failure status due to previous errors

...aha! it was a raw gzip file.

anyways, please attach text files uncompressed in the future, it saves a lot of trouble as I can just click the link and view it immediately :)

according to the debug output, checkActivities has not created anything new.

you're hitting a different bug altogether, possibly something newspaper-specific.

your config looks okay, though... but you can't get rid of those newspapers even when unlocked?
hmm, but there's one weird thing, immutability isn't the same for all applets. that was with your desktop locked; can I have one with it unlocked?

I've update my system to KDE 4.5.2 and the bug looks fixed (ArchLinux packages).

Created attachment 52448 [details]
plasma-desktop-appletsrc (unlocked)

Created attachment 52449 [details]
plasma-desktop debug / console output (unlocked)

Created attachment 52450 [details]
plasma-desktop debug / console output (unlocked)

attachment #52449 [details] did not have debug output enabled, this one has.

(In reply to comment #50)
> your config looks okay, though... but you can't get rid of those newspapers
> even when unlocked?
True, I tested this several times now, and it is still perfectly reproducible on Kubuntu. The bug does not appear on Gentoo any longer (if I unlock Plasma before removing the activities).
I noticed that Kubuntu uses an older version of KDE: 4.5.1, while Gentoo is at 4.5.2. (Both are at Qt 4.7.0.) Maybe I can find newer packages for Ubuntu, so I can see whether that makes a difference.

> hmm, but there's one weird thing, immutability isn't the same for all applets.
> that was with your desktop locked; can I have one with it unlocked?
Recently attached.

here you go:
http://www.kubuntu.org/news/kde-sc-4.5.2

(In reply to comment #56)
> here you go:
> http://www.kubuntu.org/news/kde-sc-4.5.2
Seen that, but: "There are no packages planned for Kubuntu 10.04 LTS" :(
If someone finds a PPA containing 4.5.2, please notify me.

I can report that KDE 4.5.2 for Mandriva has fixed this bug. (and introduced a new doozie :\ ) After installing 4.5.2 packaged for Mandriva at the KDE ftp site I no longer have a proliferation of activities.

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

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

SVN commit 1201419 by chani:

partial backport of r1180338

exportLayout function needed for
CCBUG: 248386

sorry I didn't get this in sooner.
CCMAIL: mueller@kde.org


 M  +33 -0     corona.cpp  
 M  +10 -0     corona.h  


WebSVN link: http://websvn.kde.org/?view=rev&revision=1201419

SVN commit 1201420 by chani:

partial backport of r1180339

exportLayout function needed for
CCBUG: 248386

sorry I didn't get this in sooner.
CCMAIL: mueller@kde.org


 M  +3 -16     activity.cpp  


WebSVN link: http://websvn.kde.org/?view=rev&revision=1201420