This is an assertion in the GtkRecent code.

This is an assertion in the GtkRecent code.

*** Bug 612316 has been marked as a duplicate of this bug. ***

It would be good to know which arguments were passed to gtk_icon_theme_load_icon there.

*** Bug 632989 has been marked as a duplicate of this bug. ***

*** Bug 638049 has been marked as a duplicate of this bug. ***

Doing a google search indicates that this bug is affecting several Gtk applications, often running in a non-GNOME environment.  I personally have had reports of it affecting glabels in kubuntu and MacOS X.

My question is this: why do this assertion at all?  Wouldn't it be more prudent to return an empty pixbuf or a hardcoded pixbuf if it cannot find a suitable icon in the default theme (a message could still be sent to the console of the problem)?  At least this way, applications don't crash, which frustrates users.

the assertion is there because the code always assumes a fallback icon will be returned; the icon is GTK_STOCK_FILE or GTK_STOCK_DIRECTORY, depending on the MIME type, and the icons pointed by these two stock items should be provided by gtk+ itself. this is the code in case:

  icon_theme = gtk_icon_theme_get_default ();
  retval = gtk_icon_theme_load_icon (icon_theme, icon_name,
                                     size,
                                     GTK_ICON_LOOKUP_USE_BUILTIN,
                                     NULL);
  g_assert (retval != NULL);

if the fallback icon has not been found it means that there is a problem in how gtk+ and/or the icon theme have been installed, or that there has been an incompatible change in gtk+.

Removing any trace I can find of recent glabels activity (this was the app which crashed) does not solve the problem. I don't know how GtkRecentManager works but I had assumed from reading what it's supposed to do that a fresh installation of the app in question would at least allow me to start the app once. Do you have any other ideas I could try? or is there any other information you'd like from me?

I have the same problems with glabels
It happens every time now after I once tried saving a layout.
Deinstallation / Reinstallation didn't solve the problem either.
I am working with kubuntu.

=============
The following is a workaround in kubuntu 10.10 (assuming the oxygen theme):

- install gnome-icon-theme
- in /usr/share/icons/oxygen/16x16/mimetypes do a symbolic link to

   ../../../gnome/16x16/mimetypes/gtk-file.png

- run update-icon-caches on /usr/share/icons/oxygen

=============
The following is the commit that seems to have caused the problem:

From 5c74a696d5c1593be0f6b801cb85a4baf1087883 Mon Sep 17 00:00:00 2001
From: Matthias Clasen <mclasen@redhat.com>
Date: Tue, 31 Aug 2010 04:34:24 +0000
Subject: Make stock icons use standard icon names

At least where standard names are available, instead of relying
on a symlink forest in the icon theme directory. For directional
variants, we look up icons by the pair ("foo-rtl", "foo") or
("foo-ltr", "foo"). See bug 626474.


This patch renames the gtk-file.png to document-x-generic.png

=============
I think the following commit in master would actually fix the problem, but this has not been applied to the 2.22 branch, so it has not made it out to the distributions:

From dbdc9c99e5f6d9e4d31567bfa78c864aa9354ab4 Mon Sep 17 00:00:00 2001
From: Matthias Clasen <mclasen@redhat.com>
Date: Wed, 13 Oct 2010 14:18:03 +0000
Subject: Make GtkRecentManager use standard icon names for themed icons

---
diff --git a/gtk/gtkrecentmanager.c b/gtk/gtkrecentmanager.c
index 5f5c012..c14f9e5 100644
--- a/gtk/gtkrecentmanager.c
+++ b/gtk/gtkrecentmanager.c
@@ -1912,9 +1912,9 @@ gtk_recent_info_get_icon (GtkRecentInfo *info,
     {
       if (info->mime_type &&
           strcmp (info->mime_type, "x-directory/normal") == 0)
-        retval = get_icon_fallback (GTK_STOCK_DIRECTORY, size);
+        retval = get_icon_fallback ("folder", size);
       else
-        retval = get_icon_fallback (GTK_STOCK_FILE, size);
+        retval = get_icon_fallback ("document-x-generic", size);
     }
   
   return retval;

Dear Jim,

thanks for the hint! this worked for me

*** Bug 648435 has been marked as a duplicate of this bug. ***

*** Bug 660418 has been marked as a duplicate of this bug. ***

I assume its fixed