bug#29581: 26.0.90; SVG file can cause emacs to crash (imagemagick)

classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

bug#29581: 26.0.90; SVG file can cause emacs to crash (imagemagick)

adam plaice
If emacs, on Linux, is compiled with imagemagick support, then opening
a specific
svg file can cause emacs to crash. The bug report is based on
https://emacs.stackexchange.com/questions/37216/open-svg-files-in-xml-mode

* To reproduce:

1. Save the following to test.svg (svg file taken from the above
mentioned stackexchange question):

<svg xmlns="http://www.w3.org/2000/svg">
  <symbol id="cross" viewBox="0 0 20 20">
    <path d="M17.1 5.2l-2.6-2.6-4.6 4.7-4.7-4.7-2.5 2.6 4.7 4.7-4.7
4.7 2.5 2.5 4.7-4.7 4.6 4.7 2.6-2.5-4.7-4.7"/>
  </symbol>
  <symbol id="play" viewBox="0 0 15 15">
    <path d="M690 60H40l330 570L700 60z" />
  </symbol>
</svg>

2. Run:

emacs -Q test.svg

* Expected result:

A blank square or nothing is displayed (since the svg file does not contain any
actual image) and (optionally) an error message is displayed.

* Actual result:

A segmentation fault occurs (with the following output) and emacs crashes:

Fatal error 11: Segmentation fault
Backtrace:
emacs[0x50e019]
emacs[0x4f46c7]
emacs[0x50c9ce]
emacs[0x50ccd3]
emacs[0x50cd10]
/lib/x86_64-linux-gnu/libpthread.so.0(+0x11390)[0x7f2f395d5390]
/usr/lib/x86_64-linux-gnu/ImageMagick-6.8.9/modules-Q16/coders/svg.so(+0xb8b8)[0x7f2f26b9a8b8]
/usr/lib/x86_64-linux-gnu/libMagickCore-6.Q16.so.2(ReadImage+0x198)[0x7f2f3bd688e8]
/usr/lib/x86_64-linux-gnu/libMagickWand-6.Q16.so.2(MagickReadImage+0x6a)[0x7f2f3c23aa3a]
emacs[0x5e39c2]
emacs[0x5ea8b4]
emacs[0x5eaba0]
emacs[0x56ca4f]
emacs[0x56bb26]
emacs[0x5a4f78]
emacs[0x56b7df]
emacs[0x56ba8b]
emacs[0x5a4f78]
emacs[0x56b7df]
emacs[0x56ba8b]
emacs[0x5a4f78]
emacs[0x56b7df]
emacs[0x56ba8b]
emacs[0x5a4f78]
emacs[0x56b7df]
emacs[0x56ba8b]
emacs[0x5a4f78]
emacs[0x56b7df]
emacs[0x56ba8b]
emacs[0x5a4f78]
emacs[0x56b7df]
emacs[0x56ba8b]
emacs[0x5a4f78]
emacs[0x56b7df]
emacs[0x56ba8b]
emacs[0x5a4f78]
emacs[0x56b7df]
emacs[0x56ba8b]
emacs[0x5a4f78]
emacs[0x56b7df]
emacs[0x56ba8b]
...
Segmentation fault (core dumped)


* Possibly relevant information

The error occurs only when emacs is compiled with ImageMagick
support. If it's compiled --without-imagemagick then the error does
not occur.  Also, when emacs is forced/tricked to use the librsvg
backend, rather than imagemagick, (even when imagemagick support was
compiled in) the error does not occur.

Trying to manipulate the file test.svg directly with imagemagick, for
example via:

convert test.svg test.png

also results in an error:

Aborted (core dumped)

so the "fault" is almost certainly on the side of imagemagick, but
perhaps there's something that emacs can do about it.


The bug is present in both emacs-25.3 and the latest emacs from the
emacs-26 branch.  It was not present, by default, in emacs-24.5.1
and earlier (as expected, the image was not displayed, but emacs did
not crash), though it seems to be because for these versions of emacs,
the imagemagick backend was not the default — if emacs is forced to
use the imagemagick backend, the bug/crash does occur.

Thank you and best regards,
Adam


In GNU Emacs 26.0.90 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.18.9)
 of 2017-12-05 built on adam
Repository revision: 46d62b9f36f1ef771a077df4227ae6559fb32e84
Windowing system distributor 'The X.Org Foundation', version 11.0.11804000
System Description:    Ubuntu 16.04.3 LTS

Recent messages:
For information about GNU Emacs and the GNU system, type C-h C-a.

Configured using:
 'configure --with-modules --without-pop'

Configured features:
XPM JPEG TIFF GIF PNG RSVG IMAGEMAGICK SOUND GPM DBUS GSETTINGS NOTIFY
ACL LIBSELINUX GNUTLS LIBXML2 FREETYPE M17N_FLT LIBOTF XFT ZLIB
TOOLKIT_SCROLL_BARS GTK3 X11 MODULES LIBSYSTEMD LCMS2

Important settings:
  value of $LANG: en_GB.UTF-8
  locale-coding-system: utf-8-unix

Major mode: Lisp Interaction

Minor modes in effect:
  tooltip-mode: t
  global-eldoc-mode: t
  eldoc-mode: t
  electric-indent-mode: t
  mouse-wheel-mode: t
  tool-bar-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  blink-cursor-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  line-number-mode: t
  transient-mark-mode: t

Load-path shadows:
None found.

