GNOME Bugzilla – Bug 673512
gnome-shell crashed with SIGSEGV in magazine_chain_pop_head()
Last modified: 2012-04-05 08:53:46 UTC
gnome-shell crashes when going to the Activities Overview after gtk-update-icon-cache is triggered. It's not new, it started to crash months ago, but I don't remember exactly when :( (I've already mentioned it on irc ~a month ago) This happens a lot on Ubuntu, as gtk-update-icon-cache is automatically triggered by some (unrelated) packages during system upgrades. I can also reproduce it just by changing the icon-theme.cache inode (cp icon-theme.cache x ; mv x icon-theme.cache). It seems to happen only on 32bit. See https://bugs.launchpad.net/ubuntu/+source/gnome-shell/+bug/955845 listing all the dupes. Some are using the nvidia blob, but not all. Here is a recent stack trace with 3.4+:
+ Trace 230008
Disassembly: => 0x773416 <g_slice_alloc+486>: mov (%esi),%edx 0x773418 <g_slice_alloc+488>: mov %edx,0x4(%eax) 0x77341b <g_slice_alloc+491>: mov 0x4(%edi),%eax 0x77341e <g_slice_alloc+494>: test %eax,%eax 0x773420 <g_slice_alloc+496>: je 0x773280 <g_slice_alloc+80> 0x773426 <g_slice_alloc+502>: sub $0x1,%eax 0x773429 <g_slice_alloc+505>: mov %eax,0x4(%edi) 0x77342c <g_slice_alloc+508>: jmp 0x773280 <g_slice_alloc+80> 0x773431 <g_slice_alloc+513>: lea 0x0(%esi,%eiz,1),%esi 0x773438 <g_slice_alloc+520>: mov 0xa54(%ebx),%edx 0x77343e <g_slice_alloc+526>: test %edx,%edx 0x773440 <g_slice_alloc+528>: jne 0x773276 <g_slice_alloc+70> 0x773446 <g_slice_alloc+534>: mov 0xa50(%ebx),%edx 0x77344c <g_slice_alloc+540>: sub $0x18,%edx 0x77344f <g_slice_alloc+543>: shr $0x3,%edx 0x773452 <g_slice_alloc+546>: cmp %edx,%eax Segfault happened at: 0x773416 <g_slice_alloc+486>: mov (%esi),%edx PC (0x00773416) ok source "(%esi)" (0x695f7473) not located in a known VMA region (needed readable region)! destination "%edx" ok
Could you run the Shell in Valgrind and reproduce the crash? You need to install debugging symbols for gnome-shell, mutter, glib and clutter. Then, the command is: G_SLICE=always-malloc G_DEBUG=gc-friendly valgrind --tool=memcheck gnome-shell Thanks!
Created attachment 211315 [details] valgrind logs sure. Here is it. Look inside for "FTA" marking where i tried to reproduce the crash.
Great! All the invalid reads are similar, looks like we try to use an icon that has been freed from the cache: ==8510== Invalid read of size 1 ==8510== at 0x40880B9: load_gicon_with_colors (st-texture-cache.c:917) ==8510== by 0x4088A6F: st_texture_cache_load_icon_name (st-texture-cache.c:1211) ==8510== by 0x407A3B4: st_icon_update (st-icon.c:490) ==8510== by 0x4556222: g_cclosure_marshal_VOID__VOIDv (gmarshal.c:115) ==8510== by 0x4552DB6: g_type_class_meta_marshalv (gclosure.c:997) ==8510== by 0x4554706: _g_closure_invoke_va (gclosure.c:840) ==8510== by 0x456DA08: g_signal_emit_valist (gsignal.c:3207) ==8510== by 0x456E432: g_signal_emit (gsignal.c:3352) ==8510== by 0x4099081: st_widget_recompute_style (st-widget.c:1533) ==8510== by 0x4099275: st_widget_map (st-widget.c:444) ==8510== by 0x5074522: clutter_actor_set_mapped (clutter-actor.c:1144) ==8510== by 0x508026B: clutter_actor_update_map_state (clutter-actor.c:1354) ==8510== Address 0x17791eeb is 19 bytes inside a block of size 20 free'd ==8510== at 0x402B06C: free (in /usr/lib/valgrind/vgpreload_memcheck-x86-linux.so) ==8510== by 0x45E3CCA: standard_free (gmem.c:98) ==8510== by 0x45E3F4F: g_free (gmem.c:252) ==8510== by 0x45F88FA: g_slice_free1 (gslice.c:1111) ==8510== by 0x407B6B5: st_icon_colors_unref (st-icon-colors.c:75) ==8510== by 0x408BC10: st_theme_node_dispose (st-theme-node.c:96) ==8510== by 0x4559181: g_object_unref (gobject.c:2981) ==8510== by 0x40992E5: st_widget_style_changed (st-widget.c:505) ==8510== by 0x176A9D77: ???
Created attachment 211341 [details] [review] st-theme-context: Make icon theme changes a bit more efficient There's no need to destroy and recreate the root node for an icon theme change. Just emit the CHANGED signal.
Created attachment 211342 [details] [review] st-theme-context: Punt icon theme changes to an idle Icon theme change signals aren't noticed immediately, they're usually noticed when trying to load an icon. Since icon theme changes cause a style change, and most icon widgets try to re-load their texture during a style change, this means that we get a stack like this: st_texture_cache_load_icon gtk_icon_theme_lookup_icon gtk_icon_theme_changed st_widget_style_changed st_texture_cache_load_icon Rather than making every place that uses StTextureCache re-entrant, punt the notifying of icon theme changes to an idle handler instead.
Review of attachment 211341 [details] [review]: Don't really see the point - we're going to recreate the rest of the theme nodes for the actor hierarchy - what's one more? (I don't really object to this patch, I just don't think it's measurable with a microscope)
Review of attachment 211342 [details] [review]: Looks good - I wouldn't have complained if you had just done the don't recreate-the-theme-node in this patch and not commented, so feel free to push the pair like this. (From discussion on irc: don't make st_theme_context_changed() have the signature for an idle handler - the naming implies that it is "like a public function" even if it's static, so shouldnt't get a random return value)
Attachment 211341 [details] pushed as 00091a2 - st-theme-context: Make icon theme changes a bit more efficient Attachment 211342 [details] pushed as 0a7968a - st-theme-context: Punt icon theme changes to an idle
Thanks. I confirm it no longer crashes. Marking verified.