GNOME Bugzilla – Bug 426987
Panel freezes after upgrading gtk icon cache
Last modified: 2007-07-20 12:01:40 UTC
$Subject says all. gtk-update-icon-cache is called by post/postun rpm scripts. Only killing (restarting) panel fixes the problem. gdb says: Program received signal SIGSEGV, Segmentation fault. [Switching to Thread -1210578736 (LWP 10542)] _int_malloc (av=0xb7f42180, bytes=10) at malloc.c:4054 4054 bck->fd = bin; (gdb) thread apply all bt
+ Trace 125541
Thread 1 (Thread -1210578736 (LWP 10542))
Can you run the panel in valgrind and try to reproduce the crash? It looks like memory corruption.
I can't reproduce crash running panel in valgrind (it keeps running), but valgrind clearly shows (884, last lines in log) some memory problem after updating icon cache and accessing menu directly after.
Created attachment 88113 [details] valgrind log
Could be related. Moving to GTK+. Here are the relevant lines: ==884== Invalid write of size 4 ==884== at 0x41215E78: get_cached_icon (gtkrecentmanager.c:1978) ==884== Address 0x40BBFCC is 4 bytes inside a block of size 8 free'd ==884== at 0x4005208: free (vg_replace_malloc.c:233) ==884== by 0x4FF17D6B: g_free (gmem.c:187) ==884== by 0x41215D53: icon_cache_element_free (gtkrecentmanager.c:1921) ==884== by 0x4FF04B42: g_hash_table_remove_all (ghash.c:468) ==884== by 0x4FF04BE5: g_hash_table_destroy (ghash.c:221) ==884== by 0x4FEFE241: g_datalist_id_set_data_full (gdataset.c:282) ==884== by 0x4FF8605F: g_object_set_data_full (gobject.c:1880) ==884== by 0x41215DDA: icon_theme_changed (gtkrecentmanager.c:1935) ==884== by 0x4FF7F967: g_closure_invoke (gclosure.c:490) ==884== by 0x4FF94460: signal_emit_unlocked_R (gsignal.c:2440) ==884== by 0x4FF95395: g_signal_emit_valist (gsignal.c:2199) ==884== by 0x4FF95660: g_signal_emit (gsignal.c:2243)
ping
(In reply to comment #5) > ping I can't reproduce. the recent files code keeps a cache of the icon for the mime type of the files, to avoid hitting the disk multiple times; this cache is released on the GtkIconTheme::changed signal, which should be emitted when the icon theme changes or the cache is regenerated. valgrind is reporting that the cache is correctly cleared, but there's an access afterwards, which is weird as the following access should generate a new cache entry. are you using a multihead setup?
no, I got only one display configured.
thanks. talking on irc, it seems that this is a bug hitting some gentoo users too, but it's not strictly triggered by the icon cache generation - which is why I cannot reproduce. the icon cache of GtkRecentManager was added to avoid I/O performance problems; the GtkIconTheme in gtk+ trunk (2.11/2.12) is definitely better at this, so I think we can safely remove the local cache and rely on the icon theme object doing the right thing.
We need a fix for GNOME-2.18 too, that means for gtk+-2.10.x. Attaching a strace output from the freezes I'm experiencing in the end of gnome package upgrading process (around the time that it updates icon caches amongst other things)
Created attachment 90865 [details] end of a strace of gnome-panel before freeze - I have a bigger 1.1MB version too This is a strace -ft `pidof gnome-panel` log while "re-emerging" gnome-applets. It froze around the time the reinstall progress got to update the icon caches and the strace output freezes too, waiting on a futex after another thread or fork segfaulted. I haven't been able to reproduce it yet with just gtk-update-icon-cache --force /icon/path and it doesn't always freeze on gnome package installations, but annoyingly often.
(In reply to comment #9) > We need a fix for GNOME-2.18 too, that means for gtk+-2.10.x. at this point, I'm dubious there will be another gtk+ 2.10 release, since 2.12 is supposed to be released within a month time, and this bug is neither reproducible with a fixed set of steps nor causes catastrophic loss of data. I can attach the patch here and distributions still shipping 2.10 can backport it to their own packages. if mclasen wants to do a last 2.10 release, I can apply it to the gtk-2-10 branch too.
Created attachment 90880 [details] [review] Remove the icon cache from the GtkRecentManager 2007-06-29 Emmanuele Bassi <ebassi@gnome.org> * gtk/gtkrecentmanager.c (get_icon_for_mime_type): Do not cache the icon pixbufs but rely on the GtkIconTheme not to hit the disk cache too much (should tentatively fix #426987).
the patch above has been committed to trunk and should remove the cause of the segfaults by simply removing the icon cache and relying on the GtkIconTheme.
Yes, please do commit to 2.10, if you don't mind. I am definitively thinking about doing one more 2.10 release
committed to gtk-2-10. people experiencing this bug with gtk+ 2.10 would please test it and check whether this has been truly fixed? thanks.
I can confirm, it solves the problem. (gtk+ 2.10.13 with stable branch changes by Emmanuele).
(In reply to comment #16) > I can confirm, it solves the problem. > (gtk+ 2.10.13 with stable branch changes by Emmanuele). thanks for the test.