GNOME Bugzilla – Bug 451634
gtk-update-icon-cache behaves badly when run on wrong path
Last modified: 2008-02-16 04:43:10 UTC
Please describe the problem: I'm following garnome's svn trunk. The latest development version (2.19.4) left me with broken icons in gnome panel, in menus, and in some apps (e.g., evolution). Not all icons are broken in all 3 cases though. I tried updating he icon caches in various directories. Running: gtk-update-icon-cache /opt/gnome/share/icons gives: No theme index file in '/opt/gnome/share/icons'. If you really want to create an icon cache here, use --ignore-theme-index. Running: gtk-update-icon-cache /opt/gnome/share/icons --ignore-theme-index gives: bad image index The generated cache was invalid. The icons remain broken. Running gtk-update-icon-cache --ignore-theme-index /usr/share/icons (the system Gnome directory) works. Steps to reproduce: 2. 3. Actual results: Expected results: Does this happen every time? Other information:
OK, I've played around a bit more. I tried reverting to an earlier version of gnome-themes (2.19.3->2.19.2). No change. I also tried uninstalling Tango--same.
One more observation. I moved the various icon directories out of /opt/gnome/share/icons (where garnome installs), running gtk-update-icon-cache --ignore-theme-index after each one. I got the same failure until I was left with just two png files: abiword_48.png firefox.png. These are what's triggering the error. If I move these 2 away and restore all the rest, the icon-cache is created. The panel apps, etc., as 1st reported remain broken. I'm wondering if this has anything to do with the large-image issue I reported in Bug 449849?
gtk-update-icon-cache is supposed to be run on the acutal theme directories, e.g. gtk-update-icon-cache /opt/gnome/share/icons/Tango gtk-update-icon-cache /opt/gnome/share/icons/gnome
Thanks for the reply. You are of course correct (I'd misread the man page). However, running them in the theme directories still doesn't fix the broken icon issue. I also just upgraded to gnome-themes-2.19.4. The problem is still there.
Can you comment out the g_unlink (tmp_cache_path); after g_printerr (_("The generated cache was invalid.\n")); in updateiconcache.c, rebuild, and attach the invalid icon cache file that it leaves behind then ?
I'm happy to make the change you suggest, however, perhaps I wasn't clear enough in comment #4. When I run gtk-update-icon-cache in the theme subdirectories I don't get the error. When I said that the problem is still there, I meant that some icons were still broken in gnome-panel, its menu's, and in some applications (e.g., evolution [e.g., in the mail window, essentially all icons except for "print" and "Cancel"], but not in Rhythmbox [all icons seem OK here]). Do you still want me to comment out the g_unlink?
No. I was interested in the bad image index The generated cache was invalid. messages you were mentioning earlier. If those don't happen anymore, then I don't need you to remove the unlink
Well, they still happen if I run gtk-update-icon-chache --ignore-theme-index /usr/share/icons or in some other non-theme icon directory. The problem is with png files that may sit there (e.g., as in my comment #2). With those moved away, I get an icon cache file and no errors. As you pointed out, this isn't the way to run gtk-update-icon-cache, but perhaps the behavior is still unintended.
The cache generation breaks if there is an image in the index.theme directory, you can try by copying an icon to /usr/share/icons/hicolor and try to update the cache then. We got several Ubuntu upgrade breakage due to people who used autopackages which installed an icon there
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=444285
Version 2.12.0
What happens is that the assertion at gtk/gtkiconcachevalidator.c:292 fails when there are icons in /usr/share/icons/hicolor (directly below this dir): (gdb) 292 check ("image index", index < info->n_directories); (gdb) print index $8 = 65535 (gdb) print info->n_directories $9 = 19
Oh and here's the dump of the image being checked: (gdb) x/64x info->cache+offset 0xb7a4d7a0: 0xff 0xff 0x00 0x04 0x00 0x1f 0xc7 0xd8 0xb7a4d7a8: 0x00 0x0e 0x00 0x04 0x00 0x1f 0xec 0x00 0xb7a4d7b0: 0x00 0x0d 0x00 0x04 0x00 0x1f 0xfc 0x28 0xb7a4d7b8: 0x00 0x09 0x00 0x04 0x00 0x20 0x05 0x50 0xb7a4d7c0: 0x00 0x07 0x00 0x04 0x00 0x20 0x0d 0x08 0xb7a4d7c8: 0x00 0x05 0x00 0x02 0x00 0x00 0x00 0x00 0xb7a4d7d0: 0x00 0x00 0x00 0x04 0x00 0x20 0x11 0x30 0xb7a4d7d8: 0x00 0x1f 0xc7 0xe0 0x00 0x00 0x00 0x00 I guess the error is rather at cache creation time though.
This is set by "dir_index = 0xffff;" in gtk/updateiconcache.c:657; shouldn't the file be simply skipped?
Created attachment 97581 [details] [review] Skip icons for which we can't lookup the directory
I believe a slightly different fix that I did some time ago fixes this too.