Re: Crash on loading image

Re: Crash on loading image

[François Pinard]

[-- Attachment #1: Type: text/plain, Size: 1446 bytes --]

[Pavel Janík]

> can you please test this?  I will provide ChangeLog entry later.
> Too tired right now...
 
> --- xfns.c.~1.537.~	Tue Jan 22 16:16:44 2002
> +++ xfns.c	Wed Feb  6 15:49:29 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))

Pavel, I just installed 21.1.90 without the patch above, and Emacs vanishes
whenever I open any of the two images you provided in your reply.  I then
installed the said patch over 21.1.90, and the image is now opened correctly
in both cases.  So the patch does repair something :-).  Congratulations!

I'm merely repeating the remainder of your comments for the other readers:

> This will be needed in RC and in HEAD.  I'm CCing emacs-devel because
> we need to get more testing for this.  If you would like to know why to
> test this, just try the above recipe with attached pictures.  I have
> tested this on a package of about 1400 pictures and only one of them
> (attached opensign.gif) had the same problem (we used Screen Width of GIF,
> but it was to small) and thus we crashed.

[-- Attachment #2: Type: text/plain, Size: 59 bytes --]


-- 
François Pinard   http://www.iro.umontreal.ca/~pinard

Re: Crash on loading image

[Pavel Janík]

   From: pinard@iro.umontreal.ca (François Pinard)
   Date: 14 Feb 2002 21:14:29 -0500

Hi François,

   > Pavel, I just installed 21.1.90 without the patch above, and Emacs vanishes
   > whenever I open any of the two images you provided in your reply.  I then
   > installed the said patch over 21.1.90, and the image is now opened correctly
   > in both cases.  So the patch does repair something :-).  Congratulations!

thank you very much. I will wait for other images before really committing
it to get it more tested.
-- 
Pavel Janík

I'm glad that Emacs is bigger and more open than some of the people who use
it.
                  -- Tony Reed in gnu.emacs.help

_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/emacs-devel

Re: Crash on loading image

[Eli Zaretskii]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 350 bytes --]


On Sat, 16 Feb 2002, Pavel =?iso-8859-2?q?Jan=EDk?= wrote:

> thank you very much. I will wait for other images before really committing
> it to get it more tested.

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.

[-- Attachment #2: Type: IMAGE/GIF, Size: 7548 bytes --]

Re: Crash on loading image

[François Pinard]

[Eli Zaretskii]

> On Sat, 16 Feb 2002, Pavel =?iso-8859-2?q?Jan=EDk?= wrote:

> > thank you very much. I will wait for other images before really committing
> > it to get it more tested.

> 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.

Hey, hey!  For those who do not know, this is the flag of the province of
Quebec! :-)

It did not crash Emacs here, which has Pavel's patch.  This system uses
libungif 4.1.0; previously, Emacs was crashing here, with libungif 4.1.0.

-- 
François Pinard   http://www.iro.umontreal.ca/~pinard

_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/emacs-devel

Re: Crash on loading image

[Pavel Janík]

