bug#61960: 30.0.50; Unexec build reliably crashes during loadup

bug#61960: 30.0.50; Unexec build reliably crashes during loadup

[Eli Zaretskii]

Today's master branch, when built with unexec, reliably crashes on a
GNU/Linux system, evidently due to invalid call to 'free' during GC.
The backtrace is at the end of his report.  I still have the crashed
temacs in GDB, so feel free to ask for more information.

The crashed command was:

  ./temacs --batch -l loadup --temacs=bootstrap

When it crashed the first time (for the same reason: invalid 'free'
call), I removed all the *.elc files in the repository and ran "make"
again, so this cannot be due to outdated *.elc files with invalid
bytecodes.  Also, all of the C sources were recompiled today after
"git pull" without any problems.

On a hunch, I've reverted the BLOCK_ALIGN change, per bug#61489,
setting it back to 1024 -- and, lo and behold, the problem went away.
Does anyone have any explanation why enlarging BLOCK_ALIGN breaks the
unexec build?  Maybe BLOCKSIZE in gmalloc.c needs an update?

  /* The allocator divides the heap into blocks of fixed size; large
     requests receive one or more whole blocks, and small requests
     receive a fragment of a block.  Fragment sizes are powers of two,
     and all fragments of a block are the same size.  When all the
     fragments in a block have been freed, the block itself is freed.  */
  #define BLOCKLOG	(INT_WIDTH > 16 ? 12 : 9)
  #define BLOCKSIZE	(1 << BLOCKLOG)
  #define BLOCKIFY(SIZE)	(((SIZE) + BLOCKSIZE - 1) / BLOCKSIZE)

So for now I'm going to make that change of BLOCK_ALIGN conditional on
the build not being the unexec one.

Note that the version and configuration info below collected by
report-emacs-bug is outdated: it shows the data and the commit of the
build that is not the one which is crashing.  The correct description
of the repository status is:

  $ git describe
  emacs-28.2-164439-g396f46d904a
  $ git show
  commit 396f46d904ab7509476b0d824ec2e4d9a231a2df (HEAD -> master, origin/master, origin/HEAD)

In GNU Emacs 30.0.50 (build 28, x86_64-pc-linux-gnu, GTK+ Version
 3.22.30, cairo version 1.15.10) of 2023-02-18 built on
 [REDACTED]
Repository revision: 97f24924df62303c944176510038f398370f8fb6
Repository branch: master
System Description: Trisquel GNU/Linux Etiona (9.0.2)

Configured using:
 'configure --with-gif=no --with-tiff=no --with-jpeg=no
 --with-xpm=ifavailable --with-modules --enable-checking=yes,glyphs
 --with-pdumper=no --with-unexec=yes --with-dumping=unexec 'CFLAGS=-O0
 -g3''

Configured features:
ACL CAIRO DBUS FREETYPE GLIB GMP GNUTLS GPM GSETTINGS HARFBUZZ JSON
LCMS2 LIBOTF LIBSELINUX LIBSYSTEMD LIBXML2 M17N_FLT MODULES NOTIFY
INOTIFY PNG RSVG SECCOMP SOUND SQLITE3 THREADS TOOLKIT_SCROLL_BARS
UNEXEC WEBP X11 XDBE XIM XINPUT2 XPM GTK3 ZLIB

Important settings:
  value of $LC_ALL: en_US.UTF-8
  value of $LANG: en_US.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
  show-paren-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
  line-number-mode: t
  indent-tabs-mode: t
  transient-mark-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t

Load-path shadows:
None found.

Features:
(shadow sort mail-extr emacsbug message yank-media dired desktop
frameset dired-loaddefs rfc822 mml url url-proxy url-privacy url-expand
url-methods url-history url-cookie generate-lisp-file url-domsuf
url-util url-parse auth-source eieio eieio-core json map url-vars
mm-view mml-smime smime gnutls puny dig mailcap mml-sec password-cache
epa epg cl-extra help-mode rfc6068 epg-config mm-decode mm-bodies
mm-encode mail-parse rfc2231 mailabbrev nnheader gnus-util time-date
range gmm-utils mailheader sendmail rfc2047 rfc2045 ietf-drums mm-util
mail-prsvr mail-utils term/xterm xterm byte-opt bytecomp byte-compile
compile rx text-property-search cl-seq comint files-x derived subr-x
ansi-osc ansi-color ring easy-mmode cl-macs inline cl-loaddefs cl-lib gv
pcase rmc iso-transl tooltip cconv eldoc paren electric uniquify
ediff-hook vc-hooks lisp-float-type elisp-mode 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 lisp-mode prog-mode register
page tab-bar menu-bar rfn-eshadow isearch easymenu timer select
scroll-bar mouse jit-lock font-lock syntax font-core term/tty-colors
frame minibuffer nadvice seq simple cl-generic indonesian philippine
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 emoji-zwj charscript
charprop case-table epa-hook jka-cmpr-hook help abbrev obarray oclosure
cl-preloaded button loaddefs theme-loaddefs faces cus-face macroexp
files window text-properties overlay sha1 md5 base64 format env
code-pages mule custom widget keymap hashtable-print-readable backquote
threads dbusbind inotify lcms2 dynamic-setting system-font-setting
font-render-setting cairo move-toolbar gtk x-toolkit xinput2 x multi-tty
make-network-process emacs)

Memory information:
((conses 16 436875 48446)
 (symbols 48 28862 0)
 (strings 32 40640 2109)
 (string-bytes 1 1352486)
 (vectors 16 9315)
 (vector-slots 8 483539 41920)
 (floats 8 75 213)
 (intervals 56 263 0)
 (buffers 976 10))

Here's the backtrace:

#0  0x00007fffef9c4e87 in raise () at /lib/x86_64-linux-gnu/libc.so.6
#1  0x00007fffef9c67f1 in abort () at /lib/x86_64-linux-gnu/libc.so.6
#2  0x00007fffefa0f837 in  () at /lib/x86_64-linux-gnu/libc.so.6
#3  0x00007fffefa168ba in  () at /lib/x86_64-linux-gnu/libc.so.6
#4  0x00007fffefa1ddec in free () at /lib/x86_64-linux-gnu/libc.so.6
#5  0x00000000007f6187 in hybrid_free_1 (ptr=0x1fc8000 <bss_sbrk_buffer+15288480>) at gmalloc.c:1735
#6  0x00000000007f61d1 in hybrid_free (ptr=0x1fc8000 <bss_sbrk_buffer+15288480>) at gmalloc.c:1747
#7  0x00000000006b4012 in lisp_align_free (block=0x2040000 <bss_sbrk_buffer+15780000>) at alloc.c:1356
#8  0x00000000006beeac in sweep_conses () at alloc.c:7454
#9  0x00000000006bf731 in gc_sweep () at alloc.c:7682
#10 0x00000000006bc9fb in garbage_collect () at alloc.c:6507
#11 0x00000000006bc424 in maybe_garbage_collect () at alloc.c:6351
#12 0x00000000006e7ea7 in maybe_gc () at lisp.h:5617
#13 0x00000000006ef02c in eval_sub (form=XIL(0x1b802a3)) at eval.c:2404
#14 0x00000000006efda6 in eval_sub (form=XIL(0x11fac73)) at eval.c:2586
#15 0x00000000006e8d16 in Fprogn (body=XIL(0x11fc733)) at eval.c:436
#16 0x00000000006f2182 in funcall_lambda (fun=XIL(0x11fcb43), nargs=2, arg_vector=0x7ffffffe6160) at eval.c:3235
#17 0x00000000006f1993 in apply_lambda (fun=XIL(0x11fcb53), args=XIL(0x11fc2b3), count=...) at eval.c:3105
#18 0x00000000006efe12 in eval_sub (form=XIL(0x11fc2a3)) at eval.c:2590
#19 0x00000000006f192d in apply_lambda (fun=XIL(0x11fd963), args=XIL(0x11fc293), count=...) at eval.c:3100
#20 0x00000000006efe12 in eval_sub (form=XIL(0x11fc283)) at eval.c:2590
#21 0x00000000006ef7a3 in eval_sub (form=XIL(0x1b801a3)) at eval.c:2488
#22 0x00000000006e8fc2 in Fsetq (args=XIL(0x1b801c3)) at eval.c:483
#23 0x00000000006ef439 in eval_sub (form=XIL(0x1b801d3)) at eval.c:2451
#24 0x00000000006efda6 in eval_sub (form=XIL(0x11fc273)) at eval.c:2586
#25 0x00000000006e8a8e in Fif (args=XIL(0x11fc263)) at eval.c:391
#26 0x00000000006ef439 in eval_sub (form=XIL(0x11fc223)) at eval.c:2451
#27 0x00000000006e8d16 in Fprogn (body=XIL(0x11fc4e3)) at eval.c:436
#28 0x00000000006eb164 in Flet (args=XIL(0x11fbc73)) at eval.c:1026
#29 0x00000000006ef439 in eval_sub (form=XIL(0x11fbbe3)) at eval.c:2451
#30 0x00000000006e8d16 in Fprogn (body=XIL(0)) at eval.c:436
#31 0x00000000006e8c03 in Fcond (args=XIL(0x11fc6c3)) at eval.c:416
#32 0x00000000006ef439 in eval_sub (form=XIL(0x11face3)) at eval.c:2451
#33 0x00000000006e8d16 in Fprogn (body=XIL(0)) at eval.c:436
#34 0x00000000006f2182 in funcall_lambda (fun=XIL(0x11fcb43), nargs=2, arg_vector=0x7ffffffe6f00) at eval.c:3235
#35 0x00000000006f1993 in apply_lambda (fun=XIL(0x11fcb53), args=XIL(0x11fbe33), count=...) at eval.c:3105
#36 0x00000000006efe12 in eval_sub (form=XIL(0x11fbe03)) at eval.c:2590
#37 0x00000000006e8fc2 in Fsetq (args=XIL(0x11fbdf3)) at eval.c:483
#38 0x00000000006ef439 in eval_sub (form=XIL(0x11fbde3)) at eval.c:2451
#39 0x00000000006e8d16 in Fprogn (body=XIL(0x11fc1a3)) at eval.c:436
#40 0x00000000006e8d4a in prog_ignore (body=XIL(0x11fbe63)) at eval.c:447
#41 0x00000000006eb23a in Fwhile (args=XIL(0x11fbdd3)) at eval.c:1047
#42 0x00000000006ef439 in eval_sub (form=XIL(0x11fbc83)) at eval.c:2451
#43 0x00000000006e8d16 in Fprogn (body=XIL(0x11fc313)) at eval.c:436
#44 0x00000000006eb164 in Flet (args=XIL(0x11fbc73)) at eval.c:1026
#45 0x00000000006ef439 in eval_sub (form=XIL(0x11fbbe3)) at eval.c:2451
#46 0x00000000006e8d16 in Fprogn (body=XIL(0)) at eval.c:436
#47 0x00000000006e8c03 in Fcond (args=XIL(0x11fc6c3)) at eval.c:416
#48 0x00000000006ef439 in eval_sub (form=XIL(0x11face3)) at eval.c:2451
#49 0x00000000006e8d16 in Fprogn (body=XIL(0)) at eval.c:436
#50 0x00000000006f2182 in funcall_lambda (fun=XIL(0x11fcb43), nargs=2, arg_vector=0x7ffffffe78d0) at eval.c:3235
#51 0x00000000006f1993 in apply_lambda (fun=XIL(0x11fcb53), args=XIL(0x11fbe33), count=...) at eval.c:3105
#52 0x00000000006efe12 in eval_sub (form=XIL(0x11fbe03)) at eval.c:2590
#53 0x00000000006e8fc2 in Fsetq (args=XIL(0x11fbdf3)) at eval.c:483
#54 0x00000000006ef439 in eval_sub (form=XIL(0x11fbde3)) at eval.c:2451
#55 0x00000000006e8d16 in Fprogn (body=XIL(0x11fc1a3)) at eval.c:436
#56 0x00000000006e8d4a in prog_ignore (body=XIL(0x11fbe63)) at eval.c:447
#57 0x00000000006eb23a in Fwhile (args=XIL(0x11fbdd3)) at eval.c:1047
#58 0x00000000006ef439 in eval_sub (form=XIL(0x11fbc83)) at eval.c:2451
#59 0x00000000006e8d16 in Fprogn (body=XIL(0x11fc313)) at eval.c:436
#60 0x00000000006eb164 in Flet (args=XIL(0x11fbc73)) at eval.c:1026
#61 0x00000000006ef439 in eval_sub (form=XIL(0x11fbbe3)) at eval.c:2451
#62 0x00000000006e8d16 in Fprogn (body=XIL(0)) at eval.c:436
#63 0x00000000006e8c03 in Fcond (args=XIL(0x11fc6c3)) at eval.c:416
#64 0x00000000006ef439 in eval_sub (form=XIL(0x11face3)) at eval.c:2451
#65 0x00000000006e8d16 in Fprogn (body=XIL(0)) at eval.c:436
#66 0x00000000006f2182 in funcall_lambda (fun=XIL(0x11fcb43), nargs=2, arg_vector=0x7ffffffe82a0) at eval.c:3235
#67 0x00000000006f1993 in apply_lambda (fun=XIL(0x11fcb53), args=XIL(0x11fbe33), count=...) at eval.c:3105
#68 0x00000000006efe12 in eval_sub (form=XIL(0x11fbe03)) at eval.c:2590
#69 0x00000000006e8fc2 in Fsetq (args=XIL(0x11fbdf3)) at eval.c:483
#70 0x00000000006ef439 in eval_sub (form=XIL(0x11fbde3)) at eval.c:2451
#71 0x00000000006e8d16 in Fprogn (body=XIL(0x11fc1a3)) at eval.c:436
#72 0x00000000006e8d4a in prog_ignore (body=XIL(0x11fbe63)) at eval.c:447
#73 0x00000000006eb23a in Fwhile (args=XIL(0x11fbdd3)) at eval.c:1047
#74 0x00000000006ef439 in eval_sub (form=XIL(0x11fbc83)) at eval.c:2451
#75 0x00000000006e8d16 in Fprogn (body=XIL(0x11fc313)) at eval.c:436
#76 0x00000000006eb164 in Flet (args=XIL(0x11fbc73)) at eval.c:1026
#77 0x00000000006ef439 in eval_sub (form=XIL(0x11fbbe3)) at eval.c:2451
#78 0x00000000006e8d16 in Fprogn (body=XIL(0)) at eval.c:436
#79 0x00000000006e8c03 in Fcond (args=XIL(0x11fc6c3)) at eval.c:416
#80 0x00000000006ef439 in eval_sub (form=XIL(0x11face3)) at eval.c:2451
#81 0x00000000006e8d16 in Fprogn (body=XIL(0)) at eval.c:436
#82 0x00000000006f2182 in funcall_lambda (fun=XIL(0x11fcb43), nargs=1, arg_vector=0x7ffffffe8c70) at eval.c:3235
#83 0x00000000006f1993 in apply_lambda (fun=XIL(0x11fcb53), args=XIL(0x11f9f13), count=...) at eval.c:3105
#84 0x00000000006efe12 in eval_sub (form=XIL(0x11f9f03)) at eval.c:2590
#85 0x00000000006ef7a3 in eval_sub (form=XIL(0x11f9ef3)) at eval.c:2488
#86 0x00000000006e8d16 in Fprogn (body=XIL(0)) at eval.c:436
#87 0x00000000006f2182 in funcall_lambda (fun=XIL(0x11fa393), nargs=1, arg_vector=0x7ffffffe9158) at eval.c:3235
#88 0x00000000006f0fca in funcall_general (fun=XIL(0x11fa3a3), numargs=1, args=0x7ffffffe9158) at eval.c:2959
#89 0x00000000006f11a7 in Ffuncall (nargs=2, args=0x7ffffffe9150)
    at eval.c:2997
#90 0x00000000006effda in Fapply (nargs=2, args=0x7ffffffe9150) at eval.c:2625
#91 0x00000000006f0aaa in apply1 (fn=XIL(0x11fa3a3), arg=XIL(0x1772373))
    at eval.c:2884
#92 0x00000000006efd7c in eval_sub (form=XIL(0x1772363)) at eval.c:2584
#93 0x00000000006e8d16 in Fprogn (body=XIL(0)) at eval.c:436
#94 0x00000000006eb164 in Flet (args=XIL(0x1772b43)) at eval.c:1026
#95 0x00000000006ef439 in eval_sub (form=XIL(0x1772d33)) at eval.c:2451
#96 0x00000000006e8d16 in Fprogn (body=XIL(0)) at eval.c:436
#97 0x00000000006f2182 in funcall_lambda (fun=XIL(0x1771bd3), nargs=2, arg_vector=0x7ffffffe9648) at eval.c:3235
#98 0x00000000006f0fca in funcall_general (fun=XIL(0x1771bc3), numargs=2, args=0x7ffffffe9648) at eval.c:2959
#99 0x00000000006f11a7 in Ffuncall (nargs=3, args=0x7ffffffe9640)
    at eval.c:2997
#100 0x00000000006f03ae in Fapply (nargs=2, args=0x7ffffffe9700) at eval.c:2668
#101 0x00000000006f0aaa in apply1 (fn=XIL(0x1771bc3), arg=XIL(0x1771a63))
    at eval.c:2884
#102 0x00000000006efd7c in eval_sub (form=XIL(0x1771a93)) at eval.c:2584
#103 0x00000000006e8d16 in Fprogn (body=XIL(0)) at eval.c:436
#104 0x00000000006f2182 in funcall_lambda (fun=XIL(0x1771493), nargs=2, arg_vector=0x7ffffffe9920) at eval.c:3235
#105 0x00000000006f1993 in apply_lambda (fun=XIL(0x1771483), args=XIL(0x1741043), count=...) at eval.c:3105
#106 0x00000000006efe12 in eval_sub (form=XIL(0x1741053)) at eval.c:2590
#107 0x00000000006e8a8e in Fif (args=XIL(0x1741063)) at eval.c:391
#108 0x00000000006ef439 in eval_sub (form=XIL(0x1741093)) at eval.c:2451
#109 0x00000000006e8d16 in Fprogn (body=XIL(0)) at eval.c:436
#110 0x00000000006eb164 in Flet (args=XIL(0x1741773)) at eval.c:1026
#111 0x00000000006ef439 in eval_sub (form=XIL(0x1741ab3)) at eval.c:2451
#112 0x00000000006e8d16 in Fprogn (body=XIL(0)) at eval.c:436
#113 0x00000000006f2182 in funcall_lambda (fun=XIL(0x1b47d63), nargs=1, arg_vector=0x7ffffffe9fc8) at eval.c:3235
#114 0x00000000006f0fca in funcall_general (fun=XIL(0x1b47d73), numargs=1, args=0x7ffffffe9fc8) at eval.c:2959
#115 0x00000000006f11a7 in Ffuncall (nargs=2, args=0x7ffffffe9fc0)
    at eval.c:2997
#116 0x00000000006ef6c9 in eval_sub (form=XIL(0x1982923)) at eval.c:2472
#117 0x00000000006e8d16 in Fprogn (body=XIL(0)) at eval.c:436
#118 0x00000000006e8c03 in Fcond (args=XIL(0x197fcf3)) at eval.c:416
#119 0x00000000006ef439 in eval_sub (form=XIL(0x1978873)) at eval.c:2451
#120 0x00000000006e8d16 in Fprogn (body=XIL(0)) at eval.c:436
#121 0x00000000006eac2d in FletX (args=XIL(0x1976da3)) at eval.c:958
#122 0x00000000006ef439 in eval_sub (form=XIL(0x1976d93)) at eval.c:2451
#123 0x00000000006e8a8e in Fif (args=XIL(0x19755b3)) at eval.c:391
#124 0x00000000006ef439 in eval_sub (form=XIL(0x19755a3)) at eval.c:2451
#125 0x00000000006e8d16 in Fprogn (body=XIL(0)) at eval.c:436
#126 0x00000000006eac2d in FletX (args=XIL(0x1af0063)) at eval.c:958
#127 0x00000000006ef439 in eval_sub (form=XIL(0x1af0053)) at eval.c:2451
#128 0x00000000006efda6 in eval_sub (form=XIL(0x1746f83)) at eval.c:2586
#129 0x00000000006e8d16 in Fprogn (body=XIL(0)) at eval.c:436
#130 0x00000000006eb164 in Flet (args=XIL(0x1746f93)) at eval.c:1026
#131 0x00000000006ef439 in eval_sub (form=XIL(0x1747003)) at eval.c:2451
#132 0x00000000006e8d16 in Fprogn (body=XIL(0)) at eval.c:436
#133 0x00000000006e8add in Fif (args=XIL(0x17471b3)) at eval.c:392
#134 0x00000000006ef439 in eval_sub (form=XIL(0x1747303)) at eval.c:2451
#135 0x00000000006e8d9d in Fprog1 (args=XIL(0x17409e3)) at eval.c:457
#136 0x00000000006ef439 in eval_sub (form=XIL(0x1747313)) at eval.c:2451
#137 0x00000000006e8d16 in Fprogn (body=XIL(0)) at eval.c:436
#138 0x00000000006f2182 in funcall_lambda (fun=XIL(0x1740283), nargs=1, arg_vector=0x7ffffffeaef0) at eval.c:3235
#139 0x00000000006f1993 in apply_lambda (fun=XIL(0x1740273), args=XIL(0x17719b3), count=...) at eval.c:3105
#140 0x00000000006efe12 in eval_sub (form=XIL(0x17719c3)) at eval.c:2590
#141 0x00000000006e8a8e in Fif (args=XIL(0x17719d3)) at eval.c:391
#142 0x00000000006ef439 in eval_sub (form=XIL(0x1771a53)) at eval.c:2451
#143 0x00000000006e8d16 in Fprogn (body=XIL(0)) at eval.c:436
#144 0x00000000006ef439 in eval_sub (form=XIL(0x1b47443)) at eval.c:2451
#145 0x00000000006e8fc2 in Fsetq (args=XIL(0x1b47483)) at eval.c:483
#146 0x00000000006ef439 in eval_sub (form=XIL(0x1b47493)) at eval.c:2451
#147 0x00000000006e8d16 in Fprogn (body=XIL(0x1b476d3)) at eval.c:436
#148 0x00000000006e8d4a in prog_ignore (body=XIL(0x1b476e3)) at eval.c:447
#149 0x00000000006eb23a in Fwhile (args=XIL(0x1b476f3)) at eval.c:1047
#150 0x00000000006ef439 in eval_sub (form=XIL(0x1b47703)) at eval.c:2451
#151 0x00000000006e8d16 in Fprogn (body=XIL(0x1b47763)) at eval.c:436
#152 0x00000000006eac2d in FletX (args=XIL(0x1b47783)) at eval.c:958
#153 0x00000000006ef439 in eval_sub (form=XIL(0x1b47793)) at eval.c:2451
#154 0x00000000006efda6 in eval_sub (form=XIL(0x1771a93)) at eval.c:2586
#155 0x00000000006e8d16 in Fprogn (body=XIL(0)) at eval.c:436
#156 0x00000000006f2182 in funcall_lambda (fun=XIL(0x1771493), nargs=2, arg_vector=0x7ffffffebac0) at eval.c:3235
#157 0x00000000006f1993 in apply_lambda (fun=XIL(0x1771483), args=XIL(0x1741043), count=...) at eval.c:3105
#158 0x00000000006efe12 in eval_sub (form=XIL(0x1741053)) at eval.c:2590
#159 0x00000000006e8a8e in Fif (args=XIL(0x1741063)) at eval.c:391
#160 0x00000000006ef439 in eval_sub (form=XIL(0x1741093)) at eval.c:2451
#161 0x00000000006e8d16 in Fprogn (body=XIL(0)) at eval.c:436
#162 0x00000000006eb164 in Flet (args=XIL(0x1741773)) at eval.c:1026
#163 0x00000000006ef439 in eval_sub (form=XIL(0x1741ab3)) at eval.c:2451
#164 0x00000000006e8d16 in Fprogn (body=XIL(0)) at eval.c:436
#165 0x00000000006f2182 in funcall_lambda (fun=XIL(0x1f606d3), nargs=1, arg_vector=0x7ffffffec168) at eval.c:3235
#166 0x00000000006f0fca in funcall_general (fun=XIL(0x1f606e3), numargs=1, args=0x7ffffffec168) at eval.c:2959
#167 0x00000000006f11a7 in Ffuncall (nargs=2, args=0x7ffffffec160)
    at eval.c:2997
