Description of problem: Gnome-shell crashes frequently on both XOrg and Wayland back-ends. After such a crash a login dialog is shown, even on XOrg. These crashes happen most often when the display mode changes. This can be plugging in, or out, an external monitor, closing and opening the laptop lid, or just when waking up from sleep mode. I've tried sending in crash reports through the ABRT dialogues, but these fail to complete through both methods of sending a core-dump to the server or generating a stack-trace locally. Also I know there are a lot of issues reported with gnome-shell, but I'm not sure which this one would belong to. Version-Release number of selected component (if applicable): gnome-shell-3.26.2-1.fc27 xorg-x11-server-1.19.5-1.fc27 How reproducible: Intermittent but frequent Steps to Reproduce: 1. 2. 3. Actual results: Expected results: Additional info: Laptop model: Dell Latitude e7240 Intel® Core™ i5-5300U CPU @ 2.30GHz × 4 Intel® HD Graphics 5500 (Broadwell GT2) Linux 4.13.13-300.fc27.x86_64
I'll confirm this bug on Fedora 27, x86-64. I'm using a desktop system with a Haswell i7-4770 processor and the Intel HD Graphics 4600 onboard GPU. It happens routinely -- but not always -- when I switch my monitor from its DP input (where the Fedora desktop lives) to another input (like the mini DP connector with a different signal source). When I switch back to the DP input I'll see the login screen, and when I log in I see a notification that either Gnome Shell or xwayland has crashed.
It sure would be nice to get some traction on this. Nearly every time I switch inputs on my monitor, or the monitor simply goes to sleep, I return to the Gnome login screen after a crashes session. What can I provide that might help?
(In reply to Clarke Wixon from comment #2) > It sure would be nice to get some traction on this. Nearly every time I > switch inputs on my monitor, or the monitor simply goes to sleep, I return > to the Gnome login screen after a crashes session. Possible duplicate of bug 1500325 maybe? > What can I provide that might help? The journal logs at the time of the issue would help for a start, ideally a backtrace from either gnome-shell or Xwayland depending on who crashed first (and took the other down with it).
Thanks Olivier, it may very well be a dup of #1500325. I'll take a look at your bug-fix in comments 34/45 -- is there an RPM for it? Looks like it's gone from koji. If not, I'll build it.
For me this is pretty clearly solved entirely by mutter-3.26.2-2.fc27, as noted in bug 1500325. Johannes, are you good?
Last time I checked if I could start running Gnome again (using i3 a.t.m.), was on Monday (ca. 10am CET). Things were still crashing then. I'll try again tomorrow, when I'm back at work with a multi-monitor setup. Thanks for the heads up! Cheers, Johan
Ok Things seem to be better now! If it's up to me, this ticket can be closed. Thanks!
Aaaaand XWayland got killed again... While things seem more stable against sleep mode and display changes, this time XWayland got killed by SIGABRT spontaneously after starting audacious (which happens to be a Qt application, is that significant?). I'm not sure if this is the same bug. The abrt dialog gives me the message that it can't report the bug, because the backtrace is unusable.
(In reply to johannes.hidding from comment #8) > Aaaaand XWayland got killed again... While things seem more stable against > sleep mode and display changes, this time XWayland got killed by SIGABRT It's not that it “got killed”, it's rather that it aborted itself because it could not communicate with the Wayland compositor. > spontaneously after starting audacious (which happens to be a Qt > application, is that significant?). I'm not sure if this is the same bug. No, unlikely the same. > The abrt dialog gives me the message that it can't report the bug, because > the backtrace is unusable. Again, the problem is very unlikely Xwayland in this case (abort) but the Wayland compositor, so not being able to get a backtrace of Xwayland doesn't matter much (the backtrace wouldn't tell much that we don't know already). What gives “journalctl” at the time of the crash (look for gnome-shell) and does “coredumpctl list” has anything relevant for gnome-shell?
Created attachment 1370800 [details] output of `journalctl | grep 'gnome-shell'`
> coredumpctl list | tail -n 2 Thu 2017-12-21 10:35:17 CET 1853 1000 1000 6 present /usr/bin/Xwayland Thu 2017-12-21 10:35:18 CET 1808 1000 1000 11 present /usr/bin/gnome-shell the output of `journalctl` is huge; I grepped it on "gnome-shell" and attached the lines surrounding the time of the incident.
(In reply to johannes.hidding from comment #11) > > coredumpctl list | tail -n 2 > Thu 2017-12-21 10:35:17 CET 1853 1000 1000 6 present > /usr/bin/Xwayland > Thu 2017-12-21 10:35:18 CET 1808 1000 1000 11 present > /usr/bin/gnome-shell > > the output of `journalctl` is huge; I grepped it on "gnome-shell" and > attached the lines surrounding the time of the incident. Perfect, so you have core files available for both Xwayand and gnome-shell! Could you please: 1. install the debuginfo packages for gnome-shell $ sudo dnf debuginfo-install gnome-shell 2. Open the core file from gnome-shell in gdb using coredumpctl $ coredumpctl gdb 1808 3. from within gdb, generate the backtrace: (gdb) bt (gdb) t a a bt 4. Copy the output from the commands above from gdb to a text file and attach to this bug report Thanks!
Created attachment 1370814 [details] gdb coredump
(In reply to johannes.hidding from comment #13) > Created attachment 1370814 [details] > gdb coredump Thanks! I suspect you don't have all the necessary debuginfo installed, but enough to point at gnome-shell (St), so moving to gnome-shell (Javascript issues are out of my league)
This message is a reminder that Fedora 27 is nearing its end of life. On 2018-Nov-30 Fedora will stop maintaining and issuing updates for Fedora 27. 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 '27'. 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 27 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 27 changed to end-of-life (EOL) status on 2018-11-30. Fedora 27 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.