GNU bug report logs - #36773
27.0.50; Accessing a cached SVG with eww can cause Emacs to crash

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 36773 in the body.
You can then email your comments to 36773 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: adam plaice <plaice.adam+lists <at> gmail.com>
To: bug-gnu-emacs <at> gnu.org
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))

Message #8 received at 36773 <at> debbugs.gnu.org (full text, mbox):

From: Pip Cet <pipcet <at> gmail.com>
To: adam plaice <plaice.adam+lists <at> gmail.com>
Cc: 36773 <at> debbugs.gnu.org
Subject: Re: bug#36773: 27.0.50; Accessing a cached SVG with eww can cause
 Emacs to crash
Date: Tue, 23 Jul 2019 18:37:38 +0000

On Tue, Jul 23, 2019 at 4:41 PM adam plaice <plaice.adam+lists <at> gmail.com> wrote:
> 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.

I can't reproduce the crash; however, I do get some "critical"
warnings from glib because we pass NULL pointers to g_object_unref,
and no image.

So there appear to be at least two bugs here. svg_load_image passes a
NULL pointer to g_object_unref, and eww passes bad cached data to
image.c. And possibly a third bug that's causing your crash.

Which version of librsvg are you using?

Message #11 received at 36773 <at> debbugs.gnu.org (full text, mbox):

From: Adam Plaice <plaiceadam <at> gmail.com>
To: Pip Cet <pipcet <at> gmail.com>
Cc: 36773 <at> debbugs.gnu.org
Subject: Re: bug#36773: 27.0.50; Accessing a cached SVG with eww can cause
 Emacs to crash
Date: Tue, 23 Jul 2019 21:33:57 +0200

Thanks for replying!

> Which version of librsvg are you using?

I'm using version 2.40.13 (installed via apt on Ubuntu 16.04).

Message #14 received at 36773 <at> debbugs.gnu.org (full text, mbox):

From: Pip Cet <pipcet <at> gmail.com>
To: Adam Plaice <plaiceadam <at> gmail.com>
Cc: 36773 <at> debbugs.gnu.org
Subject: Re: bug#36773: 27.0.50; Accessing a cached SVG with eww can cause
 Emacs to crash
Date: Tue, 23 Jul 2019 20:06:40 +0000

On Tue, Jul 23, 2019 at 7:34 PM Adam Plaice <plaiceadam <at> gmail.com> wrote:
> > Which version of librsvg are you using?
> I'm using version 2.40.13 (installed via apt on Ubuntu 16.04).

It might be helpful if you could provide a C backtrace of the
segfault, as described in the Emacs manual. (start "gdb --args ./emacs
-Q ..." in the src/ directory; enter "run", then "backtrace full",
then "xbacktrace").

Message #17 received at 36773 <at> debbugs.gnu.org (full text, mbox):

From: Adam Plaice <plaiceadam <at> gmail.com>
To: Pip Cet <pipcet <at> gmail.com>
Cc: 36773 <at> debbugs.gnu.org
Subject: Re: bug#36773: 27.0.50; Accessing a cached SVG with eww can cause
 Emacs to crash
Date: Tue, 23 Jul 2019 23:13:56 +0200

[Message part 1 (text/plain, inline)]

I've attached the backtrace.

(This is with the default optimisation level. If necessary, I could
rebuild with -O0.)

Thanks!

[gdb.txt (text/plain, attachment)]

Message #20 received at 36773 <at> debbugs.gnu.org (full text, mbox):

From: Pip Cet <pipcet <at> gmail.com>
To: Adam Plaice <plaiceadam <at> gmail.com>
Cc: 36773 <at> debbugs.gnu.org
Subject: Re: bug#36773: 27.0.50; Accessing a cached SVG with eww can cause
 Emacs to crash
Date: Wed, 24 Jul 2019 13:24:46 +0000

[Message part 1 (text/plain, inline)]

On Tue, Jul 23, 2019 at 9:14 PM Adam Plaice <plaiceadam <at> gmail.com> wrote:
>
> I've attached the backtrace.

Thanks. This seems like a librsvg bug, since it returned a NULL handle
but no error.

