Various apps crash due to assertion failure in ensure_surface_for_gicon [gtkiconhelper.c:493/494]

StacktraceTop:
 g_assertion_message () from /tmp/apport_sandbox_PhKEt1/lib/i386-linux-gnu/libglib-2.0.so.0
 g_assertion_message_expr () from /tmp/apport_sandbox_PhKEt1/lib/i386-linux-gnu/libglib-2.0.so.0
 ensure_surface_for_gicon (self=self@entry=0x816fcd80, style=0x8170a8a8, dir=dir@entry=GTK_TEXT_DIR_LTR, scale=1, gicon=0xb1f02508) at ././gtk/gtkiconhelper.c:493
 gtk_icon_helper_load_surface (self=0x816fcd80, scale=1) at ././gtk/gtkiconhelper.c:564
 gtk_icon_helper_ensure_surface (self=self@entry=0x816fcd80) at ././gtk/gtkiconhelper.c:601

Status changed to 'Confirmed' because the bug affects multiple users.

The issue there can at least be hit during upgrades, on the machine I'm currently using which is on bionic

$ LC_ALL=C eog

(eog:5727): GdkPixbuf-WARNING **: 15:51:18.029: Cannot open pixbuf loader module file '/usr/lib/x86_64-linux-gnu/gdk-pixbuf-2.0/2.10.0/loaders.cache': No such file or directory

Gtk:ERROR:../../../../gtk/gtkiconhelper.c:494:ensure_surface_for_gicon: assertion failed (error == NULL): Failed to load /org/gtk/libgtk/icons/16x16/status/image-missing.png: Unrecognized image file format (gdk-pixbuf-error-quark, 3)

gdk-pixbuf is being upgraded

iU libgdk-pixbuf2.0-0:amd64 2.36.11-2 amd64 GDK Pixbuf library

Also tracking as zenity crashes:
https://errors.ubuntu.com/problem/2b11576fed59ad23c640bc85a266cc82ec30a689
https://errors.ubuntu.com/problem/9d612b3f25168e76adb91fa4eedc301ffa632383

You may find others logged against other programs too.

Going to reassigning to debconf, while it's gtk not handling when loaders are not configured that's during-update issue where the system is in inconsistent state and I'm unsure GTK itself is where to fix the problem

it had been discussed a bit on https://irclogs.ubuntu.com/2020/04/21/%23ubuntu-release.html#t16:15

debconf handles GTK failing, but that's not a clear failure case, the error is hit when trying to load icons ... one way to address this would perhaps be to make debconf try to do that and fallback as well if it's failing. Reassigning to foundation and tagging rls-ff-incoming since that's a common case of upgrade failure

Status changed to 'Confirmed' because the bug affects multiple users.

This is indeed a complex problem and it is hard to do anything reasonable about a missing GTK frontend when debconf is not initiated from the terminal.

OTOH I think there is an easy fix for GTK+ to always include an "image-missing" icon at compile time, but apparently I'm not the first one coming up with this idea, but something is still broken:

gtk/gtkiconhelper.c:494

  if (destination == NULL)
    {
      GError *error = NULL;
      destination = gtk_icon_theme_load_icon (icon_theme,
                                              "image-missing",
                                              width,
                                              flags | GTK_ICON_LOOKUP_USE_BUILTIN | GTK_ICON_LOOKUP_GENERIC_FALLBACK,
                                              &error);
      /* We include this image as resource, so we always have it available or
       * the icontheme code is broken */
      g_assert_no_error (error);
      g_assert (destination);
      symbolic = FALSE;
    }

> OTOH I think there is an easy fix for GTK+ to always include an "image-missing" icon at compile time

I'm sorry, it's not that easy. A PNG icon is indeed included, and it gets found properly (also from the actual icon theme; that is a dependency of GTK). The problem is the ability to load PNGs *at all* is not available sometimes during the middle of dist-upgrades.

I think extending that test program in Debconf (referred to in the IRC log above) to do a bit more work - trying to load an icon - might make the fallback trigger in this case too.

e.g:

  my $window = Gtk3::Window->new('toplevel');
  my $icontheme = Gtk3::IconTheme::get_default;
  my $icon = $icontheme->load_icon('image-missing', 32, []);

If you manually remove '/usr/lib/*/gdk-pixbuf-2.0/2.10.0/loaders.cache' (suggest doing this in a VM) then you can reproduce this by extracting the program out of Debconf.

Tracking upstream in https://gitlab.gnome.org/GNOME/gtk/-/issues/3077