emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Crash on loading image


From: Pavel Janík
Subject: Re: Crash on loading image
Date: Wed, 20 Feb 2002 11:27:49 +0100
User-agent: Gnus/5.090006 (Oort Gnus v0.06) Emacs/21.2.50 (i386-suse-linux-gnu)

[ If you can not read this e-mail and Emacs will crash for you, I'm really
  sorry ;-) I'd like to have all informations and images contained in this
  e-mail. cvs up will solve your problems. ]

   From: Eli Zaretskii <address@hidden>
   Date: Sun, 17 Feb 2002 11:02:53 +0200 (IST)

Hi,

   > Here's one more GIF that was once reported to crash Emacs.  As the others 
   > I sent, this one doesn't crash for me, but I have libungif 4.1.0b1, where 
   > the bug is supposed to not exist.

thank you, Eli. This image can really crash Emacs if you use
libungif-4.1.0. So I spent last week with testing Emacs, libungif and GIF
pictures. I have now three pictures, which can crash Emacs. One is from
Eli:

Attachment: quebecan.gif
Description: GIF image

This image can crash Emacs only if it is running with libungif-4.1.0 (also
note, that some Linux distributors - like SuSE - have also libungif-4.1.0
but it is patched to prevent this bug).

Another image is from François:

Attachment: x1.gif
Description: GIF image

This image can crash both with libungif 4.1.0 and 4.1.0b1. It is special,
because it uses different Geometry and Page Geometry, see output of
identify -verbose:

Image: /home/pavel/.Emacs/Work/x1.gif
  Format: GIF (CompuServe graphics interchange format)
  Geometry: 35x47
...
  Page Geometry: 38x38+0+0

Emacs will crash in libungif, because it allocated to small region of
memory.

The same applies to next image I found in my archives:

Attachment: opensign.gif
Description: GIF image

Image: /home/pavel/.Emacs/Work/opensign.gif
  Format: GIF (CompuServe graphics interchange format)
  Geometry: 143x57
...
  Page Geometry: 10x10+0+0

Eli, this is why you see small (10x10 points) picture. Emacs/libungif
happily allocated small region of memory and then wrote the data
somewhere...

So, what should be done? The entry in etc/PROBLEMS is true and should be
there. There is no way to test for patched version of libungif when
compiling, because the real version used could be on different computer and
we should test it on run-time. The author of this version did mistake by
not incrementing minor version number so it is not possible.

The second problem (Geometry) can be solved by this patch:

--- xfns.c.~1.537.~     Tue Jan 22 16:16:44 2002
+++ xfns.c      Thu Feb  7 22:32:55 2002
@@ -10161,8 +10161,8 @@
       return 0;
     }
 
-  width = img->width = gif->SWidth;
-  height = img->height = gif->SHeight;
+  width = img->width = max (gif->SWidth, gif->Image.Left + gif->Image.Width);
+  height = img->height = max (gif->SHeight, gif->Image.Top + 
gif->Image.Height);
 
   /* Create the X image and pixmap.  */
   if (!x_create_x_image_and_pixmap (f, width, height, 0, &ximg, &img->pixmap))


I use it for about two weeks right now and do not see problems (because
I use patched 4.1.0 libungif from SuSE). This patch should go to RC and
HEAD.

Without my patch:

address@hidden:~> LD_LIBRARY_PATH=/tmp/ROOT-4.1.0b1/lib/ 
/tmp/emacs-21.1.90/src/emacs -q -f auto-image-file-mode ~/.Emacs/Work/x1.gif 
Fatal error (11).Neoprávněný přístup do paměti (SIGSEGV)

Wit my patch:

address@hidden:~> LD_LIBRARY_PATH=/tmp/ROOT-4.1.0b1/lib/ emacs -q -f 
auto-image-file-mode ~/.Emacs/Work/x1.gif

it works. I will commit it in a moment.

P.S. See http://www.janik.cz/tmp/e-mail.png for the picture of all images
in this e-mail.
-- 
Pavel Janík

Use free-form input when possible.
                  --  The Elements of Programming Style (Kernighan & Plaugher)

reply via email to

[Prev in Thread] Current Thread [Next in Thread]