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 614800 - Crash in find_image_offset()
Crash in find_image_offset()
Status: RESOLVED INCOMPLETE
Product: gtk+
Classification: Platform
Component: Widget: Other
2.22.x
Other Linux
: High normal
: ---
Assigned To: gtk-bugs
gtk-bugs
: 615929 622348 631155 632822 632854 633213 634073 634111 634625 634709 636765 637514 637535 638194 638243 638917 639333 639594 639650 639915 640339 640884 640918 641589 642079 642776 644096 644901 645122 645426 648901 649180 650081 652117 654759 660683 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2010-04-04 09:21 UTC by Milan Bouchet-Valat
Modified: 2014-11-29 17:53 UTC
See Also:
GNOME target: ---
GNOME version: 2.31/2.32


Attachments
1st valgrind log (60.67 KB, text/x-log)
2011-01-16 11:35 UTC, medic123
Details
2nd valgrind log (50.01 KB, text/x-log)
2011-01-16 11:37 UTC, medic123
Details
valgrind log with dbg appmenu-gtk-symbols (57.19 KB, text/x-log)
2011-01-25 21:59 UTC, medic123
Details
valgrind log with crash! (6.49 KB, text/plain)
2011-02-21 21:45 UTC, medic123
Details

Description Milan Bouchet-Valat 2010-04-04 09:21:42 UTC
This is on Ubuntu 10.04. The trace is from g-s-d 2.29.92, but it still occurs with 2.30. I've been able to reproduce the crash twice, once when changing theme and another time when upgrading my packages. There are also a few duplicates.

From a quick look, it seems that icon_name is not filled correctly:
theme_dir_get_icon_suffix (dir=<value optimized out>, icon_name=0x1 <Address 0x1 out of bounds>, has_icon_file=0x0)