#168 0x00000000006ef6c9 in eval_sub (form=XIL(0x1982923)) at eval.c:2472
#169 0x00000000006e8d16 in Fprogn (body=XIL(0)) at eval.c:436
#170 0x00000000006e8c03 in Fcond (args=XIL(0x197fcf3)) at eval.c:416
#171 0x00000000006ef439 in eval_sub (form=XIL(0x1978873)) at eval.c:2451
#172 0x00000000006e8d16 in Fprogn (body=XIL(0)) at eval.c:436
#173 0x00000000006eac2d in FletX (args=XIL(0x1976da3)) at eval.c:958
#174 0x00000000006ef439 in eval_sub (form=XIL(0x1976d93)) at eval.c:2451
#175 0x00000000006e8a8e in Fif (args=XIL(0x19755b3)) at eval.c:391
#176 0x00000000006ef439 in eval_sub (form=XIL(0x19755a3)) at eval.c:2451
#177 0x00000000006e8d16 in Fprogn (body=XIL(0)) at eval.c:436
#178 0x00000000006eac2d in FletX (args=XIL(0x1af0063)) at eval.c:958
#179 0x00000000006ef439 in eval_sub (form=XIL(0x1af0053)) at eval.c:2451
#180 0x00000000006efda6 in eval_sub (form=XIL(0x1746f83)) at eval.c:2586
#181 0x00000000006e8d16 in Fprogn (body=XIL(0)) at eval.c:436
#182 0x00000000006eb164 in Flet (args=XIL(0x1746f93)) at eval.c:1026
#183 0x00000000006ef439 in eval_sub (form=XIL(0x1747003)) at eval.c:2451
#184 0x00000000006e8d16 in Fprogn (body=XIL(0)) at eval.c:436
#185 0x00000000006e8add in Fif (args=XIL(0x17471b3)) at eval.c:392
#186 0x00000000006ef439 in eval_sub (form=XIL(0x1747303)) at eval.c:2451
#187 0x00000000006e8d9d in Fprog1 (args=XIL(0x17409e3)) at eval.c:457
#188 0x00000000006ef439 in eval_sub (form=XIL(0x1747313)) at eval.c:2451
#189 0x00000000006e8d16 in Fprogn (body=XIL(0)) at eval.c:436
#190 0x00000000006f2182 in funcall_lambda (fun=XIL(0x1740283), nargs=1, arg_vector=0x7ffffffed090) at eval.c:3235
#191 0x00000000006f1993 in apply_lambda (fun=XIL(0x1740273), args=XIL(0x17719b3), count=...) at eval.c:3105
#192 0x00000000006efe12 in eval_sub (form=XIL(0x17719c3)) at eval.c:2590
#193 0x00000000006e8a8e in Fif (args=XIL(0x17719d3)) at eval.c:391
#194 0x00000000006ef439 in eval_sub (form=XIL(0x1771a53)) at eval.c:2451
#195 0x00000000006e8d16 in Fprogn (body=XIL(0)) at eval.c:436
#196 0x00000000006ef439 in eval_sub (form=XIL(0x1f6fc93)) at eval.c:2451
#197 0x00000000006e8fc2 in Fsetq (args=XIL(0x1f6fcd3)) at eval.c:483
#198 0x00000000006ef439 in eval_sub (form=XIL(0x1f6fce3)) at eval.c:2451
#199 0x00000000006e8d16 in Fprogn (body=XIL(0x1f60043)) at eval.c:436
#200 0x00000000006e8d4a in prog_ignore (body=XIL(0x1f60053)) at eval.c:447
#201 0x00000000006eb23a in Fwhile (args=XIL(0x1f60063)) at eval.c:1047
#202 0x00000000006ef439 in eval_sub (form=XIL(0x1f60073)) at eval.c:2451
#203 0x00000000006e8d16 in Fprogn (body=XIL(0x1f600d3)) at eval.c:436
#204 0x00000000006eac2d in FletX (args=XIL(0x1f600f3)) at eval.c:958
#205 0x00000000006ef439 in eval_sub (form=XIL(0x1f60103)) at eval.c:2451
#206 0x00000000006efda6 in eval_sub (form=XIL(0x1771a93)) at eval.c:2586
#207 0x00000000006e8d16 in Fprogn (body=XIL(0)) at eval.c:436
#208 0x00000000006f2182 in funcall_lambda (fun=XIL(0x1771493), nargs=2, arg_vector=0x7ffffffedc60) at eval.c:3235
#209 0x00000000006f1993 in apply_lambda (fun=XIL(0x1771483), args=XIL(0x17712c3), count=...) at eval.c:3105
#210 0x00000000006efe12 in eval_sub (form=XIL(0x17712d3)) at eval.c:2590
#211 0x00000000006e8a8e in Fif (args=XIL(0x17712e3)) at eval.c:391
#212 0x00000000006ef439 in eval_sub (form=XIL(0x1771313)) at eval.c:2451
#213 0x00000000006e8d16 in Fprogn (body=XIL(0)) at eval.c:436
#214 0x00000000006ef439 in eval_sub (form=XIL(0x1f0f493)) at eval.c:2451
#215 0x00000000006e8fc2 in Fsetq (args=XIL(0x1f0f453)) at eval.c:483
#216 0x00000000006ef439 in eval_sub (form=XIL(0x1f0f443)) at eval.c:2451
#217 0x00000000006e8d16 in Fprogn (body=XIL(0x1f0f203)) at eval.c:436
#218 0x00000000006e8d4a in prog_ignore (body=XIL(0x1f0f1f3)) at eval.c:447
#219 0x00000000006eb23a in Fwhile (args=XIL(0x1f0f1e3)) at eval.c:1047
#220 0x00000000006ef439 in eval_sub (form=XIL(0x1f0f1d3)) at eval.c:2451
#221 0x00000000006e8d16 in Fprogn (body=XIL(0x1f0f173)) at eval.c:436
#222 0x00000000006eac2d in FletX (args=XIL(0x1f0f153)) at eval.c:958
#223 0x00000000006ef439 in eval_sub (form=XIL(0x1f0f143)) at eval.c:2451
#224 0x00000000006efda6 in eval_sub (form=XIL(0x1771353)) at eval.c:2586
#225 0x00000000006e8d16 in Fprogn (body=XIL(0)) at eval.c:436
#226 0x00000000006f2182 in funcall_lambda (fun=XIL(0x1770be3), nargs=2, arg_vector=0x7ffffffee830) at eval.c:3235
#227 0x00000000006f1993 in apply_lambda (fun=XIL(0x1770aa3), args=XIL(0x1744ba3), count=...) at eval.c:3105
#228 0x00000000006efe12 in eval_sub (form=XIL(0x1744bb3)) at eval.c:2590
#229 0x00000000006f192d in apply_lambda (fun=XIL(0x1772e23), args=XIL(0x1744b53), count=...) at eval.c:3100
#230 0x00000000006efe12 in eval_sub (form=XIL(0x1744bc3)) at eval.c:2590
#231 0x00000000006f192d in apply_lambda (fun=XIL(0x1772e23), args=XIL(0x1744c13), count=...) at eval.c:3100
#232 0x00000000006efe12 in eval_sub (form=XIL(0x1744c23)) at eval.c:2590
#233 0x00000000006e8d16 in Fprogn (body=XIL(0)) at eval.c:436
#234 0x00000000006eb164 in Flet (args=XIL(0x1744c53)) at eval.c:1026
#235 0x00000000006ef439 in eval_sub (form=XIL(0x1744ee3)) at eval.c:2451
#236 0x00000000006e8d16 in Fprogn (body=XIL(0)) at eval.c:436
#237 0x00000000006eb164 in Flet (args=XIL(0x1a95203)) at eval.c:1026
#238 0x00000000006ef439 in eval_sub (form=XIL(0x1ddc423)) at eval.c:2451
#239 0x00000000006e8d16 in Fprogn (body=XIL(0)) at eval.c:436
#240 0x00000000006eac2d in FletX (args=XIL(0x1ddfbe3)) at eval.c:958
#241 0x00000000006ef439 in eval_sub (form=XIL(0x1ddfbf3)) at eval.c:2451
#242 0x00000000006e8d16 in Fprogn (body=XIL(0)) at eval.c:436
#243 0x00000000006ef439 in eval_sub (form=XIL(0x1dd1493)) at eval.c:2451
#244 0x00000000006e8d16 in Fprogn (body=XIL(0)) at eval.c:436
#245 0x00000000006eac2d in FletX (args=XIL(0x1dd2dd3)) at eval.c:958
#246 0x00000000006ef439 in eval_sub (form=XIL(0x1dd2de3)) at eval.c:2451
#247 0x00000000006e8d16 in Fprogn (body=XIL(0)) at eval.c:436
#248 0x00000000006e8c03 in Fcond (args=XIL(0x197cf23)) at eval.c:416
#249 0x00000000006ef439 in eval_sub (form=XIL(0x1978873)) at eval.c:2451
#250 0x00000000006e8d16 in Fprogn (body=XIL(0)) at eval.c:436
#251 0x00000000006eac2d in FletX (args=XIL(0x1976da3)) at eval.c:958
#252 0x00000000006ef439 in eval_sub (form=XIL(0x1976d93)) at eval.c:2451
#253 0x00000000006e8a8e in Fif (args=XIL(0x19755b3)) at eval.c:391
#254 0x00000000006ef439 in eval_sub (form=XIL(0x19755a3)) at eval.c:2451
#255 0x00000000006e8d16 in Fprogn (body=XIL(0)) at eval.c:436
#256 0x00000000006eac2d in FletX (args=XIL(0x1af0063)) at eval.c:958
#257 0x00000000006ef439 in eval_sub (form=XIL(0x1af0053)) at eval.c:2451
#258 0x00000000006efda6 in eval_sub (form=XIL(0x1746f83)) at eval.c:2586
#259 0x00000000006e8d16 in Fprogn (body=XIL(0)) at eval.c:436
#260 0x00000000006eb164 in Flet (args=XIL(0x1746f93)) at eval.c:1026
#261 0x00000000006ef439 in eval_sub (form=XIL(0x1747003)) at eval.c:2451
#262 0x00000000006e8d16 in Fprogn (body=XIL(0)) at eval.c:436
#263 0x00000000006e8add in Fif (args=XIL(0x17471b3)) at eval.c:392
#264 0x00000000006ef439 in eval_sub (form=XIL(0x1747303)) at eval.c:2451
#265 0x00000000006e8d9d in Fprog1 (args=XIL(0x17409e3)) at eval.c:457
#266 0x00000000006ef439 in eval_sub (form=XIL(0x1747313)) at eval.c:2451
#267 0x00000000006e8d16 in Fprogn (body=XIL(0)) at eval.c:436
#268 0x00000000006f2182 in funcall_lambda (fun=XIL(0x1740283), nargs=1, arg_vector=0x7fffffff0530) at eval.c:3235
#269 0x00000000006f1993 in apply_lambda (fun=XIL(0x1740273), args=XIL(0x17719b3), count=...) at eval.c:3105
#270 0x00000000006efe12 in eval_sub (form=XIL(0x17719c3)) at eval.c:2590
#271 0x00000000006e8a8e in Fif (args=XIL(0x17719d3)) at eval.c:391
#272 0x00000000006ef439 in eval_sub (form=XIL(0x1771a53)) at eval.c:2451
#273 0x00000000006e8d16 in Fprogn (body=XIL(0)) at eval.c:436
#274 0x00000000006ef439 in eval_sub (form=XIL(0x1e339d3)) at eval.c:2451
#275 0x00000000006e8fc2 in Fsetq (args=XIL(0x1e33993)) at eval.c:483
#276 0x00000000006ef439 in eval_sub (form=XIL(0x1e33983)) at eval.c:2451
#277 0x00000000006e8d16 in Fprogn (body=XIL(0x1e33743)) at eval.c:436
#278 0x00000000006e8d4a in prog_ignore (body=XIL(0x1e33733)) at eval.c:447
#279 0x00000000006eb23a in Fwhile (args=XIL(0x1e33723)) at eval.c:1047
#280 0x00000000006ef439 in eval_sub (form=XIL(0x1e33713)) at eval.c:2451
#281 0x00000000006e8d16 in Fprogn (body=XIL(0x1e336b3)) at eval.c:436
#282 0x00000000006eac2d in FletX (args=XIL(0x1e33693)) at eval.c:958
#283 0x00000000006ef439 in eval_sub (form=XIL(0x1e33683)) at eval.c:2451
#284 0x00000000006efda6 in eval_sub (form=XIL(0x1771a93)) at eval.c:2586
#285 0x00000000006e8d16 in Fprogn (body=XIL(0)) at eval.c:436
#286 0x00000000006f2182 in funcall_lambda (fun=XIL(0x1771493), nargs=2, arg_vector=0x7fffffff1100) at eval.c:3235
#287 0x00000000006f1993 in apply_lambda (fun=XIL(0x1771483), args=XIL(0x1745293), count=...) at eval.c:3105
#288 0x00000000006efe12 in eval_sub (form=XIL(0x17452a3)) at eval.c:2590
#289 0x00000000006f192d in apply_lambda (fun=XIL(0x1772e23), args=XIL(0x1745273), count=...) at eval.c:3100
#290 0x00000000006efe12 in eval_sub (form=XIL(0x17452b3)) at eval.c:2590
#291 0x00000000006f192d in apply_lambda (fun=XIL(0x1772e23), args=XIL(0x1745303), count=...) at eval.c:3100
#292 0x00000000006efe12 in eval_sub (form=XIL(0x1745313)) at eval.c:2590
#293 0x00000000006e8d16 in Fprogn (body=XIL(0)) at eval.c:436
#294 0x00000000006eb164 in Flet (args=XIL(0x1745363)) at eval.c:1026
#295 0x00000000006ef439 in eval_sub (form=XIL(0x1745e83)) at eval.c:2451
#296 0x00000000006e8d16 in Fprogn (body=XIL(0)) at eval.c:436
#297 0x00000000006eb164 in Flet (args=XIL(0x1a60c83)) at eval.c:1026
#298 0x00000000006ef439 in eval_sub (form=XIL(0x1d9faf3)) at eval.c:2451
#299 0x00000000006e8a8e in Fif (args=XIL(0x1d91363)) at eval.c:391
#300 0x00000000006ef439 in eval_sub (form=XIL(0x1d91373)) at eval.c:2451
#301 0x00000000006e8d16 in Fprogn (body=XIL(0)) at eval.c:436
#302 0x00000000006eac2d in FletX (args=XIL(0x1d92cb3)) at eval.c:958
#303 0x00000000006ef439 in eval_sub (form=XIL(0x1d92cc3)) at eval.c:2451
#304 0x00000000006e8a8e in Fif (args=XIL(0x1d94343)) at eval.c:391
#305 0x00000000006ef439 in eval_sub (form=XIL(0x1d94353)) at eval.c:2451
#306 0x00000000006e8d16 in Fprogn (body=XIL(0)) at eval.c:436
#307 0x00000000006eac2d in FletX (args=XIL(0x1d95c93)) at eval.c:958
#308 0x00000000006ef439 in eval_sub (form=XIL(0x1d95ca3)) at eval.c:2451
#309 0x00000000006e8a8e in Fif (args=XIL(0x1d972e3)) at eval.c:391
#310 0x00000000006ef439 in eval_sub (form=XIL(0x1d972f3)) at eval.c:2451
#311 0x00000000006e8d16 in Fprogn (body=XIL(0)) at eval.c:436
#312 0x00000000006eac2d in FletX (args=XIL(0x1d88d53)) at eval.c:958
#313 0x00000000006ef439 in eval_sub (form=XIL(0x1d88d63)) at eval.c:2451
#314 0x00000000006e8a8e in Fif (args=XIL(0x1d8a3a3)) at eval.c:391
#315 0x00000000006ef439 in eval_sub (form=XIL(0x1d8a3b3)) at eval.c:2451
#316 0x00000000006e8d16 in Fprogn (body=XIL(0)) at eval.c:436
#317 0x00000000006eac2d in FletX (args=XIL(0x1d8bcf3)) at eval.c:958
#318 0x00000000006ef439 in eval_sub (form=XIL(0x1d8bd03)) at eval.c:2451
#319 0x00000000006e8d16 in Fprogn (body=XIL(0)) at eval.c:436
#320 0x00000000006e8c03 in Fcond (args=XIL(0x197b3e3)) at eval.c:416
#321 0x00000000006ef439 in eval_sub (form=XIL(0x1978873)) at eval.c:2451
#322 0x00000000006e8d16 in Fprogn (body=XIL(0)) at eval.c:436
#323 0x00000000006eac2d in FletX (args=XIL(0x1976da3)) at eval.c:958
#324 0x00000000006ef439 in eval_sub (form=XIL(0x1976d93)) at eval.c:2451
#325 0x00000000006e8a8e in Fif (args=XIL(0x19755b3)) at eval.c:391
#326 0x00000000006ef439 in eval_sub (form=XIL(0x19755a3)) at eval.c:2451
#327 0x00000000006e8d16 in Fprogn (body=XIL(0)) at eval.c:436
#328 0x00000000006eac2d in FletX (args=XIL(0x1af0063)) at eval.c:958
#329 0x00000000006ef439 in eval_sub (form=XIL(0x1af0053)) at eval.c:2451
#330 0x00000000006efda6 in eval_sub (form=XIL(0x1746f83)) at eval.c:2586
#331 0x00000000006e8d16 in Fprogn (body=XIL(0)) at eval.c:436
#332 0x00000000006eb164 in Flet (args=XIL(0x1746f93)) at eval.c:1026
#333 0x00000000006ef439 in eval_sub (form=XIL(0x1747003)) at eval.c:2451
#334 0x00000000006e8d16 in Fprogn (body=XIL(0)) at eval.c:436
#335 0x00000000006e8add in Fif (args=XIL(0x17471b3)) at eval.c:392
#336 0x00000000006ef439 in eval_sub (form=XIL(0x1747303)) at eval.c:2451
#337 0x00000000006e8d9d in Fprog1 (args=XIL(0x17409e3)) at eval.c:457
#338 0x00000000006ef439 in eval_sub (form=XIL(0x1747313)) at eval.c:2451
#339 0x00000000006e8d16 in Fprogn (body=XIL(0)) at eval.c:436
#340 0x00000000006f2182 in funcall_lambda (fun=XIL(0x1740283), nargs=1, arg_vector=0x7fffffff35f0) at eval.c:3235
#341 0x00000000006f1993 in apply_lambda (fun=XIL(0x1740273), args=XIL(0x17719b3), count=...) at eval.c:3105
#342 0x00000000006efe12 in eval_sub (form=XIL(0x17719c3)) at eval.c:2590
#343 0x00000000006e8a8e in Fif (args=XIL(0x17719d3)) at eval.c:391
#344 0x00000000006ef439 in eval_sub (form=XIL(0x1771a53)) at eval.c:2451
#345 0x00000000006e8d16 in Fprogn (body=XIL(0)) at eval.c:436
#346 0x00000000006ef439 in eval_sub (form=XIL(0x1d57d03)) at eval.c:2451
#347 0x00000000006e8fc2 in Fsetq (args=XIL(0x1d57cc3)) at eval.c:483
#348 0x00000000006ef439 in eval_sub (form=XIL(0x1d57cb3)) at eval.c:2451
#349 0x00000000006e8d16 in Fprogn (body=XIL(0x1d57a73)) at eval.c:436
#350 0x00000000006e8d4a in prog_ignore (body=XIL(0x1d57a63)) at eval.c:447
#351 0x00000000006eb23a in Fwhile (args=XIL(0x1d57a53)) at eval.c:1047
#352 0x00000000006ef439 in eval_sub (form=XIL(0x1d57a43)) at eval.c:2451
#353 0x00000000006e8d16 in Fprogn (body=XIL(0x1d579e3)) at eval.c:436
#354 0x00000000006eac2d in FletX (args=XIL(0x1d579c3)) at eval.c:958
#355 0x00000000006ef439 in eval_sub (form=XIL(0x1d579b3)) at eval.c:2451
#356 0x00000000006efda6 in eval_sub (form=XIL(0x1771a93)) at eval.c:2586
#357 0x00000000006e8d16 in Fprogn (body=XIL(0)) at eval.c:436
#358 0x00000000006f2182 in funcall_lambda (fun=XIL(0x1771493), nargs=2, arg_vector=0x7fffffff41c0) at eval.c:3235
#359 0x00000000006f1993 in apply_lambda (fun=XIL(0x1771483), args=XIL(0x1741043), count=...) at eval.c:3105
#360 0x00000000006efe12 in eval_sub (form=XIL(0x1741053)) at eval.c:2590
#361 0x00000000006e8a8e in Fif (args=XIL(0x1741063)) at eval.c:391
#362 0x00000000006ef439 in eval_sub (form=XIL(0x1741093)) at eval.c:2451
#363 0x00000000006e8d16 in Fprogn (body=XIL(0)) at eval.c:436
#364 0x00000000006eb164 in Flet (args=XIL(0x1741773)) at eval.c:1026
#365 0x00000000006ef439 in eval_sub (form=XIL(0x1741ab3)) at eval.c:2451
#366 0x00000000006e8d16 in Fprogn (body=XIL(0)) at eval.c:436
#367 0x00000000006f2182 in funcall_lambda (fun=XIL(0x1f56c43), nargs=1, arg_vector=0x7fffffff4868) at eval.c:3235
#368 0x00000000006f0fca in funcall_general (fun=XIL(0x1f56c33), numargs=1, args=0x7fffffff4868) at eval.c:2959
#369 0x00000000006f11a7 in Ffuncall (nargs=2, args=0x7fffffff4860)
    at eval.c:2997
