Why?

I have no idea whatsoever, i'm just reporting a patch that the distro maintainer says it's working, but I don't know why. putting it there to discuss and trying to understand

It's working because with this patch Plasma doesn't try to delete the activity it's working with.

This way Plasma crashes (note that it tries to create containment for the activity destroyed with cont->destroy() earlier; also note that only panel containment tries to be created):
-----not patched -----
!!! checkActivities (status) 2
!!! checkActivities (id) "90960718-8ab6-460d-920d-3074a925c813"
!!! checkActivities (destroyed activity): "c51bdf4c-5df8-4b04-9cf8-88a446ad2445"
!!! load (containments are NOT empty, m_shell) "org.kde.plasma.desktop"
!!! load (containmentType == panel)
!!! createContainmentForActivity (activity) "c51bdf4c-5df8-4b04-9cf8-88a446ad2445"
!!! createContainmentForActivity (screenNum) 0
-----not patched -----

And this way it works (note that both panel and desktop try to be created):
-----patched-----
!!! load (containments are NOT empty, m_shell) "org.kde.plasma.desktop"
!!! load (containmentType == panel)
!!! load (containmentType == desktop)
!!! createContainmentForActivity (activity) "94bbf033-08f1-49ca-8f58-d1963a7d6415"
!!! createContainmentForActivity (screenNum) 0
-----patched-----

Maybe there's a better way to fix the crash. I hope you can reproduce it (it happens on first login, when there are no user configs yet). But for me (downstream distro) it's still better then nothing for now.

@abondrov

Have you applied any patch other than this one to plasma? I'm asking since neither Marco nor I can replicate this on our systems (with empty-config users)

Another question, do you have a repository of what changes your distro is doing during packaging - maybe we are missing something?

What is really confusing here is where is the containment assigned to a non-existent activity coming from.

Skip this, seems I've just seen a few duplicate logs:

it seems to always have the "c51bdf4c-5df8-4b04-9cf8-88a446ad2445"
id which is a UUID and should be random. Since it is not, it is most likely
getting it from somewhere else. Some config file or something.

Is there a systemwide plasma*rc?

@mart

The reason why this change fixes the scripting problem I'm working on is that loadLayout actually calls loadDefaultLayout and this tells the scripting engine which activities exist, and which are present. That is why adding this above loadLayout was working to fix the scripting problem:

QStringList existingActivities = m_activityController->activities();
foreach (const QString &id, existingActivities) {
    qDebug() << "Corona GREPME: Init activities";
    activityAdded(id);
}

In D2283#42565, @ivan wrote:

@abondrov

Have you applied any patch other than this one to plasma? Another question, do you have a repository of what changes your distro is doing during packaging - maybe we are missing something?

You can take a look at our Plasma Workspace patches here: https://abf.rosalinux.ru/import/plasma5-workspace

Is there a systemwide plasma*rc?

You can take a look at our systemwide plasma configs and layout templates here: https://abf.rosalinux.ru/import/plasma5-config-fresh

@abondrov

Thanks.

This one needs to go away, along with making kactivitymanagerd a hard runtime requirement:

https://abf.rosalinux.ru/import/plasma5-workspace/blob/rosa2014.1/plasma-workspace-5.7.2-layout-initialization-2.patch

The load-order one is not a proper fix, so it will need to go as well when we figure out what the exact problem is.

I'll try to copy your setup to replicate the issues you are having.

@mart

Here is the patch that should fix the scripting part of the issue https://phabricator.kde.org/D2288

In D2283#42598, @ivan wrote:

This one needs to go away, along with making kactivitymanagerd a hard runtime requirement:

https://abf.rosalinux.ru/import/plasma5-workspace/blob/rosa2014.1/plasma-workspace-5.7.2-layout-initialization-2.patch

It's a backport of recently commited patch: https://quickgit.kde.org/?p=plasma-workspace.git&a=commit&h=d4b8143d552ccd8adf196afccac32985ea4bb7cb

Likely it needs to be reverted then.

@abondrov

Since you are really helpful and active, I have a couple of things for you to test :) (please do not kill me)

1. Remove david's patch backported from master (the one that checks against kamd status being Unknown - plasma-workspace-5.7.2-layout-initialization-2.patch)
2. Remove all patches similar to this one, except for Marco's which checks m_activityController->serviceStatus() == KActivities::Controller::Running
3. Can you add D2288 (https://phabricator.kde.org/D2288)
4. Modify plasma/shells/org.kde.plasma.desktop/contents/defaults and set Containment=org.kde.plasma.folder - this should change the default containment type without the need to create activities from layout.js
5. Modify layout.js to this:

loadTemplate("org.kde.plasma.desktop.defaultPanel");

var desktopsArray = desktopsForActivity(currentActivity());

print(desktopsArray.length);

for (var j = 0; j < desktopsArray.length; j++) {
    desktopsArray[j].wallpaperPlugin = 'org.kde.image';
    desktopsArray[j].currentConfigGroup = ["General"]
    desktopsArray[j].writeConfig("showToolbox", "false")
}

@abondrov

Yes, it is a backport of a patch that will be reverted once we deal with 5.7 stuff. We didn't put it in 5.7 branch because it is not really a good patch - it was supposed to cover the cases when kactivitymanagerd is not installed, but we need kactivitymanagerd in 5.7 - that is why I mentioned it needs to be a hard requirement now.

We will see for master whether we will go for keeping the patch, and changing the way kactivities report the status of the service, or reverting the patch and making kamd a hard-requirement for all future plasma releases.

p.s. The step 4 will be made a bit different with Marco's upcoming patch, but it is the only way ATM to set the default containment plugin.

so, the patch is in, you can have a defaults file in the rosa lnf that has the following:

[Desktop][org.kde.plasma.desktop]
Containment=org.kde.plasma.folder

@ivan, @mart

Since you are really helpful and active, I have a couple of things for you to test :) (please do not kill me)

I'll test it tomorrow. It takes some time to build patched plasma-workspace package and then build ISO with it.

Thanx for working on this issue :-)

@ivan, @mart

I confirm, this way it seems to work.

1. plasma-workspace: https://abf.rosalinux.ru/abondrov/plasma5-workspace/tree/rosa2014.1
2. plasma-config: https://abf.rosalinux.ru/abondrov/plasma5-config-fresh/tree/rosa2014.1
3. plasma-lnf: https://abf.rosalinux.ru/abondrov/plasma5-look-and-feel-rosa-fresh/tree/rosa2014.1

ISO used for testing: https://abf.rosalinux.ru/platforms/rosa2014.1/products/137/product_build_lists/15748

Boot logic from .xsession-errors:

!!! setShell (init): "org.kde.plasma.desktop"
!!! setShell (theme name): "rosa-fresh"
!!! unload (init, m_shell) "org.kde.plasma.desktop"
!!! load (init, m_shell): "org.kde.plasma.desktop"
!!! loadDefaultLayout (script) "/usr/share/plasma/shells/org.kde.plasma.desktop/contents/layout.js"
!!! ShellCorona screenForContainment: Plasma::Containment(0x8d1fb88) Last screen is -1
!!! ShellCorona screenForContainment: Plasma::Containment(0x8d1fb88) Last screen is -1
!!! ShellCorona screenForContainment: Plasma::Containment(0x8d1fb88) Last screen is -1
!!! createContainmentForActivity (activity) "786d68ca-8b1b-41ae-a8a4-0ad378afed9d"
!!! createContainmentForActivity (screenNum) 0
!!! createContainmentForActivity (plugin) "org.kde.plasma.folder"
!!! ShellCorona screenForContainment: Plasma::Containment(0x8d1fb88) Last screen is -1
!!! ShellCorona screenForContainment: Plasma::Containment(0x8d1fb88) Last screen is -1
!!! insertContainment (containment): Plasma::Containment(0x8b6c8b0)
!!! insertContainment (activity): "786d68ca-8b1b-41ae-a8a4-0ad378afed9d"
!!! insertContainment (screenNum): 0
!!! ShellCorona screenForContainment: Plasma::Containment(0x8d1fb88) Last screen is -1
!!! ShellCorona screenForContainment: Plasma::Containment(0x8d1fb88) Last screen is -1
!!! ShellCorona screenForContainment: Plasma::Containment(0x8d1fb88) Last screen is -1
!!! ShellCorona screenForContainment: Plasma::Containment(0x8d1fb88) Last screen is -1
!!! ShellCorona screenForContainment: Plasma::Containment(0x8b6c8b0) Last screen is -1
!!! ShellCorona screenForContainment: Plasma::Containment(0x8b6c8b0) Last screen is -1
!!! checkActivities (status) 2
!!! checkActivities (id) "786d68ca-8b1b-41ae-a8a4-0ad378afed9d"
!!! load (containments are NOT empty, m_shell) "org.kde.plasma.desktop"
!!! load (containmentType == panel)
!!! load (containmentType == desktop)
!!! createContainmentForActivity (activity) "786d68ca-8b1b-41ae-a8a4-0ad378afed9d"
!!! createContainmentForActivity (screenNum) 0

I'll ask our QA engineer to give it more testing and let you know if we find anything interesting related to this issue.

BTW, there's another containments-related Plasma crash which is easy to reproduce. Download the ISO, install it (or boot in live mode) and try to add second panel. Plasma will crash, then restart with second panel added and crash BT info provided. Bug report: https://bugs.kde.org/show_bug.cgi?id=366146

In D2283#42693, @abondrov wrote:

I'll ask our QA engineer to give it more testing and let you know if we find anything interesting related to this issue.

QA engineer confirms that Plasma doesn't crash with these changes. I'll close the bug ( https://bugs.kde.org/show_bug.cgi?id=365989 ). Thanx again for fixing it.

In D2283#42745, @mart wrote:

can you add the BT to that report?

Surely. I added it earlier today.