As for the other bug, it's a little tricky: shr calls
url-store-in-cache after url-http-parse-headers has decompressed the
file, while url-http-parse-headers itself would (correctly) cache the
uncompressed file if it were configured to do so. It's not quite clear
who's at fault here.

IOW, there's probably a conflict in existing cache directories: some
of them will store the compressed data, which won't work if it's
images; some will store the uncompressed data, which won't work for
HTML data.

I'm attaching a patch to fix the rsvg segfault, and another patch
which works around the url-http issue. However, I'm not sure how the
latter should be fixed properly.

[0002-Cache-HTTP-responses-as-uncompressed-data.patch (text/x-patch, attachment)]

[0001-Don-t-crash-when-parsing-bad-SVG-data-bug-36773.patch (text/x-patch, attachment)]

Message #23 received at 36773 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Pip Cet <pipcet <at> gmail.com>
Cc: plaiceadam <at> gmail.com, 36773 <at> debbugs.gnu.org
Subject: Re: bug#36773: 27.0.50;
 Accessing a cached SVG with eww can cause Emacs to crash
Date: Wed, 24 Jul 2019 17:46:56 +0300

> From: Pip Cet <pipcet <at> gmail.com>
> Date: Wed, 24 Jul 2019 13:24:46 +0000
> Cc: 36773 <at> debbugs.gnu.org
> 
> As for the other bug, it's a little tricky: shr calls
> url-store-in-cache after url-http-parse-headers has decompressed the
> file, while url-http-parse-headers itself would (correctly) cache the
> uncompressed file if it were configured to do so. It's not quite clear
> who's at fault here.

What's more, this problem doesn't happen in Emacs 26.2.90.  Can you
see why it started happening in Emacs 27?  Maybe that will provide a
hint as to how to fix it.

Btw, I see the same behavior as you, Pip: g_object_unref error
messages and no crash.  librasvg returns a NULL handle, but it also
returns a non-zero err.  My librsvg version is 2.40.1.

Message #26 received at 36773 <at> debbugs.gnu.org (full text, mbox):

From: Pip Cet <pipcet <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: plaiceadam <at> gmail.com, 36773 <at> debbugs.gnu.org
Subject: Re: bug#36773: 27.0.50; Accessing a cached SVG with eww can cause
 Emacs to crash
Date: Wed, 24 Jul 2019 18:28:20 +0000

On Wed, Jul 24, 2019 at 2:47 PM Eli Zaretskii <eliz <at> gnu.org> wrote:
> > From: Pip Cet <pipcet <at> gmail.com>
> > Date: Wed, 24 Jul 2019 13:24:46 +0000
> > Cc: 36773 <at> debbugs.gnu.org
> >
> > As for the other bug, it's a little tricky: shr calls
> > url-store-in-cache after url-http-parse-headers has decompressed the
> > file, while url-http-parse-headers itself would (correctly) cache the
> > uncompressed file if it were configured to do so. It's not quite clear
> > who's at fault here.
>
> What's more, this problem doesn't happen in Emacs 26.2.90.  Can you
> see why it started happening in Emacs 27?  Maybe that will provide a
> hint as to how to fix it.

-      (zlib-decompress-region (point) (point-max)))))))
+      (zlib-decompress-region (point) (point-max) t))))))

The allow-partial flag means to delete rather than simply leave the
(uncompressed) data in place.

So I guess that is a hint, we could just go back to the Emacs-26
behavior. I don't think we should, but in practice it should work
okay.

> Btw, I see the same behavior as you, Pip: g_object_unref error
> messages and no crash.  librasvg returns a NULL handle, but it also
> returns a non-zero err.  My librsvg version is 2.40.1.

The bug in librsvg was introduced between 2.40.1 and 2.40.13, and has
been fixed again since. 2.40.13 does:

    if (g_buffered_input_stream_fill (G_BUFFERED_INPUT_STREAM
(stream), 2, cancellable, error) != 2) {
        g_object_unref (stream);
        return FALSE;
    }

Which returns without an error filled in if stream doesn't contain at
least two bytes.

Message #29 received at 36773 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Pip Cet <pipcet <at> gmail.com>
Cc: plaiceadam <at> gmail.com, 36773 <at> debbugs.gnu.org
Subject: Re: bug#36773: 27.0.50; Accessing a cached SVG with eww can cause
 Emacs to crash
