Discussed with leio in #gentoo-desktop. On my Gnome system with gnome-shell 3.26.2-r4 from the gentoo repository, I can fairly reliably crash gnome-shell by pressing the Windows key to go to the activities overview and then pressing esc or the Windows key again to exit the overview. It doesn't happen when no windows are open. NVidia proprietary drivers and two Asus 4K screens attached. As per leio's helpful instructions, I recompiled gnome-shell and mutter to get debug symbols and got a meaningful stacktrace, which I will attach. Leio then suggested to apply the patch at https://bug788316.bugzilla-attachments.gnome.org/attachment.cgi?id=360638 , purely based on function names from the stack trace. That patch fixed it for me. Reproducible: Always Steps to Reproduce: 1. Press Windows key to to the activities overview when several windows are open. 2. Press Windows key again to exist the overview. Crash.
Created attachment 553500 [details] Stack trace of the gnome-shell crash
The bug reports suggest that the patch might be a mere workaround, with a proper full solution pending at the time. Presumably this would be done by now, and maybe we can find those patches to backport instead. Note that this isn't gnome bug 788316 - just the direct link without bug reference doesn't work anymore and I got the patch out of gnome bugzie this way still. We should find the original gnome upstream report and see what happened there. For the record, I'm not getting these crashes, so not sure what in the environment actually triggers it.
It indeed seems to be something to do with external screens. Crashed today right during connecting the screen, and possibly pressing Activities key (accidentally). [58387.191381] gnome-shell[1377]: segfault at 0 ip 00007f6da4d34840 sp 00007ffc88b26e58 error 4 in libmutter-1.so.0.0.0[7f6da4c7e000+14f000] [58387.191387] Code: 00 00 00 0f 1f 80 00 00 00 00 8b 35 5a 74 2a 00 31 d2 31 c0 e9 81 9a f9 ff 90 48 8b 87 f0 02 00 00 c3 0f 1f 84 00 00 00 00 00 <48> 8b 07 ff a0 08 01 00 00 0f 1f 80 00 00 00 00 48 8b 07 ff a0 10 But for sure, this did not happen earlier. Two major changes * gnome-color-manager-3.26 -> 3.30 * kernel 4.19.1 -> 4.19.5 I doubt kernel is involved, but who knows.
I think this isn't a concern with 3.30, right?
This bug description is exactly what one of my patches presented on #gentoo-desktop fixed in 3.30.
Thanks. Then this should be fixed with x11-wm/mutter-3.30.2-r1
