From debbugs-submit-bounces@debbugs.gnu.org Sat Mar 04 09:55:51 2023 Received: (at submit) by debbugs.gnu.org; 4 Mar 2023 14:55:51 +0000 Received: from localhost ([127.0.0.1]:37038 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pYTIa-0002lr-47 for submit@debbugs.gnu.org; Sat, 04 Mar 2023 09:55:50 -0500 Received: from lists.gnu.org ([209.51.188.17]:38952) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pYTIV-0002fg-5i for submit@debbugs.gnu.org; Sat, 04 Mar 2023 09:55:46 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1pYTIU-00030v-Nv for bug-gnu-emacs@gnu.org; Sat, 04 Mar 2023 09:55:42 -0500 Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1pYTIU-0003SE-Fb for bug-gnu-emacs@gnu.org; Sat, 04 Mar 2023 09:55:42 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=MIME-version:Subject:To:From:Date:in-reply-to: references; bh=dzvYgZsAq9xXLzzEnJHhiMM+e9apOmeipfFE2OuZPJ4=; b=nnTHTRA1H/4F96 EsNC5GGQzOcwQ/vwL3sWrEZIweJUi0yGMxN62tIaXXA+OLuOFeCnBEu/qm2seSj63DelWoI1b8OBF ScVnr78pbBBn1VbjujflYmEoxgw+coo0gQmjm9Ki185KYl4wTK+GRMp0oT1MH5leUMu/qe2vY+2GJ xeeekq47U2yOIVMsrpo4RAH8VcTHGdA2YmoOd9p1PYvALLq7ZfAVrsSSHihnmSLSbvLMx41udwFjX icw1nYOx1DfqYh38MePAy9heOQYj7nNcC9u5ndtvHEKVIs9sVJcsUAO+nxPgYoNzCcQaSjepaXEhF lml2423KOL0yR1e9SRFQ==; Received: from [87.69.77.57] (helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1pYTIT-0001Ed-LE for bug-gnu-emacs@gnu.org; Sat, 04 Mar 2023 09:55:42 -0500 Date: Sat, 04 Mar 2023 16:55:29 +0200 Message-Id: <83pm9oa7mm.fsf@gnu.org> From: Eli Zaretskii To: bug-gnu-emacs@gnu.org Subject: 30.0.50; Unexec build reliably crashes during loadup X-Debbugs-Cc: Paul Eggert , Andreas Schwab , Mattias =?utf-8?Q?Engdeg=C3=A5rd?= , Stefan Monnier MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: submit X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) 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 ) at gmalloc.c:1735 #6 0x00000000007f61d1 in hybrid_free (ptr=0x1fc8000 ) at gmalloc.c:1747 #7 0x00000000006b4012 in lisp_align_free (block=0x2040000 ) 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 , handlers=XIL(0x90), hfun=0x60bd35 ) 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 , 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) From debbugs-submit-bounces@debbugs.gnu.org Sat Mar 04 14:50:25 2023 Received: (at 61960) by debbugs.gnu.org; 4 Mar 2023 19:50:25 +0000 Received: from localhost ([127.0.0.1]:37791 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pYXtg-0002ew-Ok for submit@debbugs.gnu.org; Sat, 04 Mar 2023 14:50:25 -0500 Received: from forward103p.mail.yandex.net ([77.88.28.106]:41746) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pYXtd-0002ec-ET for 61960@debbugs.gnu.org; Sat, 04 Mar 2023 14:50:22 -0500 Received: from sas8-838e1e461505.qloud-c.yandex.net (sas8-838e1e461505.qloud-c.yandex.net [IPv6:2a02:6b8:c1b:28d:0:640:838e:1e46]) by forward103p.mail.yandex.net (Yandex) with ESMTP id BDBA05A047D for <61960@debbugs.gnu.org>; Sat, 4 Mar 2023 22:50:13 +0300 (MSK) Received: by sas8-838e1e461505.qloud-c.yandex.net (smtp/Yandex) with ESMTPSA id CoeVU5LbhCg1-wpG4A5xT; Sat, 04 Mar 2023 22:50:13 +0300 X-Yandex-Fwd: 1 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1677959413; bh=n+53gBS9NxnyB+36w/zxJOg9pu3jRZ11Z1M4EKotZlI=; h=Date:To:From:Subject:Message-ID; b=XUPBHfG3MnFhaXV5Ji2/EOhgsmIf3lsU5Vc+djtXyxdnbW7oLBu5UwdMc1+vUnHyw 69aIz0SpNO+TNnxOO4maZeJ5fcBqeSEUXCBCtFisO6gjUXsNh6oTW6Dk9UP6NqI/Y6 I/8tAnjoBFtmPCh6h9APEZVu14LvvW/Yoi7tCtBk= Authentication-Results: sas8-838e1e461505.qloud-c.yandex.net; dkim=pass header.i=@yandex.ru Message-ID: <62049aa9ffcf9f39fd423fb87cd8dc8e0b77f9b8.camel@yandex.ru> Subject: Re: 30.0.50; Unexec build reliably crashes during loadup From: Konstantin Kharlamov To: 61960@debbugs.gnu.org Date: Sat, 04 Mar 2023 22:50:12 +0300 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable User-Agent: Evolution 3.46.4 MIME-Version: 1.0 X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 61960 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) So, just to add some points: apparently it isn't so easy to reproduce. I bu= ilt Emacs with unexec without first looking at the `./configure` line in th= e report (looking at the report I apparently lack the `with-dumping=3Dunexe= c`), and removed the workaround to not have BLOCK_SIZE=3D2=C2=B9=E2=81=B5 i= f HAVE_UNEXEC. (worth noting probably that I first did the build, then reme= mbered 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 cras= hes. My configuration was: --prefix=3D/usr --sysconfdir=3D/etc --libexecdir=3D/u= sr/lib --localstatedir=3D/var --mandir=3D/usr/share/man --with-gameuser=3D:= games --with-modules --without-libotf --without-m17n-flt --without-gconf --= enable-link-time-optimization --with-native-compilation=3Dyes --with-xinput= 2 --with-x-toolkit=3Dgtk3 --without-xaw3d --with-sound=3Dno --with-tree-sit= ter --without-gpm --without-compress-install '--program-transform-name=3Ds/= \\([ec]tags\\)/\\1.emacs/' 'CFLAGS=3D-flto=3D2 -march=3Dnative -O3 -pipe -f= no-stack-protector -fweb -fmerge-all-constants -fno-plt -fcommon' 'LDFLAGS= =3D-flto=3D2 -O3 -march=3Dnative -fweb -fmerge-all-constants -floop-nest-op= timize -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=3Dunexec` option, but I'll try running `configure` on= ly with the flags mentioned, just for the safe case. From debbugs-submit-bounces@debbugs.gnu.org Sat Mar 04 14:51:57 2023 Received: (at 61960) by debbugs.gnu.org; 4 Mar 2023 19:51:57 +0000 Received: from localhost ([127.0.0.1]:37795 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pYXvB-0002hY-6O for submit@debbugs.gnu.org; Sat, 04 Mar 2023 14:51:57 -0500 Received: from forward501c.mail.yandex.net ([178.154.239.209]:51394) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pYXv9-0002hN-Ko for 61960@debbugs.gnu.org; Sat, 04 Mar 2023 14:51:56 -0500 Received: from sas2-8b071049b117.qloud-c.yandex.net (sas2-8b071049b117.qloud-c.yandex.net [IPv6:2a02:6b8:c08:f480:0:640:8b07:1049]) by forward501c.mail.yandex.net (Yandex) with ESMTP id 9A7F25ECAE for <61960@debbugs.gnu.org>; Sat, 4 Mar 2023 22:51:53 +0300 (MSK) Received: by sas2-8b071049b117.qloud-c.yandex.net (smtp/Yandex) with ESMTPSA id qpevXQLbouQ1-QyxN5t5Z; Sat, 04 Mar 2023 22:51:53 +0300 X-Yandex-Fwd: 1 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1677959513; bh=SGFI1N9QRRDuFKaew9f5Wh/HhYIa0ICLEyhKuUqwKus=; h=In-Reply-To:Date:References:To:From:Subject:Message-ID; b=gS9/4J2yL1JzY5lxBnNPnb8TogD+rUuL+lk+ZY1HUE26VuYU3NRjIBLa8r4JHSKpN cbjz1e7NnoYRkYvqWeOaEnbNC6SkSqmLr4EM5xRvvPRG+UVBCM8fk1ss8H81JMIw5v cPUPmi9wI8YujIxGvquBTWje0eup2g13/zuFKE/4= Authentication-Results: sas2-8b071049b117.qloud-c.yandex.net; dkim=pass header.i=@yandex.ru Message-ID: Subject: Re: 30.0.50; Unexec build reliably crashes during loadup From: Konstantin Kharlamov To: 61960@debbugs.gnu.org Date: Sat, 04 Mar 2023 22:51:52 +0300 In-Reply-To: <62049aa9ffcf9f39fd423fb87cd8dc8e0b77f9b8.camel@yandex.ru> References: <62049aa9ffcf9f39fd423fb87cd8dc8e0b77f9b8.camel@yandex.ru> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable User-Agent: Evolution 3.46.4 MIME-Version: 1.0 X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 61960 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Oh, I am sorry, I posted the configuration line from the wrong emacs build.= It's supposed to be: --prefix=3D/usr --sysconfdir=3D/etc --libexecdir=3D/usr/lib --localstatedir= =3D/var -- mandir=3D/usr/share/man --with-gameuser=3D:games --with-modules --without-l= ibotf -- without-m17n-flt --without-gconf --with-native-compilation=3Dyes --with-xin= put2 -- with-x-toolkit=3Dgtk3 --without-xaw3d --with-sound=3Dno --with-tree-sitter = --with- unexec --without-gpm --without-compress-install 'CFLAGS=3D-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=3Dunexe= c`), > and removed the workaround to not have BLOCK_SIZE=3D2=C2=B9=E2=81=B5 if H= AVE_UNEXEC. (worth > noting probably that I first did the build, then remembered I had to remo= ve > the work around installed on master branch, then re-built emacs without t= he > workaround). >=20 > Running `emacs` as well as running the `temacs` command ain't shows no > crashes. >=20 > My configuration was: --prefix=3D/usr --sysconfdir=3D/etc --libexecdir=3D= /usr/lib -- > localstatedir=3D/var --mandir=3D/usr/share/man --with-gameuser=3D:games -= -with- > modules --without-libotf --without-m17n-flt --without-gconf --enable-link= - > time-optimization --with-native-compilation=3Dyes --with-xinput2 --with-x= - > toolkit=3Dgtk3 --without-xaw3d --with-sound=3Dno --with-tree-sitter --wit= hout-gpm > --without-compress-install '--program-transform- > name=3Ds/\\([ec]tags\\)/\\1.emacs/' 'CFLAGS=3D-flto=3D2 -march=3Dnative -= O3 -pipe - > fno-stack-protector -fweb -fmerge-all-constants -fno-plt -fcommon' 'LDFLA= GS=3D- > flto=3D2 -O3 -march=3Dnative -fweb -fmerge-all-constants -floop-nest-opti= mize - > Wl,--sort-common,-z,relro -fno-plt -fcommon' >=20 > I will try to reconfigure build with the flags Eli reports. I seems to ha= ve > lacked `with-dumping=3Dunexec` option, but I'll try running `configure` o= nly > with the flags mentioned, just for the safe case. From debbugs-submit-bounces@debbugs.gnu.org Sat Mar 04 15:05:30 2023 Received: (at 61960) by debbugs.gnu.org; 4 Mar 2023 20:05:30 +0000 Received: from localhost ([127.0.0.1]:37815 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pYY8H-000353-P0 for submit@debbugs.gnu.org; Sat, 04 Mar 2023 15:05:30 -0500 Received: from forward500c.mail.yandex.net ([178.154.239.208]:52924) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pYY8E-00034t-TK for 61960@debbugs.gnu.org; Sat, 04 Mar 2023 15:05:28 -0500 Received: from myt5-18b0513eae63.qloud-c.yandex.net (myt5-18b0513eae63.qloud-c.yandex.net [IPv6:2a02:6b8:c12:571f:0:640:18b0:513e]) by forward500c.mail.yandex.net (Yandex) with ESMTP id 815845E91C for <61960@debbugs.gnu.org>; Sat, 4 Mar 2023 23:05:24 +0300 (MSK) Received: by myt5-18b0513eae63.qloud-c.yandex.net (smtp/Yandex) with ESMTPSA id N5fgOWLchiE1-CKE4VwAG; Sat, 04 Mar 2023 23:05:24 +0300 X-Yandex-Fwd: 1 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1677960324; bh=YJcehxY4gtH3iND/18braULqk4WvYx/wU3wClG6lnw4=; h=In-Reply-To:Date:References:To:From:Subject:Message-ID; b=R5/nXv6N6ur9dv8sMe1A4wFbOgltVa1eOWVXibisK678k8/brBRwElsLQ18mzXgvM ABcMxAjkgYlccm01pgyD8aGC0YPHjknbAWGv3XPCvjiHiF7GcKeXB2Mw7nbRz1eTpx RgFo3l7ji8HB0n1ElEJq+81gXkxL/J50JD/OKoIo= Authentication-Results: myt5-18b0513eae63.qloud-c.yandex.net; dkim=pass header.i=@yandex.ru Message-ID: Subject: Re: 30.0.50; Unexec build reliably crashes during loadup From: Konstantin Kharlamov To: 61960@debbugs.gnu.org Date: Sat, 04 Mar 2023 23:05:23 +0300 In-Reply-To: References: <62049aa9ffcf9f39fd423fb87cd8dc8e0b77f9b8.camel@yandex.ru> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable User-Agent: Evolution 3.46.4 MIME-Version: 1.0 X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 61960 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) So, I kind of reproduced the problem=E2=80=A6 But it doesn't happen reliabl= y. 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=3Dbootstrap` doesn't reproduce crash, it finishes successfully. Gotta figure out under what exactly conditions crash happens. From debbugs-submit-bounces@debbugs.gnu.org Sat Mar 04 15:26:37 2023 Received: (at 61960) by debbugs.gnu.org; 4 Mar 2023 20:26:37 +0000 Received: from localhost ([127.0.0.1]:37877 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pYYSj-0003gs-BS for submit@debbugs.gnu.org; Sat, 04 Mar 2023 15:26:37 -0500 Received: from forward502a.mail.yandex.net ([178.154.239.82]:55900) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pYYSg-0003gi-Kp for 61960@debbugs.gnu.org; Sat, 04 Mar 2023 15:26:36 -0500 Received: from vla5-ea54f853bdd2.qloud-c.yandex.net (vla5-ea54f853bdd2.qloud-c.yandex.net [IPv6:2a02:6b8:c18:3e9f:0:640:ea54:f853]) by forward502a.mail.yandex.net (Yandex) with ESMTP id 5ACFB5E9D8 for <61960@debbugs.gnu.org>; Sat, 4 Mar 2023 23:26:32 +0300 (MSK) Received: by vla5-ea54f853bdd2.qloud-c.yandex.net (smtp/Yandex) with ESMTPSA id VQfxVOLblGk1-gyDNFSpz; Sat, 04 Mar 2023 23:26:32 +0300 X-Yandex-Fwd: 1 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1677961592; bh=GKEZYhyX/y+DW/ArFJwJB0hI87/EEefDzHehhm5mD/E=; h=In-Reply-To:Date:References:To:From:Subject:Message-ID; b=QgbH0yMa8L4a0c6gpzRUgch/MLwaWW1q9ZoYjrI0STY0+iKpw8y251JLT99wJW7nk DTSoE1cSuRjpsP+57Joq/PEXnvk5BD47BsHjqU/Zz2z+L8OhRYIeQwXcFdaB9JUxSH a/iy3kx+2cNn5bwn3XHJ1+gRtp4gH4LOewZl46eo= Authentication-Results: vla5-ea54f853bdd2.qloud-c.yandex.net; dkim=pass header.i=@yandex.ru Message-ID: <16c908b437880c83d5d07cebfbe817e0dca12510.camel@yandex.ru> Subject: Re: 30.0.50; Unexec build reliably crashes during loadup From: Konstantin Kharlamov To: 61960@debbugs.gnu.org Date: Sat, 04 Mar 2023 23:26:31 +0300 In-Reply-To: References: <62049aa9ffcf9f39fd423fb87cd8dc8e0b77f9b8.camel@yandex.ru> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable User-Agent: Evolution 3.46.4 MIME-Version: 1.0 X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 61960 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) On Sat, 2023-03-04 at 23:05 +0300, Konstantin Kharlamov wrote: > So, I kind of reproduced the problem=E2=80=A6 But it doesn't happen relia= bly. >=20 > I reconfigured the build with the exact flags, ran `make clean` and `make= `, > and > it did fail with a `free(): invalid pointer`. >=20 > However, entering the `src/` dir and running `./temacs --batch -l loadup = -- > temacs=3Dbootstrap` doesn't reproduce crash, it finishes successfully. >=20 > Gotta figure out under what exactly conditions crash happens. UPD: did find the command that crashes: ./temacs --__aslr-disabled -batch -l loadup --temacs=3Ddump 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, c= omm: %s, args: ", pid, comm); join(args->argv); }' From debbugs-submit-bounces@debbugs.gnu.org Sat Mar 04 16:56:27 2023 Received: (at 61960) by debbugs.gnu.org; 4 Mar 2023 21:56:27 +0000 Received: from localhost ([127.0.0.1]:37934 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pYZre-0006Gt-QU for submit@debbugs.gnu.org; Sat, 04 Mar 2023 16:56:27 -0500 Received: from forward502c.mail.yandex.net ([178.154.239.210]:39672) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pYZrb-0006Gh-QJ for 61960@debbugs.gnu.org; Sat, 04 Mar 2023 16:56:25 -0500 Received: from myt6-fe378243d6ea.qloud-c.yandex.net (myt6-fe378243d6ea.qloud-c.yandex.net [IPv6:2a02:6b8:c12:488f:0:640:fe37:8243]) by forward502c.mail.yandex.net (Yandex) with ESMTP id E45C15E966; Sun, 5 Mar 2023 00:56:19 +0300 (MSK) Received: by myt6-fe378243d6ea.qloud-c.yandex.net (smtp/Yandex) with ESMTPSA id IugFiGMb8Gk1-8wrAlW2t; Sun, 05 Mar 2023 00:56:19 +0300 X-Yandex-Fwd: 1 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1677966979; bh=ebV4PRsunhoTSBc9gNYWns3eRLbSp48Ns7Yd2rHV5rM=; h=References:Date:In-Reply-To:Cc:To:From:Subject:Message-ID; b=Y/H565wqpyQLyTQGUy3RlgaPK2vGTdXdDdU32brXytTwsR1vckesDff/H912xrhcj 9XaX5Je+UNicXsFC6gvJi33oVMxd9mC32PUCziXISHXx++NQfLPdRToBtCHW3ovgcw h3LH3JoN2NAQerZ0rcwQnOdM+qPOUuZo6EJZaCno= Authentication-Results: myt6-fe378243d6ea.qloud-c.yandex.net; dkim=pass header.i=@yandex.ru Message-ID: <7a6e37ed07a49a85a51c8a3a40cadc2b752a38ef.camel@yandex.ru> Subject: Re: bug#61960: 30.0.50; Unexec build reliably crashes during loadup From: Konstantin Kharlamov To: Andrea Corallo Date: Sun, 05 Mar 2023 00:56:18 +0300 In-Reply-To: References: <62049aa9ffcf9f39fd423fb87cd8dc8e0b77f9b8.camel@yandex.ru> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable User-Agent: Evolution 3.46.4 MIME-Version: 1.0 X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 61960 Cc: 61960@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) On Sat, 2023-03-04 at 21:45 +0000, Andrea Corallo wrote: > Konstantin Kharlamov writes: >=20 > > Oh, I am sorry, I posted the configuration line from the wrong emacs bu= ild. > > It's > > supposed to be: > >=20 > > --prefix=3D/usr --sysconfdir=3D/etc --libexecdir=3D/usr/lib --localstat= edir=3D/var - > > - > > mandir=3D/usr/share/man --with-gameuser=3D:games --with-modules --witho= ut-libotf > > -- > > without-m17n-flt --without-gconf --with-native-compilation=3Dyes --with= - > > xinput2 -- > > with-x-toolkit=3Dgtk3 --without-xaw3d --with-sound=3Dno --with-tree-sit= ter -- > > with- > > unexec --without-gpm --without-compress-install 'CFLAGS=3D-O0 -g3' >=20 > Hi Konstantin, >=20 > maybe the crash you see is not related but native-compilation is not > supposed to work with unexec builds. >=20 > I think we should really add a configure time error for this.=C2=A0 Eli c= ould > 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 brok= en. I built it with sanitizer and found out that the variable `bss_size_gro= wth` when doing the dump has too big size. The only difference between "bef= ore" and "after" the BLOCK_ALIGN change is that the difference "after" beca= me quite large. It was just 440 bytes before, and became 31494584 bytes aft= er. However, when built with sanitizer, sanitizer catches the problem in both c= ases, so there's that. From debbugs-submit-bounces@debbugs.gnu.org Sat Mar 04 17:00:48 2023 Received: (at 61960) by debbugs.gnu.org; 4 Mar 2023 22:00:49 +0000 Received: from localhost ([127.0.0.1]:37938 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pYZvs-0006PR-HJ for submit@debbugs.gnu.org; Sat, 04 Mar 2023 17:00:48 -0500 Received: from forward500b.mail.yandex.net ([178.154.239.144]:47870) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pYZvq-0006PG-AJ for 61960@debbugs.gnu.org; Sat, 04 Mar 2023 17:00:47 -0500 Received: from myt6-265321db07ea.qloud-c.yandex.net (myt6-265321db07ea.qloud-c.yandex.net [IPv6:2a02:6b8:c12:2626:0:640:2653:21db]) by forward500b.mail.yandex.net (Yandex) with ESMTP id AB3E65ECB8; Sun, 5 Mar 2023 01:00:43 +0300 (MSK) Received: by myt6-265321db07ea.qloud-c.yandex.net (smtp/Yandex) with ESMTPSA id g0hmMEMdaKo1-xhW7g7pp; Sun, 05 Mar 2023 01:00:43 +0300 X-Yandex-Fwd: 1 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1677967243; bh=QoZYP7LaKchzHD2Udc5GJobrS2R93qqfKlOYIHguATc=; h=References:Date:In-Reply-To:Cc:To:From:Subject:Message-ID; b=DyoQwmeaCivUP4lVCU7emPZPb3MxbOnDLkq6lqWmw8/IZG6K/SRo+hjkxzIzxX9PQ tZJmtj+UwThWqacmhW/GeTesUp2eH71Yy4cQ5rkYmCAQXtxo+4rKWpfrzNwj6umjqO TYNVOYe0wLqQmbYYPWYTslwhpMasekl6z2F7WfSg= Authentication-Results: myt6-265321db07ea.qloud-c.yandex.net; dkim=pass header.i=@yandex.ru Message-ID: Subject: Re: bug#61960: 30.0.50; Unexec build reliably crashes during loadup From: Konstantin Kharlamov To: Andrea Corallo Date: Sun, 05 Mar 2023 01:00:42 +0300 In-Reply-To: <7a6e37ed07a49a85a51c8a3a40cadc2b752a38ef.camel@yandex.ru> References: <62049aa9ffcf9f39fd423fb87cd8dc8e0b77f9b8.camel@yandex.ru> <7a6e37ed07a49a85a51c8a3a40cadc2b752a38ef.camel@yandex.ru> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable User-Agent: Evolution 3.46.4 MIME-Version: 1.0 X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 61960 Cc: 61960@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) 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 writes: > >=20 > > > Oh, I am sorry, I posted the configuration line from the wrong emacs > > > build. > > > It's > > > supposed to be: > > >=20 > > > --prefix=3D/usr --sysconfdir=3D/etc --libexecdir=3D/usr/lib --localst= atedir=3D/var > > > - > > > - > > > mandir=3D/usr/share/man --with-gameuser=3D:games --with-modules --wit= hout- > > > libotf > > > -- > > > without-m17n-flt --without-gconf --with-native-compilation=3Dyes --wi= th- > > > xinput2 -- > > > with-x-toolkit=3Dgtk3 --without-xaw3d --with-sound=3Dno --with-tree-s= itter -- > > > with- > > > unexec --without-gpm --without-compress-install 'CFLAGS=3D-O0 -g3' > >=20 > > Hi Konstantin, > >=20 > > maybe the crash you see is not related but native-compilation is not > > supposed to work with unexec builds. > >=20 > > I think we should really add a configure time error for this.=C2=A0 Eli= could > > this change go to emacs-29? >=20 > 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 wit= h unexec(), it might be a good idea to disable that, sure. > I should note though that I'm not the reporter :) >=20 > --------------- >=20 > Regarding my current findings: apparently the `unexec` has always been br= oken. > I built it with sanitizer and found out that the variable `bss_size_growt= h` > 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 quit= e > large. It was just 440 bytes before, and became 31494584 bytes after. >=20 > However, when built with sanitizer, sanitizer catches the problem in both > cases, so there's that. From debbugs-submit-bounces@debbugs.gnu.org Sat Mar 04 17:08:37 2023 Received: (at 61960) by debbugs.gnu.org; 4 Mar 2023 22:08:37 +0000 Received: from localhost ([127.0.0.1]:37943 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pYa3R-0006bw-H9 for submit@debbugs.gnu.org; Sat, 04 Mar 2023 17:08:37 -0500 Received: from forward501b.mail.yandex.net ([178.154.239.145]:46590) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pYa3O-0006bl-Sp for 61960@debbugs.gnu.org; Sat, 04 Mar 2023 17:08:36 -0500 Received: from myt5-fc73f9af8654.qloud-c.yandex.net (myt5-fc73f9af8654.qloud-c.yandex.net [IPv6:2a02:6b8:c12:2898:0:640:fc73:f9af]) by forward501b.mail.yandex.net (Yandex) with ESMTP id 3FFCB5EC87; Sun, 5 Mar 2023 01:08:32 +0300 (MSK) Received: by myt5-fc73f9af8654.qloud-c.yandex.net (smtp/Yandex) with ESMTPSA id V8hVrHMbnCg1-EONbwgQl; Sun, 05 Mar 2023 01:08:31 +0300 X-Yandex-Fwd: 1 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1677967711; bh=XZvA7yRtJZFZ7rdArUJKpa8Hh/YbaUmgW5BgIcufUbQ=; h=References:Date:In-Reply-To:Cc:To:From:Subject:Message-ID; b=ThT2nuZRhqZSxOq5LG7Re7ZlJB+6kYmBkVY+aJZCyUwICZCUgBMAgeTLxcr+V6RY9 WA02Dku1FpyfLGQCC8v99nZS+zOARIfgcFUlzm8qC8Fa1LMUxbTpc3Ix0KrfwIsKkU AJ5gCOeIIEl8KKiPq3+QteG9Vs9I6qxK63+eMrbg= Authentication-Results: myt5-fc73f9af8654.qloud-c.yandex.net; dkim=pass header.i=@yandex.ru Message-ID: <85d98a66ebb20e5f4fde838493f15b6e0940badb.camel@yandex.ru> Subject: Re: bug#61960: 30.0.50; Unexec build reliably crashes during loadup From: Konstantin Kharlamov To: Andrea Corallo Date: Sun, 05 Mar 2023 01:08:31 +0300 In-Reply-To: References: <62049aa9ffcf9f39fd423fb87cd8dc8e0b77f9b8.camel@yandex.ru> <7a6e37ed07a49a85a51c8a3a40cadc2b752a38ef.camel@yandex.ru> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable User-Agent: Evolution 3.46.4 MIME-Version: 1.0 X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 61960 Cc: 61960@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) 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 writes: > > >=20 > > > > Oh, I am sorry, I posted the configuration line from the wrong emac= s > > > > build. > > > > It's > > > > supposed to be: > > > >=20 > > > > --prefix=3D/usr --sysconfdir=3D/etc --libexecdir=3D/usr/lib -- > > > > localstatedir=3D/var > > > > - > > > > - > > > > mandir=3D/usr/share/man --with-gameuser=3D:games --with-modules --w= ithout- > > > > libotf > > > > -- > > > > without-m17n-flt --without-gconf --with-native-compilation=3Dyes --= with- > > > > xinput2 -- > > > > with-x-toolkit=3Dgtk3 --without-xaw3d --with-sound=3Dno --with-tree= -sitter - > > > > - > > > > with- > > > > unexec --without-gpm --without-compress-install 'CFLAGS=3D-O0 -g3' > > >=20 > > > Hi Konstantin, > > >=20 > > > maybe the crash you see is not related but native-compilation is not > > > supposed to work with unexec builds. > > >=20 > > > I think we should really add a configure time error for this.=C2=A0 E= li could > > > this change go to emacs-29? > >=20 > > emacs-29 haven't got the BLOCK_ALIGN change, so is unaffected. >=20 > 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 w= ith > 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. From debbugs-submit-bounces@debbugs.gnu.org Sat Mar 04 18:38:31 2023 Received: (at 61960) by debbugs.gnu.org; 4 Mar 2023 23:38:32 +0000 Received: from localhost ([127.0.0.1]:38055 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pYbSR-0000q9-Mu for submit@debbugs.gnu.org; Sat, 04 Mar 2023 18:38:31 -0500 Received: from sonic316-21.consmr.mail.ne1.yahoo.com ([66.163.187.147]:38928) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pYbSO-0000pn-95 for 61960@debbugs.gnu.org; Sat, 04 Mar 2023 18:38:30 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1677973100; bh=RG6DFT31quLUT0BPiuo6USoL2WMDVlhQn/4rV05QaAc=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From:Subject:Reply-To; b=dBsWYMH2+x2BDaSuDKcvaDmCLTrBd76axqRh3zyDkmZYSrfQLHCGgAiG8v4QGe175t0jjf8UzDolFBbQE24U6dUhZXbNqyVLaWen1Cj3/6fOnRa2/Li+9oKiWMqN3vNEY5e0+umTXHxlFSFDvGiGpfKUJ8cirtzTa0Ojhb6+abof7Ni5lz4Syv2ZkluNvXpwPubZz0wyF2etz8u3ZJtj++CJJumAZZmM2w2xMFj7f0WR4gYzH/QEImG7cOWF789w4zs7QPS/ZlTIGAmRCMdkFQyEgsPuguy0Se5QVZljKwoR4ANhAYyjRnLHOa4APn8yOec1ZMtDgq1Q+9gIRKpuDQ== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1677973100; bh=BldRcZz39FV0KYREpwI7PJvi+kCB2ha2jGuyVQOlrME=; h=X-Sonic-MF:From:To:Subject:Date:From:Subject; b=rg3lLepN2SBdQCYvIx6bkqGgZCuZR+ewW6NPnVg3bdBbCohciw6pEdfrjGDP0ww5H3P5QJoucCnwvUrvoTSYWW9+qhzbYB4BpU24aOnPPqfFDvsHu2OE1HZIFCnNxGZSdwkMWmCFwphMim/AYU3I/p6zM30AKVdKm871H7GXwqEYQ136O6PdeAKExPNdJf/VIuZudSeoQt+geXTefrVJeSvfTnZBqty0ehnfanTLYx+wGpm0ojAUqQsPlzKbRyqWvP+YuDHY22gHVZNm/1/89cc9zpbMcgH8G1OBzJOJzbrwowih5YNJPSVHQF9Tu0x/sMr84F4w9ATpX9NSpt7GPA== X-YMail-OSG: zvCYBcMVM1nQ1s4B5WvMre6oC8uaM_5Gmq3xcbd7BZkFJehrV2S2ctHJCZImGql 6Ajx6XZL3Ra.p7MpDM83KCtlbnWMxmHoYeF_zgJddTmyCcqaq23DXkf_fv9C._d3z3LgfNdWdBcm m_0RwfKOiQvcqNe4UvTqPOKuBfU56FcaWCIeT08bcHY61etnO4vdno_R.ehoLrY6I8tXvlBEMPgk By8Mn39wnNj.khGAAEI13tra_dWnDlHbjOkVpHR7N7laaoQc9QYbP6fQd6BFOqF94WwXyKw9acsX x4No87IO.XlnhOVqY.1vQxTDW.bke9qJQcL_f8benLZmFwLRBBEI7nOHmycp18SYfyUiUVC6TZeO cGbU4aK6M_xHcATBhXGgOlx2.QuFBQp1Ap6VHCCnBpLitsvx8Nz.WlQhdZvZBRRHXma.x0DmJ4FB 69bDW5veM2hZOti6KAVG.zjCTppoeNjNP5vdpHgUG04fFp79tSya3COqH8d26Z6PUMwss9sw_rfw GcNE23xy8oS3Joy_df0e_dgEwLdl7jyemgvWySdLakjbgwupma5cftupk9NUK1OfbDolaMlqk_kt M8G4lma_BA1t0pn.2ccO3NYkme0gtYpwQf5RwixA73KchAPhpPv1JS9U23DurzTPvdzOd2ShueCW e0udejdo4HF5ux9MXO8dQxHfF9w2FhTmIrNJwIoCsuR8y57r_IY.iPSHY27x_yUGDzLkB2PN1rU_ sSZXr5LPUO38F.sh_gnDBlW81rUmODFEke0HG7oInLSL1SpB4DPM4paTrB1fl7QjPQwiZo6xKAzM TMVC4zq8vibvX5F4NnacPpkEOpnTUZWnIciG1Gom2uLsuJN8Si2DqikHynwo5Ut21KpBM.B3uirq bV3lpeV44evXpNUxmVRjkmjscldc4273Fxj8sVgTq9Mle7aI9_m5ME7D1_MqDxprxwWSC7qxDoJ0 sLNjw.GtpmZPV90Xdxbp.mufVaZoCcIxkPpP9XygkH21VTljrwlSme9Z2kFmeOn6104cSCnCREso R9bImi6NdEh8OCJHxCCEnqOYmjf2ehK1E6mzmnhHY7yhqRhgvr_k7_ARWuSoNbJ.yBZpyBZlnKJe 3h26MS_HE4tqF6m3Y1ZMIDNobbz2.0UNo9OlrZ_J_GY4TjIcJ9Zb1vdTYNkDq75MHKPHfB.0XKaC 3quOCJLXv.ZTCvGUrUAbTb0rXCH9xBe8EzxwP2qdqmbs54LeSb4snNNpQ4saJUkF7fZ.msHlhli0 sFA.r9coxQXxKEONmdZT5xoL1gscnLjLWC_bqCYLmnq6.eGB0NGCwuicmlt941Fnb8SWKkhst0FW Iv.6S4c6_gEYamJ4yuYuA6BnuzKd_gynZbvJ7KguFOpD7kygRHb028TiO5bwEdt5BChvQxDTFHW7 _9Dilj0baQqPH_.oVpjw.myvSmtBd6lNxSv8hC20l2uDOSoLH3wqfoKmQDYKetUTt8bf6STOyUQa UDkY8SL0zl0f9KCkrMZW8einjtNIac3QoSd_X0OgKxfURF4vYfcilyMhGsGJHjd2fVjam8isJEQ6 azXizUq4MlpQyJPfe5qGwC2S9gfg4oc5uTc7CBBygMvx59BCzucZaI3EDM8RSGhNg37RE1YjwneU giQGWPaSAwLr6MWZcqdyefZj21bXY_9Fj8ElRjL9dgK0mR2qp5TNiPcKPN1Nl8U49vbAc52.8p94 e0orKtjJjBV0K_Fy1LIer6SWYVBHcd_p7eIAzn.wLHzlSKE.Hyv3vdjsEy1AcYNnnnCT8Wls92bd .4r.SetevxJudxvPOwLuahCagaWVD.AfUCeBrwn7oJB2Ki65nRNBF6Rg.FY17tGB0uhAxNI_P9is 1DfZUXMGqvJtMD1.viLQaEIHLPcAbDLpHKYPk8QS8fivkJcO6T8nA7jT0wy1T5ohn8cKHZbviOe0 is4B3UQaXdA149kcVJ46u6r5LSJ6fllIHHDwh3rgEPoAQMEjXieQz9O9_U0YYgnAqBM8xBL.1vGV 7nT3oHzJh26xfXMdLBzfcpAwNiFTgBV4AiCeUfy2s4f1EZHrZIZwx1z5qbfbMhCbR21mimHzlOzl s3270pVdeRIoul9ELD23l9EHd2NhMl8vp89by2O3TtpTgxpg8zQcOmVrdTewQsJaZaxmc_PWEgVT MJCv5E6Y6n9kTYQSw5Jd5rWr8uZDUEaWOIvC9az20MUeyHy3TYpsYspLITScyikpTYwsrLXAJfWz ryxztSIgA6aHDf5LjXVRlnASU767uZ0N.D6XR3DJ0sodQeELfZUCRFXlCEaMOowOQ5kQ- X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic316.consmr.mail.ne1.yahoo.com with HTTP; Sat, 4 Mar 2023 23:38:20 +0000 Received: by hermes--production-sg3-67c57bccff-ddhjj (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 396bbf281381a0014316a6caf921384a; Sat, 04 Mar 2023 23:38:17 +0000 (UTC) From: Po Lu To: Konstantin Kharlamov Subject: Re: bug#61960: 30.0.50; Unexec build reliably crashes during loadup In-Reply-To: <85d98a66ebb20e5f4fde838493f15b6e0940badb.camel@yandex.ru> (Konstantin Kharlamov's message of "Sun, 05 Mar 2023 01:08:31 +0300") References: <62049aa9ffcf9f39fd423fb87cd8dc8e0b77f9b8.camel@yandex.ru> <7a6e37ed07a49a85a51c8a3a40cadc2b752a38ef.camel@yandex.ru> <85d98a66ebb20e5f4fde838493f15b6e0940badb.camel@yandex.ru> Date: Sun, 05 Mar 2023 07:38:13 +0800 Message-ID: <87h6v0uly2.fsf@yahoo.com> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain X-Mailer: WebService/1.1.21221 mail.backend.jedi.jws.acl:role.jedi.acl.token.atz.jws.hermes.yahoo Content-Length: 383 X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 61960 Cc: 61960@debbugs.gnu.org, Andrea Corallo X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Konstantin Kharlamov 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. From debbugs-submit-bounces@debbugs.gnu.org Sun Mar 05 00:47:02 2023 Received: (at 61960) by debbugs.gnu.org; 5 Mar 2023 05:47:02 +0000 Received: from localhost ([127.0.0.1]:38209 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pYhD4-00027Y-D5 for submit@debbugs.gnu.org; Sun, 05 Mar 2023 00:47:02 -0500 Received: from eggs.gnu.org ([209.51.188.92]:46826) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pYhD0-00026y-EB for 61960@debbugs.gnu.org; Sun, 05 Mar 2023 00:47:00 -0500 Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1pYhCv-0005Qu-1y; Sun, 05 Mar 2023 00:46:53 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=MIME-version:References:Subject:In-Reply-To:To:From: Date; bh=qdJjDQFHCr8aRLy9W8iKLPEHZ4Yu0GiIEIQd7B8BvSM=; b=HsKCkIcjVESfVZfmKnLA SDAXoN1mi2lRt+iml5h4VLDGhQ8uJNhaK1+VBMoMW8pSPlewfipzfWbO7L738C37pvdQxbmsBGk98 ORvN21gu5fCHeofAZxmnSshRwemic+qyWBS4AGThNibSrIo2XdTPhuraUJB8xOIRAcRE5NgpnwXkh EmS3+letUI+cGpuYrAp2+1ES6CUMLtaFnHJyJTsXKwS14ldd2mf7F9C+NP0yNpvAAI/OFRaYFLHrA X3h7TAKHQ4tdpqmuIZmKIZSTDjzUtqo/b3wITM4/iRUFx1EwIF0ZjtjszmvRCnO/WxodWQA7JZN75 1YYLGW5Dgbv+cA==; Received: from [87.69.77.57] (helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1pYhCu-0001Xx-08; Sun, 05 Mar 2023 00:46:52 -0500 Date: Sun, 05 Mar 2023 07:46:40 +0200 Message-Id: <83bkl7agxr.fsf@gnu.org> From: Eli Zaretskii To: Konstantin Kharlamov In-Reply-To: <62049aa9ffcf9f39fd423fb87cd8dc8e0b77f9b8.camel@yandex.ru> (message from Konstantin Kharlamov on Sat, 04 Mar 2023 22:50:12 +0300) Subject: Re: bug#61960: 30.0.50; Unexec build reliably crashes during loadup References: <83pm9oa7mm.fsf@gnu.org> <62049aa9ffcf9f39fd423fb87cd8dc8e0b77f9b8.camel@yandex.ru> MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 61960 Cc: 61960@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: Konstantin Kharlamov > 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. From debbugs-submit-bounces@debbugs.gnu.org Sun Mar 05 00:52:48 2023 Received: (at 61960) by debbugs.gnu.org; 5 Mar 2023 05:52:48 +0000 Received: from localhost ([127.0.0.1]:38219 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pYhIe-0002L7-Gu for submit@debbugs.gnu.org; Sun, 05 Mar 2023 00:52:48 -0500 Received: from eggs.gnu.org ([209.51.188.92]:45954) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pYhIc-0002Kn-So for 61960@debbugs.gnu.org; Sun, 05 Mar 2023 00:52:47 -0500 Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1pYhIP-0006Jl-QB; Sun, 05 Mar 2023 00:52:39 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=MIME-version:References:Subject:In-Reply-To:To:From: Date; bh=PK6mwxPtjjTp0Y1suP/okBJCRoT7eMJYv34d5dEhWqU=; b=nJTehOooTaXPvqjGjTSM tHEiFFgZG2yIunmxe36mrf09cWzptUrCU9lX4yx+4wjXRoqTT9x+rtybTeW3LzVQxllNeZUhTQovP OZ+mB/nPXlJOnfhxdhpcyBrZ5RXkuZtek4yghKJYGzclAA+80bLGnXq8Qe/2furOrQUr3rCB5+1E4 m5kObd3SpsPXXunjYIAsFK9LjylVHZTsuUVOjwP7yEfEj8OsIzO+nuxi6hJr9ph408mTxL5R0L2p9 QCBm+9Jc1h9mOTGcZ/v2nivIbzP6B+N+t4JrIXXfh5a14zK//Scaa+x9/iVYJYOHyJ1lHt1JU9o9t QZlY7meG+QEDGQ==; Received: from [87.69.77.57] (helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1pYhIN-0001XL-Cz; Sun, 05 Mar 2023 00:52:33 -0500 Date: Sun, 05 Mar 2023 07:52:22 +0200 Message-Id: <837cvvago9.fsf@gnu.org> From: Eli Zaretskii To: Konstantin Kharlamov In-Reply-To: (message from Konstantin Kharlamov on Sat, 04 Mar 2023 23:05:23 +0300) Subject: Re: bug#61960: 30.0.50; Unexec build reliably crashes during loadup References: <62049aa9ffcf9f39fd423fb87cd8dc8e0b77f9b8.camel@yandex.ru> MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 61960 Cc: 61960@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: Konstantin Kharlamov > 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. From debbugs-submit-bounces@debbugs.gnu.org Sun Mar 05 00:59:46 2023 Received: (at 61960) by debbugs.gnu.org; 5 Mar 2023 05:59:46 +0000 Received: from localhost ([127.0.0.1]:38224 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pYhPO-0002W1-DH for submit@debbugs.gnu.org; Sun, 05 Mar 2023 00:59:46 -0500 Received: from eggs.gnu.org ([209.51.188.92]:54808) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pYhPM-0002Vj-4j for 61960@debbugs.gnu.org; Sun, 05 Mar 2023 00:59:44 -0500 Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1pYhPG-0007Cn-3E; Sun, 05 Mar 2023 00:59:38 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=BkVBuUSAyOopACaS6fAnK8JDu+0u5b4UjouPLBZMaXY=; b=Kji/jZTlzwnM b1BZNXbSVxCwSn26x0sgsG3zozzXX5FdBytPKn+5gG137ZDhSkrlGDCzx094dtc3OBGKKhx3vTu3R x1sZuaXZlN0XSsVAZKh7JhS2bPITFOnJs8PtnnJJ9d/65TlkpTWtIeAwN/7BIJp01yS+88RfgPv1m ipSPHUPAeET5pqLFjjY1doOI9ENvnajsW9e0p+AdjwocLLuu6hU+lvNH7ZnSQSCi7p/OTKOF0BQSq aH8WKMLlASAiIGcX77v5DdkX4/uya5OIN87HYLUpO4A8nUsxoJznmJcszt7jRjvJGPAJMQ4Z/mntJ OQapckuaQBt3DDkuJcvvfw==; Received: from [87.69.77.57] (helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1pYhPF-000184-6V; Sun, 05 Mar 2023 00:59:37 -0500 Date: Sun, 05 Mar 2023 07:59:27 +0200 Message-Id: <835ybfagcg.fsf@gnu.org> From: Eli Zaretskii To: Konstantin Kharlamov In-Reply-To: <85d98a66ebb20e5f4fde838493f15b6e0940badb.camel@yandex.ru> (message from Konstantin Kharlamov on Sun, 05 Mar 2023 01:08:31 +0300) Subject: Re: bug#61960: 30.0.50; Unexec build reliably crashes during loadup References: <62049aa9ffcf9f39fd423fb87cd8dc8e0b77f9b8.camel@yandex.ru> <7a6e37ed07a49a85a51c8a3a40cadc2b752a38ef.camel@yandex.ru> <85d98a66ebb20e5f4fde838493f15b6e0940badb.camel@yandex.ru> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 61960 Cc: 61960@debbugs.gnu.org, akrl@sdf.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > Cc: 61960@debbugs.gnu.org > From: Konstantin Kharlamov > 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. From debbugs-submit-bounces@debbugs.gnu.org Mon Mar 06 13:29:21 2023 Received: (at 61960) by debbugs.gnu.org; 6 Mar 2023 18:29:21 +0000 Received: from localhost ([127.0.0.1]:43606 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pZFaL-0008KP-FH for submit@debbugs.gnu.org; Mon, 06 Mar 2023 13:29:21 -0500 Received: from eggs.gnu.org ([209.51.188.92]:56704) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pZFaJ-0008KB-23 for 61960@debbugs.gnu.org; Mon, 06 Mar 2023 13:29:19 -0500 Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1pZFaC-0000u6-JY; Mon, 06 Mar 2023 13:29:12 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=W/E//lFH9vtv+ADGAkdc4ox0OYfzu5VQC6fy76Lmt50=; b=sEvLXJKzW01n ueaB61qHxRXMhqQ1s59E3mWAl4l+EbzmsIJ8qGZU4KoJ+jJ4fElutnD55kOhg+CrPc9tpKpFSLhyZ vq6O7z76AIMwEoKAMbF59xzDXwwAJ7HbXnu+1R+rcboAW9Y5+llbed66oqqBrfO/9aa9asUCaKkre grLGnWDmc92oTFgwJIJigC8Dch44Hbhok8WJCzYzbRXTymY3ZKEv2LDazkbiNu9mpLOqr3YUKOne6 i0ZZzREv46sOswVi8kJC2+ddXFPC4IYMAm4qfr43EmI/jMzEhqM/rhAwUBKk7NvYddTj/9Ge3w89z /PZlBBoTjJUtJ/T80jDmTw==; Received: from [87.69.77.57] (helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1pZFaB-00031C-WE; Mon, 06 Mar 2023 13:29:12 -0500 Date: Mon, 06 Mar 2023 20:29:06 +0200 Message-Id: <83o7p57mz1.fsf@gnu.org> From: Eli Zaretskii To: Andrea Corallo In-Reply-To: (message from Andrea Corallo on Mon, 06 Mar 2023 17:12:55 +0000) Subject: Re: bug#61960: 30.0.50; Unexec build reliably crashes during loadup References: <62049aa9ffcf9f39fd423fb87cd8dc8e0b77f9b8.camel@yandex.ru> <7a6e37ed07a49a85a51c8a3a40cadc2b752a38ef.camel@yandex.ru> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 61960 Cc: 61960@debbugs.gnu.org, hi-angel@yandex.ru X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: Andrea Corallo > Cc: 61960@debbugs.gnu.org, Konstantin Kharlamov > 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 From debbugs-submit-bounces@debbugs.gnu.org Tue Mar 07 09:59:28 2023 Received: (at 61960) by debbugs.gnu.org; 7 Mar 2023 14:59:28 +0000 Received: from localhost ([127.0.0.1]:46927 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pZYml-0006WI-SY for submit@debbugs.gnu.org; Tue, 07 Mar 2023 09:59:28 -0500 Received: from mx.sdf.org ([205.166.94.24]:56269) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pZYmj-0006W9-NF for 61960@debbugs.gnu.org; Tue, 07 Mar 2023 09:59:26 -0500 Received: from ma.sdf.org (ma.sdf.org [205.166.94.33]) by mx.sdf.org (8.16.1/8.14.5) with ESMTPS id 327ExOFT003279 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256 bits) verified NO); Tue, 7 Mar 2023 14:59:24 GMT From: Andrea Corallo To: Eli Zaretskii Subject: Re: bug#61960: 30.0.50; Unexec build reliably crashes during loadup In-Reply-To: <83o7p57mz1.fsf@gnu.org> (Eli Zaretskii's message of "Mon, 06 Mar 2023 20:29:06 +0200") References: <62049aa9ffcf9f39fd423fb87cd8dc8e0b77f9b8.camel@yandex.ru> <7a6e37ed07a49a85a51c8a3a40cadc2b752a38ef.camel@yandex.ru> <83o7p57mz1.fsf@gnu.org> Date: Tue, 07 Mar 2023 14:59:24 +0000 Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: 3.6 (+++) X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: Eli Zaretskii writes: >> From: Andrea Corallo >> Cc: 61960@debbugs.gnu.org, Konstantin Kharlamov >> Date: Mon, 06 Mar 2023 17:12:55 +0000 >> >> > debugging session :) Yeah, if native com [...] Content analysis details: (3.6 points, 10.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- 3.6 RCVD_IN_SBL_CSS RBL: Received via a relay in Spamhaus SBL-CSS [205.166.94.33 listed in zen.spamhaus.org] -0.0 SPF_HELO_PASS SPF: HELO matches SPF record -0.0 SPF_PASS SPF: sender matches SPF record X-Debbugs-Envelope-To: 61960 Cc: 61960@debbugs.gnu.org, hi-angel@yandex.ru X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 2.6 (++) X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: Eli Zaretskii writes: >> From: Andrea Corallo >> Cc: 61960@debbugs.gnu.org, Konstantin Kharlamov >> Date: Mon, 06 Mar 2023 17:12:55 +0000 >> >> > debugging session :) Yeah, if native com [...] Content analysis details: (2.6 points, 10.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- 3.6 RCVD_IN_SBL_CSS RBL: Received via a relay in Spamhaus SBL-CSS [205.166.94.33 listed in zen.spamhaus.org] -0.0 SPF_HELO_PASS SPF: HELO matches SPF record -0.0 SPF_PASS SPF: sender matches SPF record -1.0 MAILING_LIST_MULTI Multiple indicators imply a widely-seen list manager Eli Zaretskii writes: >> From: Andrea Corallo >> Cc: 61960@debbugs.gnu.org, Konstantin Kharlamov >> 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 From debbugs-submit-bounces@debbugs.gnu.org Tue Mar 07 10:33:47 2023 Received: (at 61960) by debbugs.gnu.org; 7 Mar 2023 15:33:48 +0000 Received: from localhost ([127.0.0.1]:46974 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pZZJz-0007Na-JC for submit@debbugs.gnu.org; Tue, 07 Mar 2023 10:33:47 -0500 Received: from eggs.gnu.org ([209.51.188.92]:56854) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pZZJx-0007NL-KB for 61960@debbugs.gnu.org; Tue, 07 Mar 2023 10:33:46 -0500 Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1pZZJs-0004XK-2T; Tue, 07 Mar 2023 10:33:40 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=9hvUEhLCX3WXkQBwSF6wfLKuq+VVDz5W3zP8qHKKqO4=; b=YAWu72m8hZFS lQnhj81P0OJbCtc9MP93xriq0cHMxju5x/Mz6Fp4KNysMI3MZ+z+pL9Cve3pYW10hf2QMbbT8MKiA dH1OTvg5QEWY6xa8rxbBHv8oJ1YNamWdi36NsLrpyM6nt4A8ZDl8fNvaTajq/IOrexV0MWwhcxNTV lOKxXcgkpiaXPfTaJNZ0eQRC1sJr6zKDci2EHhj9WHsoe/lNBnm+QG0riB2a1Z5BPdQn3jiMD7qOk pPclxXwySbJV3kYNgj9S6jAPbzBG6s0hG6eH1XADepG3J2tUCAz0MAiLm4ki2E/6dALkp3JpA5wg+ MoiF7kM9q4l2d+rgZa9tiA==; Received: from [87.69.77.57] (helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1pZZJa-0007aL-9W; Tue, 07 Mar 2023 10:33:37 -0500 Date: Tue, 07 Mar 2023 17:33:18 +0200 Message-Id: <83jzzs60g1.fsf@gnu.org> From: Eli Zaretskii To: Andrea Corallo In-Reply-To: (message from Andrea Corallo on Tue, 07 Mar 2023 14:59:24 +0000) Subject: Re: bug#61960: 30.0.50; Unexec build reliably crashes during loadup References: <62049aa9ffcf9f39fd423fb87cd8dc8e0b77f9b8.camel@yandex.ru> <7a6e37ed07a49a85a51c8a3a40cadc2b752a38ef.camel@yandex.ru> <83o7p57mz1.fsf@gnu.org> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 61960 Cc: 61960@debbugs.gnu.org, hi-angel@yandex.ru X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: Andrea Corallo > 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? From debbugs-submit-bounces@debbugs.gnu.org Sat Mar 11 02:23:18 2023 Received: (at 61960) by debbugs.gnu.org; 11 Mar 2023 07:23:18 +0000 Received: from localhost ([127.0.0.1]:56449 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1patZV-0004EA-Uo for submit@debbugs.gnu.org; Sat, 11 Mar 2023 02:23:18 -0500 Received: from sonic306-20.consmr.mail.ne1.yahoo.com ([66.163.189.82]:40577) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1patZT-0004Dx-5O for 61960@debbugs.gnu.org; Sat, 11 Mar 2023 02:23:16 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1678519388; bh=tlLn4ZykVu+IZSL14j/76K9REgjaSmLaIk/m2DA7Wyk=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From:Subject:Reply-To; b=FPDE19MLTW9z/7zhZUnZ+Q96S7h7ko02wZgU7hPJgEUaeorlI+2PzxJZcgQf7yqVDcYtUTemnLEoZ2O/JHJPgfwI1SkHomtNitEUNOg4uKZb0vOlYo5y5hE5httROd+ehBNL+kREzOWWRoIOYM2gG6L5/RUuqCDfpGMa/wAB08jZCW5Rh4Ytfeay4jBWF7Gelu6KjxrcRBO2XEqadaDmfX7dE8BvdcWQJMJD6KMiMtLvTNKuvBCTm6QPXABcGa0PEr5SCwM93hPbbfC2Cexqnqr+4HGA2pfvdWAlWPXWMvXQ3HQsE+K1YyL2ceGPa+iRJVu4XTuLQB60cd6+f+/uvw== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1678519388; bh=eQfivZ2o1m3DVLq42xJJ7bbZFIUwYkqp3g1+tAPcF6i=; h=X-Sonic-MF:From:To:Subject:Date:From:Subject; b=tS9PGxc+cJqaMMWmo5Njryeaa1vtzfzVhSIK3lfmpa0w//EQ5srSgob3m9iOIKBnHO4hc61NC7XQgczafsIJu/pYkmm6dcRtzniXffVtDxFM7CwzBYuVocdo3DGb6OrqSlHp+Hf/SfIpEgcPz8ux2Sv8ivIp+R3CSHm6u2OjiP06OtJlRQeIc7NjhQXeL80nG7UDvtBnwu1n98Dhh3nEjtVpEezrnpbw2fRvUMSE4N+py7rYUkS/HBHITuWB/gobsCle75ocXsGKoMp+LkMC0yEq5o7aj6rZ2K+EicRR8PWk6TAy5oVDKun8om2TG7UV86lI4mlbYnGAafbHiPu/IA== X-YMail-OSG: 9CvDAWwVM1lKIbSqZRakuVUz3t6rJBN3af1qF35XgnfffnRis8fsw8A2S_Huf6m Q_WVI27hUxN82WGM6mnOQjdnck1r9H2uULaUWAkSs0mdZul.8EwdM93hvS2.AbrCkMLXoVtRvaof SlHcAtuKk0Cff9P3tmo4nNWo1QvMSGJtaVQN5UpZWE8q_gw8SSDVWsdZVYheIX1FPFDtTyj9s4H9 Y_Qc4IbeWoq_RNFH0Fsc93NyZMRNnLtwzjmk_G8V2b_Dso75mo32av9UM6w0vIOqneru3s5TpKqC srSa5qL74iGoAJ8NMXN5G_vPjJ4Jc2Pt2j7iILl5aC6pXzxrYXCjVZXBRiBOqlVtHp6qrgejEfcH YJSdKNM2NPSgbqZVdiqhJwDGeeYKJg3at90SY_6n1iaYXgIKu4LAX9Rg2ou0tUroEhdB8AaEkgKA tTnkpkLIiLIrpFBIcMYdWQgsb4Kqi3JUKm1D52dvl.zuC4dkYYAUBcbOheHhCiCMOL4a_g4GzBb6 qNpfwSb22gWAZiMvZw6skOzn1QYjKVO4ljy1OGe5gJKBCRSkVRsfPBFmlZ4G7EjDeGzBnK2nprQl 3ajiRaJavDlPSoSA5gsv4JKapwPPIpOgvTaaNn0W2LrNu2dgQcBoOeesoJsDlpghiE2.bBlTCuZr s0asqAgvgNH0NSzmYHtCalZ.WNxOc2qD3Ldbc9QIb6frV5ZTYPjSw0fc5jvlcDQfvGlIhzovrIub DiM1iFyp9qEs6CtHWru0jj2cDy7A6WGfTlWhXpFuhVMvIgYt3v2.ofmCoIMtEPE24bgyt5lK03A5 quvjwCTenILOgVDaIROmjzizyFsq0ksZHH5rvh0oGmrKW05xHAn77XCd0o3YLFYBrfYN1l8lV4Rs h1P91ZEB_K7.P6e.M3Eq_oWfrSinbQqU2OL0lbDzjdZtyr00Dj9OFICwBWwC9EBp1v8xgWAojpb. iVxFsCfXkB1lf48NAt0BJ5_8iS8sC5hsnP1ltXF.uZBkYPXoZJHwnvqRaDxpFI3WfzPgyTQ82Ysi Dx1of9ZbewX1lV_XGJD77fVeHxPB9W6O7.jGnOQM_.qw2fdzMxyohput28eA5rIWynueerVgimdu JUiejw2vqBCvLYcJxHK1ZXa_fCbNbTEsYn8OgzqYCsNnqrwz6ik309YN6V6kW35ADOqlcGMLOf1y 0nvCPQ8pCmmR5Ty6hHNQTA94D4107AYHiAUqSytrsKOt4jAFSYydR_GNKgjdHfHoH__8nN1DlGLr vjOt3ij702361M7VkyQkN6qdnTIg.FkiD8OWX0yv0rQ8ivYIplBoBzuiEn1Yp8c7Ivl_BC6yZGq5 a2.x0poLn9g.kAqARjCex3_VN9kezknjW68DaISQt.mu9V2gblVvNL.8zSJ6KXKSdsCEdZSgMMET EAribXvTu4R8OYHBudd8vpxOyVCxPexC3kpAKOgT0tCTw.a.QE4G66PNKWI16qbOJGICxvTX4NB8 AXVRu.gSFF5GGBgCEKbnaAPn9enus50dXDiCBnpyLuCuX8mjm797TP7mZhRsSlTAtv6tQgGQmzpc s_JbelN0HumIA2wQsTBKHra6WnOvTbLCY.BmIXvF8rasQ7I02v4eJ9t30X_JCaEvslk2ZuZKBaq2 tjB8KejKf266GUnvTb10Z6niBDYua4Grl.7497WOYrGY2MRrd9aajHx26rEwIq6Idp4F8yKGRAYp xOfVRkRdJsRiDjelFb6CCTC48MPTnbqiFFkG_DMXCR2avmX7zUVQeUFTrK9jiiN8a0tSL4iZs6Dl U7i58NTzXJtiG_bdIKbflKcI.An_rwvInnC3_KYf_EbfRFTW4ah0b1bsIp4oUASWZPK4pL.59Jp2 y._rdVkyt27sQ83ahcyVJNXqChU0cHfLdt9rJSSBYsTaggog8lPmKPh3l.ACuFXylrF_iw3BFT8z LImUEqlGfQwwx_M94B3CojK0ia1YqdwCEC8NpGFDt049evRn1cB9ySJpALXsoVRHoaCLNYhY70Bl cQsPzxBZZ9IiCW.QokdXcScWxgEXJWJ7lunaxig0x_5oIfgfDGUqsIMdgDiA8MlhmaWSROqHJT0y h8qUtE1XhE06EA0klkBJwEU4vRMhmQhTGy3nG5YOdmYvWQRzh0ynBfKKy5I3U_PmmsbMOTJyWCpP Aph0Fzu5b3nUoE0XiwlLLT52irf_mE.lxhEMjPl7uS8nMa_vVXu43Lz9TiPAeMCANVGWRycTBK8y LxvhUh3hn0noK3a7dJd8aGmbQN.14b.APKU0gka2gYc3oOZcbptZ4_DRS.7rnVMj2LA-- X-Sonic-MF: X-Sonic-ID: 0610950c-e29f-4b2c-8267-70add085ae36 Received: from sonic.gate.mail.ne1.yahoo.com by sonic306.consmr.mail.ne1.yahoo.com with HTTP; Sat, 11 Mar 2023 07:23:08 +0000 Received: by hermes--production-sg3-67c57bccff-b6t8r (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 5fabc064eb4d15bf5f8d6adcabf7699f; Sat, 11 Mar 2023 07:23:01 +0000 (UTC) From: Po Lu To: Eli Zaretskii Subject: Re: bug#61960: 30.0.50; Unexec build reliably crashes during loadup In-Reply-To: <83jzzs60g1.fsf@gnu.org> (Eli Zaretskii's message of "Tue, 07 Mar 2023 17:33:18 +0200") References: <62049aa9ffcf9f39fd423fb87cd8dc8e0b77f9b8.camel@yandex.ru> <7a6e37ed07a49a85a51c8a3a40cadc2b752a38ef.camel@yandex.ru> <83o7p57mz1.fsf@gnu.org> <83jzzs60g1.fsf@gnu.org> Date: Sat, 11 Mar 2023 15:22:56 +0800 Message-ID: <87edpveoq7.fsf@yahoo.com> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain X-Mailer: WebService/1.1.21284 mail.backend.jedi.jws.acl:role.jedi.acl.token.atz.jws.hermes.yahoo Content-Length: 991 X-Spam-Score: 1.0 (+) X-Debbugs-Envelope-To: 61960 Cc: hi-angel@yandex.ru, 61960@debbugs.gnu.org, Andrea Corallo X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Eli Zaretskii writes: >> From: Andrea Corallo >> 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. From debbugs-submit-bounces@debbugs.gnu.org Sun Mar 12 19:49:23 2023 Received: (at 61960) by debbugs.gnu.org; 12 Mar 2023 23:49:23 +0000 Received: from localhost ([127.0.0.1]:33208 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pbVRK-0006Gh-ON for submit@debbugs.gnu.org; Sun, 12 Mar 2023 19:49:23 -0400 Received: from sonic302-22.consmr.mail.ne1.yahoo.com ([66.163.186.148]:36671) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pbVRJ-0006GU-F8 for 61960@debbugs.gnu.org; Sun, 12 Mar 2023 19:49:21 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1678664953; bh=mkCOdVN+6lNvot7wh5Qxo0U4fTFrUVsWJvk0lX+SjeY=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From:Subject:Reply-To; b=VjU3A93qNbyFhT/lBvkMS1C71/sR8gbDexddUhDRjrxqOo2FwsLTYe5EESRvY9dj8bXEyqCWl9Z2ADlVWorLIw66nexHWYnZIDUt1U0io+/bsS3Zbq1iyrteoxEXGxHXciYXQplwvFtLGC8GTsRShaSGS+dxb1aVsovZecMX1BHC5zZu2BoukQwiZyJ+DyVuLHnPBkIeqlfBCsSYhzXnEOa4wHh5Hu312Oj/rOhHclMhuVesZehfkFyQCf0tzb9xJDcydcgc8exbIYKLc7F0VooeaawKlWRa2JbV2Nb9kp+6/u2Fdz3HDMaDSThNiLI8GMfOB8wJC05Pq0EvDW1FAw== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1678664953; bh=JsCS2Y8d0kSuxNnV6CnMocPFSLOEbtDJz88Q7pTB3gJ=; h=X-Sonic-MF:From:To:Subject:Date:From:Subject; b=KTo3dHz0DzWnUAIPxmGV0zqLoK1Y4FetHVeVKTJ618ndoGZ1CorjqB6iBOpVbAs5GXjSkz8nvNmL2Pq62bXQ2QWNfKXRPhJKhAHUJMl2KvwGTeHYYT/71nayG4SR6ImmkG77ffRgphVlgzZRE4lFp473UvsyJe7oSWk1nmVHgDWq79gshP12qcawntkgMkb4sxL7oBZ2/Yi4wEzwwPrAygD15+OHA0VJUm7l3JsoVjNAtMCiMmgGSdQ2yjD2iqOZSIntaSIUn8zHy0CX/PNA+Kb6Zxm/rYzOKOUo5/hGllEvCg9SWOLEayxbG0l9ZFb2qnFuT1G9fAURHGOwjF6gpQ== X-YMail-OSG: 9yKoAOIVM1kO78IxAuFLAG8NJaeCjLy.mGQ.ohy42PeUIHLpYNe95YmykOnoOgQ HZE6GlDbVWPd3B_umgTgwiNUiWwv3hME5M0NuBB7nwx7qgCIRbkTmI1JIMs0JRGmu1d9Jdqgw1dB J1kGTmf.TxUZgBt8F24fFDST4KNhLVb08Hj22qOnkzfUCZDt_TK4ScDrfy7uo_9H0BjQh5gsfpXD Yb0wfOzg2xVLsaSGdWfFqAzO8iXjKIbidj4PutLjAsDTfQsTO4RJI.atPqJFt3CgnGpqiDYK2sb_ fq4iHZk8N36HcpkD1cnjgZ_F.hgns1FBYm5.Qv_SAxlS4pa7xZeMxwtJYaSMTLPOmmd9CrSYIgJ3 czZoHXYB2k_fI.O6QnuXx0HxsiJBKYyIWVJGrSOQJF7_SEILW0mkiGizd5Jnar4MbsDvCVoyESDV tt6W2L0Vf59NMXUzEhEJ7zxkZamypvrPp.ZwzYJRUDOO4S2QbFZDSqAZTkGpSCD4LJA66Kqh..lx Xw2ZI_s5HzrnevVpOehCQc3lKqolITrEB4Hued8nImEWSx_wpiguEKnTm1V7zZMxSR.9JmbSURr6 zQYUOkVifLLnCWmELEc4egart95cwXmYPzBTDYWXnX3Sl0O0vTyfhPiFPc8f.3E0x0iq3QSDUTqV wh2ayD6al4Er64S1JPwvgDD7Txm0YjeqjdFJaL.YTG4TLw91tLJrk39ojhOWqf1NpX3bJmVBEwxu _x3HbD7_RcNJD7rggCXZEt09Hud5rF9dVX6ER..Le3rWnIz1Xq47Rr5qARBjmMrezNNjZ.4oF0r4 SvtNE.ZYtQv4poRhhFfZ_E7_gTuWdsfEir8FI.VfDOkV9DT5RQByLWx0mSG.lP_j.Ui1leHjdo4X oHNLc2GZX7yidjawdU1I_1JpjCMifnErZKYTjkZI8nG73axi_n.B8KuGjXjKZWoV2oYupPstUu3e .nCDd1qXM6Pbm.dEDNf8Y1JxwwmgubYoVp2zSLBW4Om.2TCaJtNuOHd5HCEFbf0GcCgBb35HCoCw Ku6.7MoskBj_XVmroOcFiH3AAqGUzMc1vuhvHt6ieScEVxam22xXNOmJFWg2cYt_8q9gfrZ0bq90 byy3GccrMMwqzcvqnIRYsQ17BcEuZOiPoSCH5MfDAaMJtfXd0zwcBNrCpkUm2XwaBUCO_F0AbCKz IubMSoftJ74ytejVIt6e1YgkuCZZpzVP1wFVShmddtw_wbnxNKBrRcqSJbmy8pMaZD5DkN65m_pb OCPsDNYde58DVMsY0oa39SoFyO9HRzBzeXgGyLYkMZTKL.V8hlSxUBLMbmrMoXHjOPNaqkG6R0Yi _HL.fmIJ6IypdEuY_irQmCPBSU6AR5V1vPKaPZVG4kQCuoHr_3HJOv0CsABv0cWij.JKpfvHGBDG i4ETZYQFIDEqgtwk4ZJIQBnAgqJMSdRvXpNrCNFNgrDvyLyohAJ26XzvykZrLATulsrIe7hm6M0F c2k2..LfAcpoWdgiNFureUXiD1Nr6wgUPpwXVqqQE21idh_vPh7WXtwIF8SuFhl2.M0FFZ_BlhjT kvjlSjQkup.cxek_KAiGKP0AaI_waUJxtyogERJbxQUVy7Dn54WPBqFPJVG5unSB3f3HwlmrWhbl TQyPuj1qrt0a4ITq99Std004S9U763yLtr3ckbGG6ivMN1iPV8gR976SlGsiCaub9dk7Ofrix_oY SM_Jd0.N.87GKwMIXWorFph_PkcIRKK8_6hnBLSoID_U0I9kcNg765eHRYCs9KH147r9PZDpAMH6 sWNfzyRpvywoNcHT8OVH0zWXjInECuKIYaCEXMxgr2ZebH6XtGCCl1vlA6eV5GxbLOddcO.6mR_S kEqZh2VMaotureHxDGSbZTgflHDOlOzG.08GQzfEKAorLTj71FzVs7mutysMnIFzgexrHO18aSGp g8aZnf490WRy1Z9.gHO9Ni839kEFstH.pDk8ir9XyGpvp.TT7Z5hnWtclgtmoOSQN8uSsnHq8t6m 17HOOaw6xMGuIAzyUfxHFa5LxK1VR7ujTfKnoMhMRoln_mzkCNpDTFc1xUyzZg4Id7hyl2LI50Pa i5SaXZrWHrgFD.VayV6JmCmqWd_MdNQg7K3E_Dhc7Y9nrv3zzv6ceLzUW06mmYPMkw12.C9gy_bG ip0Ni30RDGjOfyMhsyZapGMx3gEkqWuECsjL56Pcjq06370iFmRpOVEishfaP13182DfO_LIZFaT 0tZQj1tOhY1xNRwk163KG2WzAMMHYsYshsEs5AAaFZRdAiC6jVvbXxjerEhDVsJSLO_You_vXWA- - X-Sonic-MF: X-Sonic-ID: 4463eb21-bc0a-4e2e-8c67-fb7d39f13693 Received: from sonic.gate.mail.ne1.yahoo.com by sonic302.consmr.mail.ne1.yahoo.com with HTTP; Sun, 12 Mar 2023 23:49:13 +0000 Received: by hermes--production-sg3-67c57bccff-5lh9j (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 9ba1c6d7c12b1b1c398280d4854f5cde; Sun, 12 Mar 2023 23:49:07 +0000 (UTC) From: Po Lu To: Andrea Corallo Subject: Re: bug#61960: 30.0.50; Unexec build reliably crashes during loadup In-Reply-To: (Andrea Corallo's message of "Sun, 12 Mar 2023 09:23:21 +0000") References: <62049aa9ffcf9f39fd423fb87cd8dc8e0b77f9b8.camel@yandex.ru> <7a6e37ed07a49a85a51c8a3a40cadc2b752a38ef.camel@yandex.ru> <83o7p57mz1.fsf@gnu.org> <83jzzs60g1.fsf@gnu.org> <87edpveoq7.fsf@yahoo.com> Date: Mon, 13 Mar 2023 07:49:03 +0800 Message-ID: <87jzzla5u8.fsf@yahoo.com> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain X-Mailer: WebService/1.1.21284 mail.backend.jedi.jws.acl:role.jedi.acl.token.atz.jws.hermes.yahoo Content-Length: 1455 X-Spam-Score: 1.0 (+) X-Debbugs-Envelope-To: 61960 Cc: Eli Zaretskii , 61960@debbugs.gnu.org, hi-angel@yandex.ru X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Andrea Corallo writes: > Po Lu writes: > >> Eli Zaretskii writes: >> >>>> From: Andrea Corallo >>>> 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. From debbugs-submit-bounces@debbugs.gnu.org Wed Mar 15 09:56:21 2023 Received: (at 61960) by debbugs.gnu.org; 15 Mar 2023 13:56:21 +0000 Received: from localhost ([127.0.0.1]:40285 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pcRc5-0003TZ-BR for submit@debbugs.gnu.org; Wed, 15 Mar 2023 09:56:21 -0400 Received: from sonic315-20.consmr.mail.ne1.yahoo.com ([66.163.190.146]:36196) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pcRc4-0003TT-82 for 61960@debbugs.gnu.org; Wed, 15 Mar 2023 09:56:20 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1678888574; bh=O5ntAKsVPPSLvE/iKr2sZtekl3KpgnCqfiSlVbWtQu8=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From:Subject:Reply-To; b=U4jM5AN51DAu8/vrV2Hhqc0v5gT4MdHP1HMyFCdS28aFra0+meQ6zpv001XovWuuAxIsKb4U5oHi2SnYfEIgh0yhCdtz3lJpa4TdgEeG8J6pH/R5DRCGGe5jTnN0lgq7pxlhQ20/Key/LF0/7TIec8aEqbPqGXsJ0wl0W5oS5AaCwvpIUlECQRAmtg+vpUJwSykklu5WizlTSoBgJT6jk2LQw1gTYFrgHv4ddUvM0ohfevDZJSWmtKTsxVV2NTp7nEd3iuFZ8OrytwlF53ekQ0JZaJez4MATD//A8UfWVP9VevopzHsikD99gw4qr91t5L1n853ECzMLKeQudpAKVg== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1678888574; bh=dbc/fXyNN4l1yhwU4RbcegcKWxXhOIEurW6POk4Tl4o=; h=X-Sonic-MF:From:To:Subject:Date:From:Subject; b=p8zvVnMLvEnVyYpn/dPRxr8Wpuwgj1qFTbhZxfzXfsaTRQk4VkCg6mmFry1bNmsFliD+6f3FyB28kWlkV8kq5dJ4DLGjs2PFhoHol70hb7LkWWOA5EgUGhtg+LhJVHz8V1N7LmNZSqTvHf1Kw2DomofRPbL6GVzcPnL047RMzaysJ845awt1u/5BBP8Q2di56q6VNMurnnahDW1P6JIQbgehr2BQcOlL3kFyVOl5dxiziZpZBwC+BiEZrdsU2ZziKktIxFCsZgLYRsWZwHQ0X13AfG0RMeYRh1q23lU8CCIww+84sesxgE/NqetLr/wMImZA8yVeZWKfJ41664+iXg== X-YMail-OSG: fkj9R_cVM1lAMwc9ugGEFD9rkUmBBbPSDIdJ5fkYZbUkIK6V2_DD6ZRm2AfmORV e14zahr7QTPScLNz_WIuMX8eVX9kvse2NtWrotpLndyUkgNliUPUFQL0y68Bq6FGTeqJvMMzSGx2 Gcd7Zi4zE_HNSlH6zDSQVbun.XzPbZyGHLSJsWwntbbHyhmUUu77PFyGKwKVm_lpSzB1P6wUionL VKyypiSaxqCgtSaQWffntj94MNU4CrqLoFCM8VlZe.d6tS_j_o0t85C_CNihkwoNOI4r8iqFWLUP .Nxw6PhcEqbL6vNVMNJS2HSBZ_wvyVGx0XNqXASbJpFV7q0EzflA.3Fkf4YvYn2Su6EXHTmunswc z0NAfgRWjDUi69NqOQMpmkICfqZJ97o0yoxhftv9EWZY_eeu3LfCbkeffhUD6qBa97OlXJXrDGbD JWrVozWT8JbnfMC6rfbOU1L.qHwNLIxTPX5IWEJW4yD21YvUKo9x0h3fhZtJPIVn2ia3lT9CtLP9 eupRWQX4V3MVaivjqi5cAEroy5Nvt0QmaLT1Sc1W1i40i.cvJtSRWRITza1Vlva1kogtG7jAur1l jj0E2N.kJV.7DiWiF4oPaxn6vkZnKAjD8AgN.MoLfV0vm7qvqYoZJ1ugwG9NWIT4lvU9g1eZG.NI rtS7IhVwpHRZNVyPtwVBSwDAHjETvqAP733RMj3Ed4mCYyuoBHyxA9gm7eWjVXsHqCmXLN0XewGT QdQxh9loEqJ0dIRqi4qSfwQYKRXuRw1NChkn2zo3jIBF718xTQLsMghKh4tsw4H0AYtsA4xfGuTz cXOG8Pp61K_mV8NGqZm5lRR8XxormnQ0BsAkEXfPRfT.THVnVF13pUavjxxe7.kLOcogbBoedCp3 lrsI8j8ptQBHZD7RPLtOEYvgtx4S4w5hQZc3HEAic1qU7_QaCFQUkdGLszLUY207qoVjlTr43WFk KbYIM6CjmswzYLAxtOjDsSvvapBrchb4O__3MPQH8c9xs82by3XnickiWPgc__keMgavIWfoE0Sk eyT0gC7uxY7rKKQKfwikoEuxfRC_GTSSrrQEK6z49rtlb4TvwQ8YRZyT6sKvaFZMkMthclSSZhTt FRBfMmFRZ4Nx8_hxn3VZDN_E4.UcdcmpZbnNjn_bJLVa66EGoNerSdK7mCKNeQ6KfagY6KHiBZUr qg5y6LOXNcql1AGQLijyIPz8cm1Ws6lxT3ywPvVxYQrWytCz13QsjL.IwLTUjSVKlax8kpjrzfSV Px3KdQp43k9tWvUSWxyB7XTjNV0Z4wqq72grY9A_cHW8s7y.y_seyVvhG4pmpRxu739BWUYM_wwV u.7goAxYabebL6MKe1ZkxalP_C5lK9b9a2QLa9HudLFzJkZF5AZG6xML29UEu5tQydjrc.B2SVHs .ttKuVUxtBcXHJxU_xtUlJt2XM2F5X5xVfAlw1WvTKoREgoKb4y8mGlR58o96QOVKX8RwsbI_XWH RBpFc3VEe5UD0POlFE_qaPVoZyv8h0qX.07mMsOGuUyBB.WnTiXsCKnGuJwo8N3Qt.8TA1TOS4na xxPwhU3VBmad0FEHnVYwxhuWpKiuvAX4x_TEoy1m4LNgI6U5uEYVLsMpRpaXSdZto8dVlqdB8c2n H4awzEUbX1L8UIGn8jfSDNeLoYaWhB6l.HFW7EmTtEWuh93jWHXxkpG.eojssfno6tCfQY_WTVxv lcaJvCLdF5ANBTEJ.xCe_pRtfUh47hU.PwNCOr3e.YHwaRezdUguAUP8v7bHb6Vr.83UmodutynY 41c.lBRH0Gg58Bh1.WiYngxtVVmx7aXJALZ58zHSe_q4ZTeDf_JwvN4pgLTsftRBHeZZBi.tPDhv hhcc2oeDhCqp7r2ki_AdANNNkAo3FedheoKNhHaLXJITUMY04kaELTEPKRp0YGTYn8xGOaJDWVSe ewfx6q14JRhYcIcJFJJYx17UCITUVAzpx.R5wdPSyRTfYWg7EABpLyX8cdBBLjNjqaSfB81Is9wG wXDjQMF6irG6ZD212QQcxjnXBgycDqmj79L_Xb_hzPbpLGB1hc4hu.u5BY.xhJ3lU_Lj.wgniGOm rzfyVr3cJaEpPVCPKZHV8.KVJ26YTJ10n6NzNgd_N9MSN6ruIHuV2a.g6bw96GBT9kNHIjvrmwTY _PIQY1VKzsGgTt_xv99wfD84983.MhMO3RAM.CrEkePIGdXr6W8taGsXagrPF70Hyv7P3H1xYa0a ytgpuERegh2pfq66EQu0rUJATqE_jeQoQV1IL4.GC0zOM7eyhbVZOhc2BAf2ji1fhvGOsAWPK X-Sonic-MF: X-Sonic-ID: 1467c392-61a3-4819-8d7d-9528bc0a138d Received: from sonic.gate.mail.ne1.yahoo.com by sonic315.consmr.mail.ne1.yahoo.com with HTTP; Wed, 15 Mar 2023 13:56:14 +0000 Received: by hermes--production-sg3-67c57bccff-ddhjj (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID a2f3afeb9a5f835d31d358729d15ebd0; Wed, 15 Mar 2023 13:56:07 +0000 (UTC) From: Po Lu To: Andrea Corallo Subject: Re: bug#61960: 30.0.50; Unexec build reliably crashes during loadup In-Reply-To: (Andrea Corallo's message of "Wed, 15 Mar 2023 11:05:53 +0000") References: <62049aa9ffcf9f39fd423fb87cd8dc8e0b77f9b8.camel@yandex.ru> <7a6e37ed07a49a85a51c8a3a40cadc2b752a38ef.camel@yandex.ru> <83o7p57mz1.fsf@gnu.org> <83jzzs60g1.fsf@gnu.org> <87edpveoq7.fsf@yahoo.com> <87jzzla5u8.fsf@yahoo.com> Date: Wed, 15 Mar 2023 21:56:01 +0800 Message-ID: <87ilf25dam.fsf@yahoo.com> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain X-Mailer: WebService/1.1.21311 mail.backend.jedi.jws.acl:role.jedi.acl.token.atz.jws.hermes.yahoo Content-Length: 497 X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 61960 Cc: Eli Zaretskii , 61960@debbugs.gnu.org, hi-angel@yandex.ru X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Andrea Corallo 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. From debbugs-submit-bounces@debbugs.gnu.org Wed Mar 15 10:27:23 2023 Received: (at 61960) by debbugs.gnu.org; 15 Mar 2023 14:27:23 +0000 Received: from localhost ([127.0.0.1]:40308 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pcS67-0004K8-HD for submit@debbugs.gnu.org; Wed, 15 Mar 2023 10:27:23 -0400 Received: from eggs.gnu.org ([209.51.188.92]:56304) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pcS65-0004Jv-Rg for 61960@debbugs.gnu.org; Wed, 15 Mar 2023 10:27:22 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1pcS60-0005mg-9H; Wed, 15 Mar 2023 10:27:16 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=+FY0npLfLT7wa0YLvTuv5dvBJ8zMQVOwSw+gkc1pKtg=; b=d1Nio0WqeY8g zUCSrn5yAnNZug9tPtRkoGSpMIhop98wdTYv5S4cn8qwYa//G8zIfkIdnhO23jEatERGtJMFHX0n3 1pBJJGbzTEodEsb+RE0RoyTZEcAxb/mHjvX8c7gd9Zw3E2fJ1DXcI+gusL8sHtfpfRwNlCoa2kyGm HKaAobvA8UTBTj8RwkkVQ3dT/DoGC0N6FMgV6+CLJvGsoGNNlBK7UVAYq5q8fGpWoRxFIUz1jJaZH kqlbC1QC8jj5iWdwO0Rdv7ImrUGoy+SKSBU+kHan7GM/cEH4Pc1pI/HpYWJE26VRvgkiCdyC1d2Q0 6/9vnyKytHKX9mhrcdt1uw==; Received: from [87.69.77.57] (helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1pcS5j-0003Gj-5z; Wed, 15 Mar 2023 10:27:15 -0400 Date: Wed, 15 Mar 2023 16:26:55 +0200 Message-Id: <83v8j2qeds.fsf@gnu.org> From: Eli Zaretskii To: Po Lu In-Reply-To: <87ilf25dam.fsf@yahoo.com> (message from Po Lu on Wed, 15 Mar 2023 21:56:01 +0800) Subject: Re: bug#61960: 30.0.50; Unexec build reliably crashes during loadup References: <62049aa9ffcf9f39fd423fb87cd8dc8e0b77f9b8.camel@yandex.ru> <7a6e37ed07a49a85a51c8a3a40cadc2b752a38ef.camel@yandex.ru> <83o7p57mz1.fsf@gnu.org> <83jzzs60g1.fsf@gnu.org> <87edpveoq7.fsf@yahoo.com> <87jzzla5u8.fsf@yahoo.com> <87ilf25dam.fsf@yahoo.com> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 61960 Cc: hi-angel@yandex.ru, 61960@debbugs.gnu.org, akrl@sdf.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: Po Lu > Cc: Eli Zaretskii , 61960@debbugs.gnu.org, hi-angel@yandex.ru > Date: Wed, 15 Mar 2023 21:56:01 +0800 > > Andrea Corallo 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. From debbugs-submit-bounces@debbugs.gnu.org Wed Mar 15 20:30:20 2023 Received: (at 61960) by debbugs.gnu.org; 16 Mar 2023 00:30:20 +0000 Received: from localhost ([127.0.0.1]:40785 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pcbVc-0007Tx-F4 for submit@debbugs.gnu.org; Wed, 15 Mar 2023 20:30:20 -0400 Received: from sonic313-9.consmr.mail.ne1.yahoo.com ([66.163.185.32]:46225) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pcbVa-0007Tj-AY for 61960@debbugs.gnu.org; Wed, 15 Mar 2023 20:30:18 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1678926610; bh=NrssZsMPRFKqLyRzv1hCOfC8v8xnBP4RE4FyttgzeTg=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From:Subject:Reply-To; b=EJh92c7YzdAfuyM6DnzW2aFYDLTAT7tJit4h+cjlPhTf5hfCdOShqBU37PagBt1Qjy/9hZLZiN8nwFMBXPCJm5W3c6sxUS27GTPzfUCsjbSuEDPiSHN1v6h8HobVHNaf18G2tUp2payIsj8inDauAyAxDfkzpp/POcXIcbZkBeu20XA7a+Po8PxQK6xO9nMuZS816JlV0yK9yZX0T42vHyvq9eDVRGnJlIGhowP63KNaEQaVuNIkP6gbxFIN16uJzuPQrPp5JDdY1sGSWa4mo1bDXVNf5fPxocKmAeIHR48TR8AyCMHnGH5G4Y3SQNAkpHqgY2LyMDGo66Vcnv92Vg== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1678926610; bh=AlXTo6QSvgQP6Qy0iQpu+zl72otG1mz6/JYSv4+zrw7=; h=X-Sonic-MF:From:To:Subject:Date:From:Subject; b=EleFHo1ehf1xWG7ogygi9Sfnvny/V/bVpHbj08RpbUwcZ1Zh8wUJRyPCZj87d+jpKYWBGMk3wcWPviSGL1U5fb0hexO3GbI89K4FYk+n73w2sxJFssAuDNOMKJknHTP+DxU1Qa6EKvxAzUsX6fEtwfm4PTaXYiisHk6myj1co2fANg4q314/wZgKVG/eUMuGUYMyEyetfCEJ1qqxnGcb1knt7m3qwU8WvAP+bjCoDJ2Bb6ygGk+ViDvdVQ6WMan47K38GHPsjkkzHBNiABK0EHgDsC0JwqPqzv8t9ZQzJnsYED7mexlCNxs7sF8RMvwIeiOOgeo/FBSbWYCVFcrqjg== X-YMail-OSG: 6LLbnM8VM1mbHtSjiPqtleZM5dSCg_gsioYLiITjZqBSoSsgPoiy.jZK48azxfG rpI4BBuoyei7dTRe9G5XtvYp9EcmpzwX6k91AFjk4uFH8rSILuTvrRadKp._amBiMbFV6v5xxBgP cpOpU2.t2RBttg5WGQetwle5ZyxfNUvn4lVY2qYJsGSvLSUyX2PkL5kd2dSbsSlsuYdycPuexNjK ODH0fQaf3zacViLobzfu6Q2Q1AM03cIcje2z_W7gbv5.9skdiyLHWRlGQx91_uVq0Um3LNbjwOZo 2SJkvhT.Pam1e_i_Q1uS1nnMVEWvXwDAEoGVtOMONQHx2Br4cjqbu36dadgMIbpbdOGkP9TOVVO7 4eUT6IF5hgYWY60OUzyjLW.47dbGYVD49wGJyxN2YUjHUYzt1FLX5FESUOnumUjlHs3EI4aCQyP5 VazR5JChvQtBZRKYgJnnz_mxe88xla5qxbO7RPqolHhH5zb56Qr4cQaudOMv3PsGkjsNyB6l_MpU B2BuWtnCqYW3KjEIjgS2kRbO1pF9Po9OVrmdrTWM8Urk66YXuITLq3jk2qhE4KtaQXIs4977Vhnu s8eYMBIWAF.evBgWyqJMzFwZVq_sv6DM86EtppHMH43P8JsL7ErjoBIMKxkePe2LiOtfMPDaXKDg g7E8wddQsr58ij_ppp16BIUP7bcXyhyCChFqhxX1MJhzACTWRXSRxMNQSYB.mGPYYWeF.Z8s.uak R1sQfZ.VoY1J2T582EfyBh7avRYqxRtiNkZaSwPsC.Bj3ktOCiZ8fUxfa0f4iR4qMsZ.v6m5HAGu aRECQcH.E2LZWqqrq0_2q1p19tjHJxyJpXuXK_Z1CJwRLQVqRlgj0qd6HMrYylOKXkU6bsPd139a oF6xIg4H6RwjCzXXs8TLN6izJyUIOvCXweEF2tYdeQdxDGd4pKj.es4fv_VTrGTZJHMotWop_FZ7 TXaPyK7b66.R81WaNudpuGg4cWnbgGriDeDlCiYMJVUCzHHTRwHXeujwwrZTRqJs11h8Q8iKJsXY BDbXX3TC4MedAvknfaNjlm8Yz3PIIoLXb0AQ0aADSY6GCnrTrjve1oOjrY2dZq9UAWUfEg_NwgOy GgB8OG_qQj4rfM0gYDzl8hXRJsvYLZELNIU43zt95fEMFzWzgd0SyXhYKUKZ1ep3qdAj_Ci3EbhB Mlp.KPqWIhnaMgxGNeDHKoKBNTStN4.ndbjw__ledaAnujH.oBQsasmGZl9u5_wJ4MG6g2To.9p. gmEFutsVq22HSvqMUKj84EdwuuCpMB0h_IJx_JQ3AwwqIZpW7ppxxIkN2BFtL3k0UGElK6H388GS n4lISw01qGCCTOENJhLm6waNsTjMcyiFC9JkcCv4JSpwoeUULkyGv9yAwQihV.t6b7gTB80oK4E8 evade6oUGG5mVJXWM4VFCG6_chg1kMNKz12NdW8Bu_q6Vg._ttIBvIM4a9yS5mnw40g1hRH_qv9b pRlybWBpB8N6K.d0SMuUTpUhN03_rA2sG3pTCWBeYRqDV2mSc18Q8dcScCLuttTL9zmVKKtrC.Nz XjQlh0WnZKdiX5Z_A3f79YxKgXp17sPNInsJfU.Hm8eIsF53W_KSPUY1DoDCcvraIQiOU1v_v6ma CGGE0lgDIoluqhLU4L5Tmay_YlvI5ztdalhSWEHfQn_K7FvFe_pjl0NkJ1jve6KAxmk3CCvzkVMJ NIQWUhPh2TuEIVp7.94xRHrwvEGboHlr112XdL8r44KcK0VrngeVR50xzt6ezO.uvPCSkVeXtmPz q4OfIyBP90HtSXM6tlrtfUkMcSSFj3KXlAOR_gxih297NO3wPceBCoPmoROxBH9pFr3zXNsiOJzM zLpirmzoSr0SNx1oieStUqcBCcI52e4pN4T1n4SzuNNf1xYi9g_pShI6DAWiSu57I3dsYBlQllIl QI15Sp9A.PijpOU_0npmFkpfG_6piPaKnMbBAHSG2u1t80JEy_Nufip09H8ykZKyV8.RW7FcoZj2 0Nfo2vU5r8CKsek.HZtFHK3Y6bBq8RzPSa4ei3.kGcgmsYhJiAGFssYpZUYFCl74rP6txI.XktiH y_aUhEUBX7LvvdTJBfoDvnN7vxP8460aiFvT1dqBip4dNt_r6wdGfqRfHYcBKCOV6v7hFzt9L5Hm sCu4Ex_VcIaI8R2J255Z2wbLRV8YkpGJl7BkuqYp0l2uCujS.9qrgZI53NIfFl19Gjg51OsSfuhN HyK2od1JfAdOU4qMS4wOrBDb6Eh1bIhvuROkaBqdbAOWq3mGiT1evMoHmV.y40g-- X-Sonic-MF: X-Sonic-ID: 86845dbe-63c4-4ce3-97ec-de41e5987617 Received: from sonic.gate.mail.ne1.yahoo.com by sonic313.consmr.mail.ne1.yahoo.com with HTTP; Thu, 16 Mar 2023 00:30:10 +0000 Received: by hermes--production-sg3-67c57bccff-sjmln (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID d25d1a7515917de7e182b9c2ceb8ff83; Thu, 16 Mar 2023 00:30:05 +0000 (UTC) From: Po Lu To: Eli Zaretskii Subject: Re: bug#61960: 30.0.50; Unexec build reliably crashes during loadup In-Reply-To: <83v8j2qeds.fsf@gnu.org> (Eli Zaretskii's message of "Wed, 15 Mar 2023 16:26:55 +0200") References: <62049aa9ffcf9f39fd423fb87cd8dc8e0b77f9b8.camel@yandex.ru> <7a6e37ed07a49a85a51c8a3a40cadc2b752a38ef.camel@yandex.ru> <83o7p57mz1.fsf@gnu.org> <83jzzs60g1.fsf@gnu.org> <87edpveoq7.fsf@yahoo.com> <87jzzla5u8.fsf@yahoo.com> <87ilf25dam.fsf@yahoo.com> <83v8j2qeds.fsf@gnu.org> Date: Thu, 16 Mar 2023 08:30:00 +0800 Message-ID: <87edpp5yif.fsf@yahoo.com> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain X-Mailer: WebService/1.1.21311 mail.backend.jedi.jws.acl:role.jedi.acl.token.atz.jws.hermes.yahoo Content-Length: 403 X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 61960 Cc: hi-angel@yandex.ru, 61960@debbugs.gnu.org, akrl@sdf.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Eli Zaretskii 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. From debbugs-submit-bounces@debbugs.gnu.org Wed Mar 15 20:33:35 2023 Received: (at 61960) by debbugs.gnu.org; 16 Mar 2023 00:33:35 +0000 Received: from localhost ([127.0.0.1]:40791 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pcbYk-0007YW-Vf for submit@debbugs.gnu.org; Wed, 15 Mar 2023 20:33:35 -0400 Received: from sonic310-25.consmr.mail.ne1.yahoo.com ([66.163.186.206]:33952) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pcbYj-0007YI-30 for 61960@debbugs.gnu.org; Wed, 15 Mar 2023 20:33:33 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1678926805; bh=b2QR0CBM7wJDMsHgG6+darj4zqyBVablf0zF5UWO7y4=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From:Subject:Reply-To; b=qQHg6Wphcpa1A18wBrohEI7/7HzE6PALv+qtfVj5Zh70epmSWRR4Qsg4eihG9BKyJFoJ8aCzJ+k1wE0u71I/OG3Iro0B6QjiTJQz7NH9vumZp1Q1qAqu+zgahIwu4nBLV4qx/VK3whEIZKNV6PKt6n6e1ZjDyUSSKpSXJwqIEej4kjppHW1e7vCqKxJ0EFoiFzGWdx7xSkXOAWSlF/AQWwiGnF2Mk+Fg2yQBGk8Ta8XswXL2eBZpjg3zSS0DyKr/ckUAfeqBeSP3S7AlS4CIxRa7EcgbrLB+gpbifWuK3tP3mR9D6IIdf3Ym5rfY60ayvv00LT9WZA8ain31ptJeTQ== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1678926805; bh=xiWfOVSHrkTf89OgcXtJJ7cvMxPOLFtqUUXf5M+QcjZ=; h=X-Sonic-MF:From:To:Subject:Date:From:Subject; b=dqXS6VTerPf1rJlwPv7qvo615uvWMmi6VRDY6LPRvpeCmuA1fgUjROiRb93zIrxQU+Xi2sJG3IPUS3O8lyMoO/BxekvkEsTjvxPZweyoaghLdiGAmDqsAHYYrKr88FJFcUHBGdDuATUbVUmOfDVz9klGSTL9iR+VryUyw1tE7UNOlpOgvqRB4S6fLeWzBog4kR7qyKzZ3nuvxb9U/fOyXDUb6a7cmy7CDYZiZwnTH4JdyA6nVQmWrATnexik8A8lsk+FuQBFBfGe3vTc9HUmWlOAUgEyz7A4Gmg1LVCGwwB9KAwcmebDbx3J4Q64lYQUCAUOB9+mPMlc/Gj/GCgHPw== X-YMail-OSG: FZ5CLTEVM1mWCzq3J1dC0NdzgCS1LbxJm_UlqzEo7m7b2T9ypVsiep1r4WPv_SR Jk8orktobCkHxwbVW6SldKn9P0yq6zAcp_pOXm0YtM._iBsxJxgilQYD2U2jEoVLaf6isv9esfFC lAaW.lbQvs5SwX3DVqV5yur30L9YtlHyNru4l5nyTWqI6O0JTetZTMz4u.jw1ShvWIeuYYoRpXXk o2cTVKxj2P8aVlX5XNrM9b3XkX3QIAqPdZ86mjuTcgjI_skeJns7cK1EAGyj2zmoToNWvrylXOG5 WeBCn.ud8mcm8DGaIUtymyUNDV.4hQ.ivclz94DLQDHEXBsnfNcJElRi2ZHEnvDoVMhzSY3jcNJZ DZJasKDQ1EQc2lodpTm4gx8B0yXJDwAn93JikjkMtEKmi4isu6RGGK6dyIVBR.2o28LR46nqrwKJ zCfq0EMzNmcdXoCeDrr4QkJfgCNz5PyNrChFLhZJby4vDLP3ct72RX.scBtAOBtg.T3pNaCKIIVe .UlBRAzUaTrfdyePoPH8TOS1lHFUTJZWJjkX9cGeQKgmA8YPnCebDwU5KnSkpNtHlGi16AgsANxG F5pUMPEewuq.lTSCQLAgau_ZG0JMzyfxtGKUmTrAwAFGqSh2anlMe6kWUKxsvcTXkGH.Laf7FmDB yLxmuAitYOEX4QIvipR8aVZ1RlD1FNuW9nMhE8PeCYB9fsRBN9.CE.8N7X6aK3PsfCr91wKsQFBM BgopmvfbWGfV4yI4VRiOGT9TnGqwDAgm_aDF6WaI_EnR0eyTfI4GApXmXiaU_Qz9UGBnKiVTkgwu _Kd8SBM5OjAspdKEtuAY4jbyQXEUdxiMRVsGScRWb0wLgrjnXgr8M9ZoU9LG2mO9ZX0WtTR_PV_E CzSkwsEuLLqVFUb8ObFUPOjIU2t4WCXtjkuAU28cnF9eOe8nJymHoUjvJjrlEuAWq8SkhFGmeTJi UccFe17lAJ6UCWJtUi5h50DQqbgOWLughefHIQEQLJa2pnv8L8lmJxigx5brCj25KpLxle9aX2C6 k7lSKt8Aci8f6mJ.PslZUWjPznYMhEM1tgqicEySkgtjs.BRro45Gi4uUtQdyKm0ktahNWm0BHmH B5kb72p9LY6JUcECA8GTlA7BjH1yQoDeNk05ZNr9FV_Sqlt9k8tOBO3uyY.aOGp0yOvBXDWqSbOo 1gVG8JueNFRd97Kw5Zg3lyta.1Yb6MQANOzyygeTFkeSpfMK7P429WuiEMOMY2wnz3sNBun2DlPV 4qbXMXdAYq7USR3OMIfMnTaBrO8AqSluRjCwnXjD5FvLwKEudJTllIH1OrJ1D21Poy_LV9k5Yl13 o3hs7nMjnDnOXpQJ9fVfecdF7OXdPRILTeMplg0VP4YqvkSr_tBu9bX_4pHBj32ELLZ3HOuy.j.L wdA3IvcTQ_EuUMoY5gqn9.OWAdWanbV5AdlIiz6e4P.5gWxq9umTOYP4OrJkxVbv09WIfYgtIz4E 7X1J0vNNWOyVsKy6ico10Bu9sQPgDgvSy2Im2VkG5kCvwyCGhkgRu96T7zs.oV1RQENnzRS0R3J0 StHjE_m7wrf0sGUltufWtgCpvQ7WB9xGzSbKIoM9WtaNkbPrVQyFbqBH8pSW9IVeL2srobf6.tGS NQdLVmX4DUoi.v2XQCg4rLHBa76CTXBz.N.ELygXBPd8YuxkYne6JsaJIKM5YMc67_yRaJuNmFl8 UU1CrN2wouZ6rBQEuvdpmvjWhM11SNKnR2vMmGWy3GhpYOTkY6s.oIwdXRV_S_29fk0X4ef1FVQv 1Wdu_N13QwN0ipesdyDODthkUh8eGz2rYwj4GzdUZrWzy5vjqSWkp5PZxbp7_pAZ8onNNHspaC8m yCBEZL_6KPA7_.iQNTYjY6q3F0HdCr8t.toi36_XAnhZkE0C3Ujfl0nFjMep.ynV2xLylkNnL0Sr mXflX0m3m5Z35cyTQQl9h36o.3JuB8TubVtSQ8AWsUO2jHpiP_v9yQQ3tVKquTAD6iZX0WWFnxs9 cfdw1VcbQdO0awS1r1.O8eBiesYQJDFmU_eciZ1WDKz6KiKBNoqiFcp4li6N04ZjzPiO0ZpOchMc tIjEW9vqCSmlqH2Ntn8lZONCfpOn0IMy4PW8Sg2FfWRcWxrusOv7cD0jMohPt.oJ6EQWzVB900gT esc1wUwxl_uzqE8F.WUx1veutzi82D7zZih76.HQ2Dfdb0LM6SX.4GvPltweLeN.ZRYs9erb.Xmo bOBOknr6FoHg1r.jGxbPG8Qt0XT0VdnXUwtbUzvejKKqX8SmqZokrUhmuYnz.G0sZ X-Sonic-MF: X-Sonic-ID: ed0dca5a-81be-49d1-8220-01518d7086c0 Received: from sonic.gate.mail.ne1.yahoo.com by sonic310.consmr.mail.ne1.yahoo.com with HTTP; Thu, 16 Mar 2023 00:33:25 +0000 Received: by hermes--production-sg3-67c57bccff-wt27l (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 8e7bc4b9f23204cc1c5c9fbe743e2b0d; Thu, 16 Mar 2023 00:33:23 +0000 (UTC) From: Po Lu To: Andrea Corallo Subject: Re: bug#61960: 30.0.50; Unexec build reliably crashes during loadup In-Reply-To: (Andrea Corallo's message of "Wed, 15 Mar 2023 14:31:26 +0000") References: <62049aa9ffcf9f39fd423fb87cd8dc8e0b77f9b8.camel@yandex.ru> <7a6e37ed07a49a85a51c8a3a40cadc2b752a38ef.camel@yandex.ru> <83o7p57mz1.fsf@gnu.org> <83jzzs60g1.fsf@gnu.org> <87edpveoq7.fsf@yahoo.com> <87jzzla5u8.fsf@yahoo.com> <87ilf25dam.fsf@yahoo.com> Date: Thu, 16 Mar 2023 08:33:17 +0800 Message-ID: <87a60d5ycy.fsf@yahoo.com> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain X-Mailer: WebService/1.1.21311 mail.backend.jedi.jws.acl:role.jedi.acl.token.atz.jws.hermes.yahoo Content-Length: 1059 X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 61960 Cc: Eli Zaretskii , 61960@debbugs.gnu.org, hi-angel@yandex.ru X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Andrea Corallo 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 From debbugs-submit-bounces@debbugs.gnu.org Thu Mar 16 02:25:40 2023 Received: (at 61960) by debbugs.gnu.org; 16 Mar 2023 06:25:40 +0000 Received: from localhost ([127.0.0.1]:41033 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pch3T-0000Mi-P4 for submit@debbugs.gnu.org; Thu, 16 Mar 2023 02:25:40 -0400 Received: from eggs.gnu.org ([209.51.188.92]:49434) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pch3S-0000MU-3y for 61960@debbugs.gnu.org; Thu, 16 Mar 2023 02:25:38 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1pch3M-00084Q-8Y; Thu, 16 Mar 2023 02:25:32 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=g1Bkwe7GTHZa3N+/ZA/uReusznSpm9QSrGHyhY9z19M=; b=Iuic4brVmSfW xUZ0yOZgmKw3JJ1xFhZjAqXp8dTMdt1LaLNU/d70hhergOyDv3OeeLFq5X0gjM6Cj9vPPHmTtO5V/ 4n5F5/vf+p6JV4LcUC7fR+sItvd4PkNwYCRklLTD5Qp8y6ifvT1j3Zem+jD6uUNCj8CtMRIKnYSrg 6h5RD/L35Z6KVHIEYmgvhJhRELEpnoB/kwAyksQ/rt9bfTmrO1YxWGkowAZvvEbY3ZYdqaQDjBXNy WK8XT3Tz+53/NozpIIA2rx4WXjeIpfptlJv1XxPfspLBvYZ7LMRG/WWRh7gRWDbMw3UGeXFUVB1Ck iK5h5RSAHFGdERHxeH84Fg==; Received: from [87.69.77.57] (helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1pch3L-0005BV-82; Thu, 16 Mar 2023 02:25:31 -0400 Date: Thu, 16 Mar 2023 08:25:28 +0200 Message-Id: <83ilf1qkkn.fsf@gnu.org> From: Eli Zaretskii To: Po Lu In-Reply-To: <87edpp5yif.fsf@yahoo.com> (message from Po Lu on Thu, 16 Mar 2023 08:30:00 +0800) Subject: Re: bug#61960: 30.0.50; Unexec build reliably crashes during loadup References: <62049aa9ffcf9f39fd423fb87cd8dc8e0b77f9b8.camel@yandex.ru> <7a6e37ed07a49a85a51c8a3a40cadc2b752a38ef.camel@yandex.ru> <83o7p57mz1.fsf@gnu.org> <83jzzs60g1.fsf@gnu.org> <87edpveoq7.fsf@yahoo.com> <87jzzla5u8.fsf@yahoo.com> <87ilf25dam.fsf@yahoo.com> <83v8j2qeds.fsf@gnu.org> <87edpp5yif.fsf@yahoo.com> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 61960 Cc: hi-angel@yandex.ru, 61960@debbugs.gnu.org, akrl@sdf.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: Po Lu > Cc: akrl@sdf.org, 61960@debbugs.gnu.org, hi-angel@yandex.ru > Date: Thu, 16 Mar 2023 08:30:00 +0800 > > Eli Zaretskii 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. From debbugs-submit-bounces@debbugs.gnu.org Thu Mar 16 02:26:49 2023 Received: (at 61960) by debbugs.gnu.org; 16 Mar 2023 06:26:49 +0000 Received: from localhost ([127.0.0.1]:41038 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pch4b-0000OV-97 for submit@debbugs.gnu.org; Thu, 16 Mar 2023 02:26:49 -0400 Received: from eggs.gnu.org ([209.51.188.92]:54448) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pch4Z-0000OI-Pv for 61960@debbugs.gnu.org; Thu, 16 Mar 2023 02:26:48 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1pch4U-000183-JC; Thu, 16 Mar 2023 02:26:42 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=7RaznHOWSsqx1YWaLKPFBzJNIeHLTwKP4ngBKeB4a3M=; b=mM9Us8Xf9iWA Wo9hxEF1Je+A8eLRI9pVtbCk8tGjgSpHPV+Uc367IYxWHfNn56/PYW1ZeCXS2VMWMGG6PBIGThhPw k7ZaHGq52U6RgeEHz8ppGuypZr9zBpTbHH7gLqvPGPeK8YuWTBfdGWeft8BQKYiqCZTW7l+4CJS+d uH5mB29F/6WdKG5Y3I8/OiOSmGSdSswf6KYKYJvnsAqeUM0/WedOfoZHtsLi92fMzJKSAngr7qKO+ wbBP1IK4MtwHB9ZTIxq20Y70mAp1i/wUOO14vHO/aB1c63Lxxd1Na0w/8Xaww4W2e/Y2A6Ch1Mz9l hx87rSyKS/bM4vo3GYOqLQ==; Received: from [87.69.77.57] (helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1pch4T-0005I4-Vn; Thu, 16 Mar 2023 02:26:42 -0400 Date: Thu, 16 Mar 2023 08:26:39 +0200 Message-Id: <83h6ulqkio.fsf@gnu.org> From: Eli Zaretskii To: Po Lu In-Reply-To: <87a60d5ycy.fsf@yahoo.com> (message from Po Lu on Thu, 16 Mar 2023 08:33:17 +0800) Subject: Re: bug#61960: 30.0.50; Unexec build reliably crashes during loadup References: <62049aa9ffcf9f39fd423fb87cd8dc8e0b77f9b8.camel@yandex.ru> <7a6e37ed07a49a85a51c8a3a40cadc2b752a38ef.camel@yandex.ru> <83o7p57mz1.fsf@gnu.org> <83jzzs60g1.fsf@gnu.org> <87edpveoq7.fsf@yahoo.com> <87jzzla5u8.fsf@yahoo.com> <87ilf25dam.fsf@yahoo.com> <87a60d5ycy.fsf@yahoo.com> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 61960 Cc: hi-angel@yandex.ru, 61960@debbugs.gnu.org, akrl@sdf.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: Po Lu > Cc: Eli Zaretskii , 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. From debbugs-submit-bounces@debbugs.gnu.org Sat Jul 01 21:50:36 2023 Received: (at 61960) by debbugs.gnu.org; 2 Jul 2023 01:50:36 +0000 Received: from localhost ([127.0.0.1]:58912 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qFmEV-0007Tf-RJ for submit@debbugs.gnu.org; Sat, 01 Jul 2023 21:50:36 -0400 Received: from forward502a.mail.yandex.net ([178.154.239.82]:40778) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qFmEP-0007TT-Tr for 61960@debbugs.gnu.org; Sat, 01 Jul 2023 21:50:34 -0400 Received: from mail-nwsmtp-smtp-production-main-74.vla.yp-c.yandex.net (mail-nwsmtp-smtp-production-main-74.vla.yp-c.yandex.net [IPv6:2a02:6b8:c0f:5d0f:0:640:79fc:0]) by forward502a.mail.yandex.net (Yandex) with ESMTP id 3B7F55E72F for <61960@debbugs.gnu.org>; Sun, 2 Jul 2023 04:50:27 +0300 (MSK) Received: by mail-nwsmtp-smtp-production-main-74.vla.yp-c.yandex.net (smtp/Yandex) with ESMTPSA id QoESg2DDSW20-nMz0an3U; Sun, 02 Jul 2023 04:50:26 +0300 X-Yandex-Fwd: 1 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1688262627; bh=FB8vToaYXpM8CcFNXxN8PuXVDQkn43NKVwwi0BOrxgQ=; h=In-Reply-To:Date:References:To:From:Subject:Message-ID; b=KZ5lC4q5vKfN+5rK2d1B4+C38OqJL++ejy9MUgj5PRxeNOmvl+cC42HLwjRGNIO7f xSx3bqGMErGXdBjiku1bXXkvVtUcsqs1Zu81gpRoYT/CY9aLynbr2nOWulIirsXPih XJRYs8B2P9Fy6ODKaAFyErmP7xLKLPuaL4voF0J4= Authentication-Results: mail-nwsmtp-smtp-production-main-74.vla.yp-c.yandex.net; dkim=pass header.i=@yandex.ru Message-ID: <63f3de6f0cc0d015d2dcbcdd6adc95482dc0c6ad.camel@yandex.ru> Subject: Re: 30.0.50; Unexec build reliably crashes during loadup From: Konstantin Kharlamov To: 61960@debbugs.gnu.org Date: Sun, 02 Jul 2023 04:50:26 +0300 In-Reply-To: <62049aa9ffcf9f39fd423fb87cd8dc8e0b77f9b8.camel@yandex.ru> References: <62049aa9ffcf9f39fd423fb87cd8dc8e0b77f9b8.camel@yandex.ru> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable User-Agent: Evolution 3.48.3 MIME-Version: 1.0 X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 61960 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) I've found a diff that fixes the build, but whether it's okay is worth disc= ussion: 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 =3D BLOCK (ptr); size_t blockmax =3D _heaplimit - 1; - return block <=3D blockmax && _heapinfo[block].busy.type !=3D 0; + return block <=3D 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 internal= ly 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 <=3D blockmax` simply makes sure that th= e `ptr` passed is within the stack-allocated memory, which implies it can't be deal= located with `free()` There's a question though of the right-hand side that I remove, the `_heapinfo[block].busy.type !=3D 0;`. Apparently the `type` should keep som= e 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 `tema= cs` (probably a bug in rr), and without reverse-execution tracking that down wo= uld be very hard. But I would argue that the right-hand side check has no value in this funct= ion, because to determine the source of allocation it's enough to just check whe= ther `ptr` is in _heapbase .. _heaplimit range (barring the fact they're different uni= ts). From debbugs-submit-bounces@debbugs.gnu.org Sat Jul 01 22:27:41 2023 Received: (at 61960) by debbugs.gnu.org; 2 Jul 2023 02:27:41 +0000 Received: from localhost ([127.0.0.1]:58958 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qFmoP-0008Nv-Hl for submit@debbugs.gnu.org; Sat, 01 Jul 2023 22:27:41 -0400 Received: from forward500c.mail.yandex.net ([178.154.239.208]:47070) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qFmoL-0008Ne-B8 for 61960@debbugs.gnu.org; Sat, 01 Jul 2023 22:27:40 -0400 Received: from mail-nwsmtp-smtp-production-main-39.myt.yp-c.yandex.net (mail-nwsmtp-smtp-production-main-39.myt.yp-c.yandex.net [IPv6:2a02:6b8:c12:2891:0:640:3c15:0]) by forward500c.mail.yandex.net (Yandex) with ESMTP id C20A05EA62 for <61960@debbugs.gnu.org>; Sun, 2 Jul 2023 05:27:34 +0300 (MSK) Received: by mail-nwsmtp-smtp-production-main-39.myt.yp-c.yandex.net (smtp/Yandex) with ESMTPSA id YRFdwpPWm4Y0-HGSCKLs2; Sun, 02 Jul 2023 05:27:34 +0300 X-Yandex-Fwd: 1 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1688264854; bh=W/HHpBJfPuuKWxnXespmysj2wx5t6rLKcKeRTRObQwM=; h=In-Reply-To:Date:References:To:From:Subject:Message-ID; b=EQRu196QjX3TWxkhaXZQh1xNv3Yi1JRzDq6kpEmcJ8H3wTRC8ntk7xR7i+Dy5u0zl mZLsCqDzw+YiCJG71vdEUOxOHOQWK6gs1RDC3EeQ+Qj8ldbP2JwjCRXZUDMt8q7kv2 8bhBey7/ilZvnd3kvku0qm8mxAMLTHetS7FdDWOc= Authentication-Results: mail-nwsmtp-smtp-production-main-39.myt.yp-c.yandex.net; dkim=pass header.i=@yandex.ru Message-ID: Subject: Re: 30.0.50; Unexec build reliably crashes during loadup From: Konstantin Kharlamov To: 61960@debbugs.gnu.org Date: Sun, 02 Jul 2023 05:27:33 +0300 In-Reply-To: <63f3de6f0cc0d015d2dcbcdd6adc95482dc0c6ad.camel@yandex.ru> References: <62049aa9ffcf9f39fd423fb87cd8dc8e0b77f9b8.camel@yandex.ru> <63f3de6f0cc0d015d2dcbcdd6adc95482dc0c6ad.camel@yandex.ru> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable User-Agent: Evolution 3.48.3 MIME-Version: 1.0 X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 61960 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) 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 m= e and I will make a proper patch with explanation and with the removal of the `if= def HAVE_UNEXEC`. From debbugs-submit-bounces@debbugs.gnu.org Sun Jul 02 01:51:56 2023 Received: (at 61960) by debbugs.gnu.org; 2 Jul 2023 05:51:56 +0000 Received: from localhost ([127.0.0.1]:59030 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qFq04-0005d3-3F for submit@debbugs.gnu.org; Sun, 02 Jul 2023 01:51:56 -0400 Received: from eggs.gnu.org ([209.51.188.92]:53302) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qFpzy-0005cn-UO for 61960@debbugs.gnu.org; Sun, 02 Jul 2023 01:51:53 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qFpzt-0000mA-Je; Sun, 02 Jul 2023 01:51:45 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=7lyV12hSUcpbLqmspi0P/3Ewp4wLSKQzL6rke/iaxSo=; b=OSXoS/MuhvwI Z1MMJcZTN8p/EoqNanmPkHPosz6nL7/gKo7/Vu5LYGE2Au9Bkm1bZwGZkDkcwvjD4+42Tlnh5/lBl wfYHa5RO6odPMPSBwBr+CsFQ8/Ab6v/BkbSiK/jq5Zy/Ewelj9Vo7UinOQ0FE5x+M7EFjz297LoMg vOviu2NfsvuLOpR+Q6eLB+wyNLhCGpg1ljarrRDAc0kGuCDBSr5Jk18to/+WZwuiFPVzt0QkrLBOl fWpLPsIhzanF7FNqW34WHUrR1YdZoTdxfctbDYg/OBStsrQ5/x7HIocwvWJwLn7SxcB85DhZrFiFC ElF2O4dayucR8Z9KYHoBHA==; Received: from [87.69.77.57] (helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qFpzt-0004vS-13; Sun, 02 Jul 2023 01:51:45 -0400 Date: Sun, 02 Jul 2023 08:52:18 +0300 Message-Id: <835y72q2r1.fsf@gnu.org> From: Eli Zaretskii To: Konstantin Kharlamov In-Reply-To: <63f3de6f0cc0d015d2dcbcdd6adc95482dc0c6ad.camel@yandex.ru> (message from Konstantin Kharlamov on Sun, 02 Jul 2023 04:50:26 +0300) Subject: Re: bug#61960: 30.0.50; Unexec build reliably crashes during loadup References: <62049aa9ffcf9f39fd423fb87cd8dc8e0b77f9b8.camel@yandex.ru> <63f3de6f0cc0d015d2dcbcdd6adc95482dc0c6ad.camel@yandex.ru> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 61960 Cc: 61960@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: Konstantin Kharlamov > 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? From debbugs-submit-bounces@debbugs.gnu.org Sun Jul 02 07:32:19 2023 Received: (at 61960) by debbugs.gnu.org; 2 Jul 2023 11:32:19 +0000 Received: from localhost ([127.0.0.1]:59429 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qFvJT-0000On-3d for submit@debbugs.gnu.org; Sun, 02 Jul 2023 07:32:19 -0400 Received: from forward500a.mail.yandex.net ([178.154.239.80]:40402) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qFvJO-0000OZ-5x for 61960@debbugs.gnu.org; Sun, 02 Jul 2023 07:32:17 -0400 Received: from mail-nwsmtp-smtp-production-main-74.vla.yp-c.yandex.net (mail-nwsmtp-smtp-production-main-74.vla.yp-c.yandex.net [IPv6:2a02:6b8:c0f:5d0f:0:640:79fc:0]) by forward500a.mail.yandex.net (Yandex) with ESMTP id 791045E888; Sun, 2 Jul 2023 14:32:11 +0300 (MSK) Received: by mail-nwsmtp-smtp-production-main-74.vla.yp-c.yandex.net (smtp/Yandex) with ESMTPSA id AWO3SrGDXSw0-mHkG6dlw; Sun, 02 Jul 2023 14:32:11 +0300 X-Yandex-Fwd: 1 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1688297531; bh=gGO7v5ZBDeuT0WNqMG6HdLvIlvQD3dUvuLCOAQq8CAw=; h=References:Date:In-Reply-To:Cc:To:From:Subject:Message-ID; b=jFThEVod1jAO5fFkh8XWhYGqaLSLDdKNbHhVbL9ZcylnDFC3ySud0IIMK/rXys/Eg 0iWhNSit27aD9HN+cVjhxpHUMCz7RpEnDO1v5pD0vn8tMkO2kDBaAny57peoxsz+rT gFrXg/PRTKWjsMtBxV3tl9BXdJoZK7buMUJMYhjM= Authentication-Results: mail-nwsmtp-smtp-production-main-74.vla.yp-c.yandex.net; dkim=pass header.i=@yandex.ru Message-ID: Subject: Re: bug#61960: 30.0.50; Unexec build reliably crashes during loadup From: Konstantin Kharlamov To: Eli Zaretskii Date: Sun, 02 Jul 2023 14:32:09 +0300 In-Reply-To: <835y72q2r1.fsf@gnu.org> References: <62049aa9ffcf9f39fd423fb87cd8dc8e0b77f9b8.camel@yandex.ru> <63f3de6f0cc0d015d2dcbcdd6adc95482dc0c6ad.camel@yandex.ru> <835y72q2r1.fsf@gnu.org> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable User-Agent: Evolution 3.48.3 MIME-Version: 1.0 X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 61960 Cc: 61960@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) On Sun, 2023-07-02 at 08:52 +0300, Eli Zaretskii wrote: > > From: Konstantin Kharlamov > > Date: Sun, 02 Jul 2023 04:50:26 +0300 > >=20 > > I've found a diff that fixes the build, but whether it's okay is worth > > discussion: > >=20 > > =C2=A0=C2=A0=C2=A0 diff --git a/src/gmalloc.c b/src/gmalloc.c > > =C2=A0=C2=A0=C2=A0 index e655d69f660..f49bb01e08b 100644 > > =C2=A0=C2=A0=C2=A0 --- a/src/gmalloc.c > > =C2=A0=C2=A0=C2=A0 +++ b/src/gmalloc.c > > =C2=A0=C2=A0=C2=A0 @@ -1704,7 +1704,7 @@ allocated_via_gmalloc (void *p= tr) > > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 return false; > > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 size_t block =3D BLOCK (ptr); > > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 size_t blockmax =3D _heaplimit - 1= ; > > =C2=A0=C2=A0=C2=A0 -=C2=A0 return block <=3D blockmax && _heapinfo[bloc= k].busy.type !=3D 0; > > =C2=A0=C2=A0=C2=A0 +=C2=A0 return block <=3D blockmax; > > =C2=A0=C2=A0=C2=A0=C2=A0 } > >=20 > > =C2=A0=C2=A0=C2=A0=C2=A0 /* See the comments near the beginning of this= file for explanations > >=20 > > Here's what happens: Emacs uses internal stack-based allocator (apparen= tly > > allocating > > with sbrk(), but I'm not sure) along with the system allocator. Wheneve= r a > > memory is > > allocated from the internal allocator, you can't call `free()` on it. > >=20 > > 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()`. > >=20 > > Emacs also keeps the lowest and highest boundary of this stack in varia= bles > > `_heapbase` and `_heaplimit` accordingly (except the latter is measured= in > > "blocks"). The code in diff `block <=3D blockmax` simply makes sure tha= t the > > `ptr` > > passed is within the stack-allocated memory, which implies it can't be > > deallocated > > with `free()` > >=20 > > There's a question though of the right-hand side that I remove, the > > `_heapinfo[block].busy.type !=3D 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 dow= n > > would be > > very hard. > >=20 > > 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). >=20 > 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_ALI= GN is used (directly and indirectly) and the code there is very convoluted. Appar= ently 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. From debbugs-submit-bounces@debbugs.gnu.org Sun Jul 02 07:54:46 2023 Received: (at 61960) by debbugs.gnu.org; 2 Jul 2023 11:54:46 +0000 Received: from localhost ([127.0.0.1]:59443 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qFvfC-00012U-7s for submit@debbugs.gnu.org; Sun, 02 Jul 2023 07:54:46 -0400 Received: from forward502c.mail.yandex.net ([178.154.239.210]:60152) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qFvf8-00012I-HM for 61960@debbugs.gnu.org; Sun, 02 Jul 2023 07:54:44 -0400 Received: from mail-nwsmtp-smtp-production-main-91.myt.yp-c.yandex.net (mail-nwsmtp-smtp-production-main-91.myt.yp-c.yandex.net [IPv6:2a02:6b8:c12:3012:0:640:9343:0]) by forward502c.mail.yandex.net (Yandex) with ESMTP id 46B435E98C; Sun, 2 Jul 2023 14:54:40 +0300 (MSK) Received: by mail-nwsmtp-smtp-production-main-91.myt.yp-c.yandex.net (smtp/Yandex) with ESMTPSA id dsODxPTDeuQ0-VrqzNbO6; Sun, 02 Jul 2023 14:54:39 +0300 X-Yandex-Fwd: 1 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1688298879; bh=FbLgJiPGkXwkGJ4EzRvYjPd8tcDZvqbOJx19HpiuxQg=; h=References:Date:In-Reply-To:Cc:To:From:Subject:Message-ID; b=XjnjJ0A+jhAz7m4NrbqSqsj8AHnJTQXO8EEO0KkBMh+pU8ExFgDXbHgLDv4iHSlHY nt6XdaSPfe6yR6h7extYcoJL++utBzX4ZeBJKMvbb20nOqWE5LLrtaChhPya2ekb2U Y40m8i+HD/zGVymxBNm6LovlkNKbvc/L2fVpCwJQ= Authentication-Results: mail-nwsmtp-smtp-production-main-91.myt.yp-c.yandex.net; dkim=pass header.i=@yandex.ru Message-ID: <91e702922b80bea715325226af9c5cb6a0f1ebdf.camel@yandex.ru> Subject: Re: bug#61960: 30.0.50; Unexec build reliably crashes during loadup From: Konstantin Kharlamov To: Eli Zaretskii Date: Sun, 02 Jul 2023 14:54:38 +0300 In-Reply-To: References: <62049aa9ffcf9f39fd423fb87cd8dc8e0b77f9b8.camel@yandex.ru> <63f3de6f0cc0d015d2dcbcdd6adc95482dc0c6ad.camel@yandex.ru> <835y72q2r1.fsf@gnu.org> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable User-Agent: Evolution 3.48.3 MIME-Version: 1.0 X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 61960 Cc: 61960@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) 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 allocat= ed > with malloc(). Sorry, it meant to be "=E2=80=A6despite *not* being allocated with malloc" From debbugs-submit-bounces@debbugs.gnu.org Sun Jul 02 10:10:58 2023 Received: (at 61960) by debbugs.gnu.org; 2 Jul 2023 14:10:58 +0000 Received: from localhost ([127.0.0.1]:60893 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qFxn0-0004nM-I4 for submit@debbugs.gnu.org; Sun, 02 Jul 2023 10:10:58 -0400 Received: from forward500a.mail.yandex.net ([178.154.239.80]:37434) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qFxmw-0004nB-5J for 61960@debbugs.gnu.org; Sun, 02 Jul 2023 10:10:57 -0400 Received: from mail-nwsmtp-smtp-production-main-51.vla.yp-c.yandex.net (mail-nwsmtp-smtp-production-main-51.vla.yp-c.yandex.net [IPv6:2a02:6b8:c1f:5e51:0:640:23ee:0]) by forward500a.mail.yandex.net (Yandex) with ESMTP id E1DFE5E7AE; Sun, 2 Jul 2023 17:10:51 +0300 (MSK) Received: by mail-nwsmtp-smtp-production-main-51.vla.yp-c.yandex.net (smtp/Yandex) with ESMTPSA id pAR1FnYDVW20-Xf1aRzMa; Sun, 02 Jul 2023 17:10:51 +0300 X-Yandex-Fwd: 1 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1688307051; bh=KAKm+TjpqoEjXxAydJR2fjkk2ekPKmdVLTRyvDgD3TI=; h=References:Date:In-Reply-To:Cc:To:From:Subject:Message-ID; b=vV0BHif8EZRui9aNOTvmBt9IIXFgeyoK3IGan8OS2s8cwxzO/dNr8WuLxJ9wCD+47 03uTCcV6wTN1CjQ3IeON9kO07WRbynkuSOyB7II36PgQgh+h1QcmsLevaye9UggsM6 nq+myu3fTcO28KSJcRAreyLHBILan3ru5EGKjB8o= Authentication-Results: mail-nwsmtp-smtp-production-main-51.vla.yp-c.yandex.net; dkim=pass header.i=@yandex.ru Message-ID: Subject: Re: bug#61960: 30.0.50; Unexec build reliably crashes during loadup From: Konstantin Kharlamov To: Eli Zaretskii Date: Sun, 02 Jul 2023 17:10:51 +0300 In-Reply-To: References: <62049aa9ffcf9f39fd423fb87cd8dc8e0b77f9b8.camel@yandex.ru> <63f3de6f0cc0d015d2dcbcdd6adc95482dc0c6ad.camel@yandex.ru> <835y72q2r1.fsf@gnu.org> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable User-Agent: Evolution 3.48.3 MIME-Version: 1.0 X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 61960 Cc: 61960@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) 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. >=20 > 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 wi= th `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 t= hat in various bugreports. I guess I'll have to fix the docs to make sure it's = more clear for future users. From debbugs-submit-bounces@debbugs.gnu.org Fri Jul 21 12:08:57 2023 Received: (at 61960) by debbugs.gnu.org; 21 Jul 2023 16:08:57 +0000 Received: from localhost ([127.0.0.1]:34647 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qMsga-0006Kw-Ub for submit@debbugs.gnu.org; Fri, 21 Jul 2023 12:08:57 -0400 Received: from forward500c.mail.yandex.net ([2a02:6b8:c03:500:1:45:d181:d500]:45956) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qMsgY-0006Kk-Ls for 61960@debbugs.gnu.org; Fri, 21 Jul 2023 12:08:55 -0400 Received: from mail-nwsmtp-smtp-production-main-87.sas.yp-c.yandex.net (mail-nwsmtp-smtp-production-main-87.sas.yp-c.yandex.net [IPv6:2a02:6b8:c08:9396:0:640:dd2a:0]) by forward500c.mail.yandex.net (Yandex) with ESMTP id A6AEB5ECB8; Fri, 21 Jul 2023 19:08:48 +0300 (MSK) Received: by mail-nwsmtp-smtp-production-main-87.sas.yp-c.yandex.net (smtp/Yandex) with ESMTPSA id j8mTlA1DXqM0-315HdIHE; Fri, 21 Jul 2023 19:08:48 +0300 X-Yandex-Fwd: 1 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1689955728; bh=lO+FrJVxqZgkhdfutW9YIsWnRdB7qkBfdjn5Ke/ptno=; h=References:Date:In-Reply-To:Cc:To:From:Subject:Message-ID; b=RXEyPfeI5rov8EbJ4gpA6fia7JdwyCRefqDA1Sin4jnYFylCp+HDUW5qWpFx6n8AQ 2TsYTQN7ufWSshvtk7ctMA5lS4MTdTMSnhwoY+n92MWjw7KxPq7Bp5km1SY4RNTsh2 tblwDwemmgu11+K7BpYGC0QdbThBnbcb7Bv1rnAA= Authentication-Results: mail-nwsmtp-smtp-production-main-87.sas.yp-c.yandex.net; dkim=pass header.i=@yandex.ru Message-ID: <26a72dd4ef44849cbf2ed99f61199779e411136f.camel@yandex.ru> Subject: Re: bug#61960: 30.0.50; Unexec build reliably crashes during loadup From: Konstantin Kharlamov To: Eli Zaretskii Date: Fri, 21 Jul 2023 19:09:04 +0300 In-Reply-To: References: <62049aa9ffcf9f39fd423fb87cd8dc8e0b77f9b8.camel@yandex.ru> <63f3de6f0cc0d015d2dcbcdd6adc95482dc0c6ad.camel@yandex.ru> <835y72q2r1.fsf@gnu.org> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable User-Agent: Evolution 3.48.4 MIME-Version: 1.0 X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 61960 Cc: 61960@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.7 (-) 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 !=3D 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 =F0=9F=A4=B7=E2=80=8D=E2=99=82=EF=B8=8F ----------------------- 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` =E2=80=94 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.=20 So, I would be glad to hear what people think about the purpose of this gmalloc being in the project. From debbugs-submit-bounces@debbugs.gnu.org Fri Jul 21 12:30:14 2023 Received: (at 61960) by debbugs.gnu.org; 21 Jul 2023 16:30:14 +0000 Received: from localhost ([127.0.0.1]:34728 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qMt1C-0006vM-Cj for submit@debbugs.gnu.org; Fri, 21 Jul 2023 12:30:14 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:49030) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qMt18-0006u2-HG for 61960@debbugs.gnu.org; Fri, 21 Jul 2023 12:30:13 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qMt12-0003TI-I0; Fri, 21 Jul 2023 12:30:04 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=MIME-version:References:Subject:In-Reply-To:To:From: Date; bh=90GLSaT4FA5zjuHxOx9uDo0fOwoQPgRo9meDZYuoDCE=; b=lX2Gruv/vu8ut6bqmk0L Ip62Ed56zgOOHg8pKcIouT6qoPxWkkyGwhTtz6+0+2UdjfJo+cjiRvSOTsxmnUFac6AWCf4YZ2S8E 90IWOS2jEHH1WfPguD8+GeRm1A/XcwhxMhh88AaDEFo2+pZEXGuKwaAFhnGhk2HMYvjaqBUzl4hQx PWuHQb1o+1N4j7vSsAX3sCZbjAAwsEayoicPMOLKQ0p1dcfqAvO21mfM6xGTTcM0qEzByC1cdWvFM /VNnSZOng2qQr9552vxCeTYygqHAiLvKgmhTrDo9k5QE0QmesdgrgksAr5STh3hhRD+eUVomHYxoX +UAaEVjTJtkrdg==; Received: from [87.69.77.57] (helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qMt12-00064K-0s; Fri, 21 Jul 2023 12:30:04 -0400 Date: Fri, 21 Jul 2023 19:30:41 +0300 Message-Id: <83v8ed9qha.fsf@gnu.org> From: Eli Zaretskii To: Konstantin Kharlamov In-Reply-To: <26a72dd4ef44849cbf2ed99f61199779e411136f.camel@yandex.ru> (message from Konstantin Kharlamov on Fri, 21 Jul 2023 19:09:04 +0300) Subject: Re: bug#61960: 30.0.50; Unexec build reliably crashes during loadup References: <62049aa9ffcf9f39fd423fb87cd8dc8e0b77f9b8.camel@yandex.ru> <63f3de6f0cc0d015d2dcbcdd6adc95482dc0c6ad.camel@yandex.ru> <835y72q2r1.fsf@gnu.org> <26a72dd4ef44849cbf2ed99f61199779e411136f.camel@yandex.ru> MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 61960 Cc: 61960@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: Konstantin Kharlamov > 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. From debbugs-submit-bounces@debbugs.gnu.org Wed Feb 12 08:40:45 2025 Received: (at 61960) by debbugs.gnu.org; 12 Feb 2025 13:40:45 +0000 Received: from localhost ([127.0.0.1]:33308 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tiCyr-00074f-Hd for submit@debbugs.gnu.org; Wed, 12 Feb 2025 08:40:45 -0500 Received: from forward100a.mail.yandex.net ([178.154.239.83]:43132) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1tiCyo-00074K-1P for 61960@debbugs.gnu.org; Wed, 12 Feb 2025 08:40:43 -0500 Received: from mail-nwsmtp-smtp-production-main-81.vla.yp-c.yandex.net (mail-nwsmtp-smtp-production-main-81.vla.yp-c.yandex.net [IPv6:2a02:6b8:c15:2d94:0:640:e777:0]) by forward100a.mail.yandex.net (Yandex) with ESMTPS id 48DF046D47 for <61960@debbugs.gnu.org>; Wed, 12 Feb 2025 16:40:34 +0300 (MSK) Received: by mail-nwsmtp-smtp-production-main-81.vla.yp-c.yandex.net (smtp/Yandex) with ESMTPSA id WePOVb3OfGk0-tZFan3zl; Wed, 12 Feb 2025 16:40:34 +0300 X-Yandex-Fwd: 1 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1739367634; bh=iiVCsqjucyh8Pz5B0XVIquMHoEQmZR2IOTFc/cvtHMQ=; h=Date:To:From:Subject:Message-ID; b=H/nFd+wSyocgTJw5hrNfwQvyrwMi3Z6v8Y+GUceJtxKgzepHFm4zXep2N/tN5NSfi fcb46ywgJepLMtcTGBZuvhgi7Ib7Pr2VdgbAFOnfrQaWxnzBFiaMBG2c9/h0tzcdIE ss9QBV1dNw4LPS5ceetjkN1pk2Zi0NA9oPd412d0= Authentication-Results: mail-nwsmtp-smtp-production-main-81.vla.yp-c.yandex.net; dkim=pass header.i=@yandex.ru Message-ID: Subject: Re: 30.0.50; Unexec build reliably crashes during loadup From: Konstantin Kharlamov To: 61960@debbugs.gnu.org Date: Wed, 12 Feb 2025 16:40:32 +0300 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable User-Agent: Evolution 3.54.3 MIME-Version: 1.0 X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 61960 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) I think this can be closed. Commit 15e2b14f03796467fab8e8086d293a5813afaa5b removed unexec build, so nothing to do here anymore. From debbugs-submit-bounces@debbugs.gnu.org Wed Feb 12 08:59:50 2025 Received: (at 61960-done) by debbugs.gnu.org; 12 Feb 2025 13:59:50 +0000 Received: from localhost ([127.0.0.1]:33377 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tiDHK-0007vz-Ga for submit@debbugs.gnu.org; Wed, 12 Feb 2025 08:59:50 -0500 Received: from mail-ed1-x52e.google.com ([2a00:1450:4864:20::52e]:42273) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from ) id 1tiDHI-0007vk-QE for 61960-done@debbugs.gnu.org; Wed, 12 Feb 2025 08:59:49 -0500 Received: by mail-ed1-x52e.google.com with SMTP id 4fb4d7f45d1cf-5debbced002so540233a12.1 for <61960-done@debbugs.gnu.org>; Wed, 12 Feb 2025 05:59:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1739368782; x=1739973582; darn=debbugs.gnu.org; h=to:subject:message-id:date:mime-version:references:in-reply-to:from :from:to:cc:subject:date:message-id:reply-to; bh=ezRJTXRS6LtM2GsjeksAsocfDfTIY+G9d9l3qzZJ6dU=; b=OnPv5aHSNTvfBs+8MT3B+uDFdnoYOLMAcRoRBB1MEYtVxo9ignKHxjiQweiO6LG8x6 DclFwcqjBPes/rJsHHNblCkmKZH6KGMV0ocRZoQ4l2g/NatIIze1G1LLFEiRiep+r+35 wmcD1LbcJvuzDsWP5fQxRLwDSP/yhvOLZMdZajDv6IMqkBfS85i4PkeHuIS1KXP4tjVR EilFLwBPlUNxtX2/lnzbZ0SoDf2700O2tmreVeTQWcwucIa6ws3sUIzDvZzijYXKNiaU nfe8xqSxcCDBQM6bESGu+DlNpaRb11wFK2Aj7nXJv0I05wxQzCuYLpxWAI6jR5sRPQX9 J+WQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1739368782; x=1739973582; h=to:subject:message-id:date:mime-version:references:in-reply-to:from :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=ezRJTXRS6LtM2GsjeksAsocfDfTIY+G9d9l3qzZJ6dU=; b=AAtMRMnV8BkhdA7zaKU6h/M6RKKJImPttpA+EL4/H8tHkplhQ3MreeeXRwZBfvrRct OyfYCWgdjeKKVVTNWOD+TUV4Ild/sVQZNzt/qnT+uOqWdSjJLcZYm9F3ciia9gmY8T90 qBkVoTzYb7uFpgHPXi4HstcIwaIWFC+48AdWAHl2vsgRKtxlR5fRVEaQZ14NRCCUERi8 NrQMIwpZnsr8XbwiukIKG1+z3hI/v4qbcu8B92WclOSVuTctAzFzZEVw1rga/UF8C45j SbxF2El2H7ujLE4xLR2kSdfoU7vukLvRbePavazZCHQs4ZLe4VxDKcRhbOu7ps4kY9tQ w2NQ== X-Forwarded-Encrypted: i=1; AJvYcCW1HhxvGkZxCvA6ypbBxVDfXvCmLLo0IpoGKzP7Jhkb+pYISHfYlTXyAMZCr/t+0n8OC/Om+drQM/Rh@debbugs.gnu.org X-Gm-Message-State: AOJu0YykZsHzPid3kPvK6TjSKv6xyHdG5SC/gyppszy+5UAE/NsPcPZg PbPjXqW7L7aHxXTP4TkeM55bzTLWy2ylflOsT5s3zoTzr3QsIeCXO7tQU95z71CZrd8td+yTcFU KESijRURhpBwgwt5NTyFeh8dYarQ= X-Gm-Gg: ASbGnctyLtABjKHdp7I+5p4cPNoZ28+c0jnrNehRci/cxqixr46HDn71FFMsPDB/8Ic MjpHg8tZutpaAj/ZLZbMW5Iy0ljR1z1KSPtf2Ya/k2ujdVtyocgMgO5SjuDj5Ld7VPwpnJjqceR 0= X-Google-Smtp-Source: AGHT+IE4KA9DpZm4YVO9lQN2RXz0AV2sh3sp4rfKucZazRDNRke5mJ0L6FPN4XPrvgU96P+MzOPpGlGYu2Qkjv847DE= X-Received: by 2002:a05:6402:524b:b0:5db:e88c:914f with SMTP id 4fb4d7f45d1cf-5deae099fccmr2866126a12.4.1739368781708; Wed, 12 Feb 2025 05:59:41 -0800 (PST) Received: from 753933720722 named unknown by gmailapi.google.com with HTTPREST; Wed, 12 Feb 2025 05:59:41 -0800 From: Stefan Kangas In-Reply-To: References: <83pm9oa7mm.fsf@gnu.org> MIME-Version: 1.0 Date: Wed, 12 Feb 2025 05:59:41 -0800 X-Gm-Features: AWEUYZnX7T2rTe0hMVdVKiuquBmryg-uEo0Zfp_hJJ8RKbk_WZ2B7C1M9jvfnsw Message-ID: Subject: Re: bug#61960: 30.0.50; Unexec build reliably crashes during loadup To: Konstantin Kharlamov , 61960-done@debbugs.gnu.org Content-Type: text/plain; charset="UTF-8" X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 61960-done X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Konstantin Kharlamov writes: > I think this can be closed. Commit > 15e2b14f03796467fab8e8086d293a5813afaa5b removed unexec build, so > nothing to do here anymore. Thanks, I'm therefore closing this bug report. From unknown Tue Jun 17 01:49:21 2025 Received: (at fakecontrol) by fakecontrolmessage; To: internal_control@debbugs.gnu.org From: Debbugs Internal Request Subject: Internal Control Message-Id: bug archived. Date: Thu, 13 Mar 2025 11:24:23 +0000 User-Agent: Fakemail v42.6.9 # This is a fake control message. # # The action: # bug archived. thanks # This fakemail brought to you by your local debbugs # administrator