Features:
(shadow sort mail-extr emacsbug message rmc puny seq byte-opt gv
bytecomp byte-compile cconv cl-loaddefs cl-lib dired dired-loaddefs
format-spec rfc822 mml easymenu mml-sec password-cache epa derived epg
epg-config gnus-util rmail rmail-loaddefs mm-decode mm-bodies mm-encode
mail-parse rfc2231 mailabbrev gmm-utils mailheader sendmail rfc2047
rfc2045 ietf-drums mm-util mail-prsvr mail-utils elec-pair time-date
mule-util tooltip eldoc electric uniquify ediff-hook vc-hooks
lisp-float-type mwheel term/x-win x-win term/common-win x-dnd tool-bar
dnd fontset image regexp-opt fringe tabulated-list replace newcomment
text-mode elisp-mode lisp-mode prog-mode register page menu-bar
rfn-eshadow isearch timer select scroll-bar mouse jit-lock font-lock
syntax facemenu font-core term/tty-colors frame cl-generic cham georgian
utf-8-lang misc-lang vietnamese tibetan thai tai-viet lao korean
japanese eucjp-ms cp51932 hebrew greek romanian slovak czech european
ethiopic indian cyrillic chinese composite charscript charprop
case-table epa-hook jka-cmpr-hook help simple abbrev obarray minibuffer
cl-preloaded nadvice loaddefs button faces cus-face macroexp files
text-properties overlay sha1 md5 base64 format env code-pages mule
custom widget hashtable-print-readable backquote dbusbind inotify lcms2
dynamic-setting system-font-setting font-render-setting move-toolbar gtk
x-toolkit x multi-tty make-network-process emacs)

Memory information:
((conses 16 94561 8308)
 (symbols 48 20332 1)
 (miscs 40 42 118)
 (strings 32 28247 1513)
 (string-bytes 1 744109)
 (vectors 16 13967)
 (vector-slots 8 491974 7546)
 (floats 8 50 67)
 (intervals 56 219 0)
 (buffers 992 12)
 (heap 1024 35241 1000))



Reply | Threaded
Open this post in threaded view
|

bug#29581: 26.0.90; SVG file can cause emacs to crash (imagemagick)

Noam Postavsky-2
# not an Emacs bug
tags 29581 + notabug
quit

adam plaice <[hidden email]> writes:

> Trying to manipulate the file test.svg directly with imagemagick, for
> example via:
>
> convert test.svg test.png
>
> also results in an error:
>
> Aborted (core dumped)
>
> so the "fault" is almost certainly on the side of imagemagick, but
> perhaps there's something that emacs can do about it.

I don't see what; imagemagick is a C library, if it crashes there is no
recourse.



Reply | Threaded
Open this post in threaded view
|

bug#29581: 26.0.90; SVG file can cause emacs to crash (imagemagick)

Paul Eggert
In reply to this post by adam plaice
For what it's worth I cannot reproduce the problem on my platform, which should
be nearly identical to yours. I am running Ubuntu 16.04.3 patched as of today,
on an x86-64 CPU (Intel Xeon E3-1225 V2). I don't observe the problem when
running "convert test.svg test.png" either. With the -verbose flag I get this:

$ convert -verbose test.svg test.png
"inkscape" "test.svg" --export-eps="/tmp/magick-2930_tpO0u1d3XJD"
--export-dpi="90,90" --export-background="rgb(100%,100%,100%)"
--export-background-opacity="1" > "/tmp/magick-2930yrS5cAdhqGGS" 2>&1
convert: no images defined `test.png' @ error/convert.c/ConvertImageCommand/3210.

You might try "strace convert test.svg test.png" to see what went wrong. Anyway,
as you say, this doesn't appear to be an Emacs bug, and it's not clear what
Emacs could do to prevent the library from going haywire.



Reply | Threaded
Open this post in threaded view
|

bug#29581: 26.0.90; SVG file can cause emacs to crash (imagemagick)

Adam Plaice-2
Thanks for investigating, anyway!

(That is weird, as the only difference appears to be the exact x86-64
processor (the system is obviously up-to-date etc.). Also, I've
reproduced it on several different machines. However, since the bug
seems to be out-of-scope for emacs, is absent in newer versions of
ImageMagick compiled from source, and I have very little understanding
of the internals of ImageMagick, I won't continue digging into this.)



Reply | Threaded
Open this post in threaded view
|

bug#29581: 26.0.90; SVG file can cause emacs to crash (imagemagick)

Tobias Zawada

Hello,

Could a catch(...) around library calls avoid that emacs crashes?

Best regards,

Tobias

Adam Plaice hat am 13. Dezember 2017 um 02:52 geschrieben:


Thanks for investigating, anyway!

(That is weird, as the only difference appears to be the exact x86-64
processor (the system is obviously up-to-date etc.). Also, I've
reproduced it on several different machines. However, since the bug
seems to be out-of-scope for emacs, is absent in newer versions of
ImageMagick compiled from source, and I have very little understanding
of the internals of ImageMagick, I won't continue digging into this.)

Reply | Threaded
Open this post in threaded view
|

bug#29581: 26.0.90; SVG file can cause emacs to crash (imagemagick)

Noam Postavsky-2
On Wed, Dec 13, 2017 at 6:00 AM, Tobias Zawada <[hidden email]> wrote:

> Could a catch(...) around library calls avoid that emacs crashes?

What is "a catch(...)"? Do you mean the C++ construct[1]? Neither
imagemagick (afaik) nor Emacs are in C++. And even if they were C++,
catch does not help with segfaults.

[1]: http://en.cppreference.com/w/cpp/language/try_catch