Description of problem: Crash likely happened the moment I logged into KDE. The K-gears appear for about 30 seconds, fade to black and then nothing. I have to manually kill and start a new plasmashell instance to get anything useful on the desktop. Version-Release number of selected component: kf5-kinit-5.17.0-1.fc24 Additional info: reporter: libreport-2.6.3 backtrace_rating: 4 cmdline: 'klauncher [kdeinit5] --fd=8' crash_function: qt_message_fatal executable: /usr/bin/kdeinit5 global_pid: 2592 kernel: 4.4.0-0.rc5.git3.1.fc24.x86_64 runlevel: N 5 type: CCpp uid: 1000 Truncated backtrace: Thread no. 1 (10 frames) #2 qt_message_fatal at global/qlogging.cpp:1610 #3 QMessageLogger::fatal at global/qlogging.cpp:784 #4 QXcbConnection::QXcbConnection at qxcbconnection.cpp:559 #5 QXcbIntegration::QXcbIntegration at qxcbintegration.cpp:177 #6 QXcbIntegrationPlugin::create at qxcbmain.cpp:50 #7 loadIntegration at kernel/qplatformintegrationfactory.cpp:56 #8 QPlatformIntegrationFactory::create at kernel/qplatformintegrationfactory.cpp:73 #9 init_platform at kernel/qguiapplication.cpp:1032 #10 QGuiApplicationPrivate::createPlatformIntegration at kernel/qguiapplication.cpp:1199 #11 QGuiApplicationPrivate::createEventDispatcher at kernel/qguiapplication.cpp:1216 Potential duplicate: bug 1167056
Created attachment 1108106 [details] File: backtrace
Created attachment 1108107 [details] File: cgroup
Created attachment 1108108 [details] File: core_backtrace
Created attachment 1108109 [details] File: dso_list
Created attachment 1108110 [details] File: environ
Created attachment 1108111 [details] File: limits
Created attachment 1108112 [details] File: maps
Created attachment 1108113 [details] File: mountinfo
Created attachment 1108114 [details] File: namespaces
Created attachment 1108115 [details] File: open_fds
Created attachment 1108116 [details] File: proc_pid_status
Created attachment 1108117 [details] File: var_log_messages
This bug appears to have been reported against 'rawhide' during the Fedora 24 development cycle. Changing version to '24'. More information and reason for this action is here: https://fedoraproject.org/wiki/Fedora_Program_Management/HouseKeeping/Fedora24#Rawhide_Rebase
Similar problem has been detected: Steps to reproduce: 1. Create two user accounts 2. Log in with the first account 3. Application Launcher -> Leave -> New Session 4. Start a new (parallel) session as the second user 5. Log out the session of the second user account Actual results: 1. Plasma session crashes. The screen turns out black; only the KDE reporting system pops up, but it's unusable. 2. On reboot, I see that abrt collected information about some crashes (kdeinit5, plasma-worskpace, kdepim-runtime...). I chose kdeinit5, because it was the one highlitghted by KDE's own reporting tool. Expected results: Ideally, the parallel session should work as expected. How reproducible: I haven't tried to reproduce it yet. reporter: libreport-2.6.4 backtrace_rating: 4 cmdline: 'klauncher [kdeinit5] --fd=8' crash_function: qt_message_fatal executable: /usr/bin/kdeinit5 global_pid: 2195 kernel: 4.5.0-302.fc24.x86_64 package: kf5-kinit-5.20.0-1.fc24 reason: kdeinit5 killed by SIGABRT runlevel: N 5 type: CCpp uid: 1000
I can reliably reproduce the issue, when I follow the steps written with comment #14: > Steps to reproduce: > 1. Create two user accounts > 2. Log in with the first account > 3. Application Launcher -> Leave -> New Session > 4. Start a new (parallel) session as the second user > 5. Log out the session of the second user account As it stands, it's a potential violation of the "2.6.6 Shutdown, reboot, logout" F24 Beta Release criterion. "Shutting down, logging out and rebooting must work using standard console commands and the mechanisms offered (if any) by all release-blocking desktops. [...] Logging out must return the user to the environment from which they logged in, working as expected." Reference: https://fedoraproject.org/wiki/Fedora_24_Beta_Release_Criteria#Shutdown.2C_reboot.2C_logout
Discussed at 2016-04-04 blocker review meeting: [1]. This bug was accepted as Final blocker and Beta Freeze Exception: we count this as a conditional violation of "...logging out...must work using...the mechanisms offered (if any) by all release-blocking desktops." As it's conditional and affects a more advanced use case we accept it as a Final blocker rather than Beta, but also as a Beta freeze exception issue. [1] https://meetbot.fedoraproject.org/fedora-blocker-review/2016-04-04/f24-blocker-review.2016-04-04-16.05.html
Hello KDE team, is there any progress on this? We're trying to evaluate status of F24 blocker bugs. Thanks.
User switching seems to be pretty broken on my test box in general. :( Besides, as far as I can tell, the user switching case is not explicitly covered by Release criteria. *If* it is decided to be covered then, we may end up having to disable it.
I'm using F24 Beta 1.6 with one Admin and one regualar user. I selected to switch users, and noted the following after logging into the second user. a) Ctl-alt F1 gives me the login prompt. b) Ctl-alt F2 gives me the admin logon c) Ctl-alt F3 gives me the second user. In other words, a switch user would allow the second user to comprimise the sustem if the initial user was an administrator (or root). Then, I logged out from the second user, and now, the ctl-alt-F2 b) above, was blocked. I needed to re-log into the admin account to have access. And my second test will be to log out from admin b) after logging into the second account to determine if the logic works as expected. At no time should two logons or three logons be active and switchable between. eg. Root, admin and guest. That ability is a security concern.
Things are even more interesting when a) login as admin and switch user b) login as normaluser and switch user c) login as root and switch user. b) can visit a) or c) via ctl-alt-f1-f4
These findings (in comment #19) appear to not be relevant to this bug, which is about crashes when initiating user switching. I'd encourage you to file separate bug(s). It is still interesting. It is my understanding that what is *supposed* to happen when switching away to another session, is that it the original one is supposed to lock immediately, and require re-authentication to re-enter.
(In reply to Rex Dieter from comment #18) > User switching seems to be pretty broken on my test box in general. :( > > Besides, as far as I can tell, the user switching case is not explicitly > covered by Release criteria. > > *If* it is decided to be covered then, we may end up having to disable it. It's not explicitly covered, but we've blocked on it as a conditional violation of logging in/out in the past. It's sad, but if it's really completely broken as it seems to be, it might be a good idea to disable it until the functionality is fixed, otherwise people will just get frustrated from this. If this turned out to be a much rarer case, we could re-evaluate the decision for having this as a blocker. It depends how many users are affected by this and how often. Currently it seems everyone and every time they try it :-/
Fwiw, I queried on kde list, https://lists.fedoraproject.org/archives/list/kde@lists.fedoraproject.org/thread/A4FNVJMLXQCFCTWJND6S2H5IMDVUU6YA/ and seems most who responded had this feature working ok.
Running the tests in comment 14 I was able to consistently replicate the issue with VMs running with 1G and 4G memory (to rule out small memory). Tested before and after 'dnf update'. No issues on baremetal which made me suspect the graphics driver. Tested OK with video set to Cirrus, VGA and VMVGA. No display with video set to Xen. Conclusion: test only fails on VM with QXL video.
Discussed during the 2016-05-30 blocker review meeting: [1] Decision was made to reclassify this bug as a ProposedBlocker as it does not seem to have as large of an impact as originally thought. Kamil, Petr, can you perform some more tests on this bug? [1] https://meetbot-raw.fedoraproject.org/fedora-blocker-review/2016-05-30/f24-blocker-review.2016-05-30-16.01.txt
I tested this on bare metal (AMD graphics) with Fedora-KDE-Live-x86_64-24-20160529.n.0.iso and user switching seems to work fine. The reproducer from comment 14 also didn't trigger any crash.
I tested this in VM. The bug appears only when I used QXL. I was able to reproduce this bug with qxl following reproducer from comment 14. I tested all other drivers (virtio, cirrus, ...) and log out from second session worked fine.
*** Bug 1341960 has been marked as a duplicate of this bug. ***
So I think with the re-testing I'm -1 blocker on this, any other votes?
-1 blocker based on the recent comments.
also for me is: -1 blocker
Since it seems to affect QXL only, I'm -1 blocker here too.
-1 blocker.
That's five -1 votes, so setting rejectedblocker. I'm gonna propose as Final FE, though, we can discuss that Monday.
I think on this one a convo is needed to understand if there's a fix in the works and what the risk assessment is for it before considering an FE. At the moment I'm -1 FE.
Discussed at 2016-06-13 blocker review meeting: [1]. This bug was rejected as Final Freeze Exception: it's now quite late in the F24 process and there is still no indication of how any fix for this might look, and the issue mostly affects installed systems in any case, so there's no clear case to accept it [1] https://meetbot.fedoraproject.org/fedora-blocker-review/2016-06-13/f24-blocker-review.2016-06-13-16.04.html
*** Bug 1356230 has been marked as a duplicate of this bug. ***
*** Bug 1357228 has been marked as a duplicate of this bug. ***
Similar problem has been detected: Opened menus in LibreOffice Calc. reporter: libreport-2.7.1 backtrace_rating: 4 cmdline: 'klauncher [kdeinit5] --fd=8' crash_function: qt_message_fatal executable: /usr/bin/kdeinit5 global_pid: 18496 kernel: 4.6.3-300.fc24.x86_64 package: kf5-kinit-5.23.0-1.fc24 pkg_fingerprint: 73BD E983 81B4 6521 pkg_vendor: Fedora Project reason: kdeinit5 killed by SIGABRT reproducible: Not sure how to reproduce the problem runlevel: N 5 type: CCpp uid: 101416
Similar problem has been detected: Tried to add a new panel to second screen. Everything froze. reporter: libreport-2.7.2 backtrace_rating: 4 cmdline: 'klauncher [kdeinit5] --fd=8' crash_function: qt_message_fatal executable: /usr/bin/kdeinit5 global_pid: 3651 kernel: 4.6.4-301.fc24.x86_64 package: kf5-kinit-5.24.0-1.fc24 pkg_fingerprint: 73BD E983 81B4 6521 pkg_vendor: Fedora Project reason: kdeinit5 killed by SIGABRT runlevel: N 5 type: CCpp uid: 1001
*** Bug 1362306 has been marked as a duplicate of this bug. ***
Similar problem has been detected: Logged in. reporter: libreport-2.7.2 backtrace_rating: 4 cmdline: 'klauncher [kdeinit5] --fd=8' crash_function: qt_message_fatal executable: /usr/bin/kdeinit5 global_pid: 22887 kernel: 4.6.4-301.fc24.x86_64 package: kf5-kinit-5.24.0-1.fc24 pkg_fingerprint: 73BD E983 81B4 6521 pkg_vendor: Fedora Project reason: kdeinit5 killed by SIGABRT runlevel: N 5 type: CCpp uid: 101416
*** Bug 1367755 has been marked as a duplicate of this bug. ***
*** Bug 1393995 has been marked as a duplicate of this bug. ***
*** Bug 1408212 has been marked as a duplicate of this bug. ***
This message is a reminder that Fedora 24 is nearing its end of life. Approximately 2 (two) weeks from now Fedora will stop maintaining and issuing updates for Fedora 24. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '24'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 24 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
Fedora 24 changed to end-of-life (EOL) status on 2017-08-08. Fedora 24 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed.