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 357974 - Crashes (failed assertatin)
Crashes (failed assertatin)
Status: RESOLVED FIXED
Product: gdk-pixbuf
Classification: Platform
Component: general
git master
Other Linux
: Normal normal
: ---
Assigned To: gtk-bugs
gtk-bugs
Depends on:
Blocks:
 
 
Reported: 2006-09-27 14:40 UTC by Vassilis Pandis
Modified: 2010-07-10 04:09 UTC
See Also:
GNOME target: ---
GNOME version: 2.15/2.16


Attachments
File that causes the problem (2.68 KB, image/gif)
2006-09-27 14:41 UTC, Vassilis Pandis
  Details
patch proposal (928 bytes, patch)
2006-10-11 11:56 UTC, Felix Riemann
accepted-commit_now Details | Review

Description Vassilis Pandis 2006-09-27 14:40:42 UTC
Hello,

this is a bug reported by an Ubuntu user. You can find the original bug report at http://launchpad.net/bugs/6305 :

"If I double-click on this gif file, oeg crash, and so wnck-applet, workplace-selector and another applet. I obtain this output if I call oeg from a terminal:

$ eog test-bug.gif
Instantiate job with id 1.
Starting thread with id 0.
eog-image_load.c

(eog:12048): GdkPixbuf-CRITICAL **: gdk_pixbuf_new: assertion `width > 0' failed
(eog:12048): GdkPixbuf-CRITICAL **: gdk_pixbuf_loader_close: assertion `error == NULL || *error == NULL' failed

(eog:12048): GdkPixbuf-WARNING **: GdkPixbufLoader finalized without calling gdk_pixbuf_loader_close() - this is not allowed. You must explicitly end the data stream to the loader before dropping the last reference.
load success: 0
Job 001: disposing ...
Job 001: disposing end

At this point I have to press ^C (in this case applets don't crash)."



I tried to reproduce this with eog version 2.16.0.1 and I get a different behaviour:

pandis@pandis-laptop:~$ eog test-bug.gif 

(eog:17919): GdkPixbuf-CRITICAL **: gdk_pixbuf_new: assertion `width > 0' failed
pandis@pandis-laptop:~$ 

and of course, eog doesn't open. 


Thanks in advance,
Comment 1 Vassilis Pandis 2006-09-27 14:41:24 UTC
Created attachment 73497 [details]
File that causes the problem
Comment 2 Vassilis Pandis 2006-09-27 14:44:05 UTC
With gnome 2.16, no applets crashed.
Comment 3 Felix Riemann 2006-09-28 11:12:49 UTC
This seems to be a GdkPixbuf bug as it is reproducable with a simple script loading the image with a GdkPixbufAnimation object producing error output like this:
(pixbufanitest:6820): GdkPixbuf-CRITICAL **: gdk_pixbuf_new: assertion `width > 0' failed
Not enough memory to composite a frame in GIF file

I'm even able to trigger it with nautilus just by trying to view the folder containing the image (probably triggered by thumbnailing).
Comment 4 Felix Riemann 2006-10-11 11:32:15 UTC
I took a deeper look at the GIF animation at it turned out that it is not fully sane. The logical screen (that's where the individual frames are drawn to) has it's size set to 0x0. That's why the GIF loader tries to initialize a new pixbuf with size 0x0 (which is not allowed).

A similar problem was once reported for The GIMP (bug 151053) and was worked around by using the first frame's size as screen size in such cases.
Comment 5 Felix Riemann 2006-10-11 11:56:52 UTC
Created attachment 74476 [details] [review]
patch proposal

This implements a workaround similar to the one I described in comment #4.
Comment 6 Claudio Saavedra 2006-10-11 22:16:33 UTC
Felix, shouldn't this be moved to GTK+?
Comment 7 Felix Riemann 2006-10-12 09:52:21 UTC
Yes, I think it should. I don't have the rights for this, so it would be nice if you or someone with the rights could do it.
Comment 8 Matthias Clasen 2006-12-21 07:58:59 UTC
Patch looks ok at first glance, will test and commit tomorrow.
Comment 9 Matthias Clasen 2006-12-21 23:27:17 UTC
2006-12-21  Matthias Clasen  <mclasen@redhat.com>

        * io-gif.c (gif_get_lzw): Handle invalid gif animations
        a little bit more robustly.  (#357974, Vassilis Pandis,
        patch by Felix Riemann)