GNOME Bugzilla – Bug 694755
When clicking Activities, sometimes gnome-shell crashes.
Last modified: 2013-08-16 20:14:20 UTC
(gdb) bt
+ Trace 231575
gnome-shell-3.7.90-1.fc19.x86_64 gtk3-3.7.10-1.fc19.x86_64 clutter-1.13.6-1.fc19.x86_64 cogl-1.13.4-1.fc19.x86_64 vga intel HD 4000
Sometimes, after installing package, click super key(Activities) -> segmentation fault Program terminated with signal 11, Segmentation fault.
+ Trace 231618
gnome-shell-3.7.91-1.fc19.x86_64 cogl-1.13.4-1.fc19.x86_64 clutter-1.13.8-1.fc19.x86_64 gtk3-3.7.12-1.fc19.x86_64
After updating packages, Core was generated by `/usr/bin/gnome-shell'. Program terminated with signal 6, Aborted. (gdb) bt
+ Trace 231667
gnome-shell-3.7.92-1.fc19.x86_64 clutter-1.13.10-1.fc19.x86_64 gtk3-3.7.14-1.fc19.x86_64 glib2-2.35.9-1.fc19.x86_64
Has anybody tried reproducing this ?
doesn't seem to be the case :-(
in gnome-shell 3.8 # yum update totem gnome* vte3 zenity # cat /var/log/yum.log [....] Mar 27 22:13:26 Updated: gnome-icon-theme-3.8.0-1.fc19.noarch Mar 27 22:13:27 Updated: vte3-0.34.3-1.fc19.x86_64 Mar 27 22:13:29 Updated: 1:totem-3.8.0-1.fc19.x86_64 Mar 27 22:13:31 Updated: gnome-desktop3-3.8.0-1.fc19.x86_64 Mar 27 22:13:32 Updated: gnome-online-accounts-3.8.0-1.fc19.x86_64 Mar 27 22:13:33 Updated: 1:gnome-bluetooth-libs-3.8.0-1.fc19.x86_64 Mar 27 22:13:34 Updated: 1:gnome-bluetooth-3.8.0-1.fc19.x86_64 Mar 27 22:13:34 Updated: gnome-online-accounts-devel-3.8.0-1.fc19.x86_64 Mar 27 22:13:36 Updated: gnome-color-manager-3.8.0-1.fc19.x86_64 Mar 27 22:13:37 Updated: 1:totem-nautilus-3.8.0-1.fc19.x86_64 Mar 27 22:13:37 Updated: vte3-devel-0.34.3-1.fc19.x86_64 Mar 27 22:13:38 Updated: gnome-power-manager-3.8.0-1.fc19.x86_64 Mar 27 22:13:39 Updated: gnome-boxes-3.8.0-1.fc19.x86_64 Mar 27 22:13:42 Updated: gnome-packagekit-3.8.0-1.fc19.x86_64 Mar 27 22:13:43 Updated: gnome-icon-theme-symbolic-3.8.0.1-1.fc19.noarch Mar 27 22:13:44 Updated: gnome-icon-theme-legacy-3.8.0-1.fc19.noarch Mar 27 22:13:46 Updated: gnome-calculator-3.8.0-1.fc19.x86_64 Mar 27 22:13:47 Updated: gnome-system-monitor-3.8.0-1.fc19.x86_64 Mar 27 22:13:49 Updated: gnome-getting-started-docs-3.8.0.1-1.fc19.noarch Mar 27 22:13:51 Updated: zenity-3.8.0-2.fc19.x86_64 Click Super key Core was generated by `/usr/bin/gnome-shell'. Program terminated with signal 11, Segmentation fault.
+ Trace 231691
Bug 696720 has a patch that I wrote after I experienced a similar crash. Running with that applied, gnome-shell hasn't crashed yet.
The backtrace in https://bugzilla.redhat.com/928755 looks similar, but it's lacking some details because ABRT hasn't been nice to me lately. About reproducibility: After an ordinary "yum update" GNOME Shell has crashed for me every day when moving the mouse pointer to the Activities hotspot. It appeared like frozen, then restarted. After some days I've thought the crash would be the same each time, but ABRT had generated a different backtrace, too: https://bugzilla.redhat.com/926043
This issue still happens in GNOME 3.8.1. ABRT Server: URL = https://retrace.fedoraproject.org/faf/reports/87760/ Bugzilla: URL = https://bugzilla.redhat.com/show_bug.cgi?id=914942
in gnome-shell 3.8.2 After updating gnome-photos package, click super key -> gnome-shell crashes. Core was generated by `/usr/bin/gnome-shell'. Program terminated with signal 11, Segmentation fault.
+ Trace 231981
I think i figured out how this happens. The crash starts in st_icon_update() where we do: priv->pending_texture = st_texture_cache_load_gicon (cache, theme_node, priv->gicon, priv->icon_size); passing in priv->gicon. This code will get the array of icon names from the GIcon, and eventually end up in gtk_icon_theme_choose_icon(), which does: ensure_valid_themes (icon_theme); key.icon_names = (char **)icon_names; key.size = size; key.flags = flags; icon_info = g_hash_table_lookup (priv->info_cache, &key); The lookup crashes when its calculating the hash value for key because key.icon_names seem to point to some bad memory. This seems weird, because we just passed in the icon names from the icon! However, notice the call to ensure_valid_themes() before the lookup. If the user recently installed or updated an icon in the icon theme this will emit the icon theme changed signal. My guess is that gnome-shell somehow catches this and resets priv->gicon on the StIcon, freeing the old GIcon an thus making icon_names point to some invalid memory.
Created attachment 247241 [details] [review] IconTheme: Move changed emission to an idle By delaying the emission to an idle we avoid a lot of tricky reentrancy issues. For instance, a normal gtk_icon_theme_choose_icon() call could in very rare cases (when a user updated an icon theme) emit a signal which could affect the icon currently being looked up. This kind of reentrancy is very hard to test against, especially when it is so rare, so we're better of avoiding it. There is no real value to get the change signal directly anyway. All it can do is affect which icon is rendered the next frame, and we will handle the queued emission before rendering. Not to mention that icon theme change detection is polled anyway, so it is already delayed.
Comment on attachment 247241 [details] [review] IconTheme: Move changed emission to an idle Attachment 247241 [details] pushed as 159cccf - IconTheme: Move changed emission to an idle
I believe this patch should fix this bug, but i can't reproduce the actual crash so i can't verify this.
Patch has been committed
*** Bug 702701 has been marked as a duplicate of this bug. ***
*** Bug 704954 has been marked as a duplicate of this bug. ***