#370 0x00000000006ef6c9 in eval_sub (form=XIL(0x1982923)) at eval.c:2472
#371 0x00000000006e8d16 in Fprogn (body=XIL(0)) at eval.c:436
#372 0x00000000006e8c03 in Fcond (args=XIL(0x197fcf3)) at eval.c:416
#373 0x00000000006ef439 in eval_sub (form=XIL(0x1978873)) at eval.c:2451
#374 0x00000000006e8d16 in Fprogn (body=XIL(0)) at eval.c:436
#375 0x00000000006eac2d in FletX (args=XIL(0x1976da3)) at eval.c:958
#376 0x00000000006ef439 in eval_sub (form=XIL(0x1976d93)) at eval.c:2451
#377 0x00000000006e8a8e in Fif (args=XIL(0x19755b3)) at eval.c:391
#378 0x00000000006ef439 in eval_sub (form=XIL(0x19755a3)) at eval.c:2451
#379 0x00000000006e8d16 in Fprogn (body=XIL(0)) at eval.c:436
#380 0x00000000006eac2d in FletX (args=XIL(0x1af0063)) at eval.c:958
#381 0x00000000006ef439 in eval_sub (form=XIL(0x1af0053)) at eval.c:2451
#382 0x00000000006efda6 in eval_sub (form=XIL(0x1746f83)) at eval.c:2586
#383 0x00000000006e8d16 in Fprogn (body=XIL(0)) at eval.c:436
#384 0x00000000006eb164 in Flet (args=XIL(0x1746f93)) at eval.c:1026
#385 0x00000000006ef439 in eval_sub (form=XIL(0x1747003)) at eval.c:2451
#386 0x00000000006e8d16 in Fprogn (body=XIL(0)) at eval.c:436
#387 0x00000000006e8add in Fif (args=XIL(0x17471b3)) at eval.c:392
#388 0x00000000006ef439 in eval_sub (form=XIL(0x1747303)) at eval.c:2451
#389 0x00000000006e8d9d in Fprog1 (args=XIL(0x17409e3)) at eval.c:457
#390 0x00000000006ef439 in eval_sub (form=XIL(0x1747313)) at eval.c:2451
#391 0x00000000006e8d16 in Fprogn (body=XIL(0)) at eval.c:436
#392 0x00000000006f2182 in funcall_lambda (fun=XIL(0x1740283), nargs=1, arg_vector=0x7fffffff5790) at eval.c:3235
#393 0x00000000006f1993 in apply_lambda (fun=XIL(0x1740273), args=XIL(0x17719b3), count=...) at eval.c:3105
#394 0x00000000006efe12 in eval_sub (form=XIL(0x17719c3)) at eval.c:2590
#395 0x00000000006e8a8e in Fif (args=XIL(0x17719d3)) at eval.c:391
#396 0x00000000006ef439 in eval_sub (form=XIL(0x1771a53)) at eval.c:2451
#397 0x00000000006e8d16 in Fprogn (body=XIL(0)) at eval.c:436
#398 0x00000000006ef439 in eval_sub (form=XIL(0x1cc8c73)) at eval.c:2451
#399 0x00000000006e8fc2 in Fsetq (args=XIL(0x1cc8c33)) at eval.c:483
#400 0x00000000006ef439 in eval_sub (form=XIL(0x1cc8c23)) at eval.c:2451
#401 0x00000000006e8d16 in Fprogn (body=XIL(0x1cc89e3)) at eval.c:436
#402 0x00000000006e8d4a in prog_ignore (body=XIL(0x1cc89d3)) at eval.c:447
#403 0x00000000006eb23a in Fwhile (args=XIL(0x1cc89c3)) at eval.c:1047
#404 0x00000000006ef439 in eval_sub (form=XIL(0x1cc89b3)) at eval.c:2451
#405 0x00000000006e8d16 in Fprogn (body=XIL(0x1cc8953)) at eval.c:436
#406 0x00000000006eac2d in FletX (args=XIL(0x1cc8933)) at eval.c:958
#407 0x00000000006ef439 in eval_sub (form=XIL(0x1cc8923)) at eval.c:2451
#408 0x00000000006efda6 in eval_sub (form=XIL(0x1771a93)) at eval.c:2586
#409 0x00000000006e8d16 in Fprogn (body=XIL(0)) at eval.c:436
#410 0x00000000006f2182 in funcall_lambda (fun=XIL(0x1771493), nargs=2, arg_vector=0x7fffffff6360) at eval.c:3235
#411 0x00000000006f1993 in apply_lambda (fun=XIL(0x1771483), args=XIL(0x1741043), count=...) at eval.c:3105
#412 0x00000000006efe12 in eval_sub (form=XIL(0x1741053)) at eval.c:2590
#413 0x00000000006e8a8e in Fif (args=XIL(0x1741063)) at eval.c:391
#414 0x00000000006ef439 in eval_sub (form=XIL(0x1741093)) at eval.c:2451
#415 0x00000000006e8d16 in Fprogn (body=XIL(0)) at eval.c:436
#416 0x00000000006eb164 in Flet (args=XIL(0x1741773)) at eval.c:1026
#417 0x00000000006ef439 in eval_sub (form=XIL(0x1741ab3)) at eval.c:2451
#418 0x00000000006e8d16 in Fprogn (body=XIL(0)) at eval.c:436
#419 0x00000000006f2182 in funcall_lambda (fun=XIL(0x1fb0183), nargs=1, arg_vector=0x7fffffff6a08) at eval.c:3235
#420 0x00000000006f0fca in funcall_general (fun=XIL(0x1fb0173), numargs=1, args=0x7fffffff6a08) at eval.c:2959
#421 0x00000000006f11a7 in Ffuncall (nargs=2, args=0x7fffffff6a00)
    at eval.c:2997
#422 0x00000000006ef6c9 in eval_sub (form=XIL(0x1982923)) at eval.c:2472
#423 0x00000000006e8d16 in Fprogn (body=XIL(0)) at eval.c:436
#424 0x00000000006e8c03 in Fcond (args=XIL(0x197fcf3)) at eval.c:416
#425 0x00000000006ef439 in eval_sub (form=XIL(0x1978873)) at eval.c:2451
#426 0x00000000006e8d16 in Fprogn (body=XIL(0)) at eval.c:436
#427 0x00000000006eac2d in FletX (args=XIL(0x1976da3)) at eval.c:958
#428 0x00000000006ef439 in eval_sub (form=XIL(0x1976d93)) at eval.c:2451
#429 0x00000000006e8a8e in Fif (args=XIL(0x19755b3)) at eval.c:391
#430 0x00000000006ef439 in eval_sub (form=XIL(0x19755a3)) at eval.c:2451
#431 0x00000000006e8d16 in Fprogn (body=XIL(0)) at eval.c:436
#432 0x00000000006eac2d in FletX (args=XIL(0x1af0063)) at eval.c:958
#433 0x00000000006ef439 in eval_sub (form=XIL(0x1af0053)) at eval.c:2451
#434 0x00000000006efda6 in eval_sub (form=XIL(0x1746f83)) at eval.c:2586
#435 0x00000000006e8d16 in Fprogn (body=XIL(0)) at eval.c:436
#436 0x00000000006eb164 in Flet (args=XIL(0x1746f93)) at eval.c:1026
#437 0x00000000006ef439 in eval_sub (form=XIL(0x1747003)) at eval.c:2451
#438 0x00000000006e8d16 in Fprogn (body=XIL(0)) at eval.c:436
#439 0x00000000006e8add in Fif (args=XIL(0x17471b3)) at eval.c:392
#440 0x00000000006ef439 in eval_sub (form=XIL(0x1747303)) at eval.c:2451
#441 0x00000000006e8d9d in Fprog1 (args=XIL(0x17409e3)) at eval.c:457
#442 0x00000000006ef439 in eval_sub (form=XIL(0x1747313)) at eval.c:2451
#443 0x00000000006e8d16 in Fprogn (body=XIL(0)) at eval.c:436
#444 0x00000000006f2182 in funcall_lambda (fun=XIL(0x1740283), nargs=1, arg_vector=0x7fffffff7930) at eval.c:3235
#445 0x00000000006f1993 in apply_lambda (fun=XIL(0x1740273), args=XIL(0x17719b3), count=...) at eval.c:3105
#446 0x00000000006efe12 in eval_sub (form=XIL(0x17719c3)) at eval.c:2590
#447 0x00000000006e8a8e in Fif (args=XIL(0x17719d3)) at eval.c:391
#448 0x00000000006ef439 in eval_sub (form=XIL(0x1771a53)) at eval.c:2451
#449 0x00000000006e8d16 in Fprogn (body=XIL(0)) at eval.c:436
#450 0x00000000006ef439 in eval_sub (form=XIL(0x1fb0aa3)) at eval.c:2451
#451 0x00000000006e8fc2 in Fsetq (args=XIL(0x1fb0a63)) at eval.c:483
#452 0x00000000006ef439 in eval_sub (form=XIL(0x1fb0a53)) at eval.c:2451
#453 0x00000000006e8d16 in Fprogn (body=XIL(0x1fb0813)) at eval.c:436
#454 0x00000000006e8d4a in prog_ignore (body=XIL(0x1fb0803)) at eval.c:447
#455 0x00000000006eb23a in Fwhile (args=XIL(0x1fb07f3)) at eval.c:1047
#456 0x00000000006ef439 in eval_sub (form=XIL(0x1fb07e3)) at eval.c:2451
#457 0x00000000006e8d16 in Fprogn (body=XIL(0x1fb0783)) at eval.c:436
#458 0x00000000006eac2d in FletX (args=XIL(0x1fb0763)) at eval.c:958
#459 0x00000000006ef439 in eval_sub (form=XIL(0x1fb0753)) at eval.c:2451
#460 0x00000000006efda6 in eval_sub (form=XIL(0x1771a93)) at eval.c:2586
#461 0x00000000006e8d16 in Fprogn (body=XIL(0)) at eval.c:436
#462 0x00000000006f2182 in funcall_lambda (fun=XIL(0x1771493), nargs=2, arg_vector=0x7fffffff8500) at eval.c:3235
#463 0x00000000006f1993 in apply_lambda (fun=XIL(0x1771483), args=XIL(0x1741043), count=...) at eval.c:3105
#464 0x00000000006efe12 in eval_sub (form=XIL(0x1741053)) at eval.c:2590
#465 0x00000000006e8a8e in Fif (args=XIL(0x1741063)) at eval.c:391
#466 0x00000000006ef439 in eval_sub (form=XIL(0x1741093)) at eval.c:2451
#467 0x00000000006e8d16 in Fprogn (body=XIL(0)) at eval.c:436
#468 0x00000000006eb164 in Flet (args=XIL(0x1741773)) at eval.c:1026
#469 0x00000000006ef439 in eval_sub (form=XIL(0x1741ab3)) at eval.c:2451
#470 0x00000000006e8d16 in Fprogn (body=XIL(0)) at eval.c:436
#471 0x00000000006f2182 in funcall_lambda (fun=XIL(0x1edfeb3), nargs=1, arg_vector=0x7fffffff8ba8) at eval.c:3235
#472 0x00000000006f0fca in funcall_general (fun=XIL(0x1edfea3), numargs=1, args=0x7fffffff8ba8) at eval.c:2959
#473 0x00000000006f11a7 in Ffuncall (nargs=2, args=0x7fffffff8ba0)
    at eval.c:2997
#474 0x00000000006ef6c9 in eval_sub (form=XIL(0x1982923)) at eval.c:2472
#475 0x00000000006e8d16 in Fprogn (body=XIL(0)) at eval.c:436
#476 0x00000000006e8c03 in Fcond (args=XIL(0x197fcf3)) at eval.c:416
#477 0x00000000006ef439 in eval_sub (form=XIL(0x1978873)) at eval.c:2451
#478 0x00000000006e8d16 in Fprogn (body=XIL(0)) at eval.c:436
#479 0x00000000006eac2d in FletX (args=XIL(0x1976da3)) at eval.c:958
#480 0x00000000006ef439 in eval_sub (form=XIL(0x1976d93)) at eval.c:2451
#481 0x00000000006e8a8e in Fif (args=XIL(0x19755b3)) at eval.c:391
#482 0x00000000006ef439 in eval_sub (form=XIL(0x19755a3)) at eval.c:2451
#483 0x00000000006e8d16 in Fprogn (body=XIL(0)) at eval.c:436
#484 0x00000000006eac2d in FletX (args=XIL(0x1af0063)) at eval.c:958
#485 0x00000000006ef439 in eval_sub (form=XIL(0x1af0053)) at eval.c:2451
#486 0x00000000006efda6 in eval_sub (form=XIL(0x1746f83)) at eval.c:2586
#487 0x00000000006e8d16 in Fprogn (body=XIL(0)) at eval.c:436
#488 0x00000000006eb164 in Flet (args=XIL(0x1746f93)) at eval.c:1026
#489 0x00000000006ef439 in eval_sub (form=XIL(0x1747003)) at eval.c:2451
#490 0x00000000006e8d16 in Fprogn (body=XIL(0)) at eval.c:436
#491 0x00000000006e8add in Fif (args=XIL(0x17471b3)) at eval.c:392
#492 0x00000000006ef439 in eval_sub (form=XIL(0x1747303)) at eval.c:2451
#493 0x00000000006e8d9d in Fprog1 (args=XIL(0x17409e3)) at eval.c:457
#494 0x00000000006ef439 in eval_sub (form=XIL(0x1747313)) at eval.c:2451
#495 0x00000000006e8d16 in Fprogn (body=XIL(0)) at eval.c:436
#496 0x00000000006f2182 in funcall_lambda (fun=XIL(0x1740283), nargs=1, arg_vector=0x7fffffff9ad0) at eval.c:3235
#497 0x00000000006f1993 in apply_lambda (fun=XIL(0x1740273), args=XIL(0x172b573), count=...) at eval.c:3105
#498 0x00000000006efe12 in eval_sub (form=XIL(0x172b583)) at eval.c:2590
#499 0x00000000006e8d16 in Fprogn (body=XIL(0)) at eval.c:436
#500 0x00000000006eb164 in Flet (args=XIL(0x172b593)) at eval.c:1026
#501 0x00000000006ef439 in eval_sub (form=XIL(0x172b5d3)) at eval.c:2451
#502 0x00000000006e8d16 in Fprogn (body=XIL(0)) at eval.c:436
#503 0x00000000006f2182 in funcall_lambda (fun=XIL(0x172b153), nargs=1, arg_vector=0x7fffffff9f80) at eval.c:3235
#504 0x00000000006f1993 in apply_lambda (fun=XIL(0x172b143), args=XIL(0x1823873), count=...) at eval.c:3105
#505 0x00000000006efe12 in eval_sub (form=XIL(0x1823883)) at eval.c:2590
#506 0x00000000006e8a8e in Fif (args=XIL(0x1823893)) at eval.c:391
#507 0x00000000006ef439 in eval_sub (form=XIL(0x18238a3)) at eval.c:2451
#508 0x00000000006e8d16 in Fprogn (body=XIL(0)) at eval.c:436
#509 0x00000000006eb164 in Flet (args=XIL(0x18238b3)) at eval.c:1026
#510 0x00000000006ef439 in eval_sub (form=XIL(0x1823923)) at eval.c:2451
#511 0x00000000006ec35c in internal_lisp_condition_case (var=XIL(0x71f960), bodyform=XIL(0x1823923), handlers=XIL(0x18237a3)) at eval.c:1428
#512 0x00000000006ebc79 in Fcondition_case (args=XIL(0x1823933)) at eval.c:1343
#513 0x00000000006ef439 in eval_sub (form=XIL(0x1823943)) at eval.c:2451
#514 0x00000000006e8d16 in Fprogn (body=XIL(0)) at eval.c:436
#515 0x00000000006e8c03 in Fcond (args=XIL(0x1823783)) at eval.c:416
#516 0x00000000006ef439 in eval_sub (form=XIL(0x18257c3)) at eval.c:2451
#517 0x00000000006e8d16 in Fprogn (body=XIL(0)) at eval.c:436
#518 0x00000000006eb164 in Flet (args=XIL(0x18257e3)) at eval.c:1026
#519 0x00000000006ef439 in eval_sub (form=XIL(0x1825913)) at eval.c:2451
#520 0x00000000006e8d16 in Fprogn (body=XIL(0)) at eval.c:436
#521 0x00000000006f2182 in funcall_lambda (fun=XIL(0x1822413), nargs=2, arg_vector=0x7fffffffac88) at eval.c:3235
#522 0x00000000006f0fca in funcall_general (fun=XIL(0x1822403), numargs=2, args=0x7fffffffac88) at eval.c:2959
#523 0x00000000006f11a7 in Ffuncall (nargs=3, args=0x7fffffffac80)
    at eval.c:2997
#524 0x00000000007318c0 in call2 (fn=XIL(0x59b6b0), arg1=XIL(0x1ee84d3), arg2=XIL(0x30)) at lisp.h:3254
#525 0x0000000000737d5c in readevalloop_eager_expand_eval (val=XIL(0x1ee84d3), macroexpand=XIL(0x59b6b0)) at lread.c:2164
#526 0x00000000007385ce in readevalloop (readcharfun=XIL(0x1ab3005), infile0=0x0, sourcename=XIL(0x1ca76c4), printflag=false, unibyte=XIL(0), readfun=XIL(0), start=XIL(0), end=XIL(0)) at lread.c:2347
#527 0x0000000000738915 in Feval_buffer (buffer=XIL(0x1ab3005), printflag=XIL(0), filename=XIL(0x1ca76c4), unibyte=XIL(0), do_allow_print=XIL(0x30))
    at lread.c:2420
#528 0x00000000006ef93c in eval_sub (form=XIL(0x11f5e73)) at eval.c:2514
#529 0x00000000006e8d16 in Fprogn (body=XIL(0)) at eval.c:436
#530 0x00000000006e8add in Fif (args=XIL(0x11f5f23)) at eval.c:392
#531 0x00000000006ef439 in eval_sub (form=XIL(0x11f5f33)) at eval.c:2451
#532 0x00000000006e8d16 in Fprogn (body=XIL(0)) at eval.c:436
#533 0x00000000006eb164 in Flet (args=XIL(0x11f5fc3)) at eval.c:1026
#534 0x00000000006ef439 in eval_sub (form=XIL(0x11f6063)) at eval.c:2451
#535 0x00000000006e8d16 in Fprogn (body=XIL(0)) at eval.c:436
#536 0x00000000006eb164 in Flet (args=XIL(0x11f6543)) at eval.c:1026
#537 0x00000000006ef439 in eval_sub (form=XIL(0x11f6623)) at eval.c:2451
#538 0x00000000006eba98 in Funwind_protect (args=XIL(0x11f5d93)) at eval.c:1301
#539 0x00000000006ef439 in eval_sub (form=XIL(0x11f6633)) at eval.c:2451
#540 0x00000000006e8d16 in Fprogn (body=XIL(0x11f5943)) at eval.c:436
#541 0x00000000006eb164 in Flet (args=XIL(0x11f6ce3)) at eval.c:1026
#542 0x00000000006ef439 in eval_sub (form=XIL(0x11f6e03)) at eval.c:2451
#543 0x00000000006e8d16 in Fprogn (body=XIL(0)) at eval.c:436
#544 0x00000000006e8add in Fif (args=XIL(0x11f6f53)) at eval.c:392
#545 0x00000000006ef439 in eval_sub (form=XIL(0x11f6fa3)) at eval.c:2451
#546 0x00000000006e8d16 in Fprogn (body=XIL(0)) at eval.c:436
#547 0x00000000006f2182 in funcall_lambda (fun=XIL(0x11f4e93), nargs=4, arg_vector=0x7fffffffbc08) at eval.c:3235
#548 0x00000000006f0fca in funcall_general (fun=XIL(0x11f4e83), numargs=4, args=0x7fffffffbc08) at eval.c:2959
#549 0x00000000006f11a7 in Ffuncall (nargs=5, args=0x7fffffffbc00)
    at eval.c:2997
#550 0x000000000073193a in call4 (fn=XIL(0x757400), arg1=XIL(0x1ca76c4), arg2=XIL(0x1ca76c4), arg3=XIL(0), arg4=XIL(0x30)) at lisp.h:3269
#551 0x0000000000735e18 in Fload (file=XIL(0x1c37f64), noerror=XIL(0), nomessage=XIL(0x30), nosuffix=XIL(0), must_suffix=XIL(0x30)) at lread.c:1484
#552 0x00000000007364bb in save_match_data_load (file=XIL(0x1c37f64), noerror=XIL(0), nomessage=XIL(0x30), nosuffix=XIL(0), must_suffix=XIL(0x30))
    at lread.c:1637
#553 0x00000000006eea00 in load_with_autoload_queue (file=XIL(0x1c37f64), noerror=XIL(0), nomessage=XIL(0x30), nosuffix=XIL(0), must_suffix=XIL(0x30))
    at eval.c:2286
#554 0x00000000007059c0 in Frequire (feature=XIL(0xb28c00), filename=XIL(0), noerror=XIL(0)) at fns.c:3417
#555 0x00000000006ef8d6 in eval_sub (form=XIL(0x11a3803)) at eval.c:2506
#556 0x00000000006e8d16 in Fprogn (body=XIL(0)) at eval.c:436
#557 0x00000000006ef439 in eval_sub (form=XIL(0x11a35c3)) at eval.c:2451
#558 0x00000000006eedc0 in Feval (form=XIL(0x11a35c3), lexical=XIL(0x30))
    at eval.c:2363
#559 0x00000000006ef8a6 in eval_sub (form=XIL(0x1203e23)) at eval.c:2503
#560 0x00000000006ef64d in eval_sub (form=XIL(0x1203de3)) at eval.c:2467
#561 0x00000000006e8d16 in Fprogn (body=XIL(0)) at eval.c:436
#562 0x00000000006f2182 in funcall_lambda (fun=XIL(0x1204703), nargs=2, arg_vector=0x7fffffffc678) at eval.c:3235
#563 0x00000000006f0fca in funcall_general (fun=XIL(0x1204713), numargs=2, args=0x7fffffffc678) at eval.c:2959
#564 0x00000000006f11a7 in Ffuncall (nargs=3, args=0x7fffffffc670)
    at eval.c:2997
#565 0x00000000006f03ae in Fapply (nargs=2, args=0x7fffffffc730) at eval.c:2668
#566 0x00000000006f0aaa in apply1 (fn=XIL(0x1204713), arg=XIL(0x11a3813))
    at eval.c:2884
#567 0x00000000006efd7c in eval_sub (form=XIL(0x11a3873)) at eval.c:2584
#568 0x00000000007385e0 in readevalloop (readcharfun=XIL(0x122f2bd), infile0=0x0, sourcename=XIL(0x1b71ac4), printflag=false, unibyte=XIL(0), readfun=XIL(0), start=XIL(0), end=XIL(0)) at lread.c:2349
#569 0x0000000000738915 in Feval_buffer (buffer=XIL(0x122f2bd), printflag=XIL(0), filename=XIL(0x1b71ac4), unibyte=XIL(0), do_allow_print=XIL(0x30))
    at lread.c:2420
#570 0x00000000006ef93c in eval_sub (form=XIL(0x11f5e73)) at eval.c:2514
#571 0x00000000006e8d16 in Fprogn (body=XIL(0)) at eval.c:436
#572 0x00000000006e8add in Fif (args=XIL(0x11f5f23)) at eval.c:392
#573 0x00000000006ef439 in eval_sub (form=XIL(0x11f5f33)) at eval.c:2451
#574 0x00000000006e8d16 in Fprogn (body=XIL(0)) at eval.c:436
#575 0x00000000006eb164 in Flet (args=XIL(0x11f5fc3)) at eval.c:1026
#576 0x00000000006ef439 in eval_sub (form=XIL(0x11f6063)) at eval.c:2451
#577 0x00000000006e8d16 in Fprogn (body=XIL(0)) at eval.c:436
#578 0x00000000006eb164 in Flet (args=XIL(0x11f6543)) at eval.c:1026
#579 0x00000000006ef439 in eval_sub (form=XIL(0x11f6623)) at eval.c:2451
#580 0x00000000006eba98 in Funwind_protect (args=XIL(0x11f5d93)) at eval.c:1301
#581 0x00000000006ef439 in eval_sub (form=XIL(0x11f6633)) at eval.c:2451
#582 0x00000000006e8d16 in Fprogn (body=XIL(0x11f5943)) at eval.c:436
#583 0x00000000006eb164 in Flet (args=XIL(0x11f6ce3)) at eval.c:1026
#584 0x00000000006ef439 in eval_sub (form=XIL(0x11f6e03)) at eval.c:2451
#585 0x00000000006e8d16 in Fprogn (body=XIL(0)) at eval.c:436
#586 0x00000000006e8add in Fif (args=XIL(0x11f6f53)) at eval.c:392
#587 0x00000000006ef439 in eval_sub (form=XIL(0x11f6fa3)) at eval.c:2451
#588 0x00000000006e8d16 in Fprogn (body=XIL(0)) at eval.c:436
#589 0x00000000006f2182 in funcall_lambda (fun=XIL(0x11f4e93), nargs=4, arg_vector=0x7fffffffd788) at eval.c:3235
#590 0x00000000006f0fca in funcall_general (fun=XIL(0x11f4e83), numargs=4, args=0x7fffffffd788) at eval.c:2959
#591 0x00000000006f11a7 in Ffuncall (nargs=5, args=0x7fffffffd780)
    at eval.c:2997
#592 0x000000000073193a in call4 (fn=XIL(0x757400), arg1=XIL(0x1b71ac4), arg2=XIL(0x1b71ac4), arg3=XIL(0), arg4=XIL(0)) at lisp.h:3269
#593 0x0000000000735e18 in Fload (file=XIL(0x1aa2bc4), noerror=XIL(0), nomessage=XIL(0), nosuffix=XIL(0), must_suffix=XIL(0)) at lread.c:1484
#594 0x00000000006ef93c in eval_sub (form=XIL(0x121f2d3)) at eval.c:2514
#595 0x00000000007385e0 in readevalloop (readcharfun=XIL(0x8340), infile0=0x7fffffffdd70, sourcename=XIL(0x16a7f84), printflag=false, unibyte=XIL(0), readfun=XIL(0), start=XIL(0), end=XIL(0)) at lread.c:2349
#596 0x00000000007361e0 in Fload (file=XIL(0x16a7e04), noerror=XIL(0), nomessage=XIL(0), nosuffix=XIL(0), must_suffix=XIL(0)) at lread.c:1588
#597 0x00000000006ef93c in eval_sub (form=XIL(0x121c9e3)) at eval.c:2514
#598 0x00000000006eedc0 in Feval (form=XIL(0x121c9e3), lexical=XIL(0))
    at eval.c:2363
#599 0x000000000060c568 in top_level_2 () at keyboard.c:1133
#600 0x00000000006ec580 in internal_condition_case (bfun=0x60c545 <top_level_2>, handlers=XIL(0x90), hfun=0x60bd35 <cmd_error>) at eval.c:1474
#601 0x000000000060c5b0 in top_level_1 (ignore=XIL(0)) at keyboard.c:1141
#602 0x00000000006eb725 in internal_catch (tag=XIL(0x103e0), func=0x60c56a <top_level_1>, arg=XIL(0)) at eval.c:1197
#603 0x000000000060c487 in command_loop () at keyboard.c:1101
#604 0x000000000060b7f6 in recursive_edit_1 () at keyboard.c:711
#605 0x000000000060ba14 in Frecursive_edit () at keyboard.c:794
#606 0x0000000000606cce in main (argc=5, argv=0x7fffffffe358) at emacs.c:2530

Lisp Backtrace:
"Automatic GC" (0x0)
"unless" (0xfffe5f88)
"backquote-process" (0xfffe6160)
"backquote-listify" (0xfffe63e8)
"cons" (0xfffe6518)
"setq" (0xfffe66b8)
"push" (0xfffe67e8)
"if" (0xfffe6948)
"let" (0xfffe6b88)
"cond" (0xfffe6d28)
"backquote-process" (0xfffe6f00)
"setq" (0xfffe7158)
"while" (0xfffe7318)
"let" (0xfffe7558)
"cond" (0xfffe76f8)
"backquote-process" (0xfffe78d0)
"setq" (0xfffe7b28)
"while" (0xfffe7ce8)
"let" (0xfffe7f28)
"cond" (0xfffe80c8)
"backquote-process" (0xfffe82a0)
"setq" (0xfffe84f8)
"while" (0xfffe86b8)
"let" (0xfffe88f8)
"cond" (0xfffe8a98)
"backquote-process" (0xfffe8c70)
"cdr" (0xfffe8e58)
0x11fa3a0 Lisp type 3
"`" (0xfffe9198)
"let" (0xfffe93d8)
0x1771bc0 Lisp type 3
"macroexp--accumulate" (0xfffe9748)
"macroexp--all-forms" (0xfffe9920)
"if" (0xfffe9b38)
"let" (0xfffe9d58)
0x1b47d70 Lisp type 3
"funcall" (0xfffe9fc0)
"cond" (0xfffea198)
"let*" (0xfffea388)
"if" (0xfffea4e8)
"let*" (0xfffea6d8)
"pcase" (0xfffea808)
"let" (0xfffeaa28)
"if" (0xfffeabb8)
"prog1" (0xfffead18)
"macroexp--expand-all" (0xfffeaef0)
"if" (0xfffeb108)
"progn" (0xfffeb268)
"setq" (0xfffeb408)
"while" (0xfffeb5c8)
"let*" (0xfffeb7b8)
"macroexp--accumulate" (0xfffeb8e8)
"macroexp--all-forms" (0xfffebac0)
"if" (0xfffebcd8)
"let" (0xfffebef8)
0x1f606e0 Lisp type 3
"funcall" (0xfffec160)
"cond" (0xfffec338)
"let*" (0xfffec528)
"if" (0xfffec688)
"let*" (0xfffec878)
"pcase" (0xfffec9a8)
"let" (0xfffecbc8)
"if" (0xfffecd58)
"prog1" (0xfffeceb8)
"macroexp--expand-all" (0xfffed090)
"if" (0xfffed2a8)
"progn" (0xfffed408)
"setq" (0xfffed5a8)
"while" (0xfffed768)
"let*" (0xfffed958)
"macroexp--accumulate" (0xfffeda88)
"macroexp--all-forms" (0xfffedc60)
"if" (0xfffede78)
"progn" (0xfffedfd8)
"setq" (0xfffee178)
"while" (0xfffee338)
"let*" (0xfffee528)
"macroexp--accumulate" (0xfffee658)
"macroexp--all-clauses" (0xfffee830)
"macroexp--cons" (0xfffeeac8)
"macroexp--cons" (0xfffeeca8)
"let" (0xfffeeec8)
"let" (0xfffef0f8)
"let*" (0xfffef2e8)
"progn" (0xfffef448)
"let*" (0xfffef638)
"cond" (0xfffef7d8)
"let*" (0xfffef9c8)
"if" (0xfffefb28)
"let*" (0xfffefd18)
"pcase" (0xfffefe48)
"let" (0xffff0068)
"if" (0xffff01f8)
"prog1" (0xffff0358)
"macroexp--expand-all" (0xffff0530)
"if" (0xffff0748)
"progn" (0xffff08a8)
"setq" (0xffff0a48)
"while" (0xffff0c08)
"let*" (0xffff0df8)
"macroexp--accumulate" (0xffff0f28)
"macroexp--all-forms" (0xffff1100)
"macroexp--cons" (0xffff1398)
"macroexp--cons" (0xffff1578)
"let" (0xffff1798)
"let" (0xffff19b8)
"if" (0xffff1b18)
"let*" (0xffff1d08)
"if" (0xffff1e68)
"let*" (0xffff2058)
"if" (0xffff21b8)
"let*" (0xffff23a8)
"if" (0xffff2508)
"let*" (0xffff26f8)
"cond" (0xffff2898)
"let*" (0xffff2a88)
"if" (0xffff2be8)
"let*" (0xffff2dd8)
"pcase" (0xffff2f08)
"let" (0xffff3128)
"if" (0xffff32b8)
"prog1" (0xffff3418)
"macroexp--expand-all" (0xffff35f0)
"if" (0xffff3808)
"progn" (0xffff3968)
"setq" (0xffff3b08)
"while" (0xffff3cc8)
"let*" (0xffff3eb8)
"macroexp--accumulate" (0xffff3fe8)
"macroexp--all-forms" (0xffff41c0)
"if" (0xffff43d8)
"let" (0xffff45f8)
0x1f56c30 Lisp type 3
"funcall" (0xffff4860)
"cond" (0xffff4a38)
"let*" (0xffff4c28)
"if" (0xffff4d88)
"let*" (0xffff4f78)
"pcase" (0xffff50a8)
"let" (0xffff52c8)
"if" (0xffff5458)
"prog1" (0xffff55b8)
"macroexp--expand-all" (0xffff5790)
"if" (0xffff59a8)
"progn" (0xffff5b08)
"setq" (0xffff5ca8)
"while" (0xffff5e68)
"let*" (0xffff6058)
"macroexp--accumulate" (0xffff6188)
"macroexp--all-forms" (0xffff6360)
"if" (0xffff6578)
"let" (0xffff6798)
0x1fb0170 Lisp type 3
"funcall" (0xffff6a00)
"cond" (0xffff6bd8)
"let*" (0xffff6dc8)
"if" (0xffff6f28)
"let*" (0xffff7118)
"pcase" (0xffff7248)
"let" (0xffff7468)
"if" (0xffff75f8)
"prog1" (0xffff7758)
"macroexp--expand-all" (0xffff7930)
"if" (0xffff7b48)
"progn" (0xffff7ca8)
"setq" (0xffff7e48)
"while" (0xffff8008)
"let*" (0xffff81f8)
"macroexp--accumulate" (0xffff8328)
"macroexp--all-forms" (0xffff8500)
"if" (0xffff8718)
"let" (0xffff8938)
0x1edfea0 Lisp type 3
"funcall" (0xffff8ba0)
"cond" (0xffff8d78)
"let*" (0xffff8f68)
"if" (0xffff90c8)
"let*" (0xffff92b8)
"pcase" (0xffff93e8)
"let" (0xffff9608)
"if" (0xffff9798)
"prog1" (0xffff98f8)
"macroexp--expand-all" (0xffff9ad0)
"let" (0xffff9da8)
"macroexpand--all-toplevel" (0xffff9f80)
"if" (0xffffa198)
"let" (0xffffa3b8)
"condition-case" (0xffffa638)
"cond" (0xffffa7d8)
"let" (0xffffa9f8)
"internal-macroexpand-for-load" (0xffffac88)
"eval-buffer" (0xffffaf00)
"if" (0xffffafe8)
"let" (0xffffb208)
"let" (0xffffb448)
"unwind-protect" (0xffffb5a8)
"let" (0xffffb7d8)
"if" (0xffffb968)
"load-with-code-conversion" (0xffffbc08)
"require" (0xffffc090)
"progn" (0xffffc148)
"eval" (0xffffc360)
"list" (0xffffc408)
0x1204710 Lisp type 3
"eval-when-compile" (0xffffc778)
"eval-buffer" (0xffffca80)
"if" (0xffffcb68)
"let" (0xffffcd88)
"let" (0xffffcfc8)
"unwind-protect" (0xffffd128)
"let" (0xffffd358)
"if" (0xffffd4e8)
"load-with-code-conversion" (0xffffd788)
"load" (0xffffdad0)
"load" (0xffffdf00)

bug#61960: 30.0.50; Unexec build reliably crashes during loadup

[Konstantin Kharlamov]

So, just to add some points: apparently it isn't so easy to reproduce. I built Emacs with unexec without first looking at the `./configure` line in the report (looking at the report I apparently lack the `with-dumping=unexec`), and removed the workaround to not have BLOCK_SIZE=2¹⁵ if HAVE_UNEXEC. (worth noting probably that I first did the build, then remembered I had to remove the work around installed on master branch, then re-built emacs without the workaround).

Running `emacs` as well as running the `temacs` command ain't shows no crashes.

My configuration was: --prefix=/usr --sysconfdir=/etc --libexecdir=/usr/lib --localstatedir=/var --mandir=/usr/share/man --with-gameuser=:games --with-modules --without-libotf --without-m17n-flt --without-gconf --enable-link-time-optimization --with-native-compilation=yes --with-xinput2 --with-x-toolkit=gtk3 --without-xaw3d --with-sound=no --with-tree-sitter --without-gpm --without-compress-install '--program-transform-name=s/\\([ec]tags\\)/\\1.emacs/' 'CFLAGS=-flto=2 -march=native -O3 -pipe -fno-stack-protector -fweb -fmerge-all-constants -fno-plt -fcommon' 'LDFLAGS=-flto=2 -O3 -march=native -fweb -fmerge-all-constants -floop-nest-optimize -Wl,--sort-common,-z,relro -fno-plt -fcommon'

I will try to reconfigure build with the flags Eli reports. I seems to have lacked `with-dumping=unexec` option, but I'll try running `configure` only with the flags mentioned, just for the safe case.

bug#61960: 30.0.50; Unexec build reliably crashes during loadup

[Konstantin Kharlamov]

Oh, I am sorry, I posted the configuration line from the wrong emacs build. It's
supposed to be:

--prefix=/usr --sysconfdir=/etc --libexecdir=/usr/lib --localstatedir=/var --
mandir=/usr/share/man --with-gameuser=:games --with-modules --without-libotf --
without-m17n-flt --without-gconf --with-native-compilation=yes --with-xinput2 --
with-x-toolkit=gtk3 --without-xaw3d --with-sound=no --with-tree-sitter --with-
unexec --without-gpm --without-compress-install 'CFLAGS=-O0 -g3'

On Sat, 2023-03-04 at 22:50 +0300, Konstantin Kharlamov wrote:
> So, just to add some points: apparently it isn't so easy to reproduce. I built
> Emacs with unexec without first looking at the `./configure` line in the
> report (looking at the report I apparently lack the `with-dumping=unexec`),
> and removed the workaround to not have BLOCK_SIZE=2¹⁵ if HAVE_UNEXEC. (worth
> noting probably that I first did the build, then remembered I had to remove
> the work around installed on master branch, then re-built emacs without the
> workaround).
> 
> Running `emacs` as well as running the `temacs` command ain't shows no
> crashes.
> 
> My configuration was: --prefix=/usr --sysconfdir=/etc --libexecdir=/usr/lib --
> localstatedir=/var --mandir=/usr/share/man --with-gameuser=:games --with-
> modules --without-libotf --without-m17n-flt --without-gconf --enable-link-
> time-optimization --with-native-compilation=yes --with-xinput2 --with-x-
> toolkit=gtk3 --without-xaw3d --with-sound=no --with-tree-sitter --without-gpm
> --without-compress-install '--program-transform-
> name=s/\\([ec]tags\\)/\\1.emacs/' 'CFLAGS=-flto=2 -march=native -O3 -pipe -
> fno-stack-protector -fweb -fmerge-all-constants -fno-plt -fcommon' 'LDFLAGS=-
> flto=2 -O3 -march=native -fweb -fmerge-all-constants -floop-nest-optimize -
> Wl,--sort-common,-z,relro -fno-plt -fcommon'
> 
> I will try to reconfigure build with the flags Eli reports. I seems to have
> lacked `with-dumping=unexec` option, but I'll try running `configure` only
> with the flags mentioned, just for the safe case.

bug#61960: 30.0.50; Unexec build reliably crashes during loadup

[Konstantin Kharlamov]

So, I kind of reproduced the problem… But it doesn't happen reliably.

I reconfigured the build with the exact flags, ran `make clean` and `make`, and
it did fail with a `free(): invalid pointer`.

However, entering the `src/` dir and running `./temacs --batch -l loadup --
temacs=bootstrap` doesn't reproduce crash, it finishes successfully.

Gotta figure out under what exactly conditions crash happens.

bug#61960: 30.0.50; Unexec build reliably crashes during loadup

[Konstantin Kharlamov]

On Sat, 2023-03-04 at 23:05 +0300, Konstantin Kharlamov wrote:
> So, I kind of reproduced the problem… But it doesn't happen reliably.
> 
> I reconfigured the build with the exact flags, ran `make clean` and `make`,
> and
> it did fail with a `free(): invalid pointer`.
> 
> However, entering the `src/` dir and running `./temacs --batch -l loadup --
> temacs=bootstrap` doesn't reproduce crash, it finishes successfully.
> 
> Gotta figure out under what exactly conditions crash happens.

UPD: did find the command that crashes:

	./temacs --__aslr-disabled -batch -l loadup --temacs=dump

I think this command is run internally by `temacs`. I found it by running a bpftrace command alongside the build:

	 sudo bpftrace -e 'tracepoint:syscalls:sys_enter_exec*{ printf("pid: %d, comm: %s, args: ", pid, comm); join(args->argv); }'

bug#61960: 30.0.50; Unexec build reliably crashes during loadup

[Konstantin Kharlamov]

On Sat, 2023-03-04 at 21:45 +0000, Andrea Corallo wrote:
> Konstantin Kharlamov <hi-angel@yandex.ru> writes:
> 
> > Oh, I am sorry, I posted the configuration line from the wrong emacs build.
> > It's
> > supposed to be:
> > 
> > --prefix=/usr --sysconfdir=/etc --libexecdir=/usr/lib --localstatedir=/var -
> > -
> > mandir=/usr/share/man --with-gameuser=:games --with-modules --without-libotf
> > --
> > without-m17n-flt --without-gconf --with-native-compilation=yes --with-
> > xinput2 --
> > with-x-toolkit=gtk3 --without-xaw3d --with-sound=no --with-tree-sitter --
> > with-
> > unexec --without-gpm --without-compress-install 'CFLAGS=-O0 -g3'
> 
> Hi Konstantin,
> 
> maybe the crash you see is not related but native-compilation is not
> supposed to work with unexec builds.
> 
> I think we should really add a configure time error for this.  Eli could
> this change go to emacs-29?

emacs-29 haven't got the BLOCK_ALIGN change, so is unaffected.

I should note though that I'm not the reporter :)

---------------

Regarding my current findings: apparently the `unexec` has always been broken. I built it with sanitizer and found out that the variable `bss_size_growth` when doing the dump has too big size. The only difference between "before" and "after" the BLOCK_ALIGN change is that the difference "after" became quite large. It was just 440 bytes before, and became 31494584 bytes after.

However, when built with sanitizer, sanitizer catches the problem in both cases, so there's that.

bug#61960: 30.0.50; Unexec build reliably crashes during loadup

[Konstantin Kharlamov]

On Sun, 2023-03-05 at 00:56 +0300, Konstantin Kharlamov wrote:
> On Sat, 2023-03-04 at 21:45 +0000, Andrea Corallo wrote:
> > Konstantin Kharlamov <hi-angel@yandex.ru> writes:
> > 
> > > Oh, I am sorry, I posted the configuration line from the wrong emacs
> > > build.
> > > It's
> > > supposed to be:
> > > 
> > > --prefix=/usr --sysconfdir=/etc --libexecdir=/usr/lib --localstatedir=/var
> > > -
> > > -
> > > mandir=/usr/share/man --with-gameuser=:games --with-modules --without-
> > > libotf
> > > --
> > > without-m17n-flt --without-gconf --with-native-compilation=yes --with-
> > > xinput2 --
> > > with-x-toolkit=gtk3 --without-xaw3d --with-sound=no --with-tree-sitter --
> > > with-
> > > unexec --without-gpm --without-compress-install 'CFLAGS=-O0 -g3'
> > 
> > Hi Konstantin,
> > 
> > maybe the crash you see is not related but native-compilation is not
> > supposed to work with unexec builds.
> > 
> > I think we should really add a configure time error for this.  Eli could
> > this change go to emacs-29?
> 
> emacs-29 haven't got the BLOCK_ALIGN change, so is unaffected.

Ah, sorry, I failed to parse your text correctly, because I'm in context of the
debugging session :) Yeah, if native compilation isn't supposed to work with
unexec(), it might be a good idea to disable that, sure.

> I should note though that I'm not the reporter :)
> 
> ---------------
> 
> Regarding my current findings: apparently the `unexec` has always been broken.
> I built it with sanitizer and found out that the variable `bss_size_growth`
> when doing the dump has too big size. The only difference between "before" and
> "after" the BLOCK_ALIGN change is that the difference "after" became quite
> large. It was just 440 bytes before, and became 31494584 bytes after.
> 
> However, when built with sanitizer, sanitizer catches the problem in both
> cases, so there's that.

bug#61960: 30.0.50; Unexec build reliably crashes during loadup

[Konstantin Kharlamov]

On Sun, 2023-03-05 at 01:00 +0300, Konstantin Kharlamov wrote:
> On Sun, 2023-03-05 at 00:56 +0300, Konstantin Kharlamov wrote:
> > On Sat, 2023-03-04 at 21:45 +0000, Andrea Corallo wrote:
> > > Konstantin Kharlamov <hi-angel@yandex.ru> writes:
> > > 
> > > > Oh, I am sorry, I posted the configuration line from the wrong emacs
> > > > build.
> > > > It's
> > > > supposed to be:
> > > > 
> > > > --prefix=/usr --sysconfdir=/etc --libexecdir=/usr/lib --
> > > > localstatedir=/var
> > > > -
> > > > -
> > > > mandir=/usr/share/man --with-gameuser=:games --with-modules --without-
> > > > libotf
> > > > --
> > > > without-m17n-flt --without-gconf --with-native-compilation=yes --with-
> > > > xinput2 --
> > > > with-x-toolkit=gtk3 --without-xaw3d --with-sound=no --with-tree-sitter -
> > > > -
> > > > with-
> > > > unexec --without-gpm --without-compress-install 'CFLAGS=-O0 -g3'
> > > 
> > > Hi Konstantin,
> > > 
> > > maybe the crash you see is not related but native-compilation is not
> > > supposed to work with unexec builds.
> > > 
> > > I think we should really add a configure time error for this.  Eli could
> > > this change go to emacs-29?
> > 
> > emacs-29 haven't got the BLOCK_ALIGN change, so is unaffected.
> 
> Ah, sorry, I failed to parse your text correctly, because I'm in context of
> the
> debugging session :) Yeah, if native compilation isn't supposed to work with
> unexec(), it might be a good idea to disable that, sure.

Btw, that makes me wonder how important is that to fix the unexec build at all, given it will be off when native compilation is on. Native compilation makes code faster so supposed to be the future. So presumably people will always be running with enabled, thus the unexec() path would be unused.

bug#61960: 30.0.50; Unexec build reliably crashes during loadup

[Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Konstantin Kharlamov <hi-angel@yandex.ru> writes:

> Btw, that makes me wonder how important is that to fix the unexec
> build at all, given it will be off when native compilation is
> on. Native compilation makes code faster so supposed to be the
> future. So presumably people will always be running with enabled, thus
> the unexec() path would be unused.

I use the unexec build.

bug#61960: 30.0.50; Unexec build reliably crashes during loadup

[Eli Zaretskii]

> From: Konstantin Kharlamov <hi-angel@yandex.ru>
> Date: Sat, 04 Mar 2023 22:50:12 +0300
> 
> So, just to add some points: apparently it isn't so easy to reproduce. I built Emacs with unexec without first looking at the `./configure` line in the report (looking at the report I apparently lack the `with-dumping=unexec`), and removed the workaround to not have BLOCK_SIZE=2¹⁵ if HAVE_UNEXEC. (worth noting probably that I first did the build, then remembered I had to remove the work around installed on master branch, then re-built emacs without the workaround).
> 
> Running `emacs` as well as running the `temacs` command ain't shows no crashes.
> 
> My configuration was: --prefix=/usr --sysconfdir=/etc --libexecdir=/usr/lib --localstatedir=/var --mandir=/usr/share/man --with-gameuser=:games --with-modules --without-libotf --without-m17n-flt --without-gconf --enable-link-time-optimization --with-native-compilation=yes --with-xinput2 --with-x-toolkit=gtk3 --without-xaw3d --with-sound=no --with-tree-sitter --without-gpm --without-compress-install '--program-transform-name=s/\\([ec]tags\\)/\\1.emacs/' 'CFLAGS=-flto=2 -march=native -O3 -pipe -fno-stack-protector -fweb -fmerge-all-constants -fno-plt -fcommon' 'LDFLAGS=-flto=2 -O3 -march=native -fweb -fmerge-all-constants -floop-nest-optimize -Wl,--sort-common,-z,relro -fno-plt -fcommon'
> 
> I will try to reconfigure build with the flags Eli reports. I seems to have lacked `with-dumping=unexec` option, but I'll try running `configure` only with the flags mentioned, just for the safe case.

My reproduction is with all the *.elc files removed:

  $ find ./lisp -name '*.elc' -delete
  $ make -j4

The specific versions of the compiler, glibc, and the Linux kernel I
have there could also be relevant, although I'm not sure.

bug#61960: 30.0.50; Unexec build reliably crashes during loadup

[Eli Zaretskii]

> From: Konstantin Kharlamov <hi-angel@yandex.ru>
> Date: Sat, 04 Mar 2023 23:05:23 +0300
> 
> So, I kind of reproduced the problem… But it doesn't happen reliably.
> 
> I reconfigured the build with the exact flags, ran `make clean` and `make`, and
> it did fail with a `free(): invalid pointer`.
> 
> However, entering the `src/` dir and running `./temacs --batch -l loadup --
> temacs=bootstrap` doesn't reproduce crash, it finishes successfully.

Remove all the *.elc files and try again.

bug#61960: 30.0.50; Unexec build reliably crashes during loadup

[Eli Zaretskii]

> Cc: 61960@debbugs.gnu.org
> From: Konstantin Kharlamov <hi-angel@yandex.ru>
> Date: Sun, 05 Mar 2023 01:08:31 +0300
> 
> Btw, that makes me wonder how important is that to fix the unexec build at all, given it will be off when native compilation is on. Native compilation makes code faster so supposed to be the future. So presumably people will always be running with enabled, thus the unexec() path would be unused.

We decided not to drop the unexec support just yet.  So we'd like to
keep it working for now.

bug#61960: 30.0.50; Unexec build reliably crashes during loadup

[Eli Zaretskii]

> From: Andrea Corallo <akrl@sdf.org>
> Cc: 61960@debbugs.gnu.org, Konstantin Kharlamov <hi-angel@yandex.ru>
> Date: Mon, 06 Mar 2023 17:12:55 +0000
> 
> > debugging session :) Yeah, if native compilation isn't supposed to work with
> > unexec(), it might be a good idea to disable that, sure.
> 
> Eli related to this, do you think is better to install the attached on
> 29 or master?

Don't we already have an equivalent test?

  if test "${with_native_compilation}" != "no"; then
      if test "${HAVE_PDUMPER}" = no; then
	 AC_MSG_ERROR(['--with-native-compilation' requires '--with-dumping=pdumper'])
      fi

bug#61960: 30.0.50; Unexec build reliably crashes during loadup

[Andrea Corallo]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Andrea Corallo <akrl@sdf.org>
>> Cc: 61960@debbugs.gnu.org, Konstantin Kharlamov <hi-angel@yandex.ru>
>> Date: Mon, 06 Mar 2023 17:12:55 +0000
>> 
>> > debugging session :) Yeah, if native compilation isn't supposed to work with
>> > unexec(), it might be a good idea to disable that, sure.
>> 
>> Eli related to this, do you think is better to install the attached on
>> 29 or master?
>
> Don't we already have an equivalent test?
>
>   if test "${with_native_compilation}" != "no"; then
>       if test "${HAVE_PDUMPER}" = no; then
> 	 AC_MSG_ERROR(['--with-native-compilation' requires '--with-dumping=pdumper'])
>       fi

So IIUC we can compile emacs with both unexec and pdumper support, they
are not mutually exclusive, and we can specify which one to use for the
first dump with --with-dumping.

So yeah I think we have to prevent native compilation to be compiled
with unexec support, even if it's not the way Emacs is dumped the first
time.

  Andrea

bug#61960: 30.0.50; Unexec build reliably crashes during loadup

[Eli Zaretskii]

> From: Andrea Corallo <akrl@sdf.org>
> Cc: 61960@debbugs.gnu.org, hi-angel@yandex.ru
> Date: Tue, 07 Mar 2023 14:59:24 +0000
> 
> >   if test "${with_native_compilation}" != "no"; then
> >       if test "${HAVE_PDUMPER}" = no; then
> > 	 AC_MSG_ERROR(['--with-native-compilation' requires '--with-dumping=pdumper'])
> >       fi
> 
> So IIUC we can compile emacs with both unexec and pdumper support, they
> are not mutually exclusive, and we can specify which one to use for the
> first dump with --with-dumping.
> 
> So yeah I think we have to prevent native compilation to be compiled
> with unexec support, even if it's not the way Emacs is dumped the first
> time.

OK, then a simple change to the above condition (and maybe a slight
change in the message wording as well) should achieve that, right?

bug#61960: 30.0.50; Unexec build reliably crashes during loadup

[Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Andrea Corallo <akrl@sdf.org>
>> Cc: 61960@debbugs.gnu.org, hi-angel@yandex.ru
>> Date: Tue, 07 Mar 2023 14:59:24 +0000
>> 
>> >   if test "${with_native_compilation}" != "no"; then
>> >       if test "${HAVE_PDUMPER}" = no; then
>> > 	 AC_MSG_ERROR(['--with-native-compilation' requires '--with-dumping=pdumper'])
>> >       fi
>> 
>> So IIUC we can compile emacs with both unexec and pdumper support, they
>> are not mutually exclusive, and we can specify which one to use for the
>> first dump with --with-dumping.
>> 
>> So yeah I think we have to prevent native compilation to be compiled
>> with unexec support, even if it's not the way Emacs is dumped the first
>> time.
>
> OK, then a simple change to the above condition (and maybe a slight
> change in the message wording as well) should achieve that, right?

Emacs can't be built with both unexec and pdumper dumping, and configure
doesn't let you do that.  So what we have is fine.

bug#61960: 30.0.50; Unexec build reliably crashes during loadup

[Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Andrea Corallo <akrl@sdf.org> writes:

> Po Lu <luangruo@yahoo.com> writes:
>
>> Eli Zaretskii <eliz@gnu.org> writes:
>>
>>>> From: Andrea Corallo <akrl@sdf.org>
>>>> Cc: 61960@debbugs.gnu.org, hi-angel@yandex.ru
>>>> Date: Tue, 07 Mar 2023 14:59:24 +0000
>>>> 
>>>> >   if test "${with_native_compilation}" != "no"; then
>>>> >       if test "${HAVE_PDUMPER}" = no; then
>>>> > 	 AC_MSG_ERROR(['--with-native-compilation' requires '--with-dumping=pdumper'])
>>>> >       fi
>>>> 
>>>> So IIUC we can compile emacs with both unexec and pdumper support, they
>>>> are not mutually exclusive, and we can specify which one to use for the
>>>> first dump with --with-dumping.
>>>> 
>>>> So yeah I think we have to prevent native compilation to be compiled
>>>> with unexec support, even if it's not the way Emacs is dumped the first
>>>> time.
>>>
>>> OK, then a simple change to the above condition (and maybe a slight
>>> change in the message wording as well) should achieve that, right?
>>
>> Emacs can't be built with both unexec and pdumper dumping, and configure
>> doesn't let you do that.  So what we have is fine.
>
> On emacs 29
>
> configure --without-x --with-native-compilation --with-unexec=yes --with-pdumper=yes
>
> does succeed so I don't think it is fine.

What is the resulting config.h?  The quality of configure's error
reporting has gone down in the past several years.  --with-unexec is
silently ignored if you specify --with-pdumper.

bug#61960: 30.0.50; Unexec build reliably crashes during loadup

[Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Andrea Corallo <akrl@sdf.org> writes:

>  /* Define to build with portable dumper support */                                                                                                                   
>  #define HAVE_PDUMPER 1
>
> [...]
>
>  /* Define if Emacs supports unexec. */                                                                                                                               
>  #define HAVE_UNEXEC 1 

And this Emacs compiles and works?
That's astonishing.

bug#61960: 30.0.50; Unexec build reliably crashes during loadup

[Eli Zaretskii]

> From: Po Lu <luangruo@yahoo.com>
> Cc: Eli Zaretskii <eliz@gnu.org>,  61960@debbugs.gnu.org,  hi-angel@yandex.ru
> Date: Wed, 15 Mar 2023 21:56:01 +0800
> 
> Andrea Corallo <akrl@sdf.org> writes:
> 
> >  /* Define to build with portable dumper support */                                                                                                                   
> >  #define HAVE_PDUMPER 1
> >
> > [...]
> >
> >  /* Define if Emacs supports unexec. */                                                                                                                               
> >  #define HAVE_UNEXEC 1 
> 
> And this Emacs compiles and works?
> That's astonishing.

Why astonishing?  AFAIR, it was supposed to work, so unless it
bit-rotted, it should still build and work.

I do agree that the use case for such a configuration is not very
strong.

bug#61960: 30.0.50; Unexec build reliably crashes during loadup

[Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Eli Zaretskii <eliz@gnu.org> writes:

> Why astonishing?  AFAIR, it was supposed to work, so unless it
> bit-rotted, it should still build and work.

For example: Emacs with pdumper is supposed to be able to write into
objects in pure space.  But that will crash an unexec build without the
necessary protections with a write into program text, and AFAIK those
protections are disabled if HAVE_PDUMPER.

bug#61960: 30.0.50; Unexec build reliably crashes during loadup

[Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Andrea Corallo <akrl@sdf.org> writes:

> Yes, why it should not?  I explained what is my understaing of how it
> works in one of my first relpies to this thread.
>
> You wrote
>
>> Emacs can't be built with both unexec and pdumper dumping, and configure
>> doesn't let you do that.  So what we have is fine.
>
> And
>
>> The quality of configure's error
>> reporting has gone down in the past several years.  --with-unexec is
>> silently ignored if you specify --with-pdumper.
>
> But you still have to answer my question: where do you read that?

By working with both kinds of dumping while working on the garbage
collector last year, and then the MS-DOS port earlier.  I didn't
hesitate to assume:

#ifdef HAVE_UNEXEC

#else

#endif /* HAVE_PDUMPER */

My mistake, sorry.

BTW, what I said about `configure' still stands.  Count the number of
AC_ARG_WITHs that don't print errors if the package they are supposed to
enable is not present.

> PS please quote my complete message answering, debbugs.gnu.org does not
> record my mails.
>
> Thanks
>
>   Andrea

bug#61960: 30.0.50; Unexec build reliably crashes during loadup

[Eli Zaretskii]

> From: Po Lu <luangruo@yahoo.com>
> Cc: akrl@sdf.org,  61960@debbugs.gnu.org,  hi-angel@yandex.ru
> Date: Thu, 16 Mar 2023 08:30:00 +0800
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > Why astonishing?  AFAIR, it was supposed to work, so unless it
> > bit-rotted, it should still build and work.
> 
> For example: Emacs with pdumper is supposed to be able to write into
> objects in pure space.  But that will crash an unexec build without the
> necessary protections with a write into program text, and AFAIK those
> protections are disabled if HAVE_PDUMPER.

They are disabled, but no sane Lisp should write into pure space,
ever.

And it isn't really correct that they are disabled: the recent
discussions about changing names of primitives clearly shows that at
least some areas in the pure space are write-protected even in pdumper
builds.  At least that's what I see on my system.

Anyway, I think you are mistaken in how you look at this (somewhat
weird) configuration: all it was supposed to allow is decide how to
dump Emacs at run time rather than at configure time.  That's all.

bug#61960: 30.0.50; Unexec build reliably crashes during loadup

[Eli Zaretskii]

> From: Po Lu <luangruo@yahoo.com>
> Cc: Eli Zaretskii <eliz@gnu.org>,  61960@debbugs.gnu.org,  hi-angel@yandex.ru
> Date: Thu, 16 Mar 2023 08:33:17 +0800
> 
> > But you still have to answer my question: where do you read that?
> 
> By working with both kinds of dumping while working on the garbage
> collector last year, and then the MS-DOS port earlier.  I didn't
> hesitate to assume:
> 
> #ifdef HAVE_UNEXEC
> 
> #else
> 
> #endif /* HAVE_PDUMPER */
> 
> My mistake, sorry.

Yes, that is a mistake.  These two are not mutually exclusive.

bug#61960: 30.0.50; Unexec build reliably crashes during loadup

[Konstantin Kharlamov]

I've found a diff that fixes the build, but whether it's okay is worth discussion:

    diff --git a/src/gmalloc.c b/src/gmalloc.c
    index e655d69f660..f49bb01e08b 100644
    --- a/src/gmalloc.c
    +++ b/src/gmalloc.c
    @@ -1704,7 +1704,7 @@ allocated_via_gmalloc (void *ptr)
         return false;
       size_t block = BLOCK (ptr);
       size_t blockmax = _heaplimit - 1;
    -  return block <= blockmax && _heapinfo[block].busy.type != 0;
    +  return block <= blockmax;
     }

     /* See the comments near the beginning of this file for explanations

Here's what happens: Emacs uses internal stack-based allocator (apparently allocating
with sbrk(), but I'm not sure) along with the system allocator. Whenever a memory is
allocated from the internal allocator, you can't call `free()` on it.

When Emacs wants to free memory, it calls `hybrid_free_1()`, which internally
determines whether the `ptr` passed belongs to system heap or to Emacs
stack. Determining in turn is done by `allocated_via_gmalloc()`.

Emacs also keeps the lowest and highest boundary of this stack in variables
`_heapbase` and `_heaplimit` accordingly (except the latter is measured in
"blocks"). The code in diff `block <= blockmax` simply makes sure that the `ptr`
passed is within the stack-allocated memory, which implies it can't be deallocated
with `free()`

There's a question though of the right-hand side that I remove, the
`_heapinfo[block].busy.type != 0;`. Apparently the `type` should keep some memory
info, and apparently there's a bug somewhere that screws it up. It is a bug worth
fixing, although for some reason `rr replay` doesn't work for me with `temacs`
(probably a bug in rr), and without reverse-execution tracking that down would be
very hard.

But I would argue that the right-hand side check has no value in this function,
because to determine the source of allocation it's enough to just check whether `ptr`
is in _heapbase .. _heaplimit range (barring the fact they're different units).

bug#61960: 30.0.50; Unexec build reliably crashes during loadup

[Konstantin Kharlamov]

On Sun, 2023-07-02 at 04:50 +0300, Konstantin Kharlamov wrote:
> I've found a diff that fixes the build, but whether it's okay is worth
> discussion:

If by any chance the discussion is in favour of applying the change, tell me and
I will make a proper patch with explanation and with the removal of the `ifdef
HAVE_UNEXEC`.

bug#61960: 30.0.50; Unexec build reliably crashes during loadup

[Eli Zaretskii]

> From: Konstantin Kharlamov <hi-angel@yandex.ru>
> Date: Sun, 02 Jul 2023 04:50:26 +0300
> 
> I've found a diff that fixes the build, but whether it's okay is worth discussion:
> 
>     diff --git a/src/gmalloc.c b/src/gmalloc.c
>     index e655d69f660..f49bb01e08b 100644
>     --- a/src/gmalloc.c
>     +++ b/src/gmalloc.c
>     @@ -1704,7 +1704,7 @@ allocated_via_gmalloc (void *ptr)
>          return false;
>        size_t block = BLOCK (ptr);
>        size_t blockmax = _heaplimit - 1;
>     -  return block <= blockmax && _heapinfo[block].busy.type != 0;
>     +  return block <= blockmax;
>      }
> 
>      /* See the comments near the beginning of this file for explanations
> 
> Here's what happens: Emacs uses internal stack-based allocator (apparently allocating
> with sbrk(), but I'm not sure) along with the system allocator. Whenever a memory is
> allocated from the internal allocator, you can't call `free()` on it.
> 
> When Emacs wants to free memory, it calls `hybrid_free_1()`, which internally
> determines whether the `ptr` passed belongs to system heap or to Emacs
> stack. Determining in turn is done by `allocated_via_gmalloc()`.
> 
> Emacs also keeps the lowest and highest boundary of this stack in variables
> `_heapbase` and `_heaplimit` accordingly (except the latter is measured in
> "blocks"). The code in diff `block <= blockmax` simply makes sure that the `ptr`
> passed is within the stack-allocated memory, which implies it can't be deallocated
> with `free()`
> 
> There's a question though of the right-hand side that I remove, the
> `_heapinfo[block].busy.type != 0;`. Apparently the `type` should keep some memory
> info, and apparently there's a bug somewhere that screws it up. It is a bug worth
> fixing, although for some reason `rr replay` doesn't work for me with `temacs`
> (probably a bug in rr), and without reverse-execution tracking that down would be
> very hard.
> 
> But I would argue that the right-hand side check has no value in this function,
> because to determine the source of allocation it's enough to just check whether `ptr`
> is in _heapbase .. _heaplimit range (barring the fact they're different units).

Thanks, but how do you explain that this code works as-is when the
BLOCK_ALIGN change is not used?

bug#61960: 30.0.50; Unexec build reliably crashes during loadup

[Konstantin Kharlamov]

On Sun, 2023-07-02 at 08:52 +0300, Eli Zaretskii wrote:
> > From: Konstantin Kharlamov <hi-angel@yandex.ru>
> > Date: Sun, 02 Jul 2023 04:50:26 +0300
> > 
> > I've found a diff that fixes the build, but whether it's okay is worth
> > discussion:
> > 
> >     diff --git a/src/gmalloc.c b/src/gmalloc.c
> >     index e655d69f660..f49bb01e08b 100644
> >     --- a/src/gmalloc.c
> >     +++ b/src/gmalloc.c
> >     @@ -1704,7 +1704,7 @@ allocated_via_gmalloc (void *ptr)
> >          return false;
> >        size_t block = BLOCK (ptr);
> >        size_t blockmax = _heaplimit - 1;
> >     -  return block <= blockmax && _heapinfo[block].busy.type != 0;
> >     +  return block <= blockmax;
> >      }
> > 
> >      /* See the comments near the beginning of this file for explanations
> > 
> > Here's what happens: Emacs uses internal stack-based allocator (apparently
> > allocating
> > with sbrk(), but I'm not sure) along with the system allocator. Whenever a
> > memory is
> > allocated from the internal allocator, you can't call `free()` on it.
> > 
> > When Emacs wants to free memory, it calls `hybrid_free_1()`, which
> > internally
> > determines whether the `ptr` passed belongs to system heap or to Emacs
> > stack. Determining in turn is done by `allocated_via_gmalloc()`.
> > 
> > Emacs also keeps the lowest and highest boundary of this stack in variables
> > `_heapbase` and `_heaplimit` accordingly (except the latter is measured in
> > "blocks"). The code in diff `block <= blockmax` simply makes sure that the
> > `ptr`
> > passed is within the stack-allocated memory, which implies it can't be
> > deallocated
> > with `free()`
> > 
> > There's a question though of the right-hand side that I remove, the
> > `_heapinfo[block].busy.type != 0;`. Apparently the `type` should keep some
> > memory
> > info, and apparently there's a bug somewhere that screws it up. It is a bug
> > worth
> > fixing, although for some reason `rr replay` doesn't work for me with
> > `temacs`
> > (probably a bug in rr), and without reverse-execution tracking that down
> > would be
> > very hard.
> > 
> > But I would argue that the right-hand side check has no value in this
> > function,
> > because to determine the source of allocation it's enough to just check
> > whether `ptr`
> > is in _heapbase .. _heaplimit range (barring the fact they're different
> > units).
> 
> Thanks, but how do you explain that this code works as-is when the
> BLOCK_ALIGN change is not used?

I don't know exactly. But I've read calculations in alloc.c where BLOCK_ALIGN is
used (directly and indirectly) and the code there is very convoluted. Apparently
an offset somewhere gets calculated incorrectly, so some
`_heapinfo[block].busy.type` fields end up having 0 despite being allocated with
malloc(). As I mentioned it is worth investigating, but without reverse-
execution (as `rr` for some reason doesn't work with `temacs` in this case) it
will be hard to pinpoint.

I am planning to report the `rr` problem to them, so hopefully it will be
possible to find the real culprit in the future.

bug#61960: 30.0.50; Unexec build reliably crashes during loadup

[Konstantin Kharlamov]

On Sun, 2023-07-02 at 14:32 +0300, Konstantin Kharlamov wrote:
> Apparently
> an offset somewhere gets calculated incorrectly, so some
> `_heapinfo[block].busy.type` fields end up having 0 despite being allocated
> with malloc().

Sorry, it meant to be "…despite *not* being allocated with malloc"

bug#61960: 30.0.50; Unexec build reliably crashes during loadup

[Konstantin Kharlamov]

On Sun, 2023-07-02 at 14:32 +0300, Konstantin Kharlamov wrote:

> but without reverse-execution (as `rr` for some reason doesn't work with
> `temacs` in this case) it will be hard to pinpoint.
> 
> I am planning to report the `rr` problem to them, so hopefully it will be
> possible to find the real culprit in the future.

UPD: after some research turned out `rr` works well, but what I'm seeing with
`rr replay` stopping at `syscall_traced()` is due to `temacs` executing
`execve`, and gdb by default not following into it. To make it work one can
execute `when` in gdb, and then relaunch `rr replay -g $WHENRESULT`. This
peculiarity is very terribly documented despite devs vaguely referring to that
in various bugreports. I guess I'll have to fix the docs to make sure it's more
clear for future users.

bug#61960: 30.0.50; Unexec build reliably crashes during loadup

[Konstantin Kharlamov]

Okay, so I've spent today a lot of time debugging this problem, and out
of interesting things I found so far the following:

1. Problem seems like some discrepancy between _heapinfo and an abase
whose index points at _heapinfo
2. Given two Emacs executions, one which buggy and one isn't, I found
that "good execution" returns from `aligned_alloc` the same result it
gotten from `_malloc_internal_nolock`, whereas in "bad execution" it's
different.
   The reason for this is that inside `aligned_alloc()` "good
execution" *never* goes into `if (adj != 0)` condition. The function
has 3 places where `malloc` is called (which is not actually a malloc()
but instead a wrapper `gmalloc` eventually calling into
`_malloc_internal_nolock()`), one of which is inside the mentioned
condition. The latter one changes `malloc` result, while 2 others do
not.

In the lieu of that it is possible that this conditional branch simply
was never tested. I decided to check how it works in a usual Emacs
build, and I found out that it doesn't even have `gmalloc.c` source
compiled in 🤷‍♂️

-----------------------

That makes me wonder if keeping this whole customized allocation engine
even makes sense. It is not used in the actual Emacs, only in `temacs`
— but why? Is it to make `temacs` faster? I would imagine in the
"compilation usecase" where `temacs` is used, shaving off a few seconds
is not worth that complexity (not to mention I am not sure how well
this code may compete with specialized allocator projects like
"jemalloc", which also do allocation caching). This code is
incomprehensible. It does funny stuff like redefining system functions,
like `malloc` to its wrappers, so even just reading it is hard. And
I've spent hours watching simultaneously two `temacs` executions, "bad"
and "good" one, recorded with `rr record`, using reverse-execution and
watchpoints and still not sure how close I am to solving the case. 

So, I would be glad to hear what people think about the purpose of this
gmalloc being in the project.

bug#61960: 30.0.50; Unexec build reliably crashes during loadup

[Eli Zaretskii]

> From: Konstantin Kharlamov <Hi-Angel@yandex.ru>
> Cc: 61960@debbugs.gnu.org
> Date: Fri, 21 Jul 2023 19:09:04 +0300
> 
> That makes me wonder if keeping this whole customized allocation engine
> even makes sense. It is not used in the actual Emacs, only in `temacs`
> — but why?

It is used in temacs because otherwise we'd not know how to record
allocated memory in the dumped Emacs.  Doing so requires control on
the allocation details, and we can only do that with code we ourselves
maintain.

You will see that in a build with pdumper gmalloc.c is not compiled at
all.

> So, I would be glad to hear what people think about the purpose of this
> gmalloc being in the project.

It is only needed in the unexec build, AFAIU.