Tested on Ubuntu 17.10 with GNOME 3.26.1 (Gnome session with Xorg). Enabling the extension would cause the desktop session to logoff when I turn off my computer screen. Disabling it can remove the issue from my system.
Similar things seems to happen on other extensions.
You may see detail reports in these tickets:
From this comment the issue can be caused by extensions accessing non-existent GSettings key, which is a fatal error.
I'm experiencing frequent crashes of the gnome-shell too, most likely caused by dash-to-dock, though not only when I turn off the screen, but also sometimes randomly mid-session, and, reproducibly, after a lock of the screen and trying to log back in. There seem to be more tickets regarding this:
though some users state that their problems arise even without the dash-to-dock extension.
For me, however, disabling dash-to-dock got rid of all gnome-shell crashes that I experienced. I'm willing to help/debug the problem, unfortunately for me the core dump information was not very helpful.
Testet on Arch Linux 4.13.8-1 with GNOME 3.26.1
Could you check in the logs if before the crash there's some error message related to dash to dock or the shell?
sudo journalctl /usr/bin/gnome-shell
Updated to gnome shell 3.26.2 and re-enabled dash-to-dock today. So far, the observed core dumps and crashes did not reappear.
If a crash occurs, I will let you know and post the log here.
I don't know if this closes the issue or if the crashes still occur for OP, though.
This gist contains log right before the stated incident:
https://gist.github.com/yookoala/92f423effda699feac8fad2f2cefb22e
Note: There are logs about other extensions but I think they don't matter. As stated before, as long as I disable Dash to Dock and it alone, the problem is stopped.
@yookoala : do you have more than one monitor? Can't find anything interesting from the logs unfortunately. Some additional info might be useful: wayland or X? Which GPU (intel/nvidia/amd)?
@micheleg: I only have 1 monitor.
I think I'm using plain Xorg session (because wayland session is not available for me to choose)
I'm using Nvidia Geforce GTX 1050 Ti with driver package nvidia-387.
Just tried removing gnome-shell-extension-ubuntu-dock. Don't seems to fix the issue for me.
Can confirm this bug.
Dash to dock 62
Ubuntu 17.10
GNOME Shell 3.26.2
Nvidia 1060
Same problem here.
Locking the screen before turning off the monitor helps.
Automatically lock the screen when turning off the monitor doesn't work.
Turning off Dash to dock does help ;)
Dash to dock 62
Fedora 27
Gnome-Shell 3.26.2, xorg session
Intel i915 Driver
@flega68 Are you able to provide some logs?
@micheleg
I reproduced the problem and found out that it only crashes when dash to dock auto-hides. If i turn this of, everything seems to work.
Edit: Turning "Dodge windows" off is enough to make it work
Here the log I found so far (is there a better way):
journalctl /usr/bin/gnome-shell | grep dash
dash.log
@flega68 Thanks for the additional log. I'm wondering if could be related to #493.
Could you confitm your configuration: Screen resolutions and relative positions(i.e. same resolution, or if not, how they are aligned). Can you deterministically reproduce the bug?
Hello. Update here. I'm testing on Ubuntu 18.04 beta 2. Same problem.
Stably reproducible on both Xorg and Wayland session.
@micheleg
I have only one screen in this configuration. (1680x1050)
And yes, I can reproduce the Bug.
Dodge Windows on: Gnome crashes every time I unplug the monitor. Sometimes it is "just" a crash and the session stays on and sometimes Gnome crashes and the session closes.
Dodge Windows off: Normal behavior
And I have a second installation:
Fedora 27
Gnome 3.26.2
Dash to Dock 62
Dual Screen 1920x1080, Nvidia Card (proprietary drivers)
Here everything works fine...
I have a single 4k monitor connected over DisplayPort using integrated Intel graphics. I'm running Arch Linux with Gnome 3.28, but the problem also happened back on Gnome 3.26. In my testing so far it only seems to kick in when I'm running a Wayland session. In that case just turning off my monitor causes a crash and when I turn the monitor back on I'm sitting at the login screen. If I run the exact same setup but launch the Xorg session instead the problem does not happen.
I take that back, I've now gotten a crash while running an Xorg session as well. It just took a lot longer to happen. Often times, but not always, I can reproduce the crash under Wayland by simply turning my monitor off and right back on. I've never had that happen under Xorg, but I left an Xorg session logged on last night and turned my monitor off and then when I came back this morning it had crashed. Looking at the logs and it seems it was about 2 hours after I had turned the monitor off.
also confirming this bug on 17.10, gnome 3.26.2
Version: Git 09/05/2018
GNOME 3.28.1
Fedora 28 with Wayland
No multi-monitor
4K monitor
DisplayPort
GTX 1050 with 396.24 propietary driver
extend-height=true
dock-fixed=true
custom-background-color=false
apply-custom-theme=false
isolate-monitors=false
dock-position='BOTTOM'
preferred-monitor=0
custom-theme-shrink=false
transparency-mode='ADAPTIVE'
Dash To Dock on: gnome-shell crash after turning off the monitor
Dash To Dock off: no errors, no crash
I've noticed that the same thing happens when the screen lock is disabled in the privacy option of the configuration. When turning on the monitor it reloads GNOME (Windows-style with its explorer.exe hehe). The bug seems that it does not close the session by itself, it is GNOME that does it with the screen lock activated. When it is disabled it simply reloads the interface.
To me it concretely does to me when turning off the monitor, not when I turn it on.
I hope the information is useful, as you already know. There are many logs, if you tell me which look could put it without problems.
@micheleg
After having a look at @kll 's log, this seems to be the cause:
JS ERROR: TypeError: this._monitor is undefined
DockedDash<._resetPosition@/usr/share/gnome-shell/extensions/[email protected]/docking.js:1089:17
@micheleg I had a look at the 3.26 branch, and maybe this commit is to blame:
https://github.com/GNOME/gnome-shell/commit/5f8a5114833d7d31d4bd64affbd323bb7252c3d0
It seems that we need to be more careful when connecting to monitors-changed. As an example, here is how it is handled upstream: https://github.com/GNOME/gnome-shell/blob/e00f22ebe642d07bd1ab003f9b68105d8da25ed8/js/ui/overview.js#L393,
if (!Main.layoutManager.primaryMonitor)
return;
Possibly related : https://github.com/micheleg/dash-to-dock/issues/638
@perikitodestino thanks for the additional information. @franglais125 thanks for pointing out those changes!
I'm wondering if it is indeed enough to just skip the dock repositioning if there's not monitor attached. We are referring to monitors in various part of the code. My understanding is that the values stored in the monitor objects might be temporary meanigless but still valid given that they were previous monitor configuration.
Given that at each monitor change we are destroying and recreating the docks, should we just stop the recreation process if no monitor is present? This is a tentative fix: e6dab2574f5063a1f1282fd3684d7657c5b41f21.
@micheleg I'm running the branch with the fix, but all I can say is the dock still works... I can't confirm if the issue is fixed as I was not affected by it!
yeah, not easy for me as well to test. Hoping on people that can more easily try to reproduce the bug to test if it works @perikitodestino @kll @ctrl-f5 @yookoala
@micheleg Works fine, no crash :100:
Great! Please keep an eye on possible weird behaviours or regressions.
So far so good after 24 hours of use including the monitor being off overnight without a crash.
a quick test seems to be positive. Will report back if I still experience a crash.
Fix e6dab2 seems to have solved the issue for me.
Thx
had a crash again today. currently not working on external screen, but on laptop screen itself.
Only happens once, first time of the day I lock the screen. Maybe I've got different issue. Going to upgrade to 18.04 LTS today hoping gnome will be a bit more stable in general...
@ctrl-f5 or anyone else still having crashes:
Could you please attach a log if you have a new crash? That way we can verify that the cause is still the same, and if it's not we can be sure that the fix worked (or not).
I've also had two more overnight crashes, but I've also had several more times where it didn't crash. I don't think it is related to dash-to-dock though, or at least I can't find any sign of it in the logs. Here they are for completeness sake in case I'm missing something. For now I'm assuming it is unrelated.
logs
Same here with Fedora 28 and GNOME Shell 3.28.2
I've merged the fix mentioned above in master. Might not fix all problems but it seems to be beneficial [73cefdb9].
Thanks. Confirm the problem fixed on my computer that I talked about. (after update)
hi, i still have issues with dash-to-dock causing gnome to log out or crash when i turn of my monitor or when gnome turn it of, i did some testing and it only happens when dash-to-dock is active
i am using opensuse tumbleweed gnome is Version 3.28.2
i have a geforce 960 with the proprietary nvidia driver version 396.24 and my monitor is connected via displayport
in "journalctl /usr/bin/gnome-shell" some errors appear that have to do with dash-to-dock, its a lot of text so i put it on pastebin
@Culted are you running master? I habent release a version with the fix yet (I'll try to do it this week)
Most helpful comment
@perikitodestino thanks for the additional information. @franglais125 thanks for pointing out those changes!
I'm wondering if it is indeed enough to just skip the dock repositioning if there's not monitor attached. We are referring to monitors in various part of the code. My understanding is that the values stored in the monitor objects might be temporary meanigless but still valid given that they were previous monitor configuration.
Given that at each monitor change we are destroying and recreating the docks, should we just stop the recreation process if no monitor is present? This is a tentative fix: e6dab2574f5063a1f1282fd3684d7657c5b41f21.