[-- Attachment #1: Type: text/plain, Size: 706 bytes --]

[ 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 <eliz@is.elta.co.il>
   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 #2: quebecan.gif --]
[-- Type: image/gif, Size: 7548 bytes --]

[-- Attachment #3: Type: text/plain, Size: 231 bytes --]


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 #4: x1.gif --]
[-- Type: image/gif, Size: 2628 bytes --]

[-- Attachment #5: Type: text/plain, Size: 441 bytes --]


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 #6: opensign.gif --]
[-- Type: image/gif, Size: 10358 bytes --]

[-- Attachment #7: Type: text/plain, Size: 1960 bytes --]


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:

pavel@SnowWhite:~> 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:

pavel@SnowWhite:~> 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)

Re: Crash on loading image

[François Pinard]

[-- Attachment #1: Type: text/plain, Size: 289 bytes --]

[Pavel Janík]

> 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).

Oh!  That's why it works for me, then...  Thanks for this explanation.

[-- Attachment #2: Type: text/plain, Size: 59 bytes --]


-- 
François Pinard   http://www.iro.umontreal.ca/~pinard

Re: Crash on loading image

[Jason Rumney]

Pavel@Janik.cz (Pavel Janík) writes:

> 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.

Can we ask the author of libungif to release a new version with the
version number incremented, so it can be detected by configure scripts?


-- 
Jason Rumney


_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/emacs-devel

Re: Crash on loading image

[Pavel Janík]

   From: Jason Rumney <jasonr@gnu.org>
   Date: 20 Feb 2002 20:02:21 +0000

   > Can we ask the author of libungif to release a new version with the
   > version number incremented, so it can be detected by configure scripts?

I can do it, but what will we do when we detect old libungif when
compile-time? It can be different to the libungif version at run-time. We
should be able to check for libungif version at run-time.
-- 
Pavel Janík

What happens when you press <ctrl><alt><BS> in Windows? Sorry, I did not 
use any MS software since September 1996. And I'm proud of this ;)
                  -- Hubert Mantel in some mailing list

_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/emacs-devel

Re: Crash on loading image

[Jason Rumney]

Pavel@Janik.cz (Pavel Janík) writes:

>    > Can we ask the author of libungif to release a new version with the
>    > version number incremented, so it can be detected by configure scripts?
> 
> I can do it, but what will we do when we detect old libungif when
> compile-time? It can be different to the libungif version at run-time. We
> should be able to check for libungif version at run-time.

If we detect the old version of libungif at compile-time, we do not
link to it.  If the library is later upgraded, Emacs will need to be
reconfigured and recompiled to use it.  This is standard for programs
that link with optional libraries, but require specific versions.
Detecting at run-time might be more elegant, but I'm not sure if it
would be worth the extra effort.

Since libraries generally only get upgraded not downgraded, the only
potential problem with compile time checking is a pre-compiled binary
that was compiled with the new libungif, but installed on a system
with the old libungif.  But most binary distributions use packaging
tools that can at least warn the user of such dependencies, so this is
not such a big problem.


-- 
Jason Rumney


_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/emacs-devel

Re: Crash on loading image

[Pavel Janík]

   From: Richard Stallman <rms@gnu.org>
   Date: Fri, 22 Feb 2002 16:46:05 -0700 (MST)

Richard,

   >     note, that some Linux distributors - like SuSE - have also libungif-4.1.0
   > 
   > Thanks for helping to collect these test cases.  While you are at it,
   > would you please not call those companies "Linux distributors".  What
   > they distribute is much more GNU than Linux, and giving "Linux" 100%
   > of the credit hurts the GNU Project.

I know your arguments. I think all people here know your arguments so it is
pointless to discuss this on this mailing-list.

But do you really think that they distribute more GNU than Linux? Have you
ever untarred Linux kernel sources? It is *big* mess of C and asm
code. I think in case of SuSE (who sells seven CDs or 1 DVD, or 8 CDs here
in Czech republic), GNU part is minor there and *maybe* Linux part (various
binary images, sources, patches, modules etc.) of the CDs is bigger then
GNU part. But I do not have data so I can't tell exactly. What I really
think is that there are more (in terms of disk space) useless commercial
packages like Sun StarOffice, Kylix and similar stuff. Should I then refer
to SuSE as commercial Linux/XFree/Sun/GNU distributor? There are two
versions of XFree there on CDs, it is *huge* disk space. There is KDE who
is disk eater...

Did you measure what is important for users and what is not? Users of this
distribution really value KDE (GPL, but not part of GNU project). They use
XFree (not part of GNU project).

Yes, I was too materialistic in the text written above, but people tend to
think that way and you can not reply to them, because you do not have
informations. It is not correct to refer to such packages as "Linux". Yes,
I know that, it is not Linux (ie. Linux kernel). But it is not correct to
call them "GNU/Linux" as well. You know that and you still want other
people to refer to such packages as "GNU/Linux". I have the same feeling as
being in the church and listening to vicar talking about something he
believes in. Sorry for that, but this is only my opinion.

If you think that GNU project tends to be forgotten in people's minds,
something *should* be done. But saying half-truth to them is not correct
and can turn against GNU project in the future. I do not want to be there
when this happens...
-- 
Pavel Janík

_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/emacs-devel

Re: Crash on loading image

[Kim F. Storm]

Pavel@Janik.cz (Pavel Janík) writes:

>    From: Richard Stallman <rms@gnu.org>
>    Date: Fri, 22 Feb 2002 16:46:05 -0700 (MST)
> 
> Richard,
> 
>    >     note, that some Linux distributors - like SuSE - have also libungif-4.1.0
>    > 
>    > Thanks for helping to collect these test cases.  While you are at it,
>    > would you please not call those companies "Linux distributors".  What
>    > they distribute is much more GNU than Linux, and giving "Linux" 100%
>    > of the credit hurts the GNU Project.
> 
> I know your arguments. I think all people here know your arguments so it is
> pointless to discuss this on this mailing-list.
> 
> But do you really think that they distribute more GNU than Linux? 

If you take the good ol' UNIX V7 and BSD manuals, man(1) to man(8),
you can say that Linux covers man(2) and man(7), and GNU covers the
rest.  So it is fair to talk about a GNU/Linux system for the base
operating system, and that GNU is a considerable part of that.

Add to that, that Linus has contrinuted Linux to GNU as (one of) the
kernels for building a complete GNU system.  

So if GNU tells you that the proper term for a GNU system with Linux
as the kernel is GNU/Linux, then I think you - as a contibuter to GNU
- should respect that.

> Should I then refer to SuSE as commercial Linux/XFree/Sun/GNU distributor?

No, you can refer to SuSE as a commercial GNU/Linux, XFree, KDE, and
StarOffice distributor.

I don't know what the KDE and SUN developers think about their efforts
being viewed as "components of Linux".  The GNU project obviously
doesn't want to be viewed that way.


> If you think that GNU project tends to be forgotten in people's minds,
> something *should* be done. But saying half-truth to them is not correct
> and can turn against GNU project in the future. I do not want to be there
> when this happens...

In my mind, there is *less* "half-truth" about calling it GNU/Linux
than just Linux!!!

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk


_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/emacs-devel

Re: Crash on loading image

[Richard Stallman]

    But do you really think that they distribute more GNU than Linux?

I am quite confident of it.  Back in 1995, the GNU programs were 10
times the size of Linux.  If Linux has grown since then, so have the
GNU programs.

But even more important than the size of code is the fact that we
started the whole thing.  We are the ones who set out to develop a
complete free operating system, and the fact that any of them exist is
because of our determination.  GNU is more than the collection of GNU
programs.  We decided to develop GNU, a complete free system, and we
wrote the GNU programs as part of doing that.

See http://www.gnu.org/gnu/linux-and-gnu.html for more explanation.

    Should I then refer
    to SuSE as commercial Linux/XFree/Sun/GNU distributor?

It is redundant to mention XFree, since that is part of the GNU
system; we included it in GNU before Linux was written.  But you can
mention it if you like, and you can mention Sun too if you wish.  If
you would like to call the system GNU/Sun/XFree/Linux, I won't argue.
That name is more accurate than "Linux".

However, those who feel that name is too long to be practical, and
wish to shorten it, should omit secondary contributions such as Sun,
XFree and/or Linux, rather than omitting the primary contribution, GNU.

_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/emacs-devel