Control: retitle -1 gnome-shell segfault in libmutter-clutter-12.so with nvidia-graphics-drivers set to 144Hz refresh Control: severity -1 important Control: tags -1 + moreinfo Control: affects -1 + src:gnome-shell src:nvidia-graphics-drivers
On Tue, 29 Aug 2023 at 22:14:50 +0200, gozdek wrote: > I found workaround, changing the refresh in nvidia-settings from 144Hz to > 60Hz > solves the problem with libmutter segfault. Nvidia drivers: 535.104.05 A workaround exists, so this doesn't make GNOME Shell completely unusable; downgrading the bug severity to important. > Gnome-shell: Alt-F2, type 'r' > or open Firefox/Chrome browser and play any video for example from youtube Those two might actually be two separate root causes, or they might be two different ways to trigger the same root cause; it's not yet clear from the information available. Alt+F2, 'r' sometimes triggers bugs in shutdown/cleanup code paths that would normally only result in the Shell crashing when it is already trying to exit (which is a bug, but relatively harmless). This seems likely to be the same thing as #1050502, which was also reported by a user of the Nvidia proprietary graphics driver. Playing videos in a web browser probably means there is a crash involving hardware video acceleration (VA-API or VDPAU). This could be the same thing as #1050512, which was *also* reported by a user of the Nvidia proprietary graphics driver. > I found similar problem: > https://gitlab.gnome.org/GNOME/mutter/-/issues/2977201 That doesn't seem to be a valid issue URL, do you mean <https://gitlab.gnome.org/GNOME/mutter/-/issues/2977> or something else? https://gitlab.gnome.org/GNOME/mutter/-/issues/2977 seems similar to your first reproducer involving Alt+F2, 'r'. > gnome-shell[24802]: segfault at 28 ip 00007fed6c6f5f14 sp > 00007ffc869e41a0 error 4 in > libmutter-clutter-12.so.0.0.0[7fed6c689000+8d000] likely on CPU 2 (core > 2, socket 0) There is not enough information here to identify a specific crash or find a solution. Please could you get a backtrace? Please see: <https://wiki.debian.org/HowToGetABacktrace>. For gnome-shell, usually the easiest way to get a backtrace is: * Install the systemd-coredump package * Reboot (I'm not sure whether this is strictly necessary but it can't hurt) * Do whatever you need to do to trigger the crash * In a shell: DEBUGINFOD_URLS="https://debuginfod.debian.net"; coredumpctl gdb * Enable automatic download of debug symbols if prompted * At the (gdb) prompt: set pagination off * Still at the (gdb) prompt: bt In your case, you've reported two different ways to trigger this crash (one with Alt+F2, 'r' similar to #1050502, and one with videos similar to #1050512) so it would be useful if you could get a separate backtrace for each one, and send them to the bug address indicating which is which. Also, please look for any messages from gnome-shell in the system log (systemd journal) at the time of the crash, by using the journalctl tool or reading the file /var/log/syslog. For example you might see something similar to this: 2023-09-10T16:09:04.136417+01:00 tautology gnome-shell[2831]: clutter_actor_contains: assertion 'CLUTTER_IS_ACTOR (self)' failed or this: May 7 18:02:51 darter gnome-shell[2213]: Attempting to run a JS callback during garbage collection. This is most likely caused by destroying a Clutter actor or GTK widget with ::destroy signal connected, or using the destroy(), dispose(), or remove() vfuncs. Because it would crash the application, it has been blocked. Please copy anything from around the time of the crash. Thanks, smcv
