[pixel@mandriva.com: segfault on buggy .gif + patch to fix it]

[pixel@mandriva.com: segfault on buggy .gif + patch to fix it]

[Richard Stallman]

Would someone please check this patch, and either install
it and ack or expain why it is wrong?


------- Start of forwarded message -------
X-Spam-Status: No, score=0.0 required=5.0 tests=UNPARSEABLE_RELAY 
	autolearn=failed version=3.1.0
To: bug-gnu-emacs@gnu.org
From: Pixel <pixel@mandriva.com>
Date: Thu, 06 Sep 2007 16:00:09 +0200
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="=-=-="
Subject: segfault on buggy .gif + patch to fix it

- --=-=-=

download http://people.mandriva.com/~prigaux/content.gif
(file not attached here for gnus users out there...)

then do "emacs content.gif" in X mode, it will segfault.

here is a simple patch to fix the issue:


- --=-=-=
Content-Type: text/x-patch
Content-Disposition: inline;
 filename=emacs-snapshot-fix-segfault-loading-wrong-gif.patch

Index: src/image.c
===================================================================
RCS file: /sources/emacs/emacs/src/image.c,v
retrieving revision 1.85
diff -u -r1.85 image.c
- --- src/image.c	30 Aug 2007 05:05:58 -0000	1.85
+++ src/image.c	6 Sep 2007 13:56:19 -0000
@@ -7886,7 +7886,8 @@
   init_color_table ();
   bzero (pixel_colors, sizeof pixel_colors);
 
- -  for (i = 0; i < gif_color_map->ColorCount; ++i)
+  if (gif_color_map)
+    for (i = 0; i < gif_color_map->ColorCount; ++i)
     {
       int r = gif_color_map->Colors[i].Red << 8;
       int g = gif_color_map->Colors[i].Green << 8;

- --=-=-=


reproduced on:
  GNU Emacs 22.1.1 (i486-pc-linux-gnu, X toolkit, Xaw3d scroll bars) of 2007-08-22 on raven, modified by Debian
  GNU Emacs 22.1.1 (i386-mandrake-linux-gnu, X toolkit, Xaw3d scroll bars) of 2007-09-06 on n4.mandriva.com, modified by Mandriva
  GNU Emacs 23.0.50.3 (i686-pc-linux-gnu, GTK+ Version 2.11.6, multi-tty) of 2007-09-06 on n4.mandriva.com

the buggy gif comes from a MMS by SFR (a french mobile phone operator)

- --=-=-=
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
bug-gnu-emacs mailing list
bug-gnu-emacs@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-gnu-emacs

- --=-=-=--
------- End of forwarded message -------

Re: [pixel@mandriva.com: segfault on buggy .gif + patch to fix it]

[Thien-Thi Nguyen]

() Richard Stallman <rms@gnu.org>
() Fri, 07 Sep 2007 02:31:28 -0400

   Would someone please check this patch, and either install
   it and ack or expain why it is wrong?

ack; i installed it (trunk and EMACS_22_BASE).

thi

Re: [pixel@mandriva.com: segfault on buggy .gif + patch to fix it]

[Nick Roberts]

 > ack; i installed it (trunk and EMACS_22_BASE).

Installs on EMACS_22_BASE are automatically merged to the trunk.

-- 
Nick                                           http://www.inet.net.nz/~nickrob

Re: [pixel@mandriva.com: segfault on buggy .gif + patch to fix it]

[Thien-Thi Nguyen]

() Nick Roberts <nickrob@snap.net.nz>
() Fri, 7 Sep 2007 19:39:47 +1200

   Installs on EMACS_22_BASE are automatically merged to the trunk.

is this "miles-automatic" or machine-automatic?
if the former, i don't mind reducing the burden
a little for miles (if miles doesn't mind).

thi

Re: [pixel@mandriva.com: segfault on buggy .gif + patch to fix it]

[Jason Rumney]

Thien-Thi Nguyen wrote:
> is this "miles-automatic" or machine-automatic?
> if the former, i don't mind reducing the burden
> a little for miles (if miles doesn't mind).
>   

If there are no conflicts (and arch is supposed to be better than CVS at
tracking merge history to minimize conflicts) then it should be
machine-automatic with little input needed from Miles. I always leave it
to the automatic merging on the assumption that manual changes are more
likely to cause spurious conflicts than just leaving it.

Re: [pixel@mandriva.com: segfault on buggy .gif + patch to fix it]

[Davis Herring]

> is this "miles-automatic" or machine-automatic?
> if the former, i don't mind reducing the burden
> a little for miles (if miles doesn't mind).

It's better than automatic!  It's milesomatic!  (Actually, I don't know
how you do it, Miles; but on the subject, have you noticed that Richard
wants the FOR-RELEASE file in the 22 branch to -not- be synched to the
trunk?)

Davis

-- 
This product is sold by volume, not by mass.  If it appears too dense or
too sparse, it is because mass-energy conversion has occurred during
shipping.