* bug#36773: 27.0.50; Accessing a cached SVG with eww can cause Emacs to crash
@ 2019-07-23 16:40 adam plaice
2019-07-23 18:37 ` Pip Cet
2019-07-25 21:37 ` Paul Eggert
0 siblings, 2 replies; 19+ messages in thread
From: adam plaice @ 2019-07-23 16:40 UTC (permalink / raw)
To: 36773
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))
^ permalink raw reply [flat|nested] 19+ messages in thread
* bug#36773: 27.0.50; Accessing a cached SVG with eww can cause Emacs to crash
2019-07-23 16:40 bug#36773: 27.0.50; Accessing a cached SVG with eww can cause Emacs to crash adam plaice
@ 2019-07-23 18:37 ` Pip Cet
2019-07-23 19:33 ` Adam Plaice
2019-07-25 21:37 ` Paul Eggert
1 sibling, 1 reply; 19+ messages in thread
From: Pip Cet @ 2019-07-23 18:37 UTC (permalink / raw)
To: adam plaice; +Cc: 36773
On Tue, Jul 23, 2019 at 4:41 PM adam plaice <plaice.adam+lists@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?
^ permalink raw reply [flat|nested] 19+ messages in thread
* bug#36773: 27.0.50; Accessing a cached SVG with eww can cause Emacs to crash
2019-07-23 18:37 ` Pip Cet
@ 2019-07-23 19:33 ` Adam Plaice
2019-07-23 20:06 ` Pip Cet
0 siblings, 1 reply; 19+ messages in thread
From: Adam Plaice @ 2019-07-23 19:33 UTC (permalink / raw)
To: Pip Cet; +Cc: 36773
Thanks for replying!
> Which version of librsvg are you using?
I'm using version 2.40.13 (installed via apt on Ubuntu 16.04).
^ permalink raw reply [flat|nested] 19+ messages in thread
* bug#36773: 27.0.50; Accessing a cached SVG with eww can cause Emacs to crash
2019-07-23 19:33 ` Adam Plaice
@ 2019-07-23 20:06 ` Pip Cet
2019-07-23 21:13 ` Adam Plaice
0 siblings, 1 reply; 19+ messages in thread
From: Pip Cet @ 2019-07-23 20:06 UTC (permalink / raw)
To: Adam Plaice; +Cc: 36773
On Tue, Jul 23, 2019 at 7:34 PM Adam Plaice <plaiceadam@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").
^ permalink raw reply [flat|nested] 19+ messages in thread
* bug#36773: 27.0.50; Accessing a cached SVG with eww can cause Emacs to crash
2019-07-23 20:06 ` Pip Cet
@ 2019-07-23 21:13 ` Adam Plaice
2019-07-24 13:24 ` Pip Cet
0 siblings, 1 reply; 19+ messages in thread
From: Adam Plaice @ 2019-07-23 21:13 UTC (permalink / raw)
To: Pip Cet; +Cc: 36773
[-- Attachment #1: Type: text/plain, Size: 126 bytes --]
I've attached the backtrace.
(This is with the default optimisation level. If necessary, I could
rebuild with -O0.)
Thanks!
[-- Attachment #2: gdb.txt --]
[-- Type: text/plain, Size: 71650 bytes --]
Starting program: /home/adam/build/emacs/src/emacs -Q --eval \(eww\ \"https://nullprogram.com/img/diagram/collision.svg\"\)
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
[New Thread 0x7fffe5b0c700 (LWP 20012)]
[New Thread 0x7fffe4e0e700 (LWP 20013)]
[New Thread 0x7fffdffff700 (LWP 20014)]
[New Thread 0x7fffdf4bda80 (LWP 20016)]
Thread 1 "emacs" received signal SIGSEGV, Segmentation fault.
0x00007ffff41a05b0 in rsvg_handle_get_dimensions () from /usr/lib/x86_64-linux-gnu/librsvg-2.so.2
#0 0x00007ffff41a05b0 in rsvg_handle_get_dimensions () from /usr/lib/x86_64-linux-gnu/librsvg-2.so.2
No symbol table info available.
#1 0x00000000005f5d12 in svg_load_image (f=f@entry=0xf93710, img=img@entry=0x2191170, contents=<optimised out>, size=<optimised out>,
filename=<optimised out>) at image.c:9555
rsvg_handle = 0x0
dimension_data = {
width = 6453014,
height = 0,
em = 4.9406564584124654e-324,
ex = 0
}
err = 0x0
pixbuf = <optimised out>
width = <optimised out>
height = <optimised out>
pixels = <optimised out>
rowstride = <optimised out>
input_stream = 0x1939e70
base_file = <optimised out>
#2 0x00000000005f618d in svg_load (f=0xf93710, img=0x2191170) at image.c:9490
original_filename = <optimised out>
success_p = false
#3 0x00000000005f94f4 in lookup_image (f=f@entry=0xf93710, spec=spec@entry=XIL(0x1818233)) at image.c:2285
img = <optimised out>
hash = <optimised out>
#4 0x00000000005f9b6d in Fimage_metadata (spec=XIL(0x1818233), frame=<optimised out>) at image.c:1116
f = 0xf93710
id = <optimised out>
img = <optimised out>
ext = XIL(0xd67030)
#5 0x0000000000574583 in Ffuncall (nargs=2, args=args@entry=0x7fffffffab80) at eval.c:2799
fun = <optimised out>
original_fun = XIL(0x7fffe5c9f300)
numargs = 1
val = <optimised out>
count = 22
#6 0x00000000005af7b8 in exec_byte_code (bytestr=<optimised out>, vector=XIL(0x7fffe6985e5d), maxdepth=<optimised out>,
args_template=<optimised out>, nargs=nargs@entry=1, args=<optimised out>, args@entry=0x7fffe6985e60) at bytecode.c:633
op = <optimised out>
type = <optimised out>
targets = {0x5af946 <exec_byte_code+1238>, 0x5b15f4 <exec_byte_code+8580>, 0x5b15ef <exec_byte_code+8575>,
0x5b15ea <exec_byte_code+8570>, 0x5af7d7 <exec_byte_code+871>, 0x5af7d7 <exec_byte_code+871>,
0x5b15b3 <exec_byte_code+8515>, 0x5b1571 <exec_byte_code+8449>, 0x5b1991 <exec_byte_code+9505>,
0x5b198c <exec_byte_code+9500>, 0x5b1987 <exec_byte_code+9495>, 0x5b19b6 <exec_byte_code+9542>,
0x5af80b <exec_byte_code+923>, 0x5af810 <exec_byte_code+928>, 0x5b19bb <exec_byte_code+9547>,
0x5b1996 <exec_byte_code+9510>, 0x5b1853 <exec_byte_code+9187>, 0x5b184e <exec_byte_code+9182>,
0x5b1849 <exec_byte_code+9177>, 0x5b1844 <exec_byte_code+9172>, 0x5af863 <exec_byte_code+1011>,
0x5af868 <exec_byte_code+1016>, 0x5b180d <exec_byte_code+9117>, 0x5b1824 <exec_byte_code+9140>,
0x5b17a3 <exec_byte_code+9011>, 0x5b179e <exec_byte_code+9006>, 0x5b1799 <exec_byte_code+9001>,
0x5b1794 <exec_byte_code+8996>, 0x5af748 <exec_byte_code+728>, 0x5af750 <exec_byte_code+736>,
0x5b17c8 <exec_byte_code+9048>, 0x5b17a8 <exec_byte_code+9016>, 0x5b1758 <exec_byte_code+8936>,
0x5b1753 <exec_byte_code+8931>, 0x5b174e <exec_byte_code+8926>, 0x5b1749 <exec_byte_code+8921>,
0x5af791 <exec_byte_code+801>, 0x5af798 <exec_byte_code+808>, 0x5b177d <exec_byte_code+8973>,
0x5b175d <exec_byte_code+8941>, 0x5b170d <exec_byte_code+8861>, 0x5b1708 <exec_byte_code+8856>,
0x5b1703 <exec_byte_code+8851>, 0x5b16fe <exec_byte_code+8846>, 0x5af6f5 <exec_byte_code+645>,
0x5af6f8 <exec_byte_code+648>, 0x5b1732 <exec_byte_code+8898>, 0x5b1712 <exec_byte_code+8866>,
0x5b0493 <exec_byte_code+4131>, 0x5b04c2 <exec_byte_code+4178>, 0x5b0548 <exec_byte_code+4312>,
0x5af946 <exec_byte_code+1238>, 0x5af946 <exec_byte_code+1238>, 0x5af946 <exec_byte_code+1238>,
0x5af946 <exec_byte_code+1238>, 0x5af946 <exec_byte_code+1238>, 0x5b0289 <exec_byte_code+3609>,
0x5b024a <exec_byte_code+3546>, 0x5b0315 <exec_byte_code+3749>, 0x5b0071 <exec_byte_code+3073>,
0x5b0030 <exec_byte_code+3008>, 0x5b18c8 <exec_byte_code+9304>, 0x5b188d <exec_byte_code+9245>,
0x5b0003 <exec_byte_code+2963>, 0x5b190c <exec_byte_code+9372>, 0x5b1858 <exec_byte_code+9192>,
0x5affc8 <exec_byte_code+2904>, 0x5aff9d <exec_byte_code+2861>, 0x5b016a <exec_byte_code+3322>,
0x5b0132 <exec_byte_code+3266>, 0x5b00f6 <exec_byte_code+3206>, 0x5b01e0 <exec_byte_code+3440>,
0x5b01a5 <exec_byte_code+3381>, 0x5b020b <exec_byte_code+3483>, 0x5afd75 <exec_byte_code+2309>,
0x5aff2f <exec_byte_code+2751>, 0x5afef4 <exec_byte_code+2692>, 0x5afeb9 <exec_byte_code+2633>,
0x5afe7e <exec_byte_code+2574>, 0x5afe3f <exec_byte_code+2511>, 0x5afe0a <exec_byte_code+2458>,
0x5afdd5 <exec_byte_code+2405>, 0x5afda0 <exec_byte_code+2352>, 0x5afd1e <exec_byte_code+2222>,
0x5afcc7 <exec_byte_code+2135>, 0x5afc8a <exec_byte_code+2074>, 0x5afc4a <exec_byte_code+2010>,
0x5afc0a <exec_byte_code+1946>, 0x5afbca <exec_byte_code+1882>, 0x5afb8a <exec_byte_code+1818>,
0x5afb55 <exec_byte_code+1765>, 0x5afafd <exec_byte_code+1677>, 0x5afac8 <exec_byte_code+1624>,
0x5afa93 <exec_byte_code+1571>, 0x5afa5e <exec_byte_code+1518>, 0x5afa29 <exec_byte_code+1465>,
0x5b0eb1 <exec_byte_code+6721>, 0x5af918 <exec_byte_code+1192>, 0x5b0e86 <exec_byte_code+6678>,
0x5b0e56 <exec_byte_code+6630>, 0x5b0dce <exec_byte_code+6494>, 0x5b0d89 <exec_byte_code+6425>,
0x5b0d5e <exec_byte_code+6382>, 0x5b0d31 <exec_byte_code+6337>, 0x5b0d04 <exec_byte_code+6292>,
0x5b0ccf <exec_byte_code+6239>, 0x5b0ca2 <exec_byte_code+6194>, 0x5af946 <exec_byte_code+1238>,
0x5b0c75 <exec_byte_code+6149>, 0x5b0c48 <exec_byte_code+6104>, 0x5b0c1b <exec_byte_code+6059>,
0x5b0bee <exec_byte_code+6014>, 0x5b0bc1 <exec_byte_code+5969>, 0x5b0b96 <exec_byte_code+5926>,
0x5af918 <exec_byte_code+1192>, 0x5af946 <exec_byte_code+1238>, 0x5b0b57 <exec_byte_code+5863>,
0x5b0b2c <exec_byte_code+5820>, 0x5b0b01 <exec_byte_code+5777>, 0x5b0ac6 <exec_byte_code+5718>,
0x5b0a8b <exec_byte_code+5659>, 0x5b0a60 <exec_byte_code+5616>, 0x5b0a43 <exec_byte_code+5587>,
0x5b0a08 <exec_byte_code+5528>, 0x5b09cd <exec_byte_code+5469>, 0x5b0992 <exec_byte_code+5410>,
0x5b0965 <exec_byte_code+5365>, 0x5b093a <exec_byte_code+5322>, 0x5af946 <exec_byte_code+1238>,
0x5b07d7 <exec_byte_code+4967>, 0x5b0783 <exec_byte_code+4883>, 0x5b1941 <exec_byte_code+9425>,
0x5b073e <exec_byte_code+4814>, 0x5b06ff <exec_byte_code+4751>, 0x5b06c0 <exec_byte_code+4688>,
0x5b12f2 <exec_byte_code+7810>, 0x5b0818 <exec_byte_code+5032>, 0x5b17df <exec_byte_code+9071>,
0x5b08af <exec_byte_code+5183>, 0x5b1690 <exec_byte_code+8736>, 0x5b0593 <exec_byte_code+4387>,
0x5b0553 <exec_byte_code+4323>, 0x5b0445 <exec_byte_code+4053>, 0x5b0406 <exec_byte_code+3990>,
0x5b03c1 <exec_byte_code+3921>, 0x5b0357 <exec_byte_code+3815>, 0x5b07b0 <exec_byte_code+4928>,
0x5b08fb <exec_byte_code+5259>, 0x5b08d0 <exec_byte_code+5216>, 0x5b12c7 <exec_byte_code+7767>,
0x5b129c <exec_byte_code+7724>, 0x5b1271 <exec_byte_code+7681>, 0x5b1236 <exec_byte_code+7622>,
0x5b11fb <exec_byte_code+7563>, 0x5b11c0 <exec_byte_code+7504>, 0x5b1185 <exec_byte_code+7445>,
0x5b10ed <exec_byte_code+7293>, 0x5b10b2 <exec_byte_code+7234>, 0x5b1077 <exec_byte_code+7175>,
0x5b104c <exec_byte_code+7132>, 0x5b1011 <exec_byte_code+7073>, 0x5b0fd6 <exec_byte_code+7014>,
0x5b0f9e <exec_byte_code+6958>, 0x5b0f66 <exec_byte_code+6902>, 0x5b0f31 <exec_byte_code+6849>,
0x5af9f4 <exec_byte_code+1412>, 0x5b0ef6 <exec_byte_code+6790>, 0x5b163e <exec_byte_code+8654>,
0x5b15f9 <exec_byte_code+8585>, 0x5af946 <exec_byte_code+1238>, 0x5b0643 <exec_byte_code+4563>,
0x5b0602 <exec_byte_code+4498>, 0x5b05c1 <exec_byte_code+4433>, 0x5b0874 <exec_byte_code+5124>,
0x5b0839 <exec_byte_code+5065>, 0x5b00b3 <exec_byte_code+3139>, 0x5aff5a <exec_byte_code+2794>,
0x5b0e13 <exec_byte_code+6563>, 0x5b152f <exec_byte_code+8383>, 0x5b14e0 <exec_byte_code+8304>,
0x5af946 <exec_byte_code+1238>, 0x5af946 <exec_byte_code+1238>, 0x5b14a0 <exec_byte_code+8240>,
0x5b13ca <exec_byte_code+8026>, 0x5af946 <exec_byte_code+1238>, 0x5af946 <exec_byte_code+1238>,
0x5af946 <exec_byte_code+1238>, 0x5af946 <exec_byte_code+1238>, 0x5af946 <exec_byte_code+1238>,
0x5af946 <exec_byte_code+1238>, 0x5af946 <exec_byte_code+1238>, 0x5af946 <exec_byte_code+1238>,
0x5b1393 <exec_byte_code+7971> <repeats 64 times>}
const_length = <optimised out>
bytestr_length = <optimised out>
vectorp = 0x7fffe6985e60
quitcounter = <optimised out>
stack_items = <optimised out>
sa_avail = <optimised out>
sa_count = <optimised out>
alloc = <optimised out>
item_bytes = <optimised out>
stack_base = <optimised out>
top = 0x7fffffffab80
stack_lim = <optimised out>
bytestr_data = 0x7fffffffaba8 "\301\302!\205\062"
pc = 0x7fffffffabb1 "\303\001\304\"\303\002\305\"\001\205\060"
count = 22
result = <optimised out>
#7 0x000000000057423f in funcall_lambda (fun=XIL(0x7fffffffabb1), nargs=nargs@entry=1, arg_vector=0x7fffe6985e60,
arg_vector@entry=0x7fffffffad90) at eval.c:2994
val = <optimised out>
syms_left = <optimised out>
lexenv = <optimised out>
i = <optimised out>
optional = <optimised out>
rest = <optimised out>
#8 0x00000000005744d7 in Ffuncall (nargs=2, args=args@entry=0x7fffffffad88) at eval.c:2813
fun = <optimised out>
original_fun = XIL(0x7fffe5d5bc58)
numargs = 1
val = <optimised out>
count = 21
#9 0x00000000005af7b8 in exec_byte_code (bytestr=<optimised out>, vector=XIL(0xfa9a75), maxdepth=<optimised out>,
args_template=<optimised out>, nargs=nargs@entry=2, args=<optimised out>, args@entry=0xfa9a78) at bytecode.c:633
op = <optimised out>
type = <optimised out>
targets = {0x5af946 <exec_byte_code+1238>, 0x5b15f4 <exec_byte_code+8580>, 0x5b15ef <exec_byte_code+8575>,
0x5b15ea <exec_byte_code+8570>, 0x5af7d7 <exec_byte_code+871>, 0x5af7d7 <exec_byte_code+871>,
0x5b15b3 <exec_byte_code+8515>, 0x5b1571 <exec_byte_code+8449>, 0x5b1991 <exec_byte_code+9505>,
0x5b198c <exec_byte_code+9500>, 0x5b1987 <exec_byte_code+9495>, 0x5b19b6 <exec_byte_code+9542>,
0x5af80b <exec_byte_code+923>, 0x5af810 <exec_byte_code+928>, 0x5b19bb <exec_byte_code+9547>,
0x5b1996 <exec_byte_code+9510>, 0x5b1853 <exec_byte_code+9187>, 0x5b184e <exec_byte_code+9182>,
0x5b1849 <exec_byte_code+9177>, 0x5b1844 <exec_byte_code+9172>, 0x5af863 <exec_byte_code+1011>,
0x5af868 <exec_byte_code+1016>, 0x5b180d <exec_byte_code+9117>, 0x5b1824 <exec_byte_code+9140>,
0x5b17a3 <exec_byte_code+9011>, 0x5b179e <exec_byte_code+9006>, 0x5b1799 <exec_byte_code+9001>,
0x5b1794 <exec_byte_code+8996>, 0x5af748 <exec_byte_code+728>, 0x5af750 <exec_byte_code+736>,
0x5b17c8 <exec_byte_code+9048>, 0x5b17a8 <exec_byte_code+9016>, 0x5b1758 <exec_byte_code+8936>,
0x5b1753 <exec_byte_code+8931>, 0x5b174e <exec_byte_code+8926>, 0x5b1749 <exec_byte_code+8921>,
0x5af791 <exec_byte_code+801>, 0x5af798 <exec_byte_code+808>, 0x5b177d <exec_byte_code+8973>,
0x5b175d <exec_byte_code+8941>, 0x5b170d <exec_byte_code+8861>, 0x5b1708 <exec_byte_code+8856>,
0x5b1703 <exec_byte_code+8851>, 0x5b16fe <exec_byte_code+8846>, 0x5af6f5 <exec_byte_code+645>,
0x5af6f8 <exec_byte_code+648>, 0x5b1732 <exec_byte_code+8898>, 0x5b1712 <exec_byte_code+8866>,
0x5b0493 <exec_byte_code+4131>, 0x5b04c2 <exec_byte_code+4178>, 0x5b0548 <exec_byte_code+4312>,
0x5af946 <exec_byte_code+1238>, 0x5af946 <exec_byte_code+1238>, 0x5af946 <exec_byte_code+1238>,
0x5af946 <exec_byte_code+1238>, 0x5af946 <exec_byte_code+1238>, 0x5b0289 <exec_byte_code+3609>,
0x5b024a <exec_byte_code+3546>, 0x5b0315 <exec_byte_code+3749>, 0x5b0071 <exec_byte_code+3073>,
0x5b0030 <exec_byte_code+3008>, 0x5b18c8 <exec_byte_code+9304>, 0x5b188d <exec_byte_code+9245>,
0x5b0003 <exec_byte_code+2963>, 0x5b190c <exec_byte_code+9372>, 0x5b1858 <exec_byte_code+9192>,
0x5affc8 <exec_byte_code+2904>, 0x5aff9d <exec_byte_code+2861>, 0x5b016a <exec_byte_code+3322>,
0x5b0132 <exec_byte_code+3266>, 0x5b00f6 <exec_byte_code+3206>, 0x5b01e0 <exec_byte_code+3440>,
0x5b01a5 <exec_byte_code+3381>, 0x5b020b <exec_byte_code+3483>, 0x5afd75 <exec_byte_code+2309>,
0x5aff2f <exec_byte_code+2751>, 0x5afef4 <exec_byte_code+2692>, 0x5afeb9 <exec_byte_code+2633>,
0x5afe7e <exec_byte_code+2574>, 0x5afe3f <exec_byte_code+2511>, 0x5afe0a <exec_byte_code+2458>,
0x5afdd5 <exec_byte_code+2405>, 0x5afda0 <exec_byte_code+2352>, 0x5afd1e <exec_byte_code+2222>,
0x5afcc7 <exec_byte_code+2135>, 0x5afc8a <exec_byte_code+2074>, 0x5afc4a <exec_byte_code+2010>,
0x5afc0a <exec_byte_code+1946>, 0x5afbca <exec_byte_code+1882>, 0x5afb8a <exec_byte_code+1818>,
0x5afb55 <exec_byte_code+1765>, 0x5afafd <exec_byte_code+1677>, 0x5afac8 <exec_byte_code+1624>,
0x5afa93 <exec_byte_code+1571>, 0x5afa5e <exec_byte_code+1518>, 0x5afa29 <exec_byte_code+1465>,
0x5b0eb1 <exec_byte_code+6721>, 0x5af918 <exec_byte_code+1192>, 0x5b0e86 <exec_byte_code+6678>,
0x5b0e56 <exec_byte_code+6630>, 0x5b0dce <exec_byte_code+6494>, 0x5b0d89 <exec_byte_code+6425>,
0x5b0d5e <exec_byte_code+6382>, 0x5b0d31 <exec_byte_code+6337>, 0x5b0d04 <exec_byte_code+6292>,
0x5b0ccf <exec_byte_code+6239>, 0x5b0ca2 <exec_byte_code+6194>, 0x5af946 <exec_byte_code+1238>,
0x5b0c75 <exec_byte_code+6149>, 0x5b0c48 <exec_byte_code+6104>, 0x5b0c1b <exec_byte_code+6059>,
0x5b0bee <exec_byte_code+6014>, 0x5b0bc1 <exec_byte_code+5969>, 0x5b0b96 <exec_byte_code+5926>,
0x5af918 <exec_byte_code+1192>, 0x5af946 <exec_byte_code+1238>, 0x5b0b57 <exec_byte_code+5863>,
0x5b0b2c <exec_byte_code+5820>, 0x5b0b01 <exec_byte_code+5777>, 0x5b0ac6 <exec_byte_code+5718>,
0x5b0a8b <exec_byte_code+5659>, 0x5b0a60 <exec_byte_code+5616>, 0x5b0a43 <exec_byte_code+5587>,
0x5b0a08 <exec_byte_code+5528>, 0x5b09cd <exec_byte_code+5469>, 0x5b0992 <exec_byte_code+5410>,
0x5b0965 <exec_byte_code+5365>, 0x5b093a <exec_byte_code+5322>, 0x5af946 <exec_byte_code+1238>,
0x5b07d7 <exec_byte_code+4967>, 0x5b0783 <exec_byte_code+4883>, 0x5b1941 <exec_byte_code+9425>,
0x5b073e <exec_byte_code+4814>, 0x5b06ff <exec_byte_code+4751>, 0x5b06c0 <exec_byte_code+4688>,
0x5b12f2 <exec_byte_code+7810>, 0x5b0818 <exec_byte_code+5032>, 0x5b17df <exec_byte_code+9071>,
0x5b08af <exec_byte_code+5183>, 0x5b1690 <exec_byte_code+8736>, 0x5b0593 <exec_byte_code+4387>,
0x5b0553 <exec_byte_code+4323>, 0x5b0445 <exec_byte_code+4053>, 0x5b0406 <exec_byte_code+3990>,
0x5b03c1 <exec_byte_code+3921>, 0x5b0357 <exec_byte_code+3815>, 0x5b07b0 <exec_byte_code+4928>,
0x5b08fb <exec_byte_code+5259>, 0x5b08d0 <exec_byte_code+5216>, 0x5b12c7 <exec_byte_code+7767>,
0x5b129c <exec_byte_code+7724>, 0x5b1271 <exec_byte_code+7681>, 0x5b1236 <exec_byte_code+7622>,
0x5b11fb <exec_byte_code+7563>, 0x5b11c0 <exec_byte_code+7504>, 0x5b1185 <exec_byte_code+7445>,
0x5b10ed <exec_byte_code+7293>, 0x5b10b2 <exec_byte_code+7234>, 0x5b1077 <exec_byte_code+7175>,
0x5b104c <exec_byte_code+7132>, 0x5b1011 <exec_byte_code+7073>, 0x5b0fd6 <exec_byte_code+7014>,
0x5b0f9e <exec_byte_code+6958>, 0x5b0f66 <exec_byte_code+6902>, 0x5b0f31 <exec_byte_code+6849>,
0x5af9f4 <exec_byte_code+1412>, 0x5b0ef6 <exec_byte_code+6790>, 0x5b163e <exec_byte_code+8654>,
0x5b15f9 <exec_byte_code+8585>, 0x5af946 <exec_byte_code+1238>, 0x5b0643 <exec_byte_code+4563>,
0x5b0602 <exec_byte_code+4498>, 0x5b05c1 <exec_byte_code+4433>, 0x5b0874 <exec_byte_code+5124>,
0x5b0839 <exec_byte_code+5065>, 0x5b00b3 <exec_byte_code+3139>, 0x5aff5a <exec_byte_code+2794>,
0x5b0e13 <exec_byte_code+6563>, 0x5b152f <exec_byte_code+8383>, 0x5b14e0 <exec_byte_code+8304>,
0x5af946 <exec_byte_code+1238>, 0x5af946 <exec_byte_code+1238>, 0x5b14a0 <exec_byte_code+8240>,
0x5b13ca <exec_byte_code+8026>, 0x5af946 <exec_byte_code+1238>, 0x5af946 <exec_byte_code+1238>,
0x5af946 <exec_byte_code+1238>, 0x5af946 <exec_byte_code+1238>, 0x5af946 <exec_byte_code+1238>,
0x5af946 <exec_byte_code+1238>, 0x5af946 <exec_byte_code+1238>, 0x5af946 <exec_byte_code+1238>,
0x5b1393 <exec_byte_code+7971> <repeats 64 times>}
const_length = <optimised out>
bytestr_length = <optimised out>
vectorp = 0xfa9a78
quitcounter = <optimised out>
stack_items = <optimised out>
sa_avail = <optimised out>
sa_count = <optimised out>
alloc = <optimised out>
item_bytes = <optimised out>
stack_base = <optimised out>
top = 0x7fffffffad88
stack_lim = <optimised out>
bytestr_data = 0x7fffffffadc0 "\301 \203", <incomplete sequence \335>
pc = 0x7fffffffae86 "A\202", <incomplete sequence \323>
count = 21
result = <optimised out>
#10 0x000000000057423f in funcall_lambda (fun=make_fixnum(35184372083617), nargs=nargs@entry=2, arg_vector=0xfa9a78,
arg_vector@entry=0x7fffffffb030) at eval.c:2994
val = <optimised out>
syms_left = <optimised out>
lexenv = <optimised out>
i = <optimised out>
optional = <optimised out>
rest = <optimised out>
#11 0x00000000005744d7 in Ffuncall (nargs=3, args=args@entry=0x7fffffffb028) at eval.c:2813
fun = <optimised out>
original_fun = XIL(0x9a90c0)
numargs = 2
val = <optimised out>
count = 20
#12 0x00000000005af7b8 in exec_byte_code (bytestr=<optimised out>, vector=XIL(0x17870f5), maxdepth=<optimised out>,
args_template=<optimised out>, nargs=nargs@entry=1, args=<optimised out>, args@entry=0x17870f8) at bytecode.c:633
op = <optimised out>
type = <optimised out>
targets = {0x5af946 <exec_byte_code+1238>, 0x5b15f4 <exec_byte_code+8580>, 0x5b15ef <exec_byte_code+8575>,
0x5b15ea <exec_byte_code+8570>, 0x5af7d7 <exec_byte_code+871>, 0x5af7d7 <exec_byte_code+871>,
0x5b15b3 <exec_byte_code+8515>, 0x5b1571 <exec_byte_code+8449>, 0x5b1991 <exec_byte_code+9505>,
0x5b198c <exec_byte_code+9500>, 0x5b1987 <exec_byte_code+9495>, 0x5b19b6 <exec_byte_code+9542>,
0x5af80b <exec_byte_code+923>, 0x5af810 <exec_byte_code+928>, 0x5b19bb <exec_byte_code+9547>,
0x5b1996 <exec_byte_code+9510>, 0x5b1853 <exec_byte_code+9187>, 0x5b184e <exec_byte_code+9182>,
0x5b1849 <exec_byte_code+9177>, 0x5b1844 <exec_byte_code+9172>, 0x5af863 <exec_byte_code+1011>,
0x5af868 <exec_byte_code+1016>, 0x5b180d <exec_byte_code+9117>, 0x5b1824 <exec_byte_code+9140>,
0x5b17a3 <exec_byte_code+9011>, 0x5b179e <exec_byte_code+9006>, 0x5b1799 <exec_byte_code+9001>,
0x5b1794 <exec_byte_code+8996>, 0x5af748 <exec_byte_code+728>, 0x5af750 <exec_byte_code+736>,
0x5b17c8 <exec_byte_code+9048>, 0x5b17a8 <exec_byte_code+9016>, 0x5b1758 <exec_byte_code+8936>,
0x5b1753 <exec_byte_code+8931>, 0x5b174e <exec_byte_code+8926>, 0x5b1749 <exec_byte_code+8921>,
0x5af791 <exec_byte_code+801>, 0x5af798 <exec_byte_code+808>, 0x5b177d <exec_byte_code+8973>,
0x5b175d <exec_byte_code+8941>, 0x5b170d <exec_byte_code+8861>, 0x5b1708 <exec_byte_code+8856>,
0x5b1703 <exec_byte_code+8851>, 0x5b16fe <exec_byte_code+8846>, 0x5af6f5 <exec_byte_code+645>,
0x5af6f8 <exec_byte_code+648>, 0x5b1732 <exec_byte_code+8898>, 0x5b1712 <exec_byte_code+8866>,
0x5b0493 <exec_byte_code+4131>, 0x5b04c2 <exec_byte_code+4178>, 0x5b0548 <exec_byte_code+4312>,
0x5af946 <exec_byte_code+1238>, 0x5af946 <exec_byte_code+1238>, 0x5af946 <exec_byte_code+1238>,
0x5af946 <exec_byte_code+1238>, 0x5af946 <exec_byte_code+1238>, 0x5b0289 <exec_byte_code+3609>,
0x5b024a <exec_byte_code+3546>, 0x5b0315 <exec_byte_code+3749>, 0x5b0071 <exec_byte_code+3073>,
0x5b0030 <exec_byte_code+3008>, 0x5b18c8 <exec_byte_code+9304>, 0x5b188d <exec_byte_code+9245>,
0x5b0003 <exec_byte_code+2963>, 0x5b190c <exec_byte_code+9372>, 0x5b1858 <exec_byte_code+9192>,
0x5affc8 <exec_byte_code+2904>, 0x5aff9d <exec_byte_code+2861>, 0x5b016a <exec_byte_code+3322>,
0x5b0132 <exec_byte_code+3266>, 0x5b00f6 <exec_byte_code+3206>, 0x5b01e0 <exec_byte_code+3440>,
0x5b01a5 <exec_byte_code+3381>, 0x5b020b <exec_byte_code+3483>, 0x5afd75 <exec_byte_code+2309>,
0x5aff2f <exec_byte_code+2751>, 0x5afef4 <exec_byte_code+2692>, 0x5afeb9 <exec_byte_code+2633>,
0x5afe7e <exec_byte_code+2574>, 0x5afe3f <exec_byte_code+2511>, 0x5afe0a <exec_byte_code+2458>,
0x5afdd5 <exec_byte_code+2405>, 0x5afda0 <exec_byte_code+2352>, 0x5afd1e <exec_byte_code+2222>,
0x5afcc7 <exec_byte_code+2135>, 0x5afc8a <exec_byte_code+2074>, 0x5afc4a <exec_byte_code+2010>,
0x5afc0a <exec_byte_code+1946>, 0x5afbca <exec_byte_code+1882>, 0x5afb8a <exec_byte_code+1818>,
0x5afb55 <exec_byte_code+1765>, 0x5afafd <exec_byte_code+1677>, 0x5afac8 <exec_byte_code+1624>,
0x5afa93 <exec_byte_code+1571>, 0x5afa5e <exec_byte_code+1518>, 0x5afa29 <exec_byte_code+1465>,
0x5b0eb1 <exec_byte_code+6721>, 0x5af918 <exec_byte_code+1192>, 0x5b0e86 <exec_byte_code+6678>,
0x5b0e56 <exec_byte_code+6630>, 0x5b0dce <exec_byte_code+6494>, 0x5b0d89 <exec_byte_code+6425>,
0x5b0d5e <exec_byte_code+6382>, 0x5b0d31 <exec_byte_code+6337>, 0x5b0d04 <exec_byte_code+6292>,
0x5b0ccf <exec_byte_code+6239>, 0x5b0ca2 <exec_byte_code+6194>, 0x5af946 <exec_byte_code+1238>,
0x5b0c75 <exec_byte_code+6149>, 0x5b0c48 <exec_byte_code+6104>, 0x5b0c1b <exec_byte_code+6059>,
0x5b0bee <exec_byte_code+6014>, 0x5b0bc1 <exec_byte_code+5969>, 0x5b0b96 <exec_byte_code+5926>,
0x5af918 <exec_byte_code+1192>, 0x5af946 <exec_byte_code+1238>, 0x5b0b57 <exec_byte_code+5863>,
0x5b0b2c <exec_byte_code+5820>, 0x5b0b01 <exec_byte_code+5777>, 0x5b0ac6 <exec_byte_code+5718>,
0x5b0a8b <exec_byte_code+5659>, 0x5b0a60 <exec_byte_code+5616>, 0x5b0a43 <exec_byte_code+5587>,
0x5b0a08 <exec_byte_code+5528>, 0x5b09cd <exec_byte_code+5469>, 0x5b0992 <exec_byte_code+5410>,
0x5b0965 <exec_byte_code+5365>, 0x5b093a <exec_byte_code+5322>, 0x5af946 <exec_byte_code+1238>,
0x5b07d7 <exec_byte_code+4967>, 0x5b0783 <exec_byte_code+4883>, 0x5b1941 <exec_byte_code+9425>,
0x5b073e <exec_byte_code+4814>, 0x5b06ff <exec_byte_code+4751>, 0x5b06c0 <exec_byte_code+4688>,
0x5b12f2 <exec_byte_code+7810>, 0x5b0818 <exec_byte_code+5032>, 0x5b17df <exec_byte_code+9071>,
0x5b08af <exec_byte_code+5183>, 0x5b1690 <exec_byte_code+8736>, 0x5b0593 <exec_byte_code+4387>,
0x5b0553 <exec_byte_code+4323>, 0x5b0445 <exec_byte_code+4053>, 0x5b0406 <exec_byte_code+3990>,
0x5b03c1 <exec_byte_code+3921>, 0x5b0357 <exec_byte_code+3815>, 0x5b07b0 <exec_byte_code+4928>,
0x5b08fb <exec_byte_code+5259>, 0x5b08d0 <exec_byte_code+5216>, 0x5b12c7 <exec_byte_code+7767>,
0x5b129c <exec_byte_code+7724>, 0x5b1271 <exec_byte_code+7681>, 0x5b1236 <exec_byte_code+7622>,
0x5b11fb <exec_byte_code+7563>, 0x5b11c0 <exec_byte_code+7504>, 0x5b1185 <exec_byte_code+7445>,
0x5b10ed <exec_byte_code+7293>, 0x5b10b2 <exec_byte_code+7234>, 0x5b1077 <exec_byte_code+7175>,
0x5b104c <exec_byte_code+7132>, 0x5b1011 <exec_byte_code+7073>, 0x5b0fd6 <exec_byte_code+7014>,
0x5b0f9e <exec_byte_code+6958>, 0x5b0f66 <exec_byte_code+6902>, 0x5b0f31 <exec_byte_code+6849>,
0x5af9f4 <exec_byte_code+1412>, 0x5b0ef6 <exec_byte_code+6790>, 0x5b163e <exec_byte_code+8654>,
0x5b15f9 <exec_byte_code+8585>, 0x5af946 <exec_byte_code+1238>, 0x5b0643 <exec_byte_code+4563>,
0x5b0602 <exec_byte_code+4498>, 0x5b05c1 <exec_byte_code+4433>, 0x5b0874 <exec_byte_code+5124>,
0x5b0839 <exec_byte_code+5065>, 0x5b00b3 <exec_byte_code+3139>, 0x5aff5a <exec_byte_code+2794>,
0x5b0e13 <exec_byte_code+6563>, 0x5b152f <exec_byte_code+8383>, 0x5b14e0 <exec_byte_code+8304>,
0x5af946 <exec_byte_code+1238>, 0x5af946 <exec_byte_code+1238>, 0x5b14a0 <exec_byte_code+8240>,
0x5b13ca <exec_byte_code+8026>, 0x5af946 <exec_byte_code+1238>, 0x5af946 <exec_byte_code+1238>,
0x5af946 <exec_byte_code+1238>, 0x5af946 <exec_byte_code+1238>, 0x5af946 <exec_byte_code+1238>,
0x5af946 <exec_byte_code+1238>, 0x5af946 <exec_byte_code+1238>, 0x5af946 <exec_byte_code+1238>,
0x5b1393 <exec_byte_code+7971> <repeats 64 times>}
const_length = <optimised out>
bytestr_length = <optimised out>
vectorp = 0x17870f8
quitcounter = <optimised out>
stack_items = <optimised out>
sa_avail = <optimised out>
sa_count = <optimised out>
alloc = <optimised out>
item_bytes = <optimised out>
stack_base = <optimised out>
top = 0x7fffffffb028
stack_lim = <optimised out>
bytestr_data = 0x7fffffffb040 "\301 \302\002!\204\r"
pc = 0x7fffffffb05a "\210)eb)\207Ek\210\346\377\177"
count = 18
result = <optimised out>
#13 0x000000000057423f in funcall_lambda (fun=make_fixnum(35184372083734), nargs=nargs@entry=1, arg_vector=0x17870f8,
arg_vector@entry=0x7fffffffb218) at eval.c:2994
val = <optimised out>
syms_left = <optimised out>
lexenv = <optimised out>
i = <optimised out>
optional = <optimised out>
rest = <optimised out>
#14 0x00000000005744d7 in Ffuncall (nargs=2, args=args@entry=0x7fffffffb210) at eval.c:2813
fun = <optimised out>
original_fun = XIL(0xb5a030)
numargs = 1
val = <optimised out>
count = 17
#15 0x00000000005af7b8 in exec_byte_code (bytestr=<optimised out>, vector=XIL(0x1786915), maxdepth=<optimised out>,
args_template=<optimised out>, nargs=nargs@entry=4, args=<optimised out>, args@entry=0x1786918) at bytecode.c:633
op = <optimised out>
type = <optimised out>
targets = {0x5af946 <exec_byte_code+1238>, 0x5b15f4 <exec_byte_code+8580>, 0x5b15ef <exec_byte_code+8575>,
0x5b15ea <exec_byte_code+8570>, 0x5af7d7 <exec_byte_code+871>, 0x5af7d7 <exec_byte_code+871>,
0x5b15b3 <exec_byte_code+8515>, 0x5b1571 <exec_byte_code+8449>, 0x5b1991 <exec_byte_code+9505>,
0x5b198c <exec_byte_code+9500>, 0x5b1987 <exec_byte_code+9495>, 0x5b19b6 <exec_byte_code+9542>,
0x5af80b <exec_byte_code+923>, 0x5af810 <exec_byte_code+928>, 0x5b19bb <exec_byte_code+9547>,
0x5b1996 <exec_byte_code+9510>, 0x5b1853 <exec_byte_code+9187>, 0x5b184e <exec_byte_code+9182>,
0x5b1849 <exec_byte_code+9177>, 0x5b1844 <exec_byte_code+9172>, 0x5af863 <exec_byte_code+1011>,
0x5af868 <exec_byte_code+1016>, 0x5b180d <exec_byte_code+9117>, 0x5b1824 <exec_byte_code+9140>,
0x5b17a3 <exec_byte_code+9011>, 0x5b179e <exec_byte_code+9006>, 0x5b1799 <exec_byte_code+9001>,
0x5b1794 <exec_byte_code+8996>, 0x5af748 <exec_byte_code+728>, 0x5af750 <exec_byte_code+736>,
0x5b17c8 <exec_byte_code+9048>, 0x5b17a8 <exec_byte_code+9016>, 0x5b1758 <exec_byte_code+8936>,
0x5b1753 <exec_byte_code+8931>, 0x5b174e <exec_byte_code+8926>, 0x5b1749 <exec_byte_code+8921>,
0x5af791 <exec_byte_code+801>, 0x5af798 <exec_byte_code+808>, 0x5b177d <exec_byte_code+8973>,
0x5b175d <exec_byte_code+8941>, 0x5b170d <exec_byte_code+8861>, 0x5b1708 <exec_byte_code+8856>,
0x5b1703 <exec_byte_code+8851>, 0x5b16fe <exec_byte_code+8846>, 0x5af6f5 <exec_byte_code+645>,
0x5af6f8 <exec_byte_code+648>, 0x5b1732 <exec_byte_code+8898>, 0x5b1712 <exec_byte_code+8866>,
0x5b0493 <exec_byte_code+4131>, 0x5b04c2 <exec_byte_code+4178>, 0x5b0548 <exec_byte_code+4312>,
0x5af946 <exec_byte_code+1238>, 0x5af946 <exec_byte_code+1238>, 0x5af946 <exec_byte_code+1238>,
0x5af946 <exec_byte_code+1238>, 0x5af946 <exec_byte_code+1238>, 0x5b0289 <exec_byte_code+3609>,
0x5b024a <exec_byte_code+3546>, 0x5b0315 <exec_byte_code+3749>, 0x5b0071 <exec_byte_code+3073>,
0x5b0030 <exec_byte_code+3008>, 0x5b18c8 <exec_byte_code+9304>, 0x5b188d <exec_byte_code+9245>,
0x5b0003 <exec_byte_code+2963>, 0x5b190c <exec_byte_code+9372>, 0x5b1858 <exec_byte_code+9192>,
0x5affc8 <exec_byte_code+2904>, 0x5aff9d <exec_byte_code+2861>, 0x5b016a <exec_byte_code+3322>,
0x5b0132 <exec_byte_code+3266>, 0x5b00f6 <exec_byte_code+3206>, 0x5b01e0 <exec_byte_code+3440>,
0x5b01a5 <exec_byte_code+3381>, 0x5b020b <exec_byte_code+3483>, 0x5afd75 <exec_byte_code+2309>,
0x5aff2f <exec_byte_code+2751>, 0x5afef4 <exec_byte_code+2692>, 0x5afeb9 <exec_byte_code+2633>,
0x5afe7e <exec_byte_code+2574>, 0x5afe3f <exec_byte_code+2511>, 0x5afe0a <exec_byte_code+2458>,
0x5afdd5 <exec_byte_code+2405>, 0x5afda0 <exec_byte_code+2352>, 0x5afd1e <exec_byte_code+2222>,
0x5afcc7 <exec_byte_code+2135>, 0x5afc8a <exec_byte_code+2074>, 0x5afc4a <exec_byte_code+2010>,
0x5afc0a <exec_byte_code+1946>, 0x5afbca <exec_byte_code+1882>, 0x5afb8a <exec_byte_code+1818>,
0x5afb55 <exec_byte_code+1765>, 0x5afafd <exec_byte_code+1677>, 0x5afac8 <exec_byte_code+1624>,
0x5afa93 <exec_byte_code+1571>, 0x5afa5e <exec_byte_code+1518>, 0x5afa29 <exec_byte_code+1465>,
0x5b0eb1 <exec_byte_code+6721>, 0x5af918 <exec_byte_code+1192>, 0x5b0e86 <exec_byte_code+6678>,
0x5b0e56 <exec_byte_code+6630>, 0x5b0dce <exec_byte_code+6494>, 0x5b0d89 <exec_byte_code+6425>,
0x5b0d5e <exec_byte_code+6382>, 0x5b0d31 <exec_byte_code+6337>, 0x5b0d04 <exec_byte_code+6292>,
0x5b0ccf <exec_byte_code+6239>, 0x5b0ca2 <exec_byte_code+6194>, 0x5af946 <exec_byte_code+1238>,
0x5b0c75 <exec_byte_code+6149>, 0x5b0c48 <exec_byte_code+6104>, 0x5b0c1b <exec_byte_code+6059>,
0x5b0bee <exec_byte_code+6014>, 0x5b0bc1 <exec_byte_code+5969>, 0x5b0b96 <exec_byte_code+5926>,
0x5af918 <exec_byte_code+1192>, 0x5af946 <exec_byte_code+1238>, 0x5b0b57 <exec_byte_code+5863>,
0x5b0b2c <exec_byte_code+5820>, 0x5b0b01 <exec_byte_code+5777>, 0x5b0ac6 <exec_byte_code+5718>,
0x5b0a8b <exec_byte_code+5659>, 0x5b0a60 <exec_byte_code+5616>, 0x5b0a43 <exec_byte_code+5587>,
0x5b0a08 <exec_byte_code+5528>, 0x5b09cd <exec_byte_code+5469>, 0x5b0992 <exec_byte_code+5410>,
0x5b0965 <exec_byte_code+5365>, 0x5b093a <exec_byte_code+5322>, 0x5af946 <exec_byte_code+1238>,
0x5b07d7 <exec_byte_code+4967>, 0x5b0783 <exec_byte_code+4883>, 0x5b1941 <exec_byte_code+9425>,
0x5b073e <exec_byte_code+4814>, 0x5b06ff <exec_byte_code+4751>, 0x5b06c0 <exec_byte_code+4688>,
0x5b12f2 <exec_byte_code+7810>, 0x5b0818 <exec_byte_code+5032>, 0x5b17df <exec_byte_code+9071>,
0x5b08af <exec_byte_code+5183>, 0x5b1690 <exec_byte_code+8736>, 0x5b0593 <exec_byte_code+4387>,
0x5b0553 <exec_byte_code+4323>, 0x5b0445 <exec_byte_code+4053>, 0x5b0406 <exec_byte_code+3990>,
0x5b03c1 <exec_byte_code+3921>, 0x5b0357 <exec_byte_code+3815>, 0x5b07b0 <exec_byte_code+4928>,
0x5b08fb <exec_byte_code+5259>, 0x5b08d0 <exec_byte_code+5216>, 0x5b12c7 <exec_byte_code+7767>,
0x5b129c <exec_byte_code+7724>, 0x5b1271 <exec_byte_code+7681>, 0x5b1236 <exec_byte_code+7622>,
0x5b11fb <exec_byte_code+7563>, 0x5b11c0 <exec_byte_code+7504>, 0x5b1185 <exec_byte_code+7445>,
0x5b10ed <exec_byte_code+7293>, 0x5b10b2 <exec_byte_code+7234>, 0x5b1077 <exec_byte_code+7175>,
0x5b104c <exec_byte_code+7132>, 0x5b1011 <exec_byte_code+7073>, 0x5b0fd6 <exec_byte_code+7014>,
0x5b0f9e <exec_byte_code+6958>, 0x5b0f66 <exec_byte_code+6902>, 0x5b0f31 <exec_byte_code+6849>,
0x5af9f4 <exec_byte_code+1412>, 0x5b0ef6 <exec_byte_code+6790>, 0x5b163e <exec_byte_code+8654>,
0x5b15f9 <exec_byte_code+8585>, 0x5af946 <exec_byte_code+1238>, 0x5b0643 <exec_byte_code+4563>,
0x5b0602 <exec_byte_code+4498>, 0x5b05c1 <exec_byte_code+4433>, 0x5b0874 <exec_byte_code+5124>,
0x5b0839 <exec_byte_code+5065>, 0x5b00b3 <exec_byte_code+3139>, 0x5aff5a <exec_byte_code+2794>,
0x5b0e13 <exec_byte_code+6563>, 0x5b152f <exec_byte_code+8383>, 0x5b14e0 <exec_byte_code+8304>,
0x5af946 <exec_byte_code+1238>, 0x5af946 <exec_byte_code+1238>, 0x5b14a0 <exec_byte_code+8240>,
0x5b13ca <exec_byte_code+8026>, 0x5af946 <exec_byte_code+1238>, 0x5af946 <exec_byte_code+1238>,
0x5af946 <exec_byte_code+1238>, 0x5af946 <exec_byte_code+1238>, 0x5af946 <exec_byte_code+1238>,
0x5af946 <exec_byte_code+1238>, 0x5af946 <exec_byte_code+1238>, 0x5af946 <exec_byte_code+1238>,
0x5b1393 <exec_byte_code+7971> <repeats 64 times>}
const_length = <optimised out>
bytestr_length = <optimised out>
vectorp = 0x1786918
quitcounter = <optimised out>
stack_items = <optimised out>
sa_avail = <optimised out>
sa_count = <optimised out>
alloc = <optimised out>
item_bytes = <optimised out>
stack_base = <optimised out>
top = 0x7fffffffb210
stack_lim = <optimised out>
bytestr_data = 0x7fffffffb248 "\306 \307\310\311\003\"AG\312U\203\022"
pc = 0x7fffffffb33c "\210\202\a\001\356\006\006\006\006\206\005\001\003\206\005\001\357\"\210r\005q\210\332\v\360\006\n#\210\361 \210\312\026\067\n\203 \001\362\n!\210\363\364!,\207"
count = 14
result = <optimised out>
#16 0x000000000057423f in funcall_lambda (fun=XIL(0x7fffffffb33c), nargs=nargs@entry=4, arg_vector=0x1786918,
arg_vector@entry=0x7fffffffb4d8) at eval.c:2994
val = <optimised out>
syms_left = <optimised out>
lexenv = <optimised out>
i = <optimised out>
optional = <optimised out>
rest = <optimised out>
#17 0x00000000005744d7 in Ffuncall (nargs=nargs@entry=5, args=args@entry=0x7fffffffb4d0) at eval.c:2813
fun = <optimised out>
original_fun = XIL(0xb592d0)
numargs = 4
val = <optimised out>
count = 13
#18 0x0000000000576050 in Fapply (nargs=<optimised out>, args=0x7fffffffb5f0) at eval.c:2421
i = <optimised out>
funcall_nargs = 5
funcall_args = 0x7fffffffb4d0
spread_arg = XIL(0)
fun = <optimised out>
sa_avail = <optimised out>
numargs = <optimised out>
retval = <optimised out>
#19 0x0000000000574583 in Ffuncall (nargs=3, args=args@entry=0x7fffffffb5e8) at eval.c:2799
fun = <optimised out>
original_fun = XIL(0x2af0)
numargs = 2
val = <optimised out>
count = 12
#20 0x00000000005af7b8 in exec_byte_code (bytestr=<optimised out>, vector=XIL(0x16485c5), maxdepth=<optimised out>,
args_template=<optimised out>, nargs=nargs@entry=0, args=<optimised out>, args@entry=0x16485c8) at bytecode.c:633
op = <optimised out>
type = <optimised out>
targets = {0x5af946 <exec_byte_code+1238>, 0x5b15f4 <exec_byte_code+8580>, 0x5b15ef <exec_byte_code+8575>,
0x5b15ea <exec_byte_code+8570>, 0x5af7d7 <exec_byte_code+871>, 0x5af7d7 <exec_byte_code+871>,
0x5b15b3 <exec_byte_code+8515>, 0x5b1571 <exec_byte_code+8449>, 0x5b1991 <exec_byte_code+9505>,
0x5b198c <exec_byte_code+9500>, 0x5b1987 <exec_byte_code+9495>, 0x5b19b6 <exec_byte_code+9542>,
0x5af80b <exec_byte_code+923>, 0x5af810 <exec_byte_code+928>, 0x5b19bb <exec_byte_code+9547>,
0x5b1996 <exec_byte_code+9510>, 0x5b1853 <exec_byte_code+9187>, 0x5b184e <exec_byte_code+9182>,
0x5b1849 <exec_byte_code+9177>, 0x5b1844 <exec_byte_code+9172>, 0x5af863 <exec_byte_code+1011>,
0x5af868 <exec_byte_code+1016>, 0x5b180d <exec_byte_code+9117>, 0x5b1824 <exec_byte_code+9140>,
0x5b17a3 <exec_byte_code+9011>, 0x5b179e <exec_byte_code+9006>, 0x5b1799 <exec_byte_code+9001>,
0x5b1794 <exec_byte_code+8996>, 0x5af748 <exec_byte_code+728>, 0x5af750 <exec_byte_code+736>,
0x5b17c8 <exec_byte_code+9048>, 0x5b17a8 <exec_byte_code+9016>, 0x5b1758 <exec_byte_code+8936>,
0x5b1753 <exec_byte_code+8931>, 0x5b174e <exec_byte_code+8926>, 0x5b1749 <exec_byte_code+8921>,
0x5af791 <exec_byte_code+801>, 0x5af798 <exec_byte_code+808>, 0x5b177d <exec_byte_code+8973>,
0x5b175d <exec_byte_code+8941>, 0x5b170d <exec_byte_code+8861>, 0x5b1708 <exec_byte_code+8856>,
0x5b1703 <exec_byte_code+8851>, 0x5b16fe <exec_byte_code+8846>, 0x5af6f5 <exec_byte_code+645>,
0x5af6f8 <exec_byte_code+648>, 0x5b1732 <exec_byte_code+8898>, 0x5b1712 <exec_byte_code+8866>,
0x5b0493 <exec_byte_code+4131>, 0x5b04c2 <exec_byte_code+4178>, 0x5b0548 <exec_byte_code+4312>,
0x5af946 <exec_byte_code+1238>, 0x5af946 <exec_byte_code+1238>, 0x5af946 <exec_byte_code+1238>,
0x5af946 <exec_byte_code+1238>, 0x5af946 <exec_byte_code+1238>, 0x5b0289 <exec_byte_code+3609>,
0x5b024a <exec_byte_code+3546>, 0x5b0315 <exec_byte_code+3749>, 0x5b0071 <exec_byte_code+3073>,
0x5b0030 <exec_byte_code+3008>, 0x5b18c8 <exec_byte_code+9304>, 0x5b188d <exec_byte_code+9245>,
0x5b0003 <exec_byte_code+2963>, 0x5b190c <exec_byte_code+9372>, 0x5b1858 <exec_byte_code+9192>,
0x5affc8 <exec_byte_code+2904>, 0x5aff9d <exec_byte_code+2861>, 0x5b016a <exec_byte_code+3322>,
0x5b0132 <exec_byte_code+3266>, 0x5b00f6 <exec_byte_code+3206>, 0x5b01e0 <exec_byte_code+3440>,
0x5b01a5 <exec_byte_code+3381>, 0x5b020b <exec_byte_code+3483>, 0x5afd75 <exec_byte_code+2309>,
0x5aff2f <exec_byte_code+2751>, 0x5afef4 <exec_byte_code+2692>, 0x5afeb9 <exec_byte_code+2633>,
0x5afe7e <exec_byte_code+2574>, 0x5afe3f <exec_byte_code+2511>, 0x5afe0a <exec_byte_code+2458>,
0x5afdd5 <exec_byte_code+2405>, 0x5afda0 <exec_byte_code+2352>, 0x5afd1e <exec_byte_code+2222>,
0x5afcc7 <exec_byte_code+2135>, 0x5afc8a <exec_byte_code+2074>, 0x5afc4a <exec_byte_code+2010>,
0x5afc0a <exec_byte_code+1946>, 0x5afbca <exec_byte_code+1882>, 0x5afb8a <exec_byte_code+1818>,
0x5afb55 <exec_byte_code+1765>, 0x5afafd <exec_byte_code+1677>, 0x5afac8 <exec_byte_code+1624>,
0x5afa93 <exec_byte_code+1571>, 0x5afa5e <exec_byte_code+1518>, 0x5afa29 <exec_byte_code+1465>,
0x5b0eb1 <exec_byte_code+6721>, 0x5af918 <exec_byte_code+1192>, 0x5b0e86 <exec_byte_code+6678>,
0x5b0e56 <exec_byte_code+6630>, 0x5b0dce <exec_byte_code+6494>, 0x5b0d89 <exec_byte_code+6425>,
0x5b0d5e <exec_byte_code+6382>, 0x5b0d31 <exec_byte_code+6337>, 0x5b0d04 <exec_byte_code+6292>,
0x5b0ccf <exec_byte_code+6239>, 0x5b0ca2 <exec_byte_code+6194>, 0x5af946 <exec_byte_code+1238>,
0x5b0c75 <exec_byte_code+6149>, 0x5b0c48 <exec_byte_code+6104>, 0x5b0c1b <exec_byte_code+6059>,
0x5b0bee <exec_byte_code+6014>, 0x5b0bc1 <exec_byte_code+5969>, 0x5b0b96 <exec_byte_code+5926>,
0x5af918 <exec_byte_code+1192>, 0x5af946 <exec_byte_code+1238>, 0x5b0b57 <exec_byte_code+5863>,
0x5b0b2c <exec_byte_code+5820>, 0x5b0b01 <exec_byte_code+5777>, 0x5b0ac6 <exec_byte_code+5718>,
0x5b0a8b <exec_byte_code+5659>, 0x5b0a60 <exec_byte_code+5616>, 0x5b0a43 <exec_byte_code+5587>,
0x5b0a08 <exec_byte_code+5528>, 0x5b09cd <exec_byte_code+5469>, 0x5b0992 <exec_byte_code+5410>,
0x5b0965 <exec_byte_code+5365>, 0x5b093a <exec_byte_code+5322>, 0x5af946 <exec_byte_code+1238>,
0x5b07d7 <exec_byte_code+4967>, 0x5b0783 <exec_byte_code+4883>, 0x5b1941 <exec_byte_code+9425>,
0x5b073e <exec_byte_code+4814>, 0x5b06ff <exec_byte_code+4751>, 0x5b06c0 <exec_byte_code+4688>,
0x5b12f2 <exec_byte_code+7810>, 0x5b0818 <exec_byte_code+5032>, 0x5b17df <exec_byte_code+9071>,
0x5b08af <exec_byte_code+5183>, 0x5b1690 <exec_byte_code+8736>, 0x5b0593 <exec_byte_code+4387>,
0x5b0553 <exec_byte_code+4323>, 0x5b0445 <exec_byte_code+4053>, 0x5b0406 <exec_byte_code+3990>,
0x5b03c1 <exec_byte_code+3921>, 0x5b0357 <exec_byte_code+3815>, 0x5b07b0 <exec_byte_code+4928>,
0x5b08fb <exec_byte_code+5259>, 0x5b08d0 <exec_byte_code+5216>, 0x5b12c7 <exec_byte_code+7767>,
0x5b129c <exec_byte_code+7724>, 0x5b1271 <exec_byte_code+7681>, 0x5b1236 <exec_byte_code+7622>,
0x5b11fb <exec_byte_code+7563>, 0x5b11c0 <exec_byte_code+7504>, 0x5b1185 <exec_byte_code+7445>,
0x5b10ed <exec_byte_code+7293>, 0x5b10b2 <exec_byte_code+7234>, 0x5b1077 <exec_byte_code+7175>,
0x5b104c <exec_byte_code+7132>, 0x5b1011 <exec_byte_code+7073>, 0x5b0fd6 <exec_byte_code+7014>,
0x5b0f9e <exec_byte_code+6958>, 0x5b0f66 <exec_byte_code+6902>, 0x5b0f31 <exec_byte_code+6849>,
0x5af9f4 <exec_byte_code+1412>, 0x5b0ef6 <exec_byte_code+6790>, 0x5b163e <exec_byte_code+8654>,
0x5b15f9 <exec_byte_code+8585>, 0x5af946 <exec_byte_code+1238>, 0x5b0643 <exec_byte_code+4563>,
0x5b0602 <exec_byte_code+4498>, 0x5b05c1 <exec_byte_code+4433>, 0x5b0874 <exec_byte_code+5124>,
0x5b0839 <exec_byte_code+5065>, 0x5b00b3 <exec_byte_code+3139>, 0x5aff5a <exec_byte_code+2794>,
0x5b0e13 <exec_byte_code+6563>, 0x5b152f <exec_byte_code+8383>, 0x5b14e0 <exec_byte_code+8304>,
0x5af946 <exec_byte_code+1238>, 0x5af946 <exec_byte_code+1238>, 0x5b14a0 <exec_byte_code+8240>,
0x5b13ca <exec_byte_code+8026>, 0x5af946 <exec_byte_code+1238>, 0x5af946 <exec_byte_code+1238>,
0x5af946 <exec_byte_code+1238>, 0x5af946 <exec_byte_code+1238>, 0x5af946 <exec_byte_code+1238>,
0x5af946 <exec_byte_code+1238>, 0x5af946 <exec_byte_code+1238>, 0x5af946 <exec_byte_code+1238>,
0x5b1393 <exec_byte_code+7971> <repeats 64 times>}
const_length = <optimised out>
bytestr_length = <optimised out>
vectorp = 0x16485c8
quitcounter = <optimised out>
stack_items = <optimised out>
sa_avail = <optimised out>
sa_count = <optimised out>
alloc = <optimised out>
item_bytes = <optimised out>
stack_base = <optimised out>
top = 0x7fffffffb5e8
stack_lim = <optimised out>
bytestr_data = 0x7fffffffb628 "\305\306\b!\t>\204\020"
pc = 0x7fffffffb691 "\207eb\210\001\207\021\316p!\211\022\207"
count = 12
result = <optimised out>
#21 0x000000000057423f in funcall_lambda (fun=XIL(0x7fffffffb691), nargs=nargs@entry=0, arg_vector=0x16485c8,
arg_vector@entry=0x7fffffffb840) at eval.c:2994
val = <optimised out>
syms_left = <optimised out>
lexenv = <optimised out>
i = <optimised out>
optional = <optimised out>
rest = <optimised out>
#22 0x00000000005744d7 in Ffuncall (nargs=1, args=args@entry=0x7fffffffb838) at eval.c:2813
fun = <optimised out>
original_fun = XIL(0xc78400)
numargs = 0
val = <optimised out>
count = 11
#23 0x00000000005af7b8 in exec_byte_code (bytestr=<optimised out>, vector=XIL(0x1730895), maxdepth=<optimised out>,
args_template=<optimised out>, nargs=nargs@entry=3, args=<optimised out>, args@entry=0x1730898) at bytecode.c:633
op = <optimised out>
type = <optimised out>
targets = {0x5af946 <exec_byte_code+1238>, 0x5b15f4 <exec_byte_code+8580>, 0x5b15ef <exec_byte_code+8575>,
0x5b15ea <exec_byte_code+8570>, 0x5af7d7 <exec_byte_code+871>, 0x5af7d7 <exec_byte_code+871>,
0x5b15b3 <exec_byte_code+8515>, 0x5b1571 <exec_byte_code+8449>, 0x5b1991 <exec_byte_code+9505>,
0x5b198c <exec_byte_code+9500>, 0x5b1987 <exec_byte_code+9495>, 0x5b19b6 <exec_byte_code+9542>,
0x5af80b <exec_byte_code+923>, 0x5af810 <exec_byte_code+928>, 0x5b19bb <exec_byte_code+9547>,
0x5b1996 <exec_byte_code+9510>, 0x5b1853 <exec_byte_code+9187>, 0x5b184e <exec_byte_code+9182>,
0x5b1849 <exec_byte_code+9177>, 0x5b1844 <exec_byte_code+9172>, 0x5af863 <exec_byte_code+1011>,
0x5af868 <exec_byte_code+1016>, 0x5b180d <exec_byte_code+9117>, 0x5b1824 <exec_byte_code+9140>,
0x5b17a3 <exec_byte_code+9011>, 0x5b179e <exec_byte_code+9006>, 0x5b1799 <exec_byte_code+9001>,
0x5b1794 <exec_byte_code+8996>, 0x5af748 <exec_byte_code+728>, 0x5af750 <exec_byte_code+736>,
0x5b17c8 <exec_byte_code+9048>, 0x5b17a8 <exec_byte_code+9016>, 0x5b1758 <exec_byte_code+8936>,
0x5b1753 <exec_byte_code+8931>, 0x5b174e <exec_byte_code+8926>, 0x5b1749 <exec_byte_code+8921>,
0x5af791 <exec_byte_code+801>, 0x5af798 <exec_byte_code+808>, 0x5b177d <exec_byte_code+8973>,
0x5b175d <exec_byte_code+8941>, 0x5b170d <exec_byte_code+8861>, 0x5b1708 <exec_byte_code+8856>,
0x5b1703 <exec_byte_code+8851>, 0x5b16fe <exec_byte_code+8846>, 0x5af6f5 <exec_byte_code+645>,
0x5af6f8 <exec_byte_code+648>, 0x5b1732 <exec_byte_code+8898>, 0x5b1712 <exec_byte_code+8866>,
0x5b0493 <exec_byte_code+4131>, 0x5b04c2 <exec_byte_code+4178>, 0x5b0548 <exec_byte_code+4312>,
0x5af946 <exec_byte_code+1238>, 0x5af946 <exec_byte_code+1238>, 0x5af946 <exec_byte_code+1238>,
0x5af946 <exec_byte_code+1238>, 0x5af946 <exec_byte_code+1238>, 0x5b0289 <exec_byte_code+3609>,
0x5b024a <exec_byte_code+3546>, 0x5b0315 <exec_byte_code+3749>, 0x5b0071 <exec_byte_code+3073>,
0x5b0030 <exec_byte_code+3008>, 0x5b18c8 <exec_byte_code+9304>, 0x5b188d <exec_byte_code+9245>,
0x5b0003 <exec_byte_code+2963>, 0x5b190c <exec_byte_code+9372>, 0x5b1858 <exec_byte_code+9192>,
0x5affc8 <exec_byte_code+2904>, 0x5aff9d <exec_byte_code+2861>, 0x5b016a <exec_byte_code+3322>,
0x5b0132 <exec_byte_code+3266>, 0x5b00f6 <exec_byte_code+3206>, 0x5b01e0 <exec_byte_code+3440>,
0x5b01a5 <exec_byte_code+3381>, 0x5b020b <exec_byte_code+3483>, 0x5afd75 <exec_byte_code+2309>,
0x5aff2f <exec_byte_code+2751>, 0x5afef4 <exec_byte_code+2692>, 0x5afeb9 <exec_byte_code+2633>,
0x5afe7e <exec_byte_code+2574>, 0x5afe3f <exec_byte_code+2511>, 0x5afe0a <exec_byte_code+2458>,
0x5afdd5 <exec_byte_code+2405>, 0x5afda0 <exec_byte_code+2352>, 0x5afd1e <exec_byte_code+2222>,
0x5afcc7 <exec_byte_code+2135>, 0x5afc8a <exec_byte_code+2074>, 0x5afc4a <exec_byte_code+2010>,
0x5afc0a <exec_byte_code+1946>, 0x5afbca <exec_byte_code+1882>, 0x5afb8a <exec_byte_code+1818>,
0x5afb55 <exec_byte_code+1765>, 0x5afafd <exec_byte_code+1677>, 0x5afac8 <exec_byte_code+1624>,
0x5afa93 <exec_byte_code+1571>, 0x5afa5e <exec_byte_code+1518>, 0x5afa29 <exec_byte_code+1465>,
0x5b0eb1 <exec_byte_code+6721>, 0x5af918 <exec_byte_code+1192>, 0x5b0e86 <exec_byte_code+6678>,
0x5b0e56 <exec_byte_code+6630>, 0x5b0dce <exec_byte_code+6494>, 0x5b0d89 <exec_byte_code+6425>,
0x5b0d5e <exec_byte_code+6382>, 0x5b0d31 <exec_byte_code+6337>, 0x5b0d04 <exec_byte_code+6292>,
0x5b0ccf <exec_byte_code+6239>, 0x5b0ca2 <exec_byte_code+6194>, 0x5af946 <exec_byte_code+1238>,
0x5b0c75 <exec_byte_code+6149>, 0x5b0c48 <exec_byte_code+6104>, 0x5b0c1b <exec_byte_code+6059>,
0x5b0bee <exec_byte_code+6014>, 0x5b0bc1 <exec_byte_code+5969>, 0x5b0b96 <exec_byte_code+5926>,
0x5af918 <exec_byte_code+1192>, 0x5af946 <exec_byte_code+1238>, 0x5b0b57 <exec_byte_code+5863>,
0x5b0b2c <exec_byte_code+5820>, 0x5b0b01 <exec_byte_code+5777>, 0x5b0ac6 <exec_byte_code+5718>,
0x5b0a8b <exec_byte_code+5659>, 0x5b0a60 <exec_byte_code+5616>, 0x5b0a43 <exec_byte_code+5587>,
0x5b0a08 <exec_byte_code+5528>, 0x5b09cd <exec_byte_code+5469>, 0x5b0992 <exec_byte_code+5410>,
0x5b0965 <exec_byte_code+5365>, 0x5b093a <exec_byte_code+5322>, 0x5af946 <exec_byte_code+1238>,
0x5b07d7 <exec_byte_code+4967>, 0x5b0783 <exec_byte_code+4883>, 0x5b1941 <exec_byte_code+9425>,
0x5b073e <exec_byte_code+4814>, 0x5b06ff <exec_byte_code+4751>, 0x5b06c0 <exec_byte_code+4688>,
0x5b12f2 <exec_byte_code+7810>, 0x5b0818 <exec_byte_code+5032>, 0x5b17df <exec_byte_code+9071>,
0x5b08af <exec_byte_code+5183>, 0x5b1690 <exec_byte_code+8736>, 0x5b0593 <exec_byte_code+4387>,
0x5b0553 <exec_byte_code+4323>, 0x5b0445 <exec_byte_code+4053>, 0x5b0406 <exec_byte_code+3990>,
0x5b03c1 <exec_byte_code+3921>, 0x5b0357 <exec_byte_code+3815>, 0x5b07b0 <exec_byte_code+4928>,
0x5b08fb <exec_byte_code+5259>, 0x5b08d0 <exec_byte_code+5216>, 0x5b12c7 <exec_byte_code+7767>,
0x5b129c <exec_byte_code+7724>, 0x5b1271 <exec_byte_code+7681>, 0x5b1236 <exec_byte_code+7622>,
0x5b11fb <exec_byte_code+7563>, 0x5b11c0 <exec_byte_code+7504>, 0x5b1185 <exec_byte_code+7445>,
0x5b10ed <exec_byte_code+7293>, 0x5b10b2 <exec_byte_code+7234>, 0x5b1077 <exec_byte_code+7175>,
0x5b104c <exec_byte_code+7132>, 0x5b1011 <exec_byte_code+7073>, 0x5b0fd6 <exec_byte_code+7014>,
0x5b0f9e <exec_byte_code+6958>, 0x5b0f66 <exec_byte_code+6902>, 0x5b0f31 <exec_byte_code+6849>,
0x5af9f4 <exec_byte_code+1412>, 0x5b0ef6 <exec_byte_code+6790>, 0x5b163e <exec_byte_code+8654>,
0x5b15f9 <exec_byte_code+8585>, 0x5af946 <exec_byte_code+1238>, 0x5b0643 <exec_byte_code+4563>,
0x5b0602 <exec_byte_code+4498>, 0x5b05c1 <exec_byte_code+4433>, 0x5b0874 <exec_byte_code+5124>,
0x5b0839 <exec_byte_code+5065>, 0x5b00b3 <exec_byte_code+3139>, 0x5aff5a <exec_byte_code+2794>,
0x5b0e13 <exec_byte_code+6563>, 0x5b152f <exec_byte_code+8383>, 0x5b14e0 <exec_byte_code+8304>,
0x5af946 <exec_byte_code+1238>, 0x5af946 <exec_byte_code+1238>, 0x5b14a0 <exec_byte_code+8240>,
0x5b13ca <exec_byte_code+8026>, 0x5af946 <exec_byte_code+1238>, 0x5af946 <exec_byte_code+1238>,
0x5af946 <exec_byte_code+1238>, 0x5af946 <exec_byte_code+1238>, 0x5af946 <exec_byte_code+1238>,
0x5af946 <exec_byte_code+1238>, 0x5af946 <exec_byte_code+1238>, 0x5af946 <exec_byte_code+1238>,
0x5b1393 <exec_byte_code+7971> <repeats 64 times>}
const_length = <optimised out>
bytestr_length = <optimised out>
vectorp = 0x1730898
quitcounter = <optimised out>
stack_items = <optimised out>
sa_avail = <optimised out>
sa_count = <optimised out>
alloc = <optimised out>
item_bytes = <optimised out>
stack_base = <optimised out>
top = 0x7fffffffb838
stack_lim = <optimised out>
bytestr_data = 0x7fffffffb860 "\306\307 D\310\311\312\003#\266\002ˉpo\204\206\001eb\210\314\315!\203,"
pc = 0x7fffffffb94c "\210\202\206\001\001\203\003\001\350C\310\311\312\003#\266\002\351\026\065\202\206\001\tꚃ2\001\353C\310\311\312\003#\266\002\354\026\065\004\bV\203\206\001\355C\310\311\312\003#\266\002\354\356\b!\006\006\211\bZ#\210\202\206\001\v\250\203z\001\357C\310\311\312\003#\266\002\360\026\065\v\320U\203]\001\361C\310\311\312\003#\266\002\342 \203\206\001\336 \210\202\206\001\004\bV\203\206\001\362C\310\311\312\003#\266\002\360\356\b!\006\006\211\bZ#\210\202\206\001\363C\310\311\312\003#\266\002\351\026\065\364C\310\311\312\003#\266\002\211p=\205\227\001db\207\220\001"
count = 11
result = <optimised out>
#24 0x000000000057423f in funcall_lambda (fun=XIL(0x7fffffffb94c), nargs=nargs@entry=3, arg_vector=0x1730898,
arg_vector@entry=0x7fffffffbb80) at eval.c:2994
val = <optimised out>
syms_left = <optimised out>
lexenv = <optimised out>
i = <optimised out>
optional = <optimised out>
rest = <optimised out>
#25 0x00000000005744d7 in Ffuncall (nargs=4, args=args@entry=0x7fffffffbb78) at eval.c:2813
fun = <optimised out>
original_fun = XIL(0xc786a0)
numargs = 3
val = <optimised out>
count = 10
#26 0x00000000005af7b8 in exec_byte_code (bytestr=<optimised out>, vector=XIL(0x177ccb5), maxdepth=<optimised out>,
args_template=<optimised out>, nargs=nargs@entry=2, args=<optimised out>, args@entry=0x177ccb8) at bytecode.c:633
op = <optimised out>
type = <optimised out>
targets = {0x5af946 <exec_byte_code+1238>, 0x5b15f4 <exec_byte_code+8580>, 0x5b15ef <exec_byte_code+8575>,
0x5b15ea <exec_byte_code+8570>, 0x5af7d7 <exec_byte_code+871>, 0x5af7d7 <exec_byte_code+871>,
0x5b15b3 <exec_byte_code+8515>, 0x5b1571 <exec_byte_code+8449>, 0x5b1991 <exec_byte_code+9505>,
0x5b198c <exec_byte_code+9500>, 0x5b1987 <exec_byte_code+9495>, 0x5b19b6 <exec_byte_code+9542>,
0x5af80b <exec_byte_code+923>, 0x5af810 <exec_byte_code+928>, 0x5b19bb <exec_byte_code+9547>,
0x5b1996 <exec_byte_code+9510>, 0x5b1853 <exec_byte_code+9187>, 0x5b184e <exec_byte_code+9182>,
0x5b1849 <exec_byte_code+9177>, 0x5b1844 <exec_byte_code+9172>, 0x5af863 <exec_byte_code+1011>,
0x5af868 <exec_byte_code+1016>, 0x5b180d <exec_byte_code+9117>, 0x5b1824 <exec_byte_code+9140>,
0x5b17a3 <exec_byte_code+9011>, 0x5b179e <exec_byte_code+9006>, 0x5b1799 <exec_byte_code+9001>,
0x5b1794 <exec_byte_code+8996>, 0x5af748 <exec_byte_code+728>, 0x5af750 <exec_byte_code+736>,
0x5b17c8 <exec_byte_code+9048>, 0x5b17a8 <exec_byte_code+9016>, 0x5b1758 <exec_byte_code+8936>,
0x5b1753 <exec_byte_code+8931>, 0x5b174e <exec_byte_code+8926>, 0x5b1749 <exec_byte_code+8921>,
0x5af791 <exec_byte_code+801>, 0x5af798 <exec_byte_code+808>, 0x5b177d <exec_byte_code+8973>,
0x5b175d <exec_byte_code+8941>, 0x5b170d <exec_byte_code+8861>, 0x5b1708 <exec_byte_code+8856>,
0x5b1703 <exec_byte_code+8851>, 0x5b16fe <exec_byte_code+8846>, 0x5af6f5 <exec_byte_code+645>,
0x5af6f8 <exec_byte_code+648>, 0x5b1732 <exec_byte_code+8898>, 0x5b1712 <exec_byte_code+8866>,
0x5b0493 <exec_byte_code+4131>, 0x5b04c2 <exec_byte_code+4178>, 0x5b0548 <exec_byte_code+4312>,
0x5af946 <exec_byte_code+1238>, 0x5af946 <exec_byte_code+1238>, 0x5af946 <exec_byte_code+1238>,
0x5af946 <exec_byte_code+1238>, 0x5af946 <exec_byte_code+1238>, 0x5b0289 <exec_byte_code+3609>,
0x5b024a <exec_byte_code+3546>, 0x5b0315 <exec_byte_code+3749>, 0x5b0071 <exec_byte_code+3073>,
0x5b0030 <exec_byte_code+3008>, 0x5b18c8 <exec_byte_code+9304>, 0x5b188d <exec_byte_code+9245>,
0x5b0003 <exec_byte_code+2963>, 0x5b190c <exec_byte_code+9372>, 0x5b1858 <exec_byte_code+9192>,
0x5affc8 <exec_byte_code+2904>, 0x5aff9d <exec_byte_code+2861>, 0x5b016a <exec_byte_code+3322>,
0x5b0132 <exec_byte_code+3266>, 0x5b00f6 <exec_byte_code+3206>, 0x5b01e0 <exec_byte_code+3440>,
0x5b01a5 <exec_byte_code+3381>, 0x5b020b <exec_byte_code+3483>, 0x5afd75 <exec_byte_code+2309>,
0x5aff2f <exec_byte_code+2751>, 0x5afef4 <exec_byte_code+2692>, 0x5afeb9 <exec_byte_code+2633>,
0x5afe7e <exec_byte_code+2574>, 0x5afe3f <exec_byte_code+2511>, 0x5afe0a <exec_byte_code+2458>,
0x5afdd5 <exec_byte_code+2405>, 0x5afda0 <exec_byte_code+2352>, 0x5afd1e <exec_byte_code+2222>,
0x5afcc7 <exec_byte_code+2135>, 0x5afc8a <exec_byte_code+2074>, 0x5afc4a <exec_byte_code+2010>,
0x5afc0a <exec_byte_code+1946>, 0x5afbca <exec_byte_code+1882>, 0x5afb8a <exec_byte_code+1818>,
0x5afb55 <exec_byte_code+1765>, 0x5afafd <exec_byte_code+1677>, 0x5afac8 <exec_byte_code+1624>,
0x5afa93 <exec_byte_code+1571>, 0x5afa5e <exec_byte_code+1518>, 0x5afa29 <exec_byte_code+1465>,
0x5b0eb1 <exec_byte_code+6721>, 0x5af918 <exec_byte_code+1192>, 0x5b0e86 <exec_byte_code+6678>,
0x5b0e56 <exec_byte_code+6630>, 0x5b0dce <exec_byte_code+6494>, 0x5b0d89 <exec_byte_code+6425>,
0x5b0d5e <exec_byte_code+6382>, 0x5b0d31 <exec_byte_code+6337>, 0x5b0d04 <exec_byte_code+6292>,
0x5b0ccf <exec_byte_code+6239>, 0x5b0ca2 <exec_byte_code+6194>, 0x5af946 <exec_byte_code+1238>,
0x5b0c75 <exec_byte_code+6149>, 0x5b0c48 <exec_byte_code+6104>, 0x5b0c1b <exec_byte_code+6059>,
0x5b0bee <exec_byte_code+6014>, 0x5b0bc1 <exec_byte_code+5969>, 0x5b0b96 <exec_byte_code+5926>,
0x5af918 <exec_byte_code+1192>, 0x5af946 <exec_byte_code+1238>, 0x5b0b57 <exec_byte_code+5863>,
0x5b0b2c <exec_byte_code+5820>, 0x5b0b01 <exec_byte_code+5777>, 0x5b0ac6 <exec_byte_code+5718>,
0x5b0a8b <exec_byte_code+5659>, 0x5b0a60 <exec_byte_code+5616>, 0x5b0a43 <exec_byte_code+5587>,
0x5b0a08 <exec_byte_code+5528>, 0x5b09cd <exec_byte_code+5469>, 0x5b0992 <exec_byte_code+5410>,
0x5b0965 <exec_byte_code+5365>, 0x5b093a <exec_byte_code+5322>, 0x5af946 <exec_byte_code+1238>,
0x5b07d7 <exec_byte_code+4967>, 0x5b0783 <exec_byte_code+4883>, 0x5b1941 <exec_byte_code+9425>,
0x5b073e <exec_byte_code+4814>, 0x5b06ff <exec_byte_code+4751>, 0x5b06c0 <exec_byte_code+4688>,
0x5b12f2 <exec_byte_code+7810>, 0x5b0818 <exec_byte_code+5032>, 0x5b17df <exec_byte_code+9071>,
0x5b08af <exec_byte_code+5183>, 0x5b1690 <exec_byte_code+8736>, 0x5b0593 <exec_byte_code+4387>,
0x5b0553 <exec_byte_code+4323>, 0x5b0445 <exec_byte_code+4053>, 0x5b0406 <exec_byte_code+3990>,
0x5b03c1 <exec_byte_code+3921>, 0x5b0357 <exec_byte_code+3815>, 0x5b07b0 <exec_byte_code+4928>,
0x5b08fb <exec_byte_code+5259>, 0x5b08d0 <exec_byte_code+5216>, 0x5b12c7 <exec_byte_code+7767>,
0x5b129c <exec_byte_code+7724>, 0x5b1271 <exec_byte_code+7681>, 0x5b1236 <exec_byte_code+7622>,
0x5b11fb <exec_byte_code+7563>, 0x5b11c0 <exec_byte_code+7504>, 0x5b1185 <exec_byte_code+7445>,
0x5b10ed <exec_byte_code+7293>, 0x5b10b2 <exec_byte_code+7234>, 0x5b1077 <exec_byte_code+7175>,
0x5b104c <exec_byte_code+7132>, 0x5b1011 <exec_byte_code+7073>, 0x5b0fd6 <exec_byte_code+7014>,
0x5b0f9e <exec_byte_code+6958>, 0x5b0f66 <exec_byte_code+6902>, 0x5b0f31 <exec_byte_code+6849>,
0x5af9f4 <exec_byte_code+1412>, 0x5b0ef6 <exec_byte_code+6790>, 0x5b163e <exec_byte_code+8654>,
0x5b15f9 <exec_byte_code+8585>, 0x5af946 <exec_byte_code+1238>, 0x5b0643 <exec_byte_code+4563>,
0x5b0602 <exec_byte_code+4498>, 0x5b05c1 <exec_byte_code+4433>, 0x5b0874 <exec_byte_code+5124>,
0x5b0839 <exec_byte_code+5065>, 0x5b00b3 <exec_byte_code+3139>, 0x5aff5a <exec_byte_code+2794>,
0x5b0e13 <exec_byte_code+6563>, 0x5b152f <exec_byte_code+8383>, 0x5b14e0 <exec_byte_code+8304>,
0x5af946 <exec_byte_code+1238>, 0x5af946 <exec_byte_code+1238>, 0x5b14a0 <exec_byte_code+8240>,
0x5b13ca <exec_byte_code+8026>, 0x5af946 <exec_byte_code+1238>, 0x5af946 <exec_byte_code+1238>,
0x5af946 <exec_byte_code+1238>, 0x5af946 <exec_byte_code+1238>, 0x5af946 <exec_byte_code+1238>,
0x5af946 <exec_byte_code+1238>, 0x5af946 <exec_byte_code+1238>, 0x5af946 <exec_byte_code+1238>,
0x5b1393 <exec_byte_code+7971> <repeats 64 times>}
const_length = <optimised out>
bytestr_length = <optimised out>
vectorp = 0x177ccb8
quitcounter = <optimised out>
stack_items = <optimised out>
sa_avail = <optimised out>
sa_count = <optimised out>
alloc = <optimised out>
item_bytes = <optimised out>
stack_base = <optimised out>
top = 0x7fffffffbb78
stack_lim = <optimised out>
bytestr_data = 0x7fffffffbba0 "\301\002!\205,"
pc = 0x7fffffffbbcb ")\207"
count = 9
result = <optimised out>
#27 0x000000000057423f in funcall_lambda (fun=XIL(0x7fffffffbbcb), nargs=nargs@entry=2, arg_vector=0x177ccb8,
arg_vector@entry=0x7fffffffbd38) at eval.c:2994
val = <optimised out>
syms_left = <optimised out>
lexenv = <optimised out>
i = <optimised out>
optional = <optimised out>
rest = <optimised out>
#28 0x00000000005744d7 in Ffuncall (nargs=nargs@entry=3, args=args@entry=0x7fffffffbd30) at eval.c:2813
fun = <optimised out>
original_fun = XIL(0xbdbb30)
numargs = 2
val = <optimised out>
count = 8
#29 0x0000000000576050 in Fapply (nargs=nargs@entry=2, args=args@entry=0x7fffffffbde0) at eval.c:2421
i = <optimised out>
funcall_nargs = 3
funcall_args = 0x7fffffffbd30
spread_arg = XIL(0)
fun = <optimised out>
sa_avail = <optimised out>
numargs = <optimised out>
retval = <optimised out>
#30 0x000000000057623c in apply1 (fn=XIL(0xbdbb30), arg=<optimised out>) at eval.c:2637
No locals.
#31 0x0000000000572f06 in internal_condition_case_1 (bfun=bfun@entry=0x5b2910 <read_process_output_call>, arg=XIL(0x180e493),
handlers=handlers@entry=XIL(0x90), hfun=hfun@entry=0x5b2880 <read_process_output_error_handler>) at eval.c:1375
val = <optimised out>
c = 0xcd1f50
#32 0x00000000005b2bb1 in read_and_dispose_of_process_output (coding=<optimised out>, nbytes=396,
chars=0x7fffffffbe70 "HTTP/1.1 304 Not Modified\r\nDate: Tue, 23 Jul 2019 20:54:49 GMT\r\nVia: 1.1 varnish\r\nCache-Control: max-age=600\r\nETag: W/\"5d371eb2-1e5b\"\r\nExpires: Tue, 23 Jul 2019 19:07:46 GMT\r\nAge: 0\r\nConnection: keep-"..., p=0x17b22a0)
at process.c:6058
outstream = XIL(0xbdbb30)
text = XIL(0x187fcb4)
outer_running_asynch_code = false
waiting = -1
#33 read_process_output (proc=proc@entry=XIL(0x17b22a5), channel=channel@entry=13) at process.c:5969
nbytes = 396
coding = <optimised out>
carryover = <optimised out>
odeactivate = XIL(0)
chars = "HTTP/1.1 304 Not Modified\r\nDate: Tue, 23 Jul 2019 20:54:49 GMT\r\nVia: 1.1 varnish\r\nCache-Control: max-age=600\r\nETag: W/\"5d371eb2-1e5b\"\r\nExpires: Tue, 23 Jul 2019 19:07:46 GMT\r\nAge: 0\r\nConnection: keep-"...
#34 0x00000000005ba349 in wait_reading_process_output (time_limit=time_limit@entry=0, nsecs=nsecs@entry=0, read_kbd=read_kbd@entry=-1,
do_display=true, wait_for_cell=wait_for_cell@entry=XIL(0), wait_proc=wait_proc@entry=0x0, just_wait_proc=0) at process.c:5662
nread = <optimised out>
process_skipped = <optimised out>
channel = 13
nfds = <optimised out>
Available = {
fds_bits = {8192, 0 <repeats 15 times>}
}
Writeok = {
fds_bits = {0 <repeats 16 times>}
}
check_write = <optimised out>
check_delay = <optimised out>
no_avail = <optimised out>
xerrno = 11
proc = XIL(0x17b22a5)
timeout = {
tv_sec = 0,
tv_nsec = 365954771
}
end_time = <optimised out>
timer_delay = <optimised out>
got_output_end_time = {
tv_sec = 1564015289,
tv_nsec = 170520753
}
wait = FOREVER
got_some_output = -1
prev_wait_proc_nbytes_read = 0
retry_for_async = <optimised out>
now = <optimised out>
#35 0x0000000000501783 in kbd_buffer_get_event (end_time=0x0, used_mouse_menu=0x7fffffffd9bb, kbp=<synthetic pointer>)
at keyboard.c:3836
do_display = <optimised out>
obj = <optimised out>
#36 read_event_from_main_queue (used_mouse_menu=<optimised out>, local_getcjmp=<optimised out>, end_time=<optimised out>)
at keyboard.c:2138
c = XIL(0)
save_jump = {{
__jmpbuf = {0, 0, 0, 0, 0, 0, 0, 0},
__mask_was_saved = 0,
__saved_mask = {
__val = {0 <repeats 16 times>}
}
}}
kb = <optimised out>
#37 read_decoded_event_from_main_queue (used_mouse_menu=<optimised out>, prev_event=<optimised out>, local_getcjmp=<optimised out>,
end_time=<optimised out>) at keyboard.c:2201
frame = <optimised out>
terminal = <optimised out>
events = {XIL(0), XIL(0), XIL(0), XIL(0), XIL(0), XIL(0), XIL(0), XIL(0x17af6a3), XIL(0), XIL(0xcd7425), XIL(0x6a50), XIL(0),
XIL(0), XIL(0x1), make_fixnum(0), XIL(0x5cb013)}
n = <optimised out>
#38 read_char (commandflag=commandflag@entry=1, map=map@entry=XIL(0x180e7a3), prev_event=<optimised out>,
used_mouse_menu=used_mouse_menu@entry=0x7fffffffd9bb, end_time=end_time@entry=0x0) at keyboard.c:2810
c = <optimised out>
jmpcount = <optimised out>
local_getcjmp = {{
__jmpbuf = {0, 3666669966553521299, 4, 16332565, 4294967295, 13464613, -3666669965869310829, 3666669279797320851},
__mask_was_saved = 0,
__saved_mask = {
__val = {33840, 140737488345120, 13464608, 140737488344736, 13464613, 6, 5662005, 13464608, 6, 13464613, 160, 1, 33840,
0, 0, 0}
}
}}
save_jump = {{
__jmpbuf = {0, 0, 0, 0, 0, 0, 0, 0},
__mask_was_saved = 0,
__saved_mask = {
__val = {0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 10586265195537616896, 140737067187072, 12786752, 0, 0, 2}
}
}}
tem = <optimised out>
save = <optimised out>
previous_echo_area_message = XIL(0)
also_record = XIL(0)
reread = false
recorded = false
polling_stopped_here = true
orig_kboard = <optimised out>
#39 0x00000000005033a7 in read_key_sequence (keybuf=keybuf@entry=0x7fffffffdac0, prompt=prompt@entry=XIL(0),
dont_downcase_last=dont_downcase_last@entry=false, can_return_switch_frame=can_return_switch_frame@entry=true,
fix_current_buffer=fix_current_buffer@entry=true, prevent_redisplay=prevent_redisplay@entry=false) at keyboard.c:9124
interrupted_kboard = 0xe56c30
interrupted_frame = 0xf93710
key = <optimised out>
used_mouse_menu = false
echo_local_start = 0
last_real_key_start = <optimised out>
keys_local_start = <optimised out>
new_binding = <optimised out>
t = <optimised out>
echo_start = 0
keys_start = 0
current_binding = XIL(0x180e7a3)
first_unbound = 31
mock_input = 0
used_mouse_menu_history = {false <repeats 30 times>}
fkey = {
parent = XIL(0xd1bbb3),
map = XIL(0xd1bbb3),
start = 0,
end = 0
}
keytran = {
parent = XIL(0x7fffe6e30c03),
map = XIL(0x7fffe6e30c03),
start = 0,
end = 0
}
indec = {
parent = XIL(0xd1bba3),
map = XIL(0xd1bba3),
start = 0,
end = 0
}
shift_translated = false
delayed_switch_frame = XIL(0)
original_uppercase = XIL(0)
original_uppercase_position = -1
dummyflag = false
fake_prefixed_keys = XIL(0)
first_event = XIL(0)
second_event = <optimised out>
#40 0x0000000000504b50 in command_loop_1 () at keyboard.c:1348
cmd = <optimised out>
keybuf = {XIL(0x13), XIL(0x4), XIL(0x7fffe6cdcc8d), XIL(0xc8), XIL(0), XIL(0x92e9f81b5e19d000), XIL(0xffff8000000024c1),
XIL(0x7fffe60b2ab8), XIL(0), XIL(0x4000000010000000), XIL(0x400000003f000000), XIL(0x4000000018000000), XIL(0x7fffffffdbd0),
XIL(0x92e9f81b5e19d000), XIL(0x7fffe6e57bb0), XIL(0xc320c0), XIL(0), XIL(0), make_fixnum(0), XIL(0x561e8b),
XIL(0x7fffe6e57bb0), XIL(0xc320c0), XIL(0), XIL(0x78), XIL(0xcb1723), XIL(0), make_fixnum(1000), XIL(0xffffffff), XIL(0),
XIL(0x573719)}
i = <optimised out>
prev_modiff = 0
prev_buffer = 0x0
#41 0x0000000000572e6e in internal_condition_case (bfun=bfun@entry=0x504930 <command_loop_1>, handlers=handlers@entry=XIL(0x90),
hfun=hfun@entry=0x4fbc80 <cmd_error>) at eval.c:1351
val = <optimised out>
c = 0xcd1e20
#42 0x00000000004f68bc in command_loop_2 (ignore=ignore@entry=XIL(0)) at keyboard.c:1091
val = XIL(0)
#43 0x0000000000572e0c in internal_catch (tag=tag@entry=XIL(0xcea0), func=func@entry=0x4f68a0 <command_loop_2>, arg=arg@entry=XIL(0))
at eval.c:1112
val = <optimised out>
c = 0xcd1cf0
#44 0x00000000004f6879 in command_loop () at keyboard.c:1070
No locals.
#45 0x00000000004fb889 in recursive_edit_1 () at keyboard.c:714
val = <optimised out>
#46 0x00000000004fbbb4 in Frecursive_edit () at keyboard.c:786
buffer = <optimised out>
#47 0x000000000041c351 in main (argc=4, argv=0x7fffffffde78) at emacs.c:2086
stack_bottom_variable = 0x0
do_initial_setlocale = <optimised out>
no_loadup = false
junk = 0x0
dname_arg = 0x0
ch_to_dir = 0x0
original_pwd = <optimised out>
dump_mode = <optimised out>
skip_args = 0
temacs = 0x0
attempt_load_pdump = <optimised out>
rlim = {
rlim_cur = 10022912,
rlim_max = 18446744073709551615
}
sockfd = -1
module_assertions = <optimised out>
Lisp Backtrace:
[Thread 0x7fffdf4bda80 (LWP 20016) exited]
"image-metadata" (0xffffab88)
"image-multi-frame-p" (0xffffad90)
"shr-put-image" (0xffffb030)
"eww-display-image" (0xffffb218)
"eww-render" (0xffffb4d8)
"apply" (0xffffb5f0)
"url-http-activate-callback" (0xffffb840)
"url-http-wait-for-headers-change-function" (0xffffbb80)
"url-http-generic-filter" (0xffffbd38)
"image-metadata" (0xffffab88)
"image-multi-frame-p" (0xffffad90)
"shr-put-image" (0xffffb030)
"eww-display-image" (0xffffb218)
"eww-render" (0xffffb4d8)
"apply" (0xffffb5f0)
"url-http-activate-callback" (0xffffb840)
"url-http-wait-for-headers-change-function" (0xffffbb80)
"url-http-generic-filter" (0xffffbd38)
quit
^ permalink raw reply [flat|nested] 19+ messages in thread
* bug#36773: 27.0.50; Accessing a cached SVG with eww can cause Emacs to crash
2019-07-23 21:13 ` Adam Plaice
@ 2019-07-24 13:24 ` Pip Cet
2019-07-24 14:46 ` Eli Zaretskii
2019-07-25 9:38 ` Lars Ingebrigtsen
0 siblings, 2 replies; 19+ messages in thread
From: Pip Cet @ 2019-07-24 13:24 UTC (permalink / raw)
To: Adam Plaice; +Cc: 36773
[-- Attachment #1: Type: text/plain, Size: 862 bytes --]
On Tue, Jul 23, 2019 at 9:14 PM Adam Plaice <plaiceadam@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.
[-- Attachment #2: 0002-Cache-HTTP-responses-as-uncompressed-data.patch --]
[-- Type: text/x-patch, Size: 2275 bytes --]
From 4206c1f7a833a54e13dab318abd332a4fb35d067 Mon Sep 17 00:00:00 2001
From: Pip Cet <pipcet@gmail.com>
Date: Wed, 24 Jul 2019 13:23:50 +0000
Subject: [PATCH 2/2] Cache HTTP responses as uncompressed data.
* lisp/url/url-http.el (url-http-parse-headers): Decompress before
storing URL buffers in the cache.
---
lisp/url/url-http.el | 13 +++++++++----
1 file changed, 9 insertions(+), 4 deletions(-)
diff --git a/lisp/url/url-http.el b/lisp/url/url-http.el
index 527760118d..d282b166e9 100644
--- a/lisp/url/url-http.el
+++ b/lisp/url/url-http.el
@@ -589,6 +589,7 @@ url-http-parse-headers
(let* ((buffer (current-buffer))
(class (/ url-http-response-status 100))
(success nil)
+ (nodecompress nil)
;; other status symbols: jewelry and luxury cars
(status-symbol (cadr (assq url-http-response-status url-http-codes))))
(url-http-debug "Parsed HTTP headers: class=%d status=%d"
@@ -628,8 +629,10 @@ url-http-parse-headers
;; Generic success for all others. Store in the cache, and
;; mark it as successful.
(widen)
- (if (and url-automatic-caching (equal url-http-method "GET"))
- (url-store-in-cache buffer))))
+ (when (and url-automatic-caching (equal url-http-method "GET"))
+ (setq nodecompress t)
+ (url-handle-content-transfer-encoding)
+ (url-store-in-cache buffer))))
(setq success t))
(3 ; Redirection
;; 300 Multiple choices
@@ -677,7 +680,8 @@ url-http-parse-headers
(url-cache-create-filename (url-view-url t)))
(url-cache-extract (url-cache-create-filename (url-view-url t)))
(setq redirect-uri nil
- success t))
+ success t
+ nodecompress t))
('use-proxy ; 305
;; The requested resource MUST be accessed through the
;; proxy given by the Location field. The Location field
@@ -941,7 +945,8 @@ url-http-parse-headers
class url-http-response-status)))
(if (not success)
(url-mark-buffer-as-dead buffer)
- (url-handle-content-transfer-encoding))
+ (if (not nodecompress)
+ (url-handle-content-transfer-encoding)))
(url-http-debug "Finished parsing HTTP headers: %S" success)
(widen)
(goto-char (point-min))
--
2.22.0
[-- Attachment #3: 0001-Don-t-crash-when-parsing-bad-SVG-data-bug-36773.patch --]
[-- Type: text/x-patch, Size: 1503 bytes --]
From 1b6f3bd532bf1ea819d3780def2e2c9594b1204d Mon Sep 17 00:00:00 2001
From: Pip Cet <pipcet@gmail.com>
Date: Wed, 24 Jul 2019 12:34:36 +0000
Subject: [PATCH 1/2] Don't crash when parsing bad SVG data (bug#36773)
* src/image.c (svg_load_image): Be more careful about librsvg
returning NULL pointers.
---
src/image.c | 9 +++++++--
1 file changed, 7 insertions(+), 2 deletions(-)
diff --git a/src/image.c b/src/image.c
index 355c849491..b1f84e1946 100644
--- a/src/image.c
+++ b/src/image.c
@@ -9530,11 +9530,15 @@ svg_load_image (struct frame *f, struct image *img, char *contents,
if (base_file)
g_object_unref (base_file);
g_object_unref (input_stream);
- if (err) goto rsvg_error;
+ if (err || rsvg_handle == NULL)
+ goto rsvg_error;
#else
/* Make a handle to a new rsvg object. */
rsvg_handle = rsvg_handle_new ();
+ if (rsvg_handle == NULL)
+ goto rsvg_error;
+
/* Set base_uri for properly handling referenced images (via 'href').
See rsvg bug 596114 - "image refs are relative to curdir, not .svg file"
<https://gitlab.gnome.org/GNOME/librsvg/issues/33>. */
@@ -9654,7 +9658,8 @@ svg_load_image (struct frame *f, struct image *img, char *contents,
return 1;
rsvg_error:
- g_object_unref (rsvg_handle);
+ if (rsvg_handle != NULL)
+ g_object_unref (rsvg_handle);
/* FIXME: Use error->message so the user knows what is the actual
problem with the image. */
image_error ("Error parsing SVG image `%s'", img->spec);
--
2.22.0
^ permalink raw reply related [flat|nested] 19+ messages in thread
* bug#36773: 27.0.50; Accessing a cached SVG with eww can cause Emacs to crash
2019-07-24 13:24 ` Pip Cet
@ 2019-07-24 14:46 ` Eli Zaretskii
2019-07-24 18:28 ` Pip Cet
2019-07-25 9:38 ` Lars Ingebrigtsen
1 sibling, 1 reply; 19+ messages in thread
From: Eli Zaretskii @ 2019-07-24 14:46 UTC (permalink / raw)
To: Pip Cet; +Cc: plaiceadam, 36773
> From: Pip Cet <pipcet@gmail.com>
> Date: Wed, 24 Jul 2019 13:24:46 +0000
> Cc: 36773@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.
^ permalink raw reply [flat|nested] 19+ messages in thread
* bug#36773: 27.0.50; Accessing a cached SVG with eww can cause Emacs to crash
2019-07-24 14:46 ` Eli Zaretskii
@ 2019-07-24 18:28 ` Pip Cet
2019-07-24 19:11 ` Eli Zaretskii
0 siblings, 1 reply; 19+ messages in thread
From: Pip Cet @ 2019-07-24 18:28 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: plaiceadam, 36773
On Wed, Jul 24, 2019 at 2:47 PM Eli Zaretskii <eliz@gnu.org> wrote:
> > From: Pip Cet <pipcet@gmail.com>
> > Date: Wed, 24 Jul 2019 13:24:46 +0000
> > Cc: 36773@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.
^ permalink raw reply [flat|nested] 19+ messages in thread
* bug#36773: 27.0.50; Accessing a cached SVG with eww can cause Emacs to crash
2019-07-24 18:28 ` Pip Cet
@ 2019-07-24 19:11 ` Eli Zaretskii
2019-07-24 22:13 ` Adam Plaice
0 siblings, 1 reply; 19+ messages in thread
From: Eli Zaretskii @ 2019-07-24 19:11 UTC (permalink / raw)
To: Pip Cet; +Cc: plaiceadam, 36773
> From: Pip Cet <pipcet@gmail.com>
> Date: Wed, 24 Jul 2019 18:28:20 +0000
> Cc: plaiceadam@gmail.com, 36773@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.
^ permalink raw reply [flat|nested] 19+ messages in thread
* bug#36773: 27.0.50; Accessing a cached SVG with eww can cause Emacs to crash
2019-07-24 19:11 ` Eli Zaretskii
@ 2019-07-24 22:13 ` Adam Plaice
2019-07-25 12:05 ` Pip Cet
0 siblings, 1 reply; 19+ messages in thread
From: Adam Plaice @ 2019-07-24 22:13 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: Pip Cet, 36773
> 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
^ permalink raw reply [flat|nested] 19+ messages in thread
* bug#36773: 27.0.50; Accessing a cached SVG with eww can cause Emacs to crash
2019-07-24 13:24 ` Pip Cet
2019-07-24 14:46 ` Eli Zaretskii
@ 2019-07-25 9:38 ` Lars Ingebrigtsen
2019-07-25 11:51 ` Pip Cet
1 sibling, 1 reply; 19+ messages in thread
From: Lars Ingebrigtsen @ 2019-07-25 9:38 UTC (permalink / raw)
To: Pip Cet; +Cc: Adam Plaice, 36773
Pip Cet <pipcet@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
^ permalink raw reply [flat|nested] 19+ messages in thread
* bug#36773: 27.0.50; Accessing a cached SVG with eww can cause Emacs to crash
2019-07-25 9:38 ` Lars Ingebrigtsen
@ 2019-07-25 11:51 ` Pip Cet
2019-07-25 12:55 ` Eli Zaretskii
2019-07-25 17:09 ` Lars Ingebrigtsen
0 siblings, 2 replies; 19+ messages in thread
From: Pip Cet @ 2019-07-25 11:51 UTC (permalink / raw)
To: Lars Ingebrigtsen; +Cc: Adam Plaice, 36773
On Thu, Jul 25, 2019 at 9:38 AM Lars Ingebrigtsen <larsi@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?
^ permalink raw reply [flat|nested] 19+ messages in thread
* bug#36773: 27.0.50; Accessing a cached SVG with eww can cause Emacs to crash
2019-07-24 22:13 ` Adam Plaice
@ 2019-07-25 12:05 ` Pip Cet
0 siblings, 0 replies; 19+ messages in thread
From: Pip Cet @ 2019-07-25 12:05 UTC (permalink / raw)
To: Adam Plaice; +Cc: 36773
On Wed, Jul 24, 2019 at 10:13 PM Adam Plaice <plaiceadam@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.
^ permalink raw reply [flat|nested] 19+ messages in thread
* bug#36773: 27.0.50; Accessing a cached SVG with eww can cause Emacs to crash
2019-07-25 11:51 ` Pip Cet
@ 2019-07-25 12:55 ` Eli Zaretskii
2019-07-25 14:14 ` Pip Cet
2019-07-25 17:09 ` Lars Ingebrigtsen
1 sibling, 1 reply; 19+ messages in thread
From: Eli Zaretskii @ 2019-07-25 12:55 UTC (permalink / raw)
To: Pip Cet; +Cc: larsi, plaiceadam, 36773
> From: Pip Cet <pipcet@gmail.com>
> Date: Thu, 25 Jul 2019 11:51:16 +0000
> Cc: Adam Plaice <plaiceadam@gmail.com>, 36773@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.
^ permalink raw reply [flat|nested] 19+ messages in thread
* bug#36773: 27.0.50; Accessing a cached SVG with eww can cause Emacs to crash
2019-07-25 12:55 ` Eli Zaretskii
@ 2019-07-25 14:14 ` Pip Cet
2019-07-25 22:14 ` Adam Plaice
2019-07-27 10:58 ` Eli Zaretskii
0 siblings, 2 replies; 19+ messages in thread
From: Pip Cet @ 2019-07-25 14:14 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: larsi, plaiceadam, 36773
[-- Attachment #1: Type: text/plain, Size: 1030 bytes --]
On Thu, Jul 25, 2019 at 12:55 PM Eli Zaretskii <eliz@gnu.org> wrote:
> > From: Pip Cet <pipcet@gmail.com>
> > Date: Thu, 25 Jul 2019 11:51:16 +0000
> > Cc: Adam Plaice <plaiceadam@gmail.com>, 36773@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.
[-- Attachment #2: 0001-Don-t-crash-when-parsing-bad-SVG-data-bug-36773.patch --]
[-- Type: text/x-patch, Size: 1503 bytes --]
From 1b6f3bd532bf1ea819d3780def2e2c9594b1204d Mon Sep 17 00:00:00 2001
From: Pip Cet <pipcet@gmail.com>
Date: Wed, 24 Jul 2019 12:34:36 +0000
Subject: [PATCH 1/2] Don't crash when parsing bad SVG data (bug#36773)
* src/image.c (svg_load_image): Be more careful about librsvg
returning NULL pointers.
---
src/image.c | 9 +++++++--
1 file changed, 7 insertions(+), 2 deletions(-)
diff --git a/src/image.c b/src/image.c
index 355c849491..b1f84e1946 100644
--- a/src/image.c
+++ b/src/image.c
@@ -9530,11 +9530,15 @@ svg_load_image (struct frame *f, struct image *img, char *contents,
if (base_file)
g_object_unref (base_file);
g_object_unref (input_stream);
- if (err) goto rsvg_error;
+ if (err || rsvg_handle == NULL)
+ goto rsvg_error;
#else
/* Make a handle to a new rsvg object. */
rsvg_handle = rsvg_handle_new ();
+ if (rsvg_handle == NULL)
+ goto rsvg_error;
+
/* Set base_uri for properly handling referenced images (via 'href').
See rsvg bug 596114 - "image refs are relative to curdir, not .svg file"
<https://gitlab.gnome.org/GNOME/librsvg/issues/33>. */
@@ -9654,7 +9658,8 @@ svg_load_image (struct frame *f, struct image *img, char *contents,
return 1;
rsvg_error:
- g_object_unref (rsvg_handle);
+ if (rsvg_handle != NULL)
+ g_object_unref (rsvg_handle);
/* FIXME: Use error->message so the user knows what is the actual
problem with the image. */
image_error ("Error parsing SVG image `%s'", img->spec);
--
2.22.0
[-- Attachment #3: 0002-Don-t-double-decompress-cached-HTTP-responses-bug-36.patch --]
[-- Type: text/x-patch, Size: 2907 bytes --]
From 026f799e42c2ca2fa3a3dc1467c8b2ebd5983dd0 Mon Sep 17 00:00:00 2001
From: Pip Cet <pipcet@gmail.com>
Date: Thu, 25 Jul 2019 13:22:15 +0000
Subject: [PATCH 2/2] Don't double-decompress cached HTTP responses (bug#36773)
* lisp/url/url-http.el (url-handle-content-transfer-encoding): Modify
the message headers as well as the message body to reflect
decompression.
* lisp/mail/mail-utils.el (mail-fetch-field): Add DELETE argument, to
delete header lines included in the result.
---
lisp/mail/mail-utils.el | 13 ++++++++++---
lisp/url/url-http.el | 2 +-
2 files changed, 11 insertions(+), 4 deletions(-)
diff --git a/lisp/mail/mail-utils.el b/lisp/mail/mail-utils.el
index cbcbdfaeb2..fd00dd19bc 100644
--- a/lisp/mail/mail-utils.el
+++ b/lisp/mail/mail-utils.el
@@ -284,11 +284,13 @@ 'rmail-dont-reply-to
\f
;;;###autoload
-(defun mail-fetch-field (field-name &optional last all list)
+(defun mail-fetch-field (field-name &optional last all list delete)
"Return the value of the header field whose type is FIELD-NAME.
If second arg LAST is non-nil, use the last field of type FIELD-NAME.
If third arg ALL is non-nil, concatenate all such fields with commas between.
If 4th arg LIST is non-nil, return a list of all such fields.
+If 5th arg DELETE is non-nil, delete all header lines that are
+included in the result.
The buffer should be narrowed to just the header, else false
matches may be returned from the message body."
(save-excursion
@@ -311,7 +313,9 @@ mail-fetch-field
(setq value (concat value
(if (string= value "") "" ", ")
(buffer-substring-no-properties
- opoint (point)))))))
+ opoint (point)))))
+ (if delete
+ (delete-region (point-at-bol) (point)))))
(if list
value
(and (not (string= value "")) value)))
@@ -324,7 +328,10 @@ mail-fetch-field
;; Back up over newline, then trailing spaces or tabs
(forward-char -1)
(skip-chars-backward " \t" opoint)
- (buffer-substring-no-properties opoint (point)))))))))
+ (prog1
+ (buffer-substring-no-properties opoint (point))
+ (if delete
+ (delete-region (point-at-bol) (1+ (point))))))))))))
\f
;; Parse a list of tokens separated by commas.
;; It runs from point to the end of the visible part of the buffer.
diff --git a/lisp/url/url-http.el b/lisp/url/url-http.el
index 527760118d..41bad9dba0 100644
--- a/lisp/url/url-http.el
+++ b/lisp/url/url-http.el
@@ -951,7 +951,7 @@ url-http-parse-headers
(start end &optional allow-partial))
(defun url-handle-content-transfer-encoding ()
- (let ((encoding (mail-fetch-field "content-encoding")))
+ (let ((encoding (mail-fetch-field "content-encoding" nil nil nil t)))
(when (and encoding
(fboundp 'zlib-available-p)
(zlib-available-p)
--
2.22.0
^ permalink raw reply related [flat|nested] 19+ messages in thread
* bug#36773: 27.0.50; Accessing a cached SVG with eww can cause Emacs to crash
2019-07-25 11:51 ` Pip Cet
2019-07-25 12:55 ` Eli Zaretskii
@ 2019-07-25 17:09 ` Lars Ingebrigtsen
1 sibling, 0 replies; 19+ messages in thread
From: Lars Ingebrigtsen @ 2019-07-25 17:09 UTC (permalink / raw)
To: Pip Cet; +Cc: Adam Plaice, 36773
Pip Cet <pipcet@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
^ permalink raw reply [flat|nested] 19+ messages in thread
* bug#36773: 27.0.50; Accessing a cached SVG with eww can cause Emacs to crash
2019-07-23 16:40 bug#36773: 27.0.50; Accessing a cached SVG with eww can cause Emacs to crash adam plaice
2019-07-23 18:37 ` Pip Cet
@ 2019-07-25 21:37 ` Paul Eggert
1 sibling, 0 replies; 19+ messages in thread
From: Paul Eggert @ 2019-07-25 21:37 UTC (permalink / raw)
To: Pip Cet; +Cc: 36773
[-- Attachment #1: Type: text/plain, Size: 315 bytes --]
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.
[-- Attachment #2: 0001-Don-t-crash-when-parsing-bad-SVG-data.patch --]
[-- Type: text/x-patch, Size: 1491 bytes --]
From 2fbe24895bc621cb2ff1b9898c010eec288545f6 Mon Sep 17 00:00:00 2001
From: Paul Eggert <eggert@cs.ucla.edu>
Date: Thu, 25 Jul 2019 14:29:22 -0700
Subject: [PATCH] Don't crash when parsing bad SVG data
Derived from a patch by Pip Cet (Bug#36773#47).
* src/image.c (svg_load_image): Work around librsvg 2.40.13 bug.
---
src/image.c | 8 ++++++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/src/image.c b/src/image.c
index 355c849491..8cab860085 100644
--- a/src/image.c
+++ b/src/image.c
@@ -9530,10 +9530,13 @@ svg_load_image (struct frame *f, struct image *img, char *contents,
if (base_file)
g_object_unref (base_file);
g_object_unref (input_stream);
- if (err) goto rsvg_error;
+
+ /* Check rsvg_handle too, to avoid librsvg 2.40.13 bug (Bug#36773#26). */
+ if (!rsvg_handle || err) goto rsvg_error;
#else
/* Make a handle to a new rsvg object. */
rsvg_handle = rsvg_handle_new ();
+ eassume (rsvg_handle);
/* Set base_uri for properly handling referenced images (via 'href').
See rsvg bug 596114 - "image refs are relative to curdir, not .svg file"
@@ -9654,7 +9657,8 @@ svg_load_image (struct frame *f, struct image *img, char *contents,
return 1;
rsvg_error:
- g_object_unref (rsvg_handle);
+ if (rsvg_handle)
+ g_object_unref (rsvg_handle);
/* FIXME: Use error->message so the user knows what is the actual
problem with the image. */
image_error ("Error parsing SVG image `%s'", img->spec);
--
2.17.1
^ permalink raw reply related [flat|nested] 19+ messages in thread
* bug#36773: 27.0.50; Accessing a cached SVG with eww can cause Emacs to crash
2019-07-25 14:14 ` Pip Cet
@ 2019-07-25 22:14 ` Adam Plaice
2019-07-27 10:58 ` Eli Zaretskii
1 sibling, 0 replies; 19+ messages in thread
From: Adam Plaice @ 2019-07-25 22:14 UTC (permalink / raw)
To: Pip Cet; +Cc: Lars Ingebrigtsen, 36773
> Patches attached (the first should be unmodified). Appears to work here.
FWIW the new 0002 also works for me.
Thank you very much.
Adam
^ permalink raw reply [flat|nested] 19+ messages in thread
* bug#36773: 27.0.50; Accessing a cached SVG with eww can cause Emacs to crash
2019-07-25 14:14 ` Pip Cet
2019-07-25 22:14 ` Adam Plaice
@ 2019-07-27 10:58 ` Eli Zaretskii
1 sibling, 0 replies; 19+ messages in thread
From: Eli Zaretskii @ 2019-07-27 10:58 UTC (permalink / raw)
To: Pip Cet; +Cc: 36773-done, larsi, plaiceadam
> From: Pip Cet <pipcet@gmail.com>
> Date: Thu, 25 Jul 2019 14:14:43 +0000
> Cc: larsi@gnus.org, plaiceadam@gmail.com, 36773@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.
^ permalink raw reply [flat|nested] 19+ messages in thread
end of thread, other threads:[~2019-07-27 10:58 UTC | newest]
Thread overview: 19+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2019-07-23 16:40 bug#36773: 27.0.50; Accessing a cached SVG with eww can cause Emacs to crash adam plaice
2019-07-23 18:37 ` Pip Cet
2019-07-23 19:33 ` Adam Plaice
2019-07-23 20:06 ` Pip Cet
2019-07-23 21:13 ` Adam Plaice
2019-07-24 13:24 ` Pip Cet
2019-07-24 14:46 ` Eli Zaretskii
2019-07-24 18:28 ` Pip Cet
2019-07-24 19:11 ` Eli Zaretskii
2019-07-24 22:13 ` Adam Plaice
2019-07-25 12:05 ` Pip Cet
2019-07-25 9:38 ` Lars Ingebrigtsen
2019-07-25 11:51 ` Pip Cet
2019-07-25 12:55 ` Eli Zaretskii
2019-07-25 14:14 ` Pip Cet
2019-07-25 22:14 ` Adam Plaice
2019-07-27 10:58 ` Eli Zaretskii
2019-07-25 17:09 ` Lars Ingebrigtsen
2019-07-25 21:37 ` Paul Eggert
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).