Date: Wed, 24 Jul 2019 22:11:04 +0300

> From: Pip Cet <pipcet <at> gmail.com>
> Date: Wed, 24 Jul 2019 18:28:20 +0000
> Cc: plaiceadam <at> gmail.com, 36773 <at> debbugs.gnu.org
> 
> > What's more, this problem doesn't happen in Emacs 26.2.90.  Can you
> > see why it started happening in Emacs 27?  Maybe that will provide a
> > hint as to how to fix it.
> 
> -      (zlib-decompress-region (point) (point-max)))))))
> +      (zlib-decompress-region (point) (point-max) t))))))
> 
> The allow-partial flag means to delete rather than simply leave the
> (uncompressed) data in place.

I thought that additional argument only mattered upon failure to
completely uncompress the data.  Otherwise, the use of that argument
should not have changed the behavior.  Are you saying that the
decompression failed in this case?  If not, what am I missing?

Thanks.

Message #32 received at 36773 <at> debbugs.gnu.org (full text, mbox):

From: Adam Plaice <plaiceadam <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: Pip Cet <pipcet <at> gmail.com>, 36773 <at> debbugs.gnu.org
Subject: Re: bug#36773: 27.0.50; Accessing a cached SVG with eww can cause
 Emacs to crash
Date: Thu, 25 Jul 2019 00:13:16 +0200

> I'm attaching a patch to fix the rsvg segfault, and another patch
> which works around the url-http issue. However, I'm not sure how the
> latter should be fixed properly.

Thanks! The first patch indeed prevents the crash, while the second also
causes the image to be displayed (as expected).

> -      (zlib-decompress-region (point) (point-max)))))))
> +      (zlib-decompress-region (point) (point-max) t))))))

> So I guess that is a hint, we could just go back to the Emacs-26
> behavior. I don't think we should, but in practice it should work
> okay.

b36913d803ee22a314f2e0a27523fbadeb60dd2c introduced the above change.
Testing with a checkout of it, results in a blank "standard error box"
being displayed, though interestingly without a crash.  At
b36913d803ee22a314f^ the SVG was correctly displayed, so
b36913d803ee22a314f did indeed introduce (part of) this bug.  However,
not using ALLOW-PARTIAL, would re-introduce Bug#33133, which would
probably not be a great idea.

(I tried bisecting to find out when the crashes themselves started,
but without appropriate "make clean"ing (or more severe), I ended up
in an unbuildable state, and I didn't have time for full rebuilds,
with this range to be bisected.  In any case, your
0001-Don-t-crash-when-parsing-bad-SVG-data-bug-36773.patch fixes the
crash.)

> I thought that additional argument only mattered upon failure to
> completely uncompress the data.  Otherwise, the use of that argument
> should not have changed the behavior.  Are you saying that the
> decompression failed in this case?  If not, what am I missing?

