Romain Francoise writes: > Can you reproduce the bug with the latest Emacs sources from CVS? Your > reports mention Emacs 21.3 an 21.4, this codebase is very old.
I managed to find some time to do this test at last. Current CVS emacs crashes too. I also tried to understand what the problem is. The GIF image is strange. Doing identify on it gives this output: /tmp/poison.gif[0] GIF 450x33 450x33+0+235 PseudoClass 64c 31kb 0.000u 0:01 /tmp/poison.gif[1] GIF 53x76 450x33+53+116 PseudoClass 64c 31kb 0.000u 0:01 /tmp/poison.gif[2] GIF 53x75 450x33+53+115 PseudoClass 64c 31kb 0.000u 0:01 /tmp/poison.gif[3] GIF 59x77 450x33+30+115 PseudoClass 64c 31kb 0.000u 0:01 /tmp/poison.gif[4] GIF 50x70 450x33+24+122 PseudoClass 64c 31kb 0.000u 0:01 /tmp/poison.gif[5] GIF 54x71 450x33+20+129 PseudoClass 64c 31kb 0.000u 0:01 I don't know in detail what those sizes attributes represent. But single stepping through gif_load in image.c I note that it first calls x_create_x_image_and_pixmap() with width=450 and height=200. Later on it computes image_top to 235. Thus, in the first loop after the assignment of image_top it lets y loop from 0 to 234, and does an XPutPixel for each x and y value. The crash happens with y==200, which is the first row not allocated in ximg. I don't quite understand all aspects here. But my impression is that the bug is indeed in emacs. It gets fooled somehow by this nonstandard GIF image. _______________________________________________ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel
