GNOME Bugzilla – Bug 743862
ico: Parses compressed data as BMP if compressed entry is last
Last modified: 2018-05-22 13:18:19 UTC
I have an .ico file which gimp opens just fine, but eog fails to load it. NOTE: I don't think the fault is at EOG, but I use it as an entry point to find a more suitable compoent. The same 'noisy output' is seen in nautilus by means of the preview created (so hopefully this is something shared between eog and whatever creates the thumbnail for nautilus). I attach an Icon for reference
Hi Dominique, I think you forgot to attach the icon file. ;) If nautilus exhibits this as well, this is likely a bug in gdk-pixbuf's ICO loader. However, it could be that it is just showing the thumbnail, that was generated by eog.
Created attachment 295997 [details] The icon I talked about I was sure I went through attaching the file.. but maybe not..
Yes, that seems to be coming from gdk-pixbuf's ICO loader. However, I noted that Imagemagick seems to have some troubles working with it as well.
The biggest icon that's currently parseable by the ico loader is the 48x48, the 2 bigger sizes are compressed. Still, the output shouldn't be the utter garbage we got, unless we're trying to parse something we can't handle. I'll try to fix this, but in the end, we'll have support for PNG-compressed icons handled in bug 551026.
There's no memory corruption at all, in fact, the code is fairly solid in that case. The problem is that: - each time data is fed into the loader, through gdk_pixbuf__ico_image_load_increment(), we check whether we have enough data to load the header, as checked in DecodeHeader() - decode header will check each icon entry in the dictionary and try to find the best one - if the largest one is last, it will increase the size of the header buffer until it can read the Bitmap header for that entry, so it can check if it's compressed - if it's compressed, then we fallback on another icon, etc. Here, the problem is that the largest icon is the furthest in the file, so when we're done checking whether it's compressed, there's all the data before that last entry's header in the "header buffer". And then we start stuffing the data into the "line" buffer. Essentially, the data you see is PNG data parsed as a BMP because the last (and the one before last) icons are compressed, and we're reading from the wrong buffer. Merging the buffers and using only one would solve the problem. Adding PNG support would only solve the problem for this particular icon though.
Created attachment 341970 [details] [review] tests: Add test for bug 743862
-- GitLab Migration Automatic Message -- This bug has been migrated to GNOME's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/gdk-pixbuf/issues/50.