GNOME Bugzilla – Bug 664026
Gnome shell freezes from time to time
Last modified: 2011-12-16 21:23:03 UTC
Gnome Shell freezes at random intervals. Usually it takes a day or two. Most commonly the bug occurs when scrolling through websites or pdfs. The shell can't be recovered by restarting it. Reboot necessary to get it back working. Sometimes even switching to a virtual console is not possible anymore. Mouse pointer can still be moved when the bug occurs but everything else is frozen. No real errors messages in log files, except for .xsession-errors: (gnome-shell:1182): St-CRITICAL **: _st_paint_shadow_with_opacity: assertion `shadow_spec != NULL' failed Hardware: IBM T60, ATI X1400 using the radeon drivers
Could you get us a backtrace? You'd need to follow the instructions at https://live.gnome.org/GnomeShell/Debugging. Start the debugging early, and work like usual for a few days until the freeze happens. Thanks! You can also try using the proprietary NVidia driver to check where the problem lives, since it seems to be a driver issue.
Thanks, I will try to debug and report back. However, switching the drivers is not possible. I'm using an old ATI X1400 graphics card which is not supported by proprietary drivers anymore.
I debugged gnome-shell but didn't really get much output via gdb. That's probably because I don't have any debugging symbols installed. Sorry, I'm doing this first time. As I'm an archlinux user now, installing debugging symbols means I have to compile the gnome-shell :( but it's the only way, right?
No, there are debugging symbols packages for Arch, you need to ask Ionut Biru (if he doesn't notice this bug).
Created attachment 201748 [details] backtrace backtrace of gnome-shell
So I compiled gnome-shell with debugging symbols, attached gnome-shell to gdb, did a continue in gdb, and waited. After the crash I had to do CTRL-C to get access to the command line in gdb again (is this the right way of doing it?). Then I acquired the backtrace, it's attached. It seems to be a graphics driver issue since restarting gnome shell doesn't work. however, after a reboot everything is fine again.
I think I tracked down the problem. I was looking at the error console of gnome shell and saw a message somewhat like "weather extension is not compatible". I installed the weather extension (https://github.com/simon04/gnome-shell-extension-weather) using gnome shell 3.0 and it disappeared from the panel somewhere along the updates to 3.2 I removed the weather extension's folder from /usr/share/gnome-shell/extensions/. Some hours later I got a freeze but after I rebooted into gnome shell I haven't experienced any freezes. Does that make sense for you?
Dear developers, the problem seems to be resolved. Thanks for your help, Milan! So is this a bug or not? Clearly the problem cause is not gnome shell itself, but maybe it shouldn't crash like that when dealing with buggy extensions?
Yes, the shell shouldn't crash when using the weather extension. I've tried to debug it, and I couldn't find the problem. Still, the corresponding unthread-safe code in gjs has been removed. *** This bug has been marked as a duplicate of bug 661323 ***
I was cheering to soon. The problem still exists without the weather extension but somehow seems to appear less often. So this is not a duplicate bug, but apparently not a bug of gnome shell either. A person with the same laptop as me has the problem using XFCE with compiz enabled [1]. Also I found a person with a different laptop but same graphics card who has the problem using gnome shell [2]. The devil seems to be ATI X1400 graphics card and the open source drivers... Any ideas on how to debug this problem? If not I will leave you alone now ;) [1] https://bbs.archlinux.org/viewtopic.php?pid=1028846#p1028846 [2] http://askubuntu.com/questions/70504/mouse-can-still-move-but-no-clicks-are-registered-and-everything-is-locked-up
If it happens also under Compiz, then that's simply a X freeze. Report a bug to X.org on bugs.freedesktop.org for your driver, and include there the output from dmesg and /var/log/Xorg.0.log. They'll probably ask you to get more precise information, but they'll know better than I do.