GNOME Bugzilla – Bug 557059
crash when compositing emblems with icon
Last modified: 2009-03-02 15:05:00 UTC
I have a treeview with a pixbuf cell renderer, displaying GIcons. The icons in my model are emblemed icons, containing a "go-up" themed icon emblemed upon a mime type icon. See attached testcase. Steps to repro: Run the testcase. Results: Crash. (gdb) where 20
+ Trace 208417
Valgrind info: ==11064== Process terminating with default action of signal 11 (SIGSEGV) ==11064== Bad permissions for mapped region at address 0x8AA62C8 ==11064== at 0x462555B: composite_line (pixops.c:640) ==11064== by 0x46271F9: pixops_process (pixops.c:1340) ==11064== by 0x4628153: _pixops_composite_real (pixops.c:1798) ==11064== by 0x4628368: _pixops_composite (pixops.c:1865) ==11064== by 0x461DE4F: gdk_pixbuf_composite (gdk-pixbuf-scale.c:142) ==11064== by 0x41644C1: apply_emblems (gtkicontheme.c:2829) ==11064== by 0x4164A79: icon_info_ensure_scale_and_pixbuf (gtkicontheme.c:3014) ==11064== by 0x4164B21: gtk_icon_info_load_icon (gtkicontheme.c:3050) ==11064== by 0x40CA907: gtk_cell_renderer_pixbuf_create_themed_pixbuf (gtkcellrendererpixbuf.c:464) ==11064== by 0x40CAC2F: gtk_cell_renderer_pixbuf_get_size (gtkcellrendererpixbuf.c:548) ==11064== by 0x40C7160: gtk_cell_renderer_get_size (gtkcellrenderer.c:522) This is with gtk+ svn trunk.
Created attachment 120918 [details] testcase
Created attachment 120919 [details] [review] proposed patch This patch fixes the crash for me.
Not sure I understand the pixbuf copying business. Why is that needed ?
Well, the valgrind hint ==11064== Bad permissions for mapped region at address 0x8AA62C8 made me think that maybe the pixbuf in question is a cache pixbuf with data from the builtin icons or from the icon theme cache (and thus cannot be used as dest pixbuf in gdk_pixbuf_composite) ?
good point.
please commit to trunk and gtk-2-14
Committed to trunk and 2-14. The pixbuf copying could be omitted when unnecessary, if there was a way to check whether the pixbuf's data is mutable, but there appears to be no such way?
*** Bug 573764 has been marked as a duplicate of this bug. ***