bug-gnu-emacs
[Top][All Lists]
Advanced

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

Crash when loading a particular gif image


From: Göran Uddeborg
Subject: Crash when loading a particular gif image
Date: Tue, 13 Sep 2005 18:31:44 +0200

In GNU Emacs 21.4.1 (x86_64-redhat-linux-gnu, X toolkit, Xaw3d scroll bars)
 of 2005-05-18 on dolly.build.redhat.com
configured using `configure  --build=x86_64-redhat-linux 
--host=x86_64-redhat-linux --target=x86_64-redhat-linux-gnu --program-prefix= 
--prefix=/usr --exec-prefix=/usr --bindir=/usr/bin --sbindir=/usr/sbin 
--sysconfdir=/etc --datadir=/usr/share --includedir=/usr/include 
--libdir=/usr/lib64 --libexecdir=/usr/libexec --localstatedir=/var 
--sharedstatedir=/usr/com --mandir=/usr/share/man --infodir=/usr/share/info 
--with-pop --with-sound'
Important settings:
  value of $LC_ALL: nil
  value of $LC_COLLATE: nil
  value of $LC_CTYPE: nil
  value of $LC_MESSAGES: nil
  value of $LC_MONETARY: nil
  value of $LC_NUMERIC: nil
  value of $LC_TIME: nil
  value of $LANG: sv_SE
  locale-coding-system: iso-latin-1
  default-enable-multibyte-characters: t

Please describe exactly what actions triggered the bug
and the precise symptoms of the bug:

If I put the attached GIF image in /tmp/poison.gif, start "emacs -q",
and execute this line immediately in the default *scratch* buffer

   (put-text-property 1 10 'display (list 'image ':type 'gif ':file 
"/tmp/poison.gif" ':ascent 50))

then my emacs crashes with a segmentation fault.  (I type, or paste, the
line into the buffer, and then type C-j just after it.)

The text between 1 and 10 would be part of the standard message
explaining what the *scratch* buffer is about.

This does not happen for any picture, just for this particular one.

The source of the picture is from some SPAM I got which wasn't
captured.  I use VM as a mail reader, and it splits pictures into
stripes with "convert" from ImageMagick.  This is one of the stripes.
It could very well be something wrong in the format of the picture.
It's not complete garbage, I can look at it with other programs, but
the spammer och "convert" may have done some more subtle mistake.  But
in any case emacs shouldn't crash on broken input, should it?

I've tried this with both emacs 21.3 and 21.4, on i386 and x86_64
Fedora systems, with the same effect on all.


Recent input:
C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n 
C-n C-n C-n C-n C-v C-n C-n C-n C-n C-n C-n C-n C-n 
C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n 
C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n 
C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n 
C-x o C-x o C-x o C-x o M-< C-s s u b m i t C-s C-a 
C-p C-p C-p C-x o M-x r e p o r t - e m <tab> <ret
urn>

Recent messages:
For information about the GNU Project and its goals, type C-h C-p.
call-interactively: Quit
Making completion list...
Loading view...done
Loading apropos...done
Loading comint...done
No completions of bug
Mark set
Mark saved where search started
Loading emacsbug...done

Attachment: poison.gif
Description: Poisonous GIF image


reply via email to

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