If I understand the issue correctly, it's because
`zlib-decompress-region' is trying to decompress content that is in
the cache and had already been decompressed.  Hence, the decompression
fails and deletes the contents, which, depending on other particulars,
either crashes Emacs or causes a warning, and in any case prevents the
actual image from being displayed.

Thank you!
Adam

Message #35 received at 36773 <at> debbugs.gnu.org (full text, mbox):

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Pip Cet <pipcet <at> gmail.com>
Cc: Adam Plaice <plaiceadam <at> gmail.com>, 36773 <at> debbugs.gnu.org
Subject: Re: bug#36773: 27.0.50; Accessing a cached SVG with eww can cause
 Emacs to crash
Date: Thu, 25 Jul 2019 11:38:07 +0200

Pip Cet <pipcet <at> gmail.com> writes:

> As for the other bug, it's a little tricky: shr calls
> url-store-in-cache after url-http-parse-headers has decompressed the
> file, while url-http-parse-headers itself would (correctly) cache the
> uncompressed file if it were configured to do so. It's not quite clear
> who's at fault here.

Perhaps url-store-in-cache should take a parameter to remove the
Content-Encoding header (i.e. "gzip")?  It should really be up to the
program that uses url.el (i.e. shr) whether to cache the data or not...

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Message #38 received at 36773 <at> debbugs.gnu.org (full text, mbox):

From: Pip Cet <pipcet <at> gmail.com>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: Adam Plaice <plaiceadam <at> gmail.com>, 36773 <at> debbugs.gnu.org
Subject: Re: bug#36773: 27.0.50; Accessing a cached SVG with eww can cause
 Emacs to crash
Date: Thu, 25 Jul 2019 11:51:16 +0000

On Thu, Jul 25, 2019 at 9:38 AM Lars Ingebrigtsen <larsi <at> gnus.org> wrote:
> > As for the other bug, it's a little tricky: shr calls
> > url-store-in-cache after url-http-parse-headers has decompressed the
> > file, while url-http-parse-headers itself would (correctly) cache the
> > uncompressed file if it were configured to do so. It's not quite clear
> > who's at fault here.
>
> Perhaps url-store-in-cache should take a parameter to remove the
> Content-Encoding header (i.e. "gzip")?  It should really be up to the
> program that uses url.el (i.e. shr) whether to cache the data or not...

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?

Message #41 received at 36773 <at> debbugs.gnu.org (full text, mbox):

From: Pip Cet <pipcet <at> gmail.com>
To: Adam Plaice <plaiceadam <at> gmail.com>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 36773 <at> debbugs.gnu.org
Subject: Re: bug#36773: 27.0.50; Accessing a cached SVG with eww can cause
 Emacs to crash
Date: Thu, 25 Jul 2019 12:05:10 +0000

On Wed, Jul 24, 2019 at 10:13 PM Adam Plaice <plaiceadam <at> gmail.com> wrote:
> > I'm attaching a patch to fix the rsvg segfault, and another patch
> > which works around the url-http issue. However, I'm not sure how the
> > latter should be fixed properly.
>
> Thanks! The first patch indeed prevents the crash, while the second also
> causes the image to be displayed (as expected).

Thank you for testing.

> > -      (zlib-decompress-region (point) (point-max)))))))
> > +      (zlib-decompress-region (point) (point-max) t))))))
>
> > So I guess that is a hint, we could just go back to the Emacs-26
> > behavior. I don't think we should, but in practice it should work
> > okay.
>
> b36913d803ee22a314f2e0a27523fbadeb60dd2c introduced the above change.
> Testing with a checkout of it, results in a blank "standard error box"
> being displayed, though interestingly without a crash.  At
> b36913d803ee22a314f^ the SVG was correctly displayed, so
> b36913d803ee22a314f did indeed introduce (part of) this bug.  However,
> not using ALLOW-PARTIAL, would re-introduce Bug#33133, which would
> probably not be a great idea.

Agreed. As I said, I think it's best to remove the content-encoding
header when interpreting it.

> > I thought that additional argument only mattered upon failure to
> > completely uncompress the data.  Otherwise, the use of that argument
> > should not have changed the behavior.  Are you saying that the
> > decompression failed in this case?  If not, what am I missing?
>
> If I understand the issue correctly, it's because
> `zlib-decompress-region' is trying to decompress content that is in
> the cache and had already been decompressed.

That's my understanding as well.

> Hence, the decompression
> fails and deletes the contents, which, depending on other particulars,
> either crashes Emacs or causes a warning, and in any case prevents the
> actual image from being displayed.

I don't think "allow-partial" properly expresses the "and delete the
specified region unconditionally" semantics we now have. It might make
more sense to replace the region only if at least one byte of data was
successfully decompressed.

Message #44 received at 36773 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Pip Cet <pipcet <at> gmail.com>
Cc: larsi <at> gnus.org, plaiceadam <at> gmail.com, 36773 <at> debbugs.gnu.org
Subject: Re: bug#36773: 27.0.50;
 Accessing a cached SVG with eww can cause Emacs to crash
Date: Thu, 25 Jul 2019 15:55:09 +0300

> From: Pip Cet <pipcet <at> gmail.com>
> Date: Thu, 25 Jul 2019 11:51:16 +0000
> Cc: Adam Plaice <plaiceadam <at> gmail.com>, 36773 <at> debbugs.gnu.org
> 
> > Perhaps url-store-in-cache should take a parameter to remove the
> > Content-Encoding header (i.e. "gzip")?  It should really be up to the
> > program that uses url.el (i.e. shr) whether to cache the data or not...
> 
> 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.