Reported on https://bugs.launchpad.net/ubuntu/+source/gnome-settings-daemon/+bug/551809


  • #0 find_image_offset
    at /build/buildd/gtk+2.0-2.20.0/gtk/gtkiconcache.c line 208
  • #1 _gtk_icon_cache_get_icon_flags
    at /build/buildd/gtk+2.0-2.20.0/gtk/gtkiconcache.c line 283
  • #2 theme_dir_get_icon_suffix
    at /build/buildd/gtk+2.0-2.20.0/gtk/gtkicontheme.c line 2069
  • #3 choose_icon
    at /build/buildd/gtk+2.0-2.20.0/gtk/gtkicontheme.c line 2132
  • #4 ensure_pixbuf_for_gicon
    at /build/buildd/gtk+2.0-2.20.0/gtk/gtkimage.c line 1771
  • #5 gtk_image_calc_size
    at /build/buildd/gtk+2.0-2.20.0/gtk/gtkimage.c line 2333
  • #6 gtk_image_size_request
    at /build/buildd/gtk+2.0-2.20.0/gtk/gtkimage.c line 2359
  • #7 g_cclosure_marshal_VOID__BOXED
    from /usr/lib/libgobject-2.0.so.0
  • #8 ??
    from /usr/lib/libgobject-2.0.so.0
  • #9 g_closure_invoke
    from /usr/lib/libgobject-2.0.so.0
  • #10 ??
    from /usr/lib/libgobject-2.0.so.0
  • #11 g_signal_emit_valist
    from /usr/lib/libgobject-2.0.so.0
  • #12 g_signal_emit_by_name
    from /usr/lib/libgobject-2.0.so.0
  • #13 do_size_request
    at /build/buildd/gtk+2.0-2.20.0/gtk/gtksizegroup.c line 628
  • #14 _gtk_size_group_compute_requisition
    at /build/buildd/gtk+2.0-2.20.0/gtk/gtksizegroup.c line 828
  • #15 IA__gtk_widget_size_request
    at /build/buildd/gtk+2.0-2.20.0/gtk/gtkwidget.c line 3886
  • #16 gtk_window_size_request
    at /build/buildd/gtk+2.0-2.20.0/gtk/gtkwindow.c line 4953
  • #17 g_cclosure_marshal_VOID__BOXED
    from /usr/lib/libgobject-2.0.so.0
  • #18 ??
    from /usr/lib/libgobject-2.0.so.0
  • #19 g_closure_invoke
    from /usr/lib/libgobject-2.0.so.0
  • #20 ??
    from /usr/lib/libgobject-2.0.so.0
  • #21 g_signal_emit_valist
    from /usr/lib/libgobject-2.0.so.0
  • #22 g_signal_emit_by_name
    from /usr/lib/libgobject-2.0.so.0
  • #23 do_size_request
    at /build/buildd/gtk+2.0-2.20.0/gtk/gtksizegroup.c line 628
  • #24 _gtk_size_group_compute_requisition
    at /build/buildd/gtk+2.0-2.20.0/gtk/gtksizegroup.c line 828
  • #25 IA__gtk_widget_size_request
    at /build/buildd/gtk+2.0-2.20.0/gtk/gtkwidget.c line 3886
  • #26 gtk_window_compute_configure_request
    at /build/buildd/gtk+2.0-2.20.0/gtk/gtkwindow.c line 5837
  • #27 gtk_window_check_resize
    at /build/buildd/gtk+2.0-2.20.0/gtk/gtkwindow.c line 6049
  • #28 gtk_plug_check_resize
    at /build/buildd/gtk+2.0-2.20.0/gtk/gtkplug.c line 992
  • #29 g_cclosure_marshal_VOID__VOID
    from /usr/lib/libgobject-2.0.so.0
  • #30 ??
    from /usr/lib/libgobject-2.0.so.0
  • #31 g_closure_invoke
    from /usr/lib/libgobject-2.0.so.0
  • #32 ??
    from /usr/lib/libgobject-2.0.so.0
  • #33 g_signal_emit_valist
    from /usr/lib/libgobject-2.0.so.0
  • #34 g_signal_emit
    from /usr/lib/libgobject-2.0.so.0
  • #35 IA__gtk_container_check_resize
    at /build/buildd/gtk+2.0-2.20.0/gtk/gtkcontainer.c line 1425
  • #36 gtk_container_idle_sizer
    at /build/buildd/gtk+2.0-2.20.0/gtk/gtkcontainer.c line 1350
  • #37 gdk_threads_dispatch
    at /build/buildd/gtk+2.0-2.20.0/gdk/gdk.c line 512
  • #38 ??
    from /lib/libglib-2.0.so.0
  • #39 g_main_context_dispatch
    from /lib/libglib-2.0.so.0
  • #40 ??
    from /lib/libglib-2.0.so.0
  • #41 g_main_loop_run
    from /lib/libglib-2.0.so.0
  • #42 IA__gtk_main
    at /build/buildd/gtk+2.0-2.20.0/gtk/gtkmain.c line 1219
  • #43 main
    at main.c line 502

Comment 1 Tobias Mueller 2010-09-01 19:30:33 UTC
*** Bug 615929 has been marked as a duplicate of this bug. ***
Comment 2 Milan Bouchet-Valat 2010-09-13 11:06:58 UTC
Moving component: since the bug seems to happen when rebuilding the theme cache, it must be in GTK+.
Comment 3 Milan Bouchet-Valat 2010-09-13 11:45:44 UTC
Trace is weird because ensure_pixbuf_for_gicon() from gtkimage.c doesn't call choose_icon() from gtkicontheme.c directly, but via gtk_icon_theme_lookup_by_gicon() and gtk_icon_theme_choose_icon().

Anyway, the invalid pointers containing icon names must come from there, where we have:
>  else if (G_IS_THEMED_ICON (icon))
>    {
>      const gchar **names;
>
>      names = (const gchar **)g_themed_icon_get_names (G_THEMED_ICON (icon));
>      info = gtk_icon_theme_choose_icon (icon_theme, names, size, flags);
>
>      return info;
>    }

g_themed_icon_get_names(), in glib/gio/gthemedicon.c, merely does a type check and:
>  return (const char * const *)icon->names;

So I guess that when theme cache is updated, icon->names is freed and becomes somewhat corrupted. But I couldn't find a place where something is obviously wrong in GThemedIcon.

