After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 557059 - crash when compositing emblems with icon
crash when compositing emblems with icon
Status: RESOLVED FIXED
Product: gtk+
Classification: Platform
Component: Widget: Other
unspecified
Other Linux
: Normal critical
: ---
Assigned To: gtk-bugs
gtk-bugs
: 573764 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2008-10-20 11:22 UTC by Christian Persch
Modified: 2009-03-02 15:05 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
testcase (2.98 KB, text/plain)
2008-10-20 11:23 UTC, Christian Persch
  Details
proposed patch (1.15 KB, patch)
2008-10-20 11:33 UTC, Christian Persch
accepted-commit_now Details | Review

Description Christian Persch 2008-10-20 11:22:27 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
  • #0 composite_line
    at pixops.c line 640
  • #1 pixops_process
    at pixops.c line 1340
  • #2 _pixops_composite_real
    at pixops.c line 1798
  • #3 _pixops_composite
    at pixops.c line 1865
  • #4 gdk_pixbuf_composite
    at gdk-pixbuf-scale.c line 142
  • #5 apply_emblems
    at gtkicontheme.c line 2829
  • #6 icon_info_ensure_scale_and_pixbuf
    at gtkicontheme.c line 3014
  • #7 gtk_icon_info_load_icon
    at gtkicontheme.c line 3050
  • #8 gtk_cell_renderer_pixbuf_create_themed_pixbuf
    at gtkcellrendererpixbuf.c line 464
  • #9 gtk_cell_renderer_pixbuf_get_size
    at gtkcellrendererpixbuf.c line 548
  • #10 gtk_cell_renderer_get_size
    at gtkcellrenderer.c line 522


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.
Comment 1 Christian Persch 2008-10-20 11:23:23 UTC
Created attachment 120918 [details]
testcase
Comment 2 Christian Persch 2008-10-20 11:33:32 UTC
Created attachment 120919 [details] [review]
proposed patch

This patch fixes the crash for me.
Comment 3 Matthias Clasen 2008-10-20 14:01:15 UTC
Not sure I understand the pixbuf copying business. Why is that needed ?
Comment 4 Christian Persch 2008-10-20 14:14:04 UTC
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) ?
Comment 5 Matthias Clasen 2008-10-20 14:25:40 UTC
good point.
Comment 6 Matthias Clasen 2008-10-20 14:25:57 UTC
please commit to trunk and gtk-2-14
Comment 7 Christian Persch 2008-10-20 16:57:39 UTC
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?
Comment 8 Christian Persch 2009-03-02 15:05:00 UTC
*** Bug 573764 has been marked as a duplicate of this bug. ***