Thanks.

Message #47 received at 36773 <at> debbugs.gnu.org (full text, mbox):

From: Pip Cet <pipcet <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: larsi <at> gnus.org, plaiceadam <at> gmail.com, 36773 <at> debbugs.gnu.org
Subject: Re: bug#36773: 27.0.50; Accessing a cached SVG with eww can cause
 Emacs to crash
Date: Thu, 25 Jul 2019 14:14:43 +0000

[Message part 1 (text/plain, inline)]

On Thu, Jul 25, 2019 at 12:55 PM Eli Zaretskii <eliz <at> gnu.org> wrote:
> > From: Pip Cet <pipcet <at> gmail.com>
> > Date: Thu, 25 Jul 2019 11:51:16 +0000
> > Cc: Adam Plaice <plaiceadam <at> gmail.com>, 36773 <at> debbugs.gnu.org
> >
> > > Perhaps url-store-in-cache should take a parameter to remove the
> > > Content-Encoding header (i.e. "gzip")?  It should really be up to the
> > > program that uses url.el (i.e. shr) whether to cache the data or not...
> >
> > 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.

[0001-Don-t-crash-when-parsing-bad-SVG-data-bug-36773.patch (text/x-patch, attachment)]

[0002-Don-t-double-decompress-cached-HTTP-responses-bug-36.patch (text/x-patch, attachment)]

Message #50 received at 36773 <at> debbugs.gnu.org (full text, mbox):

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Pip Cet <pipcet <at> gmail.com>
Cc: Adam Plaice <plaiceadam <at> gmail.com>, 36773 <at> debbugs.gnu.org
Subject: Re: bug#36773: 27.0.50; Accessing a cached SVG with eww can cause
 Emacs to crash
Date: Thu, 25 Jul 2019 19:09:05 +0200

Pip Cet <pipcet <at> gmail.com> writes:

>> Perhaps url-store-in-cache should take a parameter to remove the
>> Content-Encoding header (i.e. "gzip")?  It should really be up to the
>> program that uses url.el (i.e. shr) whether to cache the data or not...
>
> 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, that makes a lot more sense.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Message #53 received at 36773 <at> debbugs.gnu.org (full text, mbox):

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: Pip Cet <pipcet <at> gmail.com>
Cc: 36773 <at> debbugs.gnu.org
Subject: Re: bug#36773: 27.0.50; Accessing a cached SVG with eww can cause
 Emacs to crash
Date: Thu, 25 Jul 2019 14:37:26 -0700

[Message part 1 (text/plain, inline)]

Thanks for writing those patches. The image.c patch is obviously needed to 
prevent a core dump, so I installed the attached variant of it (added a comment, 
changed a never-can-happen branch in obsolete code to an eassume). I assume the 
Elisp changes are good too, but I didn't check them so didn't install them.

[0001-Don-t-crash-when-parsing-bad-SVG-data.patch (text/x-patch, attachment)]

Message #56 received at 36773 <at> debbugs.gnu.org (full text, mbox):

From: Adam Plaice <plaiceadam <at> gmail.com>
To: Pip Cet <pipcet <at> gmail.com>
Cc: Lars Ingebrigtsen <larsi <at> gnus.org>, 36773 <at> debbugs.gnu.org
Subject: Re: bug#36773: 27.0.50; Accessing a cached SVG with eww can cause
 Emacs to crash
Date: Fri, 26 Jul 2019 00:14:10 +0200

> Patches attached (the first should be unmodified). Appears to work here.

FWIW the new 0002 also works for me.

Thank you very much.
Adam

Message #61 received at 36773-done <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Pip Cet <pipcet <at> gmail.com>
Cc: 36773-done <at> debbugs.gnu.org, larsi <at> gnus.org, plaiceadam <at> gmail.com
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 <pipcet <at> gmail.com>
> Date: Thu, 25 Jul 2019 14:14:43 +0000
> Cc: larsi <at> gnus.org, plaiceadam <at> gmail.com, 36773 <at> debbugs.gnu.org
> 
> > > 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.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.