--- Begin Message ---
|
Subject: |
27.0.50; Accessing a cached SVG with eww can cause Emacs to crash |
|
Date: |
Tue, 23 Jul 2019 18:40:14 +0200 |
A cached SVG accessed with eww can cause Emacs to crash, even when the
same SVG does not cause a crash when it was not cached.
* To reproduce:
1. Since emacs -Q does not ignore ~/.emacs.d/url/cache it's best to use
a completely fresh profile with a custom HOME.
mkdir ~/temp_profile/
2. Open a page (https://nullprogram.com/blog/2019/07/22/) in eww that
includes the SVG and will cause it to be cached.
HOME=/home/adam/temp_profile/ emacs -Q --eval '(eww
"https://nullprogram.com/blog/2019/07/22/";)'
3. Exit Emacs (the bug will also occur if Emacs isn't exited and only
the eww buffer killed, but this way is simplest).
4. Open the SVG (https://nullprogram.com/img/diagram/collision.svg)
directly.
HOME=/home/adam/temp_profile/ emacs -Q --eval '(eww
"https://nullprogram.com/img/diagram/collision.svg";)'
(In all:
mkdir ~/temp_profile/
HOME=/home/adam/temp_profile/ emacs -Q --eval '(eww
"https://nullprogram.com/blog/2019/07/22/";)'
HOME=/home/adam/temp_profile/ emacs -Q --eval '(eww
"https://nullprogram.com/img/diagram/collision.svg";)'
)
* Expected result:
The webpage, including images, is correctly displayed in 2, and the SVG
is correctly displayed in 4.
* Actual result:
The webpage, including images, is correctly display in 2, but loading
the SVG causes a crash:
Fatal error 11: Segmentation fault
Backtrace:
emacs[0x50f869]
emacs[0x41aa4d]
emacs[0x50e13e]
emacs[0x50e4d3]
emacs[0x50e510]
/lib/x86_64-linux-gnu/libpthread.so.0(+0x11390)[0x7fbacc66b390]
/usr/lib/x86_64-linux-gnu/librsvg-2.so.2(rsvg_handle_get_dimensions+0x0)[0x7fbacf3095b0]
emacs[0x5f5d12]
emacs[0x5f618d]
emacs[0x5f94f4]
emacs[0x5f9b6d]
emacs[0x574583]
emacs[0x5af7b8]
emacs[0x5744d7]
emacs[0x5af7b8]
emacs[0x5744d7]
emacs[0x5af7b8]
emacs[0x5744d7]
emacs[0x5af7b8]
emacs[0x5744d7]
emacs[0x576050]
emacs[0x574583]
emacs[0x5af7b8]
emacs[0x5744d7]
emacs[0x5af7b8]
emacs[0x5744d7]
emacs[0x5af7b8]
emacs[0x5744d7]
emacs[0x576050]
emacs[0x57623c]
emacs[0x572f06]
emacs[0x5b2bb1]
emacs[0x5ba349]
emacs[0x501783]
emacs[0x5033a7]
emacs[0x504b50]
emacs[0x572e6e]
emacs[0x4f68bc]
emacs[0x572e0c]
emacs[0x4f6879]
emacs[0x4fb889]
...
Segmentation fault (core dumped)
* Further information
Removing the relevant cache entry at
~/.emacs.d/url/cache/adam/https/com/nullprogram/87600a34d4be777955bc9e1315cb16c4
prevents the crash from occurring:
rm
~/temp_profile/.emacs.d/url/cache/adam/https/com/nullprogram/87600a34d4be777955bc9e1315cb16c4
HOME=/home/adam/temp_profile/ emacs -Q --eval '(eww
"https://nullprogram.com/img/diagram/collision.svg";)'
Editing the cache entry to remove the line `Content-Encoding: gzip' also
prevents the crash:
sed '/^Content-Encoding: gzip$/ D' -i
~/temp_profile/.emacs.d/url/cache/adam/https/com/nullprogram/87600a34d4be777955bc9e1315cb16c4
HOME=/home/adam/temp_profile/ emacs -Q --eval '(eww
"https://nullprogram.com/img/diagram/collision.svg";)'
* Speculation
I think that the bug is caused by the fact that when Emacs receives an
HTTP response with Content-Encoding: gzip in the headers, it
(naturally!) decompresses the content, and when storing a cache, it
writes the decompressed content. However, when opening the cache, Emacs
again tries to follow the (still existing) `Content-Encoding' header and
tries decompress the content. `zlib-decompress-region' in
`url-handle-content-transfer-encoding' obviously fails, and (I think)
replaces the content with an empty string. Parsing that "content", in
turn causes the image library (in this case rsvg) to crash.
(On the surface level, the bug is obviously caused by the library
crashing, but as already discussed in many other bugs, this is probably
unavoidable.)
Thank you and best regards,
Adam
In GNU Emacs 27.0.50 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.18.9)
of 2019-07-20 built on adam
Repository revision: 189296bfcc3ff9fef66ba28e045b2898125120f2
Repository branch: master
Windowing system distributor 'The X.Org Foundation', version 11.0.11804000
System Description: Ubuntu 16.04.6 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 SOUND GPM DBUS GSETTINGS GLIB NOTIFY INOTIFY
ACL LIBSELINUX GNUTLS LIBXML2 FREETYPE HARFBUZZ M17N_FLT LIBOTF XFT ZLIB
TOOLKIT_SCROLL_BARS GTK3 X11 XDBE XIM MODULES THREADS PDUMPER LCMS2 GMP
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 dired dired-loaddefs
format-spec rfc822 mml easymenu mml-sec password-cache epa derived epg
epg-config gnus-util rmail rmail-loaddefs text-property-search time-date
seq byte-opt gv bytecomp byte-compile cconv mm-decode mm-bodies
mm-encode mail-parse rfc2231 mailabbrev gmm-utils mailheader cl-loaddefs
cl-lib sendmail rfc2047 rfc2045 ietf-drums mm-util mail-prsvr mail-utils
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 threads 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 43246 7640)
(symbols 48 5878 1)
(strings 32 15473 1825)
(string-bytes 1 500975)
(vectors 16 9022)
(vector-slots 8 120278 8826)
(floats 8 17 37)
(intervals 56 188 0)
(buffers 992 11)
(heap 1024 12205 1072))
--- End Message ---
--- Begin Message ---
|
Subject: |
Re: bug#36773: 27.0.50; Accessing a cached SVG with eww can cause Emacs to crash |
|
Date: |
Sat, 27 Jul 2019 13:58:46 +0300 |
> From: Pip Cet <address@hidden>
> Date: Thu, 25 Jul 2019 14:14:43 +0000
> Cc: address@hidden, address@hidden, address@hidden
>
> > > I misread what you wrote at first, but I like my misreading better:
> > > url-handle-content-transfer-encoding modifies the message, but not its
> > > headers. Why shouldn't it do both?
> >
> > Yes, I think it should. Because that's the root cause of the problem:
> > the data is uncompressed, but the headers still say it is compressed.
>
> Okay, I think it's likely we're going to require something similar for
> other headers, so I added an argument to mail-fetch-field to delete
> the fetched field's header line(s).
>
> Patches attached (the first should be unmodified). Appears to work here.
Thanks, I've now pushed your second patch, and I'm closing this bug.
--- End Message ---