A possible explanation is that choose_icon() in gtkicontheme.c calls ensure_valid_themes(). Which means we have:
- g_themed_icon_get_names()
- ensure_valid_themes()
- theme_lookup_icon()

If ensure_valid_themes() triggers the destruction of the GThemedIcon, theme_lookup_icon() will find itself using invalid pointers. Not sure that's possible, but that doesn't seem so unlikely. The simple fix would mean copying the strv before updating themes, but there may be a way of checking whether the icon has disappeared.
Comment 4 Milan Bouchet-Valat 2010-09-14 19:48:46 UTC
Matthias suggested the GIcon is wrongly freed because the application is buggy and releases the reference it holds when the 'changed' signal is emitted by GtkIconTheme destroys it. But there's no application here: the GtkImage should own the GIcon (and it indeed does ref it).

The application could theoretically mess with references on a GIcon passed to GtkImage by unref()ing too often... but g-s-d doesn't use GIcon at all... So no luck.

The trace looks like the crash happens when a window is performing size requisition (from gtk_container_idle_sizer), and there are two GtkSizeGroups, the child group owning a widget whose type is hard to guess - maybe a GtkButton in a dialog's action area?

We have a few interesting warnings in ~/.xsession-errors, which are common to many reports:
(bluetooth-applet:1604): Gtk-CRITICAL **: IA__gtk_widget_set_sensitive: assertion `GTK_IS_WIDGET (widget)' failed
(nautilus:1594): GConf-CRITICAL **: gconf_value_free: assertion `value != NULL' failed
(gnome-appearance-properties:1869): Gdk-CRITICAL **: IA__gdk_display_sync: assertion `GDK_IS_DISPLAY (display)' failed
(gnome-appearance-properties:1869): Gdk-CRITICAL **: IA__gdk_display_sync: assertion `GDK_IS_DISPLAY (display)' failed
(empathy:1938): Gdk-CRITICAL **: IA__gdk_drawable_get_size: assertion `GDK_IS_DRAWABLE (drawable)' failed
(empathy:1938): Gdk-CRITICAL **: gdk_window_invalidate_rect_full: assertion `GDK_IS_WINDOW (window)' failed
(see for example http://launchpadlibrarian.net/54502134/XsessionErrors.txt)
Comment 5 Milan Bouchet-Valat 2010-09-14 22:30:08 UTC
OK, so it seems the GtkPlug that appears in the trace comes from GtkStatusIcon, which eventually led me to Ubuntu's libappindicator patches. When indicator applet isn't in the panel, it falls back to status icons.

There, the code is using gtk_status_icon_set_from_gicon(), but it seems nothing is wrong since the GIcon is created right before this call (using g_themed_icon_new_with_default_fallbacks()), and unreferenced right after.


Considering the GDK_IS_DISPLAY (display) assertion errors quoted above, I'm wondering if anything could break the GdkDisplay, thus killing the GtkPlug that is used by GtkStatusIcon, destroying it's child GtkImage and the associated GIcon; all this process happening in the middle of a call to gtk_icon_theme_lookup_by_gicon(). But that might be far too crazy to happen, and I don't know how this works at all.


The problem with the reference count theory is that we must find the place where the GIcon is unreferenced when themes are updated. I didn't find such a call, since GtkIconCache doesn't use GIcons. If this call doesn't exist, it's hard to explain why the GIcon would be destroyed right in the middle of the lookup - and it must happen just after gtk_icon_theme_lookup_by_gicon(), since there are G_IS_THEMED_ICON() checks in it.
Comment 6 Milan Bouchet-Valat 2010-09-20 20:41:04 UTC
I'm happy to note that today I reproduced the crash without updating my icon cache, and (roll drum) with gnome-power-manager. So, it's definitely linked with the libappindicator use of GtkStatusIcon, and not to gnome-settings-daemon.
Comment 7 Milan Bouchet-Valat 2010-10-04 13:59:50 UTC
The first time you show gnome-power-manager's status icon, Valgrind reports the following trace. I'm not sure at all this is a real issue or just a red herring, because png_zalloc() is a callback provided by libpng to zlib, which calls it when it needs to allocate memory: png_zalloc() can return 0 if it thinks not enough memory is available.

The code is quite complex, with many conditions leading to different return paths. But I don't see how an uninitialized memory area could lead to far-fetched consequences in a random GIcon... We're not talking about 

Note this is with libpng 1.2.44 sadly, 1.4.4 may have fixed this issue.

==25844==    at 0x4DCD611: inflateReset2 (inflate.c:157)
==25844==    by 0x4DCD6EC: inflateInit2_ (inflate.c:193)
==25844==    by 0x4DCD762: inflateInit_ (inflate.c:206)
==25844==    by 0x4C6DF13: png_create_read_struct_2 (pngread.c:164)
==25844==    by 0x68523BA: gdk_pixbuf__png_image_begin_load (io-png.c:443)
==25844==    by 0x467D839: gdk_pixbuf_loader_load_module (gdk-pixbuf-loader.c:384)
==25844==    by 0x467E534: gdk_pixbuf_loader_write (gdk-pixbuf-loader.c:419)
==25844==    by 0x467BD54: load_from_stream (gdk-pixbuf-io.c:1374)
==25844==    by 0x467BE07: gdk_pixbuf_new_from_stream (gdk-pixbuf-io.c:1492)
==25844==    by 0x42E8DC8: icon_info_ensure_scale_and_pixbuf (gtkicontheme.c:2984)
==25844==    by 0x42E94E0: gtk_icon_info_load_icon (gtkicontheme.c:3066)
==25844==    by 0x42FD805: ensure_pixbuf_for_gicon (gtkimage.c:1778)
==25844==  Uninitialised value was created by a heap allocation
==25844==    at 0x4025BD3: malloc (vg_replace_malloc.c:236)
==25844==    by 0x48343D7: g_try_malloc (gmem.c:284)
==25844==    by 0x6852C4C: png_malloc_callback (io-png.c:237)
==25844==    by 0x4C77BE7: png_malloc (pngmem.c:466)
==25844==    by 0x4C5F8A0: png_zalloc (png.c:175)
==25844==    by 0x4DCD6C8: inflateInit2_ (inflate.c:187)
==25844==    by 0x4DCD762: inflateInit_ (inflate.c:206)
==25844==    by 0x4C6DF13: png_create_read_struct_2 (pngread.c:164)
==25844==    by 0x68523BA: gdk_pixbuf__png_image_begin_load (io-png.c:443)
==25844==    by 0x467D839: gdk_pixbuf_loader_load_module (gdk-pixbuf-loader.c:384)
==25844==    by 0x467E534: gdk_pixbuf_loader_write (gdk-pixbuf-loader.c:419)
==25844==    by 0x467BD54: load_from_stream (gdk-pixbuf-io.c:1374)
Comment 8 Baptiste Mille-Mathias 2010-10-05 19:05:05 UTC
*** Bug 631155 has been marked as a duplicate of this bug. ***
Comment 9 Akhil Laddha 2010-10-22 12:32:37 UTC
*** Bug 632854 has been marked as a duplicate of this bug. ***
Comment 10 Akhil Laddha 2010-10-22 12:32:50 UTC
*** Bug 632822 has been marked as a duplicate of this bug. ***
Comment 11 Akhil Laddha 2010-10-27 04:06:05 UTC
*** Bug 633213 has been marked as a duplicate of this bug. ***
Comment 12 Fabio Durán Verdugo 2010-11-06 01:34:50 UTC
*** Bug 634111 has been marked as a duplicate of this bug. ***
Comment 13 Fabio Durán Verdugo 2010-11-06 01:35:10 UTC
*** Bug 634073 has been marked as a duplicate of this bug. ***
Comment 14 Akhil Laddha 2010-11-12 04:30:20 UTC
*** Bug 634625 has been marked as a duplicate of this bug. ***
Comment 15 Akhil Laddha 2010-11-13 01:47:15 UTC
*** Bug 634709 has been marked as a duplicate of this bug. ***
Comment 16 Akhil Laddha 2010-12-08 12:50:48 UTC
*** Bug 636765 has been marked as a duplicate of this bug. ***
Comment 17 Fabio Durán Verdugo 2010-12-18 22:50:19 UTC
*** Bug 637535 has been marked as a duplicate of this bug. ***
Comment 18 Milan Bouchet-Valat 2010-12-18 23:33:49 UTC
All duplicates are from Ubuntu systems, so that supports our suspicions that this bug comes from application indicators (more precisely, their GtkStatusIcon fallback).

Bug 637535 has an interesting point, which also supports my conclusions:
> when the window popped up, it was doing this:
> Processing triggers for hicolor-icon-theme ...
In some cases, but not every time, updating icon themes leads to this crash. (It can also happen without updating icon cache, though I'm not sure exactly when.)
Comment 19 medic123 2010-12-19 01:04:42 UTC
due to the fact i had triggered this bug 5 times within last 2 weeks in ubuntu 11.04 and it had hit nm-applet every time, i guess that this could be a start for reproducing and debugging.

I use wlan, so nm-applet changes icons a couple of times in no time..
( Connect->disconnect->connecting->connected )
Comment 20 Milan Bouchet-Valat 2010-12-19 12:12:14 UTC
Interesting. If you're more or less able to reproduce it, can you run nm-applet in Valgrind to get more details on the crash? The commands are:
killall nm-applet
G_SLICE=always-malloc G_DEBUG=gc-friendly valgrind --tool=memcheck --num-callers=20 --log-file=nm-applet-valgrind.log nm-applet
and you need to wait until the crash happens.

But before that, please install debugging information from:
http://ddebs.ubuntu.com/pool/main/g/glib2.0/
http://ddebs.ubuntu.com/pool/main/libi/libindicator/
One for glib and one for libindicator. Version and architecture depend on you system, but you can find out which one you need with:
apt-cache policy libglib2.0-0
apt-cache policy libindicator1

Thanks!
Comment 21 Akhil Laddha 2010-12-20 04:18:50 UTC
*** Bug 637514 has been marked as a duplicate of this bug. ***
Comment 22 Akhil Laddha 2010-12-20 04:19:12 UTC
*** Bug 622348 has been marked as a duplicate of this bug. ***
Comment 23 Fabio Durán Verdugo 2010-12-28 20:11:08 UTC
*** Bug 638194 has been marked as a duplicate of this bug. ***
Comment 24 Akhil Laddha 2010-12-29 11:55:52 UTC
*** Bug 638243 has been marked as a duplicate of this bug. ***
Comment 25 Fabio Durán Verdugo 2011-01-12 23:41:23 UTC
*** Bug 639333 has been marked as a duplicate of this bug. ***
Comment 26 medic123 2011-01-13 00:14:26 UTC
i have put valgrind on nm-applet, as you suggested, and wasnt able to crash nm-applet again.
But what i see, is that it tries to load a bunch of nonexistant icons and prints an error, where it crashed before...

not sure though if this nonexistent icon could trigger this error - but it seems it was introduced ( and fixed? ) by Debian & Ubuntu.
Comment 27 Milan Bouchet-Valat 2011-01-13 10:26:43 UTC
Valgrind log, please? ;-)

I don't think it's been fixed, it's just that it's only triggered when performing major package upgrades, which typically happens on development releases.
Comment 28 Akhil Laddha 2011-01-15 14:09:04 UTC
*** Bug 639594 has been marked as a duplicate of this bug. ***
Comment 29 medic123 2011-01-16 11:35:06 UTC
Created attachment 178438 [details]
1st valgrind log
Comment 30 medic123 2011-01-16 11:37:42 UTC
Created attachment 178439 [details]
2nd valgrind log

Both were run while i did the same as before - but it didnt crash .. it threw some errors instead about missing files
Comment 31 Milan Bouchet-Valat 2011-01-16 17:48:57 UTC
Interesting. The invalid reads all come from the appmenu-gtk module, which I think is the Ubuntu addition for global menu. Unfortunately, the symbols are missing for this object. Could you install the package for your architecture and version from http://ddebs.ubuntu.com/pool/main/a/appmenu-gtk/, and post a new Valgrind trace? Thanks!
Comment 32 André Klapper 2011-01-16 17:51:19 UTC
*** Bug 639650 has been marked as a duplicate of this bug. ***
Comment 33 Bastien Nocera 2011-01-18 16:47:42 UTC
*** Bug 638917 has been marked as a duplicate of this bug. ***
Comment 34 Fabio Durán Verdugo 2011-01-23 21:13:15 UTC
*** Bug 640339 has been marked as a duplicate of this bug. ***
Comment 35 Akhil Laddha 2011-01-24 03:49:34 UTC
*** Bug 639915 has been marked as a duplicate of this bug. ***
Comment 36 medic123 2011-01-25 21:59:45 UTC
Created attachment 179333 [details]
valgrind log with dbg appmenu-gtk-symbols
Comment 37 Milan Bouchet-Valat 2011-01-26 11:13:59 UTC
Ah, sorry, I missed a few packages... You also need to install libappindicator1-dbgsym and libdbusmenu-glib3-dbgsym from:
http://ddebs.ubuntu.com/pool/main/liba/libappindicator/
http://ddebs.ubuntu.com/pool/main/libd/libdbusmenu/
Comment 38 Akhil Laddha 2011-01-29 11:11:06 UTC
*** Bug 640884 has been marked as a duplicate of this bug. ***
Comment 39 Akhil Laddha 2011-01-30 01:14:44 UTC
*** Bug 640918 has been marked as a duplicate of this bug. ***
Comment 40 Akhil Laddha 2011-02-05 14:54:17 UTC
*** Bug 641589 has been marked as a duplicate of this bug. ***
Comment 41 Akhil Laddha 2011-02-11 03:42:41 UTC
*** Bug 642079 has been marked as a duplicate of this bug. ***
Comment 42 André Klapper 2011-02-19 20:21:54 UTC
*** Bug 642776 has been marked as a duplicate of this bug. ***
Comment 43 medic123 2011-02-21 21:45:27 UTC
Created attachment 181529 [details]
valgrind log with crash!

yeehaa..
it occured during an upgrade, but i hope the essential symbols are still valid
Comment 44 Akhil Laddha 2011-03-07 12:30:09 UTC
*** Bug 644096 has been marked as a duplicate of this bug. ***
Comment 45 Mathieu Trudel-Lapierre 2011-03-12 02:57:40 UTC
After much fighting with nm-applet, I've managed to reproduce this issue on Ubuntu 11.04, again in the fallback mechanism for indicators to use GtkStatusIcons.

Milan, I get pretty much as far as you do with the libappindicator code, however it seems to me that changing the library to use gtk_status_icon_set_from_icon_name rather than ..._set_from_gicon makes it not crash (at least, that's what transpires so far from my testing and reports in LP #708118). I guess that might mean it's really an issue in glib/gtk?
Comment 46 Milan Bouchet-Valat 2011-03-12 10:01:20 UTC
Maybe, but I couldn't find where GIcon's code could allow the incriminated char* to point to invalid memory. I guess it's also possible that something corrupts the pointer, which may only happen under certain circumstances, explaining why it's so hard to reproduce. And the latest Valgrind trace doesn't show anything obvious to me: libappindicator/libdbusmenu doesn't appear. Maybe have a look at the previous trace, which mentioned it (with missing symbols).
Comment 47 Mathieu Trudel-Lapierre 2011-03-14 14:41:45 UTC
With some more messing with libappindicator code, seems like removing the unref'ing of the themed icon makes the crash not reappear. I haven't done too much testing, but it's easy enough to replicate with nm-applet and a little while loop in shell:

while true; do sudo gtk-update-icon-cache -f /usr/share/icons/ubuntu-mono-light; sleep 1; done

That's obviously set for the theme I currently use, but works just as well for other themes too (or just the general gnome icon directory). From there, having nm-applet re-negotiate DHCP (to get the progress animation, which rapidly alternates between a number of icons) or connecting to a network tends to have the applet crash.
Comment 48 Akhil Laddha 2011-03-16 11:54:55 UTC
*** Bug 644901 has been marked as a duplicate of this bug. ***
Comment 49 Fabio Durán Verdugo 2011-03-18 13:16:46 UTC
*** Bug 645122 has been marked as a duplicate of this bug. ***
Comment 50 Fabio Durán Verdugo 2011-03-22 00:02:04 UTC
*** Bug 645426 has been marked as a duplicate of this bug. ***
Comment 51 Fabio Durán Verdugo 2011-04-28 23:07:45 UTC
*** Bug 648901 has been marked as a duplicate of this bug. ***
Comment 52 André Klapper 2011-05-02 17:45:57 UTC
*** Bug 649180 has been marked as a duplicate of this bug. ***
Comment 53 Akhil Laddha 2011-05-13 06:48:31 UTC
*** Bug 650081 has been marked as a duplicate of this bug. ***
Comment 54 André Klapper 2011-06-08 15:17:50 UTC
*** Bug 652117 has been marked as a duplicate of this bug. ***
Comment 55 Milan Bouchet-Valat 2011-06-08 16:15:54 UTC
Last time I heard about this bug, it was traced down to a bug in both libappindicator and GtkStatusIcon, and fixed by two patches[1] which were committed in GTK+ in Ubuntu (plus one patch in libappindicator). The patches add a 'use-fallback' property to GtkImage, and use it from GtkStatusIcon, defined as:
> Whether the icon displayed in the GtkImage will use
> standard icon names fallback. The value of this property
> is only relevant for images of type %GTK_IMAGE_ICON_NAME
> and %GTK_IMAGE_GICON.


So it should probably be fixed in Ubuntu 11.04. I can't say whether we need these patches at all, since I couldn't get any information on them. Collaboration with upstream is hard, it seems...

Mathieu, do you have more informations?


1: http://bazaar.launchpad.net/~ubuntu-branches/ubuntu/natty/gtk+2.0/natty/view/head:/debian/patches/093_gtk3_gtkimage_fallbacks_use.patch
2: http://bazaar.launchpad.net/~ubuntu-branches/ubuntu/natty/gtk+2.0/natty/view/head:/debian/patches/097_statusicon_image_fallback.patch
Comment 56 Ted Gould 2011-06-08 16:39:43 UTC
Well, I consider those patches a work around for this bug.  The reason we were using the GIcon was to get the fallback support easily accessible in the icon.  Since we had already backported the "use-fallback" support for GtkImage it made sense to use that and a GtkImage in the GtkStatusIcon.

I'd love a fix for this bug, as I think those work arounds aren't the best and reduce the compatibility of Ubuntu's GTK with the upstream one.  But all the research that I've done on this bug has ended up with no results.  I'm not sure of where to go other than those work arounds.

So, in a nutshell, the bug still exists.  But the way that most people are probably getting to it has been removed by the work around.
Comment 57 Fabio Durán Verdugo 2011-07-16 21:40:23 UTC
*** Bug 654759 has been marked as a duplicate of this bug. ***
Comment 58 Akhil Laddha 2011-10-03 01:04:06 UTC
*** Bug 660683 has been marked as a duplicate of this bug. ***
Comment 59 Kyrylo V. Polezhaiev 2013-02-16 08:07:25 UTC
So, blocker bug is forgotten and last message here was 1.5 year ago?
Comment 60 Emmanuele Bassi (:ebassi) 2013-02-16 08:42:55 UTC
removing the blocker tag, given that it's clearly not one. the fact that it happened only on Ubuntu and with interactions with the appindicator library was already suspicious enough to not warrant the 'blocker' tag in the first place anyway.

confirmation that this crash still happens outside of Ubuntu, steps to reproduce it, and a proper backtrace would help.
Comment 61 Milan Bouchet-Valat 2013-02-16 11:55:22 UTC
Kyrylo, have you experienced the bug on a recent Ubuntu (or other distro) release? Are you sure this is the same bug?
Comment 62 Kyrylo V. Polezhaiev 2013-02-16 15:16:05 UTC
No, I just wonder why this bug has "blocker" status. Its very red to be forgotten.
Comment 63 André Klapper 2014-11-29 17:53:45 UTC
No indicators that this is still a problem (as per comment 62). Closing as INCOMPLETE.