Bug 310486 - Unable to logout/reboot after KDE upgrade.
Summary: Unable to logout/reboot after KDE upgrade.
Status: RESOLVED NOT A BUG
Alias: None
Product: ksmserver
Classification: Plasma
Component: general (show other bugs)
Version: Git
Platform: Arch Linux Linux
: NOR major
Target Milestone: ---
Assignee: Lubos Lunak
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2012-11-22 10:08 UTC by Alexander
Modified: 2013-01-28 13:59 UTC (History)
7 users (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments
kde-runtime-4.9.98-kde#310486.patch (3.58 KB, patch)
2013-01-27 23:02 UTC, Kevin Kofler
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Alexander 2012-11-22 10:08:13 UTC
Just upgraded to KDE 4.9.80 and when I am trying to restart my PC or at least simply log out my screen gets dark but nothing happen, floating menu with "log out" button doesn't appear as usual.

This is from ~/.xsession-errors
QObject::connect: Cannot connect (null)::logoutRequested() to KSMShutdownDlg::slotLogout()
QObject::connect: Cannot connect (null)::haltRequested() to KSMShutdownDlg::slotHalt()
QObject::connect: Cannot connect (null)::suspendRequested(int) to KSMShutdownDlg::slotSuspend(int)
QObject::connect: Cannot connect (null)::rebootRequested() to KSMShutdownDlg::slotReboot()
QObject::connect: Cannot connect (null)::rebootRequested2(int) to KSMShutdownDlg::slotReboot(int)
QObject::connect: Cannot connect (null)::cancelRequested() to KSMShutdownDlg::reject()
QObject::connect: Cannot connect (null)::lockScreenRequested() to KSMShutdownDlg::slotLockScreen()

Reproducible: Always

Steps to Reproduce:
1. Upgrade from 4.9.* to 4.9.80
2. Try to log out


Expected Results:  
It should not happen, otherwise you should warn users they should not run upgrade from running KDE session (but this is not a good way to go I think).
Comment 1 Christoph Feck 2012-11-22 12:42:19 UTC
Did you find any particular application which blocks the logout? In the meantime, reassigning to ksmserver developers to check the NULL connects.
Comment 2 Alexander 2012-11-22 13:04:58 UTC
Hi, no, I didn't. Just upgraded from 4.9.3 and tried to log out. Btw I did not even know that any application could block the log out, but seems like I've closed everything before exit as I usually do.
Comment 3 Philip Muškovac 2012-12-08 21:11:52 UTC
Confirmed on Kubuntu with 4.9.80 and 4.9.90.
Comment 4 Philip Muškovac 2013-01-19 15:47:37 UTC
And it still happens when upgrading 4.9.5 to 4.9.98
Comment 5 Rex Dieter 2013-01-19 16:53:04 UTC
marking confirmed (i witnessed this too on upgrading to 4.9.9x)
Comment 6 Kevin Kofler 2013-01-22 15:54:58 UTC
The offending connections happen here:
https://projects.kde.org/projects/kde/kde-workspace/repository/entry/ksmserver/shutdowndlg.cpp?rev=KDE%2F4.9#L249

I haven't been able to find why the rootObject is null though. I suspected some issue with the QML (the ksmserver from 4.9 still running and choking on the 4.10 QML files), but it doesn't seem to have been renamed nor changed incompatibly betwen 4.9 and 4.10.
Comment 7 Philip Muškovac 2013-01-23 09:01:27 UTC
What I'm seeing in xsession-errors is this:

file:///usr/share/kde4/apps/ksmserver/themes/default/main.qml:27:1: plugin cannot be loaded for module "org.kde.plasma.components": Cannot load library /usr/lib/kde4/imports/org/kde/plasma/components/libplasmacomponentsplugin.so: (/usr/lib/kde4/imports/org/kde/plasma/components/libplasmacomponentsplugin.so: undefined symbol: _ZN12KDeclarative16componentsTargetEv) 
     import org.kde.plasma.components 0.1 as PlasmaComponents 
     ^ 
QObject::connect: Cannot connect (null)::logoutRequested() to KSMShutdownDlg::slotLogout()
QObject::connect: Cannot connect (null)::haltRequested() to KSMShutdownDlg::slotHalt()
QObject::connect: Cannot connect (null)::suspendRequested(int) to KSMShutdownDlg::slotSuspend(int)
QObject::connect: Cannot connect (null)::rebootRequested() to KSMShutdownDlg::slotReboot()
QObject::connect: Cannot connect (null)::rebootRequested2(int) to KSMShutdownDlg::slotReboot(int)
QObject::connect: Cannot connect (null)::cancelRequested() to KSMShutdownDlg::reject()
QObject::connect: Cannot connect (null)::lockScreenRequested() to KSMShutdownDlg::slotLockScreen()

As the symbol error happens directly before the null connections it might be related?
Comment 8 Christoph Feck 2013-01-23 11:56:48 UTC
Philip, "undefined symbol" always means you are mixing KDE components from different repositories or compilations. Please ask in the forums of your distribution, which repositories are compatible.
Comment 9 Philip Muškovac 2013-01-23 12:13:45 UTC
@Christoph:
I know that (and I'm a Kubuntu Developer btw.). The problem here is:
KDE running: 4.9.5
KDE installed: 4.9.98

this happens when trying to reboot after the upgrade. I understand that binary compatibility between different KDE releases is usually not guaranteed. But in this case: How the hell is a regular user that doesn't know what Konsole is supposed to reboot after the upgrade without the kickoff Leave menu working? Other than pressing the power button on the PC which isn't really an acceptable solution from a distribution perspective.
Comment 10 Kevin Kofler 2013-01-23 18:09:49 UTC
So the issue is this static method:
http://lxr.kde.org/ident?i=componentsTarget
introduced in kdelibs 4.10, along with a few others (defaultComponentTarget is also used by the same Plasma components plugin code), by this commit:
https://projects.kde.org/projects/kde/kdelibs/repository/revisions/f050b932407f095a9931549ac8a81e6bdd4542ff
(WARNING: PLEASE READ ON BEFORE ATTEMPTING TO BACKPORT THAT COMMIT!)
The dynamically loaded plugin from 4.10 tries to use that method, but the ksmserver loading the plugin is from 4.9 and already has kdelibs 4.9 loaded, so the symbol is not available.

A workaround for the affected distributions (any distribution which shipped with 4.9 or older will want this) is to *revert* this commit:
https://projects.kde.org/projects/kde/kde-runtime/repository/revisions/deee161a42efda74965ca4aab7d79fb7fb375352
Unfortunately, this workaround will have to be kept until the next release of the distribution (which ships with kdelibs 4.10 or higher, or with those methods backported). And no, backporting the methods to an existing distribution now DOES NOT HELP because users may be upgrading directly from the released distro to 4.10.
Comment 11 Lukáš Tinkl 2013-01-24 13:03:27 UTC
Adding aseigo to CC
Comment 12 Daniel Nicoletti 2013-01-25 13:14:03 UTC
I'm sorry but reverting that commit is just a workaround to an issue that is not going to be properly fixed.
Which is why I keep telling people that yes, you can crash an application with QML, what should be done here?
ksmserver should spawn a new process that will load that QML thing, the new process will have all KDE 4.10 stuff and even if someone in the future breaks some API/ABI in future critical things like this will never happen again.
If the spawned process fails to load just perform the action without confirmation (imagine now that someone actually removed all KDE related packages...)
Comment 13 Aaron J. Seigo 2013-01-25 13:35:48 UTC
kde-workspace 4.10 requires kdelibs and kde-runtime 4.10. this is simply not supported, and never has been.

in constrast: kdelibs 4.10 can be used with kde-workspace 4.9.
Comment 14 Lukáš Tinkl 2013-01-25 13:39:02 UTC
Nobody argues about that Aaron but the bug itself (the inability to logout) seems pretty valid to me
Comment 15 Kevin Kofler 2013-01-25 20:00:40 UTC
Let's just apply the workaround from comment #10 in our distros and be done with it.
Comment 16 Kevin Kofler 2013-01-27 23:02:03 UTC
Created attachment 76763 [details]
kde-runtime-4.9.98-kde#310486.patch

The attached patch basically reverts:
http://commits.kde.org/kde-runtime/deee161a42efda74965ca4aab7d79fb7fb375352

I cleaned it up so that it only reverts the parts of the change actually causing the problem and made it actually build (proof: http://koji.fedoraproject.org/koji/buildinfo?buildID=380666) when applied against 4.9.98.

I understand that upstream is not interested in supporting this case, but distributions which are hitting the conditions described in comment #10 definitely WILL want to apply this patch.
Comment 17 Kevin Kofler 2013-01-28 13:59:54 UTC
Rex Dieter tested the workaround from comment #16 and confirmed that it fixes the bug.