From unknown Sat Jun 14 18:56:05 2025 X-Loop: help-debbugs@gnu.org Subject: bug#38912: 27.0.60; PDumper meets segmentation fault when evil is loaded Resent-From: NiwTinray Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 04 Jan 2020 03:27:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: report 38912 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: 38912@debbugs.gnu.org X-Debbugs-Original-To: bug-gnu-emacs@gnu.org Received: via spool by submit@debbugs.gnu.org id=B.157810837630058 (code B ref -1); Sat, 04 Jan 2020 03:27:02 +0000 Received: (at submit) by debbugs.gnu.org; 4 Jan 2020 03:26:16 +0000 Received: from localhost ([127.0.0.1]:42309 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ina4t-0007oh-79 for submit@debbugs.gnu.org; Fri, 03 Jan 2020 22:26:16 -0500 Received: from lists.gnu.org ([209.51.188.17]:39106) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1inYZY-0005Pm-Mr for submit@debbugs.gnu.org; Fri, 03 Jan 2020 20:49:49 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:38878) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1inYZW-00045a-Ds for bug-gnu-emacs@gnu.org; Fri, 03 Jan 2020 20:49:48 -0500 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=0.1 required=5.0 tests=BAYES_50,FREEMAIL_FROM, RCVD_IN_DNSWL_LOW,URIBL_BLOCKED autolearn=disabled version=3.3.2 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1inYZK-0001Io-4x for bug-gnu-emacs@gnu.org; Fri, 03 Jan 2020 20:49:41 -0500 Received: from pv50p00im-ztdg10021801.me.com ([17.58.6.56]:37598) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1inYZI-00018O-Pi for bug-gnu-emacs@gnu.org; Fri, 03 Jan 2020 20:49:34 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=icloud.com; s=1a1hai; t=1578102559; bh=q67Y9pd/9dvq+qUzIKAS3VgOyR4Rog6hUCkXOhaEtds=; h=From:Content-Type:Subject:Message-Id:Date:To; b=Q4aUGHlfI6dvax+n+/VDHsAEXPIHGeK0kWPCHw/Jxtyf/ROYzVwZzT1mRA3gQ4ajr +TAX8PKR0YULYgt3HqRs/u9gTEVvpbcBa/gHU731EKO5AZ/GxAcjoAHZGWzzwlHSiN 4/0ubWodjdIy3iq4MZaAyO1Yv2mP1Bq2xifKuQx+LaZObUfoGLCtngsT0Ulwszr7Mj 1Cx2dyUEy+vbKfo0HiURx2ZuTrFqolTDeDQdxK9jWludPh90U5VkTfzZg3YOf1fjF1 4WOGeftesy5JoP5Io6pKt54gmR3w802uqhTxJJhFoIBl7CcIpjZ5WpFVxmj3TU/+We ObOMB0S0/NNZQ== Received: from [10.128.195.48] (unknown [59.64.129.71]) by pv50p00im-ztdg10021801.me.com (Postfix) with ESMTPSA id 4F0DA360802 for ; Sat, 4 Jan 2020 01:49:18 +0000 (UTC) From: NiwTinray Content-Type: text/plain; charset=gb2312 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.8\)) Message-Id: <333553AC-68DE-4F1C-9586-5A13248AD6DD@icloud.com> Date: Sat, 4 Jan 2020 09:49:14 +0800 X-Mailer: Apple Mail (2.3445.104.8) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2020-01-03_06:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=1 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 mlxscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1908290000 definitions=main-2001040016 X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] [fuzzy] X-Received-From: 17.58.6.56 X-Spam-Score: -1.3 (-) X-Mailman-Approved-At: Fri, 03 Jan 2020 22:26:14 -0500 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.3 (--) Hi, Emacs Dev,=20 I was testing the new portable dumper with my personal Emacs. When I loaded my dumped file, Emacs crashed on segmentation fault. After tracking down the issue, I found the issues is caused by the undo-tree mode in package "evil". To reproduce the bug, try this: emacs --batch -f package-initialize --eval=3D'(use-package evil :ensure t)' --eval=3D'(dump-emacs-portable "test.pdmp")' && emacs --dump-file test.pdmp If I turned off the global-undo-tree-mode manually, it won't crash: emacs --batch -f package-initialize --eval=3D'(use-package evil :ensure t)' --eval=3D'(global-undo-tree-mode -1)' --eval=3D'(dump-emacs-portable "test.pdmp")' && emacs --dump-file test.pdmp So the problem must be exist in the undo-tree-mode. I don't have the knowledge/techniques to track down the bug further. Please help me investigate this! Backtrace on crash: #0 0x00000000004f1240 in Fcurrent_active_maps (olp=3Dolp@entry=3D0x30, = position=3Dposition@entry=3D0x0) at keymap.c:1541 #1 0x00000000004f167d in Fkey_binding (key=3D0x7fffefba745d, = accept_default=3D0x0, no_remap=3D0x0, position=3D0x0) at keymap.c:1681 #2 0x00000000005546a3 in Ffuncall (nargs=3D2, = args=3Dargs@entry=3D0x7fffffffd5d0) at eval.c:2794 #3 0x0000000000588d28 in exec_byte_code (bytestr=3D, = vector=3D0x7fffefba2715, maxdepth=3D, = args_template=3D, nargs=3Dnargs@entry=3D0, = args=3D, args@entry=3D0x7fffefba2718) at bytecode.c:633 #4 0x000000000055439f in funcall_lambda (fun=3D0x7fffffffd5e3, = nargs=3Dnargs@entry=3D0, arg_vector=3D0x7fffefba2718, = arg_vector@entry=3D0x7fffffffd768) at eval.c:2989 #5 0x00000000005545ef in Ffuncall (nargs=3D1, = args=3Dargs@entry=3D0x7fffffffd760) at eval.c:2808 #6 0x0000000000588d28 in exec_byte_code (bytestr=3D, = vector=3D0x7fffefba262d, maxdepth=3D, = args_template=3D, nargs=3Dnargs@entry=3D0, = args=3D, args@entry=3D0x7fffefba2630) at bytecode.c:633 #7 0x000000000055439f in funcall_lambda (fun=3D0x7fffffffd79e, = nargs=3Dnargs@entry=3D0, arg_vector=3D0x7fffefba2630, = arg_vector@entry=3D0x7fffffffd958) at eval.c:2989 #8 0x00000000005545ef in Ffuncall (nargs=3D1, args=3D0x7fffffffd950) at = eval.c:2808 #9 0x00000000005546e9 in funcall_nil (nargs=3D, = args=3D) at eval.c:2435 #10 0x00000000005534a5 in run_hook_with_args (nargs=3D1, = args=3D0x7fffffffd950, funcall=3D0x5546e0 ) at eval.c:2612 #11 0x0000000000553616 in Frun_hook_with_args (args=3D0x7fffffffd950, = nargs=3D1) at eval.c:2477 #12 run_hook (hook=3D0x7fffeefb53f0) at eval.c:2625 #13 Frun_hooks (nargs=3D1, args=3D0x7fffffffd9f8) at eval.c:2459 #14 0x00000000005546a3 in Ffuncall (nargs=3D2, = args=3Dargs@entry=3D0x7fffffffd9f0) at eval.c:2794 #15 0x0000000000588d28 in exec_byte_code (bytestr=3D, = vector=3D0x7fffefab5415, maxdepth=3D, = args_template=3D, nargs=3Dnargs@entry=3D1, = args=3D, args@entry=3D0x7fffefab5418) at bytecode.c:633 #16 0x000000000055439f in funcall_lambda (fun=3D0x7fffffffda66, = nargs=3Dnargs@entry=3D1, arg_vector=3D0x7fffefab5418, = arg_vector@entry=3D0x7fffffffdbd0) at eval.c:2989 #17 0x00000000005545ef in Ffuncall (nargs=3D2, = args=3Dargs@entry=3D0x7fffffffdbc8) at eval.c:2808 #18 0x0000000000588d28 in exec_byte_code (bytestr=3D, = vector=3D0x7fffefc794ad, maxdepth=3D, = args_template=3D, nargs=3Dnargs@entry=3D0, = args=3D, args@entry=3D0x7fffefc794b0) at bytecode.c:633 #19 0x000000000055439f in funcall_lambda (fun=3D0x7fffffffdbf1, = nargs=3Dnargs@entry=3D0, arg_vector=3D0x7fffefc794b0, = arg_vector@entry=3D0x7fffffffdd50) at eval.c:2989 #20 0x00000000005545ef in Ffuncall (nargs=3Dnargs@entry=3D1, = args=3Dargs@entry=3D0x7fffffffdd48) at eval.c:2808 #21 0x0000000000554758 in call0 (fn=3D0x7fffef08c260) at eval.c:2647 #22 0x000000000050a4ff in get_minibuffer (depth=3Ddepth@entry=3D0) at = minibuf.c:754 #23 0x0000000000501283 in init_buffer () at buffer.c:5430 #24 0x00000000004139ba in main (argc=3D3, argv=3D) at = emacs.c:1777 In GNU Emacs 27.0.60 (build 1, x86_64-pc-linux-gnu) of 2020-01-01 built on omnisky Repository revision: 186152ba400b58d2d278c52d2e3d896decae767e Repository branch: emacs-27 System Description: Ubuntu 16.04.6 LTS Recent messages: Saving file /home/ntr/.config/emacs/custom.el... Wrote = /home/ntr/.config/emacs/emacs.saves/.!home!ntr!.config!emacs!custom.el.~un= do-tree~ Wrote /home/ntr/.config/emacs/custom.el helm-M-x: Package =A1=AEevil-20190729.704=A1=AF is used by = =A1=AEevil-multiedit=A1=AF as dependency, not deleting Mark saved where search started Package =A1=AEhighlight-parentheses-20180704.1102=A1=AF deleted. Mark saved where search started Saving file /home/ntr/.config/emacs/bunny-core-packages.el... Wrote = /home/ntr/.config/emacs/emacs.saves/.!home!ntr!.config!emacs!bunny-core-pa= ckages.el.~undo-tree~ Wrote /home/ntr/.config/emacs/bunny-core-packages.el Configured using: 'configure --with-x-toolkit=3Dno' Configured features: XPM JPEG TIFF GIF PNG SOUND GSETTINGS GLIB NOTIFY INOTIFY GNUTLS FREETYPE HARFBUZZ XFT ZLIB OLDXMENU X11 XDBE XIM MODULES THREADS JSON PDUMPER GMP Important settings: value of $LC_ALL: en_US.UTF-8 value of $LC_CTYPE: zh_CN.UTF-8 value of $LC_MONETARY: zh_CN.UTF-8 value of $LC_NUMERIC: zh_CN.UTF-8 value of $LC_TIME: zh_CN.UTF-8 value of $LANG: en_US.UTF-8 locale-coding-system: utf-8-unix Major mode: Emacs-Lisp Minor modes in effect: doom-modeline-mode: t recentf-mode: t xterm-mouse-mode: t display-time-mode: t workgroups-mode: t keyfreq-autosave-mode: t keyfreq-mode: t global-magit-file-mode: t magit-file-mode: t magit-auto-revert-mode: t global-git-commit-mode: t async-bytecomp-package-mode: t company-statistics-mode: t global-company-mode: t company-mode: t global-hungry-delete-mode: t hungry-delete-mode: t eyebrowse-mode: t helm-mode: t override-global-mode: t delete-selection-mode: t auto-revert-mode: t global-hl-line-mode: t which-key-mode: t global-evil-matchit-mode: t evil-matchit-mode: t global-evil-collection-unimpaired-mode: t evil-collection-unimpaired-mode: t evil-leader-mode: t global-undo-tree-mode: t undo-tree-mode: t shell-dirtrack-mode: t evil-mode: t evil-local-mode: t global-hl-todo-mode: t hl-todo-mode: t global-highlight-parentheses-mode: t highlight-parentheses-mode: t aggressive-indent-mode: t tooltip-mode: t global-eldoc-mode: t eldoc-mode: t electric-indent-mode: t mouse-wheel-mode: t file-name-shadow-mode: t global-font-lock-mode: t font-lock-mode: t auto-composition-mode: t auto-encryption-mode: t auto-compression-mode: t line-number-mode: t transient-mark-mode: t Load-path shadows: None found. Features: (evil-matchit-simple helm-ring em-unix em-term em-script em-prompt em-ls em-hist em-pred em-dirs esh-var em-cmpl em-basic em-banner em-alias esh-mode eshell esh-cmd esh-ext esh-opt esh-proc esh-io esh-arg esh-module esh-groups shadow sort mail-extr emacsbug sendmail tabify ido face-remap image-file mule-util view lsp-clients lsp-haxe lsp-erlang lsp-fsharp lsp-metals lsp-elm lsp-dart lsp-clojure lsp-go lsp-xml lsp-css lsp-intelephense lsp-vetur lsp-html lsp-solargraph lsp-rust lsp-pyls lsp helm-for-files helm-bookmark helm-adaptive helm-external helm-net ffap vc-mtn vc-hg vc-bzr vc-src vc-sccs vc-svn vc-cvs vc-rcs vc vc-dispatcher jka-compr eieio-opt speedbar sb-image ezimage dframe help-fns radix-tree so-long winner helm-command helm-elisp helm-eval edebug backtrace helm-info term/xterm xterm doom-modeline doom-modeline-segments doom-modeline-env doom-modeline-core recentf magit-bookmark bookmark ediff ediff-merg ediff-mult ediff-wind ediff-diff ediff-help ediff-init ediff-util xt-mouse bunny-sshfs flymake-diagnostic-at-point popup lsp-python-ms python-el-fgallina-expansions python tramp-sh tramp tramp-loaddefs trampver tramp-integration files-x tramp-compat parse-time iso8601 ls-lisp company-lsp lsp-mode ewoc markdown-mode tree-widget spinner network-stream nsm inline ht em-glob esh-util dash-functional bindat flymake-proc flymake warnings bunny-pyenv eldoc-eval all-the-icons all-the-icons-faces data-material data-weathericons data-octicons data-fileicons data-faicons data-alltheicons memoize eshell-git-prompt leuven-theme time bunny-insert-surroundings bunny-krws bunny-company-simple-complete bunny-eshell-extensions bunny-terminal-here bunny-workgroups bunny-register-jumper bunny-h5ls bunny-prettify-json-file web-server web-server-status-codes keyfreq evil-magit magit-submodule magit-obsolete magit-blame magit-stash magit-reflog magit-bisect magit-push magit-pull magit-fetch magit-clone magit-remote magit-commit magit-sequence magit-notes magit-worktree magit-tag magit-merge magit-branch magit-reset magit-files magit-refs magit-status magit magit-repos magit-apply magit-wip magit-log which-func imenu magit-diff smerge-mode magit-core magit-autorevert magit-margin magit-transient magit-process magit-mode git-commit magit-git magit-section magit-utils crm log-edit message rmc rfc822 mml mml-sec epa derived epg epg-config mm-decode mm-bodies mm-encode mail-parse rfc2231 mailabbrev gmm-utils mailheader pcvs-util add-log with-editor async-bytecomp server git-timemachine transient vc-git diff-mode org-preview-html eww mm-url gnus nnheader gnus-util rmail rmail-loaddefs rfc2047 rfc2045 ietf-drums mail-utils mm-util mail-prsvr url-queue shr text-property-search puny svg xml the-org-mode-expansions org ob ob-tangle ob-ref ob-lob ob-table ob-exp org-macro org-footnote org-src ob-comint org-pcomplete org-list org-faces org-entities time-date noutline outline org-version ob-emacs-lisp ob-core ob-eval org-table ol org-keys org-compat org-macs org-loaddefs find-func cal-menu calendar cal-loaddefs company-statistics company-oddmuse company-keywords company-etags etags fileloop generator company-gtags company-dabbrev-code company-dabbrev company-files company-capf company-cmake company-xcode company-clang company-semantic company-eclim company-template company-bbdb company pcase multi-term shell-pop term disp-table ehelp htmlize hungry-delete expand-region text-mode-expansions html-mode-expansions er-basic-expansions expand-region-core expand-region-custom golden-ratio eyebrowse use-package-diminish buffer-move transpose-frame helm-ag helm-descbinds helm-projectile cus-edit cus-start cus-load wid-edit helm-mode helm-files helm-buffers helm-occur helm-tags helm-locate helm-grep helm-regexp format-spec helm-utils helm-help helm-types helm helm-source eieio-compat helm-multi-match helm-lib async use-package-bind-key bind-key counsel xdg xref project swiper ivy delsel colir ivy-overlay ace-window avy ace-jump-zap ace-jump-mode cl ranger autorevert filenotify hl-line evil-collection-dired dired dired-loaddefs evil-collection-neotree neotree projectile grep compile ibuf-ext ibuffer ibuffer-loaddefs shrink-path rx f s dash which-key evil-multiedit iedit iedit-lib evil-nerd-commenter evil-nerd-commenter-operator evil-nerd-commenter-sdk sgml-mode dom evil-matchit evil-matchit-sdk evil-collection-unimpaired evil-collection bunny-minor-mode-leader-keymap zone-rainbow color zone symbol-overlay evil-leader evil evil-integration undo-tree diff evil-maps evil-commands reveal flyspell ispell evil-jumps evil-command-window evil-types evil-search evil-ex shell pcomplete comint ansi-color evil-macros evil-repeat evil-states evil-core advice evil-common windmove thingatpt rect evil-digraphs evil-vars edmacro kmacro hl-todo posframe rainbow-delimiters highlight-parentheses move-text macrostep ring pp exec-path-from-shell try url url-proxy url-privacy url-expand url-methods url-history url-cookie url-domsuf url-util mailcap anaphora aggressive-indent easy-mmode cl-extra help-mode use-package-ensure use-package-core finder-inf info package easymenu browse-url url-handlers url-parse auth-source cl-seq eieio eieio-core cl-macs eieio-loaddefs password-cache json subr-x map url-vars seq byte-opt gv bytecomp byte-compile cconv cl-loaddefs cl-lib tooltip eldoc electric uniquify ediff-hook vc-hooks lisp-float-type mwheel term/x-win x-win term/common-win x-dnd tool-bar dnd fontset image regexp-opt fringe tabulated-list replace newcomment text-mode elisp-mode lisp-mode prog-mode register page tab-bar menu-bar rfn-eshadow isearch timer select scroll-bar mouse jit-lock font-lock syntax facemenu font-core term/tty-colors frame minibuffer cl-generic cham georgian utf-8-lang misc-lang vietnamese tibetan thai tai-viet lao korean japanese eucjp-ms cp51932 hebrew greek romanian slovak czech european ethiopic indian cyrillic chinese composite charscript charprop case-table epa-hook jka-cmpr-hook help simple abbrev obarray cl-preloaded nadvice loaddefs button faces cus-face macroexp files text-properties overlay sha1 md5 base64 format env code-pages mule custom widget hashtable-print-readable backquote threads inotify dynamic-setting system-font-setting font-render-setting x multi-tty make-network-process emacs) Memory information: ((conses 16 632937 99192) (symbols 48 53853 52) (strings 32 181171 13075) (string-bytes 1 5457906) (vectors 16 89834) (vector-slots 8 1780900 209238) (floats 8 893 401) (intervals 56 24129 5564) (buffers 1000 48) (heap 1024 49509 3144))= From unknown Sat Jun 14 18:56:05 2025 X-Loop: help-debbugs@gnu.org Subject: bug#38912: 27.0.60; PDumper meets segmentation fault when evil is loaded Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 04 Jan 2020 09:19:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 38912 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: NiwTinray Cc: 38912@debbugs.gnu.org Received: via spool by 38912-submit@debbugs.gnu.org id=B38912.157812948232011 (code B ref 38912); Sat, 04 Jan 2020 09:19:01 +0000 Received: (at 38912) by debbugs.gnu.org; 4 Jan 2020 09:18:02 +0000 Received: from localhost ([127.0.0.1]:42462 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1infZJ-0008K8-Oi for submit@debbugs.gnu.org; Sat, 04 Jan 2020 04:18:01 -0500 Received: from eggs.gnu.org ([209.51.188.92]:35435) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1infZI-0008Jl-7t for 38912@debbugs.gnu.org; Sat, 04 Jan 2020 04:18:00 -0500 Received: from fencepost.gnu.org ([2001:470:142:3::e]:50017) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1infZB-0001Vt-Fw; Sat, 04 Jan 2020 04:17:53 -0500 Received: from [176.228.60.248] (port=3581 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1infZA-0000x8-Ku; Sat, 04 Jan 2020 04:17:53 -0500 Date: Sat, 04 Jan 2020 11:17:54 +0200 Message-Id: <83ftgvh96l.fsf@gnu.org> From: Eli Zaretskii In-reply-to: <333553AC-68DE-4F1C-9586-5A13248AD6DD@icloud.com> (bug-gnu-emacs@gnu.org) References: <333553AC-68DE-4F1C-9586-5A13248AD6DD@icloud.com> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Spam-Score: -2.3 (--) 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 (---) > Date: Sat, 4 Jan 2020 09:49:14 +0800 > From: NiwTinray via "Bug reports for GNU Emacs, > the Swiss army knife of text editors" > > I was testing the new portable dumper with my personal Emacs. When I > loaded my dumped file, Emacs crashed on segmentation fault. > After tracking down the issue, I found the issues is caused by the > undo-tree mode in package "evil". > To reproduce the bug, try this: > > emacs --batch -f package-initialize --eval='(use-package evil :ensure > t)' --eval='(dump-emacs-portable "test.pdmp")' && emacs --dump-file > test.pdmp I cannot reproduce this from "emacs -Q" because 'use-package' is not a known function. Can you show a recipe starting from "emacs -Q", please? Also, does this happen if you add -Q to the Emacs invocation after dumping? If not, there's more detail missing in your report: the customizations in your init files. In addition, please also show the Lisp-level backtrace from the crash, by using the xbacktrace command (it is defined in the src/.gdbinit file in the Emacs source tree). > Backtrace on crash: > #0 0x00000000004f1240 in Fcurrent_active_maps (olp=olp@entry=0x30, position=position@entry=0x0) at keymap.c:1541 GDB usually displays the fatal signal that killed the program; can you show that part as well? Thanks. From unknown Sat Jun 14 18:56:05 2025 X-Loop: help-debbugs@gnu.org Subject: bug#38912: 27.0.60; PDumper meets segmentation fault when evil is loaded Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 05 Jan 2020 18:46:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 38912 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: NiwTinray , Daniel Colascione Cc: 38912@debbugs.gnu.org Received: via spool by 38912-submit@debbugs.gnu.org id=B38912.157824992418693 (code B ref 38912); Sun, 05 Jan 2020 18:46:02 +0000 Received: (at 38912) by debbugs.gnu.org; 5 Jan 2020 18:45:24 +0000 Received: from localhost ([127.0.0.1]:44609 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ioAtv-0004rQ-ID for submit@debbugs.gnu.org; Sun, 05 Jan 2020 13:45:24 -0500 Received: from eggs.gnu.org ([209.51.188.92]:33342) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ioAtt-0004rD-DS for 38912@debbugs.gnu.org; Sun, 05 Jan 2020 13:45:22 -0500 Received: from fencepost.gnu.org ([2001:470:142:3::e]:40719) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ioAtn-00039u-L0; Sun, 05 Jan 2020 13:45:15 -0500 Received: from [176.228.60.248] (port=2635 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1ioAtm-0001Yy-Na; Sun, 05 Jan 2020 13:45:15 -0500 Date: Sun, 05 Jan 2020 20:45:19 +0200 Message-Id: <83a771g2tc.fsf@gnu.org> From: Eli Zaretskii In-reply-to: (message from NiwTinray on Sun, 5 Jan 2020 13:25:07 +0800) References: <333553AC-68DE-4F1C-9586-5A13248AD6DD@icloud.com> <83ftgvh96l.fsf@gnu.org> MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Spam-Score: -2.3 (--) 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 (---) [Please use "Reply All" to reply, so that the bug address is kept on the CC list.] > From: NiwTinray > Date: Sun, 5 Jan 2020 13:25:07 +0800 > > > I cannot reproduce this from "emacs -Q" because 'use-package' is not a > > known function. Can you show a recipe starting from "emacs -Q", > > please? > > Here. I've attached a minimal script file that helps reproduce this bug. > > (require 'package) > (package-initialize) > (add-to-list 'package-archives > '("melpa-stable" . "https://stable.melpa.org/packages/") t) > (unless (package-installed-p 'evil) > (package-refresh-contents) > (package-install 'evil)) > (require 'evil) > (dump-emacs-portable "/tmp/test.pdmp") > > The script downloads the package "evil" from Melpa stable, load the evil package > and dumps an image to /tmp/test.pdmp. > > > Also, does this happen if you add -Q to the Emacs invocation after > > dumping? If not, there's more detail missing in your report: the > > customizations in your init files. > > > Sure. Please download this file, and run the command: > > emacs --batch -Q --script evil.el > > To see the bug happen, load the test.pdmp file: > > emacs -Q --dump-file /tmp/test.pdmp > > You should see a segmentation fault: > > [1] 23369 segmentation fault (core dumped) emacs -Q --dump-file /tmp/test.pdmp > > I run debugger inside src/.gdbinit using the command: > > gdb -x .gdbinit --args ./emacs --dump-file /tmp/test.pdmp > > And logged backtrace. See my second attachment: > > (base) omnisky :: ~/emacs/src ‹emacs-27*› » gdb -x .gdbinit --args ./emacs --dump-file /tmp/test.pdmp > GNU gdb (Ubuntu 7.11.1-0ubuntu1~16.5) 7.11.1 > Copyright (C) 2016 Free Software Foundation, Inc. > License GPLv3+: GNU GPL version 3 or later > This is free software: you are free to change and redistribute it. > There is NO WARRANTY, to the extent permitted by law. Type "show copying" > and "show warranty" for details. > This GDB was configured as "x86_64-linux-gnu". > Type "show configuration" for configuration details. > For bug reporting instructions, please see: > . > Find the GDB manual and other documentation resources online at: > . > For help, type "help". > Type "apropos word" to search for commands related to "word"... > Reading symbols from ./emacs...done. > warning: File "/home/ntr/emacs/src/.gdbinit" auto-loading has been declined by your `auto-load safe-path' set to "$debugdir:$datadir/auto-load". > To enable execution of this file add > add-auto-load-safe-path /home/ntr/emacs/src/.gdbinit > line to your configuration file "/home/ntr/.gdbinit". > To completely disable this security protection add > set auto-load safe-path / > line to your configuration file "/home/ntr/.gdbinit". > For more information about this security protection see the > "Auto-loading safe path" section in the GDB manual. E.g., run from the shell: > info "(gdb)Auto-loading safe path" > SIGINT is used by the debugger. > Are you sure you want to change it? (y or n) [answered Y; input not from terminal] > Environment variable "DISPLAY" not defined. > TERM = xterm-24bits > Breakpoint 1 at 0x411df0: file emacs.c, line 370. > Breakpoint 2 at 0x4bfe60: file xterm.c, line 10130. > (gdb) r > Starting program: /home/ntr/emacs/src/emacs --dump-file /tmp/test.pdmp > /home/ntr/emacs/src/emacs: /raid_sdc/home/ntr/anaconda3/lib/libtiff.so.5: no version information available (required by /home/ntr/emacs/src/emacs) > [Thread debugging using libthread_db enabled] > Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1". > > Program received signal SIGSEGV, Segmentation fault. > 0x00000000004f12d0 in Fcurrent_active_maps (olp=olp@entry=XIL(0x30), position=position@entry=XIL(0)) at keymap.c:1541 > 1541 && NILP (KVAR (current_kboard, Voverriding_terminal_local_map)) > (gdb) xbacktrace > "key-binding" (0xffffd5c8) > "turn-on-undo-tree-mode" (0xffffd758) > "global-undo-tree-mode-enable-in-buffers" (0xffffd948) > "run-hooks" (0xffffd9e8) > "run-mode-hooks" (0xffffdbc0) > "minibuffer-inactive-mode" (0xffffdd40) > (gdb) In my debug build of Emacs 27.0.60 I get an assertion violation while dumping, which probably is already a sign of trouble. Daniel, any ideas? Here's the backtrace from the assertion violation, and some data involved in the assertion: dumping fingerprint: 79862409ba15bcbb091a8b1aa5b942cc3283f12f123a69372f5cfe59de047ba9 pdumper.c:2684: Emacs fatal error: assertion failed: EQ (expected_value, found_value) Thread 1 hit Breakpoint 1, terminate_due_to_signal (sig=22, backtrace_limit=2147483647) at emacs.c:371 371 signal (sig, SIG_DFL); (gdb) bt #0 terminate_due_to_signal (sig=22, backtrace_limit=2147483647) at emacs.c:371 #1 0x01317f22 in die ( msg=0x19bac5c "EQ (expected_value, found_value)", file=0x19ba210 "pdumper.c", line=2684) at alloc.c:7246 #2 0x01326817 in check_hash_table_rehash (table_orig=XIL(0xa000000006288090)) at pdumper.c:2684 #3 0x01326a6c in dump_hash_table (ctx=0x82d1f0, object=XIL(0xa000000006288090), offset=-4) at pdumper.c:2725 #4 0x013279c5 in dump_vectorlike (ctx=0x82d1f0, lv=XIL(0xa000000006288090), offset=-4) at pdumper.c:2991 #5 0x01327f92 in dump_object (ctx=0x82d1f0, object=XIL(0xa000000006288090)) at pdumper.c:3127 #6 0x0132ace3 in dump_drain_deferred_hash_tables (ctx=0x82d1f0) at pdumper.c:3977 #7 0x0132b4ca in Fdump_emacs_portable (filename=XIL(0x8000000006d24008), track_referrers=XIL(0)) at pdumper.c:4148 #8 0x013825de in eval_sub (form=XIL(0xc0000000067b2150)) at eval.c:2276 #9 0x0137aec2 in Fprogn (body=XIL(0)) at eval.c:462 #10 0x01382182 in eval_sub (form=XIL(0xc0000000067b2090)) at eval.c:2226 #11 0x013819e8 in Feval (form=XIL(0xc0000000067b2090), lexical=XIL(0x30)) at eval.c:2102 #12 0x01384ecc in funcall_subr (subr=0x1960b00 , numargs=2, args=0x82d978) at eval.c:2869 #13 0x013848f9 in Ffuncall (nargs=3, args=0x82d970) at eval.c:2794 #14 0x01427e37 in exec_byte_code (bytestr=XIL(0x800000000612e1e0), vector=XIL(0xa00000000612d0f8), maxdepth=make_fixnum(25), args_template=make_fixnum(257), nargs=1, args=0x82e378) at bytecode.c:633 #15 0x01385a11 in funcall_lambda (fun=XIL(0xa00000000612d0c8), nargs=1, arg_vector=0x82e370) at eval.c:2989 #16 0x01384953 in Ffuncall (nargs=2, args=0x82e368) at eval.c:2796 #17 0x01427e37 in exec_byte_code (bytestr=XIL(0x8000000006131a80), vector=XIL(0xa00000000612e450), maxdepth=make_fixnum(14), args_template=make_fixnum(0), nargs=0, args=0x82efa8) at bytecode.c:633 #18 0x01385a11 in funcall_lambda (fun=XIL(0xa00000000612e420), nargs=0, arg_vector=0x82efa8) at eval.c:2989 #19 0x01384953 in Ffuncall (nargs=1, args=0x82efa0) at eval.c:2796 #20 0x01427e37 in exec_byte_code (bytestr=XIL(0x8000000006132488), vector=XIL(0xa000000006131c20), maxdepth=make_fixnum(12), args_template=make_fixnum(0), nargs=0, args=0x82f680) at bytecode.c:633 #21 0x01385a11 in funcall_lambda (fun=XIL(0xa000000006131bf0), nargs=0, arg_vector=0x82f680) at eval.c:2989 #22 0x01385519 in apply_lambda (fun=XIL(0xa000000006131bf0), args=XIL(0), count=4) at eval.c:2926 #23 0x01382b51 in eval_sub (form=XIL(0xc000000006278198)) at eval.c:2318 #24 0x013819e8 in Feval (form=XIL(0xc000000006278198), lexical=XIL(0)) at eval.c:2102 #25 0x011df7a3 in top_level_2 () at keyboard.c:1100 #26 0x0137f02d in internal_condition_case (bfun=0x11df76d , handlers=XIL(0x90), hfun=0x11def2f ) at eval.c:1355 #27 0x011df818 in top_level_1 (ignore=XIL(0)) at keyboard.c:1108 #28 0x0137e1f8 in internal_catch (tag=XIL(0xdfe0), func=0x11df7a9 , arg=XIL(0)) at eval.c:1116 #29 0x011df679 in command_loop () at keyboard.c:1069 #30 0x011de9b7 in recursive_edit_1 () at keyboard.c:714 #31 0x011dec2d in Frecursive_edit () at keyboard.c:786 #32 0x011d3547 in main (argc=4, argv=0xa42848) at emacs.c:2054 Lisp Backtrace: "dump-emacs-portable" (0x82d468) "progn" (0x82d658) "eval" (0x82d978) "command-line-1" (0x82e370) "command-line" (0x82efa8) "normal-top-level" (0x82f680) (gdb) fr 5 #5 0x01327f92 in dump_object (ctx=0x82d1f0, object=XIL(0xa000000006288090)) at pdumper.c:3127 3127 offset = dump_vectorlike (ctx, object, offset); (gdb) p object $1 = XIL(0xa000000006288090) (gdb) xtype Lisp_Vectorlike PVEC_HASH_TABLE (gdb) xhashtable $2 = (struct Lisp_Hash_Table *) 0x6288090 (gdb) p *$ $3 = { header = { size = 1291882500 }, weak = XIL(0), hash = XIL(0xa0000000068192c0), next = XIL(0xa0000000068194d0), index = XIL(0xa0000000068196e0), count = 13, next_free = 13, purecopy = false, mutable = true, rehash_threshold = 0.8125, rehash_size = 0.5, key_and_value = XIL(0xa000000005fbe6f8), test = { name = XIL(0x5610), user_hash_function = XIL(0), user_cmp_function = XIL(0), cmpfn = 0x13a7ffe , hashfn = 0x13a8107 }, next_weak = 0x0 } (gdb) p $2->key_and_value $4 = XIL(0xa000000005fbe6f8) (gdb) xtype Lisp_Vectorlike PVEC_NORMAL_VECTOR (gdb) xvector $5 = (struct Lisp_Vector *) 0x5fbe6f8 0 (gdb) p $2->test.name $6 = XIL(0x5610) (gdb) xtype Lisp_Symbol (gdb) xsymbol $7 = (struct Lisp_Symbol *) 0x1bc74d0 "equal" (gdb) p expected_value $8 = XIL(0xa000000006a527d8) (gdb) xtype Lisp_Vectorlike PVEC_COMPILED (gdb) xcompiled $9 = (struct Lisp_Vector *) 0x6a527d8 {make_fixnum(771), XIL(0x8000000006ab8250), XIL(0xa000000006a36558), make_fixnum(13), XIL(0x8000000006ab81c0)} (gdb) p found_value $10 = XIL(0xa000000006c2fc00) (gdb) xtype Lisp_Vectorlike PVEC_COMPILED (gdb) xcompiled $11 = (struct Lisp_Vector *) 0x6c2fc00 {make_fixnum(771), XIL(0x80000000069d21b0), XIL(0xa000000006c2fba0), make_fixnum(13), XIL(0x8000000006a412b0)} (gdb) From unknown Sat Jun 14 18:56:05 2025 X-Loop: help-debbugs@gnu.org Subject: bug#38912: 27.0.60; PDumper meets segmentation fault when evil is loaded Resent-From: Pip Cet Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 06 Jan 2020 15:53:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 38912 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Eli Zaretskii Cc: NiwTinray , 38912@debbugs.gnu.org, Daniel Colascione Received: via spool by 38912-submit@debbugs.gnu.org id=B38912.157832596024918 (code B ref 38912); Mon, 06 Jan 2020 15:53:01 +0000 Received: (at 38912) by debbugs.gnu.org; 6 Jan 2020 15:52:40 +0000 Received: from localhost ([127.0.0.1]:46539 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ioUgK-0006Tp-6c for submit@debbugs.gnu.org; Mon, 06 Jan 2020 10:52:40 -0500 Received: from mail-ot1-f43.google.com ([209.85.210.43]:44075) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ioUgI-0006TY-Uz for 38912@debbugs.gnu.org; Mon, 06 Jan 2020 10:52:39 -0500 Received: by mail-ot1-f43.google.com with SMTP id h9so69623518otj.11 for <38912@debbugs.gnu.org>; Mon, 06 Jan 2020 07:52:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=kak+O91xVS7l6S7dzJdrAMxWCydNRkC2IFYSS8RTL7w=; b=bYY89wpsvYy03RaBC/B86OROzXqRei/oYzZzweBATQ/Cp/QkTg2u+qBb58fmdXZXgu kFfdGdA+lAOpm7VVEUmqmNq8PRT+tqw9KHk/+h//Ts5CTcNWYIGZ6Cv9V94egktmjkDU k1eDhoUMOxrQXI8kTo35GJ6HD4xoDZqeO1quPkcOQK1EPBiBP6nA0O83pQFcnQYCalSq c/G8U+z+opakGZGX6n1Dp99xhbcB9IVWT0i/E2zjvyV7gQaXUKfObd5Q6ctn0uBAGe/R XhPorSkZH8aN7TaV38rt62UL0Wbnq1d4iiob79/Z+WKwnwpFHzG6HSepvCawJuNRxds6 1S4w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=kak+O91xVS7l6S7dzJdrAMxWCydNRkC2IFYSS8RTL7w=; b=emUTSNs4yHB+2qCdAeGPdTOZ8XD8Tjhd46uP+e6DinkgR0OQH8liuIRGsTTg/o1Ui7 Qgpscj89MjZxXGueqUQcADmJ9jWVqdFimzfsA0oWevDbBSoc+YhrH7O3ZI7C67rR2+II iH+o43woumK1MUszhruesnP85BPzWTx08fmHOAgS/VP5XtcNHRahT0IiE/bHch2RS6MI 8WEzmRFt6niICL5ObZ8nbNw7qCKmOSs15uY9WHhJi+rCWaFStJecZZqCKFcmJ2OoGFt3 GD2Cej5UwD+cRTlm//Qk5z01I9C9lIbwTEbF7OJZETcpYds2F0LoCe3Uilf5X85TYPjG b+Qg== X-Gm-Message-State: APjAAAX0Cduj2cvxHDFyRotlsXgmKv0J7WqipigZCWmQHV/vN65bQ8V0 +vSHet1taViu9B57E4Ps4TQT1pEKbmC/NlL1eJ4= X-Google-Smtp-Source: APXvYqyxFv7rMZrLmWP8h/PEMaPKHzlcIjl4AyGU+PjQkNAmwiupfDV4mErsqjOua8b6lCF4p+R0lQHXDwJcEFAfh5U= X-Received: by 2002:a05:6830:1bd5:: with SMTP id v21mr123019042ota.154.1578325953230; Mon, 06 Jan 2020 07:52:33 -0800 (PST) MIME-Version: 1.0 References: <333553AC-68DE-4F1C-9586-5A13248AD6DD@icloud.com> <83ftgvh96l.fsf@gnu.org> <83a771g2tc.fsf@gnu.org> In-Reply-To: <83a771g2tc.fsf@gnu.org> From: Pip Cet Date: Mon, 6 Jan 2020 15:51:57 +0000 Message-ID: Content-Type: text/plain; charset="UTF-8" X-Spam-Score: 0.0 (/) 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, Jan 5, 2020 at 6:46 PM Eli Zaretskii wrote: > In my debug build of Emacs 27.0.60 I get an assertion violation while > dumping, which probably is already a sign of trouble. I think that's unrelated, but here's some analysis anyway, in case we want to fix this bug: Different bytecode objects may be `equal', but have different sxhashes. (equal #[0 "" [] 0] #[0 "" [] 0]) (sxhash #[0 "" [] 0]) (sxhash #[0 "" [] 0]) When such bytecodes are used as keys for a hash table using hashfn_equal, I believe the result is, fairly obviously, two hash table entries for equal keys; when the hash table is rehashed, we may be unlucky enough to retrieve the wrong one, leading to the crash. That's what cl-generic.el does for the table cl--generic-dispatchers, which I believe is what you were looking at. > #2 0x01326817 in check_hash_table_rehash (table_orig=XIL(0xa000000006288090)) > at pdumper.c:2684 Can you confirm table_orig is cl--generic-dispatchers? Again, I doubt this is related to the original bug. That `equal' behaves weirdly like this is a problem I've mentioned before (when (equal a b) signals but (equal b a) succeeds), but the consensus then was not to change it, so it's possible this is only the rehashing check needing to be more careful. From unknown Sat Jun 14 18:56:05 2025 X-Loop: help-debbugs@gnu.org Subject: bug#38912: 27.0.60; PDumper meets segmentation fault when evil is loaded Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 06 Jan 2020 16:35:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 38912 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Pip Cet Cc: niwtrx@icloud.com, 38912@debbugs.gnu.org, dancol@dancol.org Received: via spool by 38912-submit@debbugs.gnu.org id=B38912.157832844429153 (code B ref 38912); Mon, 06 Jan 2020 16:35:01 +0000 Received: (at 38912) by debbugs.gnu.org; 6 Jan 2020 16:34:04 +0000 Received: from localhost ([127.0.0.1]:46560 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ioVKO-0007a8-74 for submit@debbugs.gnu.org; Mon, 06 Jan 2020 11:34:04 -0500 Received: from eggs.gnu.org ([209.51.188.92]:34418) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ioVKM-0007Zd-Np for 38912@debbugs.gnu.org; Mon, 06 Jan 2020 11:34:03 -0500 Received: from fencepost.gnu.org ([2001:470:142:3::e]:57733) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ioVKF-000283-RU; Mon, 06 Jan 2020 11:33:56 -0500 Received: from [176.228.60.248] (port=3227 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1ioVKF-0004CT-4O; Mon, 06 Jan 2020 11:33:55 -0500 Date: Mon, 06 Jan 2020 18:34:02 +0200 Message-Id: <83o8vgee85.fsf@gnu.org> From: Eli Zaretskii In-reply-to: (message from Pip Cet on Mon, 6 Jan 2020 15:51:57 +0000) References: <333553AC-68DE-4F1C-9586-5A13248AD6DD@icloud.com> <83ftgvh96l.fsf@gnu.org> <83a771g2tc.fsf@gnu.org> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Spam-Score: -2.3 (--) 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: Pip Cet > Date: Mon, 6 Jan 2020 15:51:57 +0000 > Cc: NiwTinray , Daniel Colascione , 38912@debbugs.gnu.org > > > #2 0x01326817 in check_hash_table_rehash (table_orig=XIL(0xa000000006288090)) > > at pdumper.c:2684 > > Can you confirm table_orig is cl--generic-dispatchers? I don't think I know how. Hash tables don't seem to have names stored in them, do they? (If they did, I'd expect xhashtable to print that name.) > Again, I doubt this is related to the original bug. That `equal' > behaves weirdly like this is a problem I've mentioned before (when > (equal a b) signals but (equal b a) succeeds), but the consensus then > was not to change it, so it's possible this is only the rehashing > check needing to be more careful. If you can suggest how to make that check more careful, please do. Thanks. From unknown Sat Jun 14 18:56:05 2025 X-Loop: help-debbugs@gnu.org Subject: bug#38912: 27.0.60; PDumper meets segmentation fault when evil is loaded Resent-From: Pip Cet Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 06 Jan 2020 16:40:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 38912 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Eli Zaretskii Cc: niwtrx@icloud.com, 38912@debbugs.gnu.org, Daniel Colascione Received: via spool by 38912-submit@debbugs.gnu.org id=B38912.157832877229738 (code B ref 38912); Mon, 06 Jan 2020 16:40:02 +0000 Received: (at 38912) by debbugs.gnu.org; 6 Jan 2020 16:39:32 +0000 Received: from localhost ([127.0.0.1]:46567 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ioVPg-0007ja-1Z for submit@debbugs.gnu.org; Mon, 06 Jan 2020 11:39:32 -0500 Received: from mail-oi1-f174.google.com ([209.85.167.174]:37095) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ioVPe-0007jL-1v for 38912@debbugs.gnu.org; Mon, 06 Jan 2020 11:39:30 -0500 Received: by mail-oi1-f174.google.com with SMTP id z64so10007737oia.4 for <38912@debbugs.gnu.org>; Mon, 06 Jan 2020 08:39:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=IXZUIoKz9ndp4LUWk4nZC2YH+fHIrtPImbdJaio6KSU=; b=Hp5ST24zyNNeKDKujBPfnDn6JTRRRz4v2hPf1uBr2sXXtZojK3lp/yScnvndGmkXM7 W22gFJ4aclwtO/66NncudRrLKRxh0lkYb0FsboXlF1VCfmkmKpplems/0dJ19cgy0Y1v oVxXoEqg1JVuhLtcKaQ6+kSLlo7pEN2MlaFEauI9UVmHALWSBNNmCdDf13ru1ZrVH+nT nYFlCLC/WwCYipXL5Y9f2WwOsFossngkku9BYD6wfmqtZRwUzuZZXNwZGILyjvc7ybnM Fbs2G/WEEfktc+rLTIMsXlzSuyuhEVIAEFcZ7p9EJUODwGNqVjPlS/RmI8d60IspO7ri E8ug== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=IXZUIoKz9ndp4LUWk4nZC2YH+fHIrtPImbdJaio6KSU=; b=YdUKGK2rXkPTXpvAwbqvr+UhIO+DoyVP55+W8TxBvuFtptxJh94/xtcXxAHY3Wnpae z7/Umiy9f7K8MoRnpKiLPOfho+5X9tB9XWEvj56tsVpuEn3LjApiWQ2C8AQ8KUqZb0rf OluBGBqOzcTNhD2pI+CsT3Xw/Tbg14/mclj2C9SohatUufFaC/lgtk9d8p+pMWNbaXlZ IVIH0IxyfWuD5Vszbq16/vDlkQ1B43o7BQ7Y9pct69gmC7JDQZ9oN2L6sIm73zcqE6V/ x+2prTsD1MaRxsL9CICap2Vvdv6Lg1khYbh3KnOP0apy2pRujvNYn1+PZNr9ltPgKSSL IP2g== X-Gm-Message-State: APjAAAXL1H+XdvfLcd2Ab8Mu74UscvVdifes1BVsWQUln0OqZpBaFYij pr01Ql59/QKvlWnfDmlj7Rr/qt2uhH6zEfhya5I= X-Google-Smtp-Source: APXvYqz+BymrHjw09G4fI6YG11tKX9D7DBQ/8VEY34mgjsaVLUA8D1aMFJwY66mjsG+ng5IwluhQe3eZ23QpzCLSeTk= X-Received: by 2002:a54:4396:: with SMTP id u22mr5982327oiv.128.1578328764337; Mon, 06 Jan 2020 08:39:24 -0800 (PST) MIME-Version: 1.0 References: <333553AC-68DE-4F1C-9586-5A13248AD6DD@icloud.com> <83ftgvh96l.fsf@gnu.org> <83a771g2tc.fsf@gnu.org> <83o8vgee85.fsf@gnu.org> In-Reply-To: <83o8vgee85.fsf@gnu.org> From: Pip Cet Date: Mon, 6 Jan 2020 16:38:48 +0000 Message-ID: Content-Type: text/plain; charset="UTF-8" X-Spam-Score: 0.0 (/) 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 Mon, Jan 6, 2020 at 4:33 PM Eli Zaretskii wrote: > > From: Pip Cet > > Date: Mon, 6 Jan 2020 15:51:57 +0000 > > Cc: NiwTinray , Daniel Colascione , 38912@debbugs.gnu.org > > > > > #2 0x01326817 in check_hash_table_rehash (table_orig=XIL(0xa000000006288090)) > > > at pdumper.c:2684 > > > > Can you confirm table_orig is cl--generic-dispatchers? > > I don't think I know how. I meant something like p Fsymbol_value(intern("cl--generic-dispatchers")) in gdb. Will that work on your platform? > Hash tables don't seem to have names stored > in them, do they? (If they did, I'd expect xhashtable to print that > name.) They don't have names, no. > > Again, I doubt this is related to the original bug. That `equal' > > behaves weirdly like this is a problem I've mentioned before (when > > (equal a b) signals but (equal b a) succeeds), but the consensus then > > was not to change it, so it's possible this is only the rehashing > > check needing to be more careful. > > If you can suggest how to make that check more careful, please do. I'd suggest just skipping the entire check for hashfn_equal, at least on the Emacs 27 branch. On master, I'd prefer to make equal-equality imply sxhash-equality. From unknown Sat Jun 14 18:56:05 2025 X-Loop: help-debbugs@gnu.org Subject: bug#38912: 27.0.60; PDumper meets segmentation fault when evil is loaded Resent-From: "Daniel Colascione" Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 06 Jan 2020 17:02:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 38912 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: "Eli Zaretskii" Cc: niwtrx@icloud.com, 38912@debbugs.gnu.org, dancol@dancol.org, Pip Cet Received: via spool by 38912-submit@debbugs.gnu.org id=B38912.157833009432157 (code B ref 38912); Mon, 06 Jan 2020 17:02:02 +0000 Received: (at 38912) by debbugs.gnu.org; 6 Jan 2020 17:01:34 +0000 Received: from localhost ([127.0.0.1]:46585 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ioVl0-0008Ma-6P for submit@debbugs.gnu.org; Mon, 06 Jan 2020 12:01:34 -0500 Received: from dancol.org ([96.126.100.184]:58100) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ioVkx-0008MR-LN for 38912@debbugs.gnu.org; Mon, 06 Jan 2020 12:01:32 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=dancol.org; s=x; h=Content-Transfer-Encoding:Content-Type:MIME-Version:Cc:To:From: Subject:Date:References:In-Reply-To:Message-ID:Sender:Reply-To:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=xag8HFSXr1hEbYi1Xhv9hwnOz5AUQ+PEGvrtTJmuLnk=; b=hqZualFvtrEd4VdSObo3a8gcJJ pJSgb4Zr2gZKuAH/fuIdJGq06cnJcHyVT0ttC8eE8rNSzeV2h/vXpyvC7rywQoxHkcof57Q1Tl7Qn lwIcmzQXWuaSvsXA6ND+CLgz7zkm6VC3e/SC72C3JnP1wWNfkSGTP9LzwG4IIM9MG0R5kg4bf6uGL 9+aNX1OGa/b6AHJjsNcjkmZuD6/Wvx9+INLDU09uEaM/V6OGYqCBr60k7O9bWLkkKFSH60rUP7p+5 Pco6DwIWO+rudvcf1OJULoqy4m/naLkpFPr5XNinEpdEwCc4utFq/tOemM4bowCHXo2q3zG1PrC6u TfLMMidA==; Received: from localhost ([127.0.0.1] helo=dancol.org) by dancol.org with esmtp (Exim 4.89) (envelope-from ) id 1ioVkq-0007A0-LA; Mon, 06 Jan 2020 09:01:24 -0800 Received: from 127.0.0.1 (SquirrelMail authenticated user dancol) by dancol.org with HTTP; Mon, 6 Jan 2020 09:01:24 -0800 Message-ID: <8b2e879676c6ecc1371d50e033164424.squirrel@dancol.org> In-Reply-To: <83o8vgee85.fsf@gnu.org> References: <333553AC-68DE-4F1C-9586-5A13248AD6DD@icloud.com> <83ftgvh96l.fsf@gnu.org> <83a771g2tc.fsf@gnu.org> <83o8vgee85.fsf@gnu.org> Date: Mon, 6 Jan 2020 09:01:24 -0800 From: "Daniel Colascione" User-Agent: SquirrelMail/1.4.23 [SVN] MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal X-Spam-Score: -0.0 (/) 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 (-) >> From: Pip Cet >> Date: Mon, 6 Jan 2020 15:51:57 +0000 >> Cc: NiwTinray , Daniel Colascione >> , 38912@debbugs.gnu.org >> >> > #2 0x01326817 in check_hash_table_rehash >> (table_orig=XIL(0xa000000006288090)) >> > at pdumper.c:2684 >> >> Can you confirm table_orig is cl--generic-dispatchers? > > I don't think I know how. Hash tables don't seem to have names stored > in them, do they? (If they did, I'd expect xhashtable to print that > name.) > >> Again, I doubt this is related to the original bug. That `equal' >> behaves weirdly like this is a problem I've mentioned before (when >> (equal a b) signals but (equal b a) succeeds), but the consensus then >> was not to change it, so it's possible this is only the rehashing >> check needing to be more careful. This consensus is wrong. We need to make equality imply sxhash equality or very odd things (like this) will happen. C++ and Java both require this relationship between hash code equality and object equality, and we should too. Can we just fix the bytecode sxhash bug? From unknown Sat Jun 14 18:56:05 2025 X-Loop: help-debbugs@gnu.org Subject: bug#38912: 27.0.60; PDumper meets segmentation fault when evil is loaded Resent-From: "Daniel Colascione" Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 06 Jan 2020 17:11:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 38912 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: "Eli Zaretskii" Cc: NiwTinray , 38912@debbugs.gnu.org, Daniel Colascione Received: via spool by 38912-submit@debbugs.gnu.org id=B38912.1578330627591 (code B ref 38912); Mon, 06 Jan 2020 17:11:02 +0000 Received: (at 38912) by debbugs.gnu.org; 6 Jan 2020 17:10:27 +0000 Received: from localhost ([127.0.0.1]:46598 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ioVta-00009S-Qe for submit@debbugs.gnu.org; Mon, 06 Jan 2020 12:10:27 -0500 Received: from dancol.org ([96.126.100.184]:58286) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ioVtY-00009I-Fd for 38912@debbugs.gnu.org; Mon, 06 Jan 2020 12:10:24 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=dancol.org; s=x; h=Content-Transfer-Encoding:Content-Type:MIME-Version:Cc:To:From: Subject:Date:References:In-Reply-To:Message-ID:Sender:Reply-To:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=FPTAIL4tiztV7pq0BpWbQEX0OBDODwb117204Ry76C0=; b=pm83BDcBZ+eHhLPruU0FuO8c5N OHToOBP9g7rrSjsX0dm4zB/9M07U466kRVcm2aLrxu5cxKnDesd0zN6p88W6xMycXnRF2BMyLagwG /bvh0Kleke1K9cL/Ur1hjx63720rXFMai1A90fAQEiN+x9fgbI+qVJ9fVNefr6HOqYGd06VNsWvyA WW1MmZ5jCDzztLVW5Ppu1g85qsoeCXM4eqHD/6wzItrk7f+Fj7Qm916DucM+xrHFwJgxbPThsZ1im Ns9n08UVkvkumtUx+NQU128xtycAlf9Z++wfzJaHugD9lxt7addmsQ2xdSZ+L5YZhFnyCCbskN9fU Dk1Bj/jg==; Received: from localhost ([127.0.0.1] helo=dancol.org) by dancol.org with esmtp (Exim 4.89) (envelope-from ) id 1ioVtT-0007Kx-Vj; Mon, 06 Jan 2020 09:10:20 -0800 Received: from 127.0.0.1 (SquirrelMail authenticated user dancol) by dancol.org with HTTP; Mon, 6 Jan 2020 09:10:20 -0800 Message-ID: In-Reply-To: <83a771g2tc.fsf@gnu.org> References: <333553AC-68DE-4F1C-9586-5A13248AD6DD@icloud.com> <83ftgvh96l.fsf@gnu.org> <83a771g2tc.fsf@gnu.org> Date: Mon, 6 Jan 2020 09:10:20 -0800 From: "Daniel Colascione" User-Agent: SquirrelMail/1.4.23 [SVN] MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal X-Spam-Score: -0.0 (/) 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 (-) > [Please use "Reply All" to reply, so that the bug address is kept on > the CC list.] > >> From: NiwTinray >> Date: Sun, 5 Jan 2020 13:25:07 +0800 >> >> > I cannot reproduce this from "emacs -Q" because 'use-package' is not a >> > known function. Can you show a recipe starting from "emacs -Q", >> > please? >> >> Here. I've attached a minimal script file that helps reproduce this bug. >> >> (require 'package) >> (package-initialize) >> (add-to-list 'package-archives >> '("melpa-stable" . "https://stable.melpa.org/packages/") t) >> (unless (package-installed-p 'evil) >> (package-refresh-contents) >> (package-install 'evil)) >> (require 'evil) >> (dump-emacs-portable "/tmp/test.pdmp") >> >> The script downloads the package "evil" from Melpa stable, load the evil >> package >> and dumps an image to /tmp/test.pdmp. >> >> > Also, does this happen if you add -Q to the Emacs invocation after >> > dumping? If not, there's more detail missing in your report: the >> > customizations in your init files. >> >> >> Sure. Please download this file, and run the command: >> >> emacs --batch -Q --script evil.el >> >> To see the bug happen, load the test.pdmp file: >> >> emacs -Q --dump-file /tmp/test.pdmp >> >> You should see a segmentation fault: >> >> [1] 23369 segmentation fault (core dumped) emacs -Q --dump-file >> /tmp/test.pdmp >> >> I run debugger inside src/.gdbinit using the command: >> >> gdb -x .gdbinit --args ./emacs --dump-file /tmp/test.pdmp >> >> And logged backtrace. See my second attachment: >> >> (base) omnisky :: ~/emacs/src ‹emacs-27*› » gdb -x .gdbinit --args >> ./emacs --dump-file /tmp/test.pdmp >> GNU gdb (Ubuntu 7.11.1-0ubuntu1~16.5) 7.11.1 >> Copyright (C) 2016 Free Software Foundation, Inc. >> License GPLv3+: GNU GPL version 3 or later >> >> This is free software: you are free to change and redistribute it. >> There is NO WARRANTY, to the extent permitted by law. Type "show >> copying" >> and "show warranty" for details. >> This GDB was configured as "x86_64-linux-gnu". >> Type "show configuration" for configuration details. >> For bug reporting instructions, please see: >> . >> Find the GDB manual and other documentation resources online at: >> . >> For help, type "help". >> Type "apropos word" to search for commands related to "word"... >> Reading symbols from ./emacs...done. >> warning: File "/home/ntr/emacs/src/.gdbinit" auto-loading has been >> declined by your `auto-load safe-path' set to >> "$debugdir:$datadir/auto-load". >> To enable execution of this file add >> add-auto-load-safe-path /home/ntr/emacs/src/.gdbinit >> line to your configuration file "/home/ntr/.gdbinit". >> To completely disable this security protection add >> set auto-load safe-path / >> line to your configuration file "/home/ntr/.gdbinit". >> For more information about this security protection see the >> "Auto-loading safe path" section in the GDB manual. E.g., run from the >> shell: >> info "(gdb)Auto-loading safe path" >> SIGINT is used by the debugger. >> Are you sure you want to change it? (y or n) [answered Y; input not from >> terminal] >> Environment variable "DISPLAY" not defined. >> TERM = xterm-24bits >> Breakpoint 1 at 0x411df0: file emacs.c, line 370. >> Breakpoint 2 at 0x4bfe60: file xterm.c, line 10130. >> (gdb) r >> Starting program: /home/ntr/emacs/src/emacs --dump-file /tmp/test.pdmp >> /home/ntr/emacs/src/emacs: >> /raid_sdc/home/ntr/anaconda3/lib/libtiff.so.5: no version information >> available (required by /home/ntr/emacs/src/emacs) >> [Thread debugging using libthread_db enabled] >> Using host libthread_db library >> "/lib/x86_64-linux-gnu/libthread_db.so.1". >> >> Program received signal SIGSEGV, Segmentation fault. >> 0x00000000004f12d0 in Fcurrent_active_maps (olp=olp@entry=XIL(0x30), >> position=position@entry=XIL(0)) at keymap.c:1541 >> 1541 && NILP (KVAR (current_kboard, >> Voverriding_terminal_local_map)) >> (gdb) xbacktrace >> "key-binding" (0xffffd5c8) >> "turn-on-undo-tree-mode" (0xffffd758) >> "global-undo-tree-mode-enable-in-buffers" (0xffffd948) >> "run-hooks" (0xffffd9e8) >> "run-mode-hooks" (0xffffdbc0) >> "minibuffer-inactive-mode" (0xffffdd40) >> (gdb) > > In my debug build of Emacs 27.0.60 I get an assertion violation while > dumping, which probably is already a sign of trouble. > > Daniel, any ideas? I haven't had a chance over the past few days to repro this problem, but I hope to do so this weeekend. The messages about the assertion failure *during* dumping do seem likely unrelated. The easiest way to debug this particular crash is with rr. Run the original test as "rr record emacs [args]", then run "rr replay". The latter will dump you in a GDB prompt. Type "cont" and run the replay of Emacs until you get to the SIGSEGV. Run "watch -l [expression]" to break out of execution whenever that value changes, then run "reverse-cont" to run the replay *backwards* until you get to the code that changed the variable with the bad value. From unknown Sat Jun 14 18:56:05 2025 X-Loop: help-debbugs@gnu.org Subject: bug#38912: 27.0.60; PDumper meets segmentation fault when evil is loaded Resent-From: Pip Cet Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 06 Jan 2020 17:15:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 38912 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Daniel Colascione , emacs-devel@gnu.org Cc: niwtrx@icloud.com, 38912@debbugs.gnu.org, Eli Zaretskii Received: via spool by 38912-submit@debbugs.gnu.org id=B38912.1578330863972 (code B ref 38912); Mon, 06 Jan 2020 17:15:02 +0000 Received: (at 38912) by debbugs.gnu.org; 6 Jan 2020 17:14:23 +0000 Received: from localhost ([127.0.0.1]:46602 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ioVxP-0000Fb-Jp for submit@debbugs.gnu.org; Mon, 06 Jan 2020 12:14:23 -0500 Received: from mail-ot1-f54.google.com ([209.85.210.54]:45121) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ioVxO-0000FJ-4Z for 38912@debbugs.gnu.org; Mon, 06 Jan 2020 12:14:22 -0500 Received: by mail-ot1-f54.google.com with SMTP id 59so72554234otp.12 for <38912@debbugs.gnu.org>; Mon, 06 Jan 2020 09:14:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=vmpaOjiRhtTPvrWge/yTbwEpuaWt5vkGpsc5UDVWaLs=; b=n+7tv8D2/LH38YOCeN5Rr4okMOBExG+D4fbCvJD5rFzWeibCF6zroffr/ObVkFqju4 4f5I+bkdNotienpSNl4vPrKcVyXpcACGEHo0hjKH+F33U1ItL2aMigrsJidj9pCqsotw 2gwvjzLPTqllUvk2sn6xhqRH5JkMNMVTDJUt8TKPbvo+nVUvIOFEVUaeq2HDowPIDS26 s1OorU+zdETOA/6kk3oQJF1LigE2sqvE0GBXWRsivHYv8h+kQo31kHsKvY8U4mqFbHl0 A0DRNVrjB4LhidiYFGxyT0HAK4wHnHdu1EFGYq+wLRRSNNP0/5/rSp35gaT7BemuDd+c d4HA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=vmpaOjiRhtTPvrWge/yTbwEpuaWt5vkGpsc5UDVWaLs=; b=YSDOvVOVbCEyEShPSPyujGPCNYIi+MmKwU2WXFFkEghufvlWWPMan+kSo8G4Gi1lGX cgi2n/olosWEDQAyg9DrY+Jf53aD3YpsNCIQmpr//LGhfCsVJTRdqote6aEfcgYt+myW c6jELDzIkGiobeGAEe9PLQfUNgk5bjKltgjVg1e1zojy1S+asLSggY0aDbOGqvzTuhPW cxYmcaC5lF3n7KBr1B2cHePYiezyr1IJJUtLiy8zXQppBhiOcA+PfrVOPpcswJufsbax bPfdfZOv1+VtGIx+lvMe4hHAs8QvgkFHNYhP1jFXzKaiQsXRCC+cC+BYxlVmn4/Yx9+n KMWA== X-Gm-Message-State: APjAAAU06E0hVLdJme2QAj1aIWbIG38MTDfwLT1P/4+GSAnLBh3D2G5G svBsAAbxpn7gVxiWDxPkzNaEFPuI1zY9p1tez/0= X-Google-Smtp-Source: APXvYqyUE2ucRJnx19JUStEZqTIyiZNLRKu0s4p8d0DdXWbinOC0o1UQvGdHOMSMYFxpWeXQDu8MOVIPDf9cWIAZBVc= X-Received: by 2002:a9d:68cb:: with SMTP id i11mr111575295oto.210.1578330856573; Mon, 06 Jan 2020 09:14:16 -0800 (PST) MIME-Version: 1.0 References: <333553AC-68DE-4F1C-9586-5A13248AD6DD@icloud.com> <83ftgvh96l.fsf@gnu.org> <83a771g2tc.fsf@gnu.org> <83o8vgee85.fsf@gnu.org> <8b2e879676c6ecc1371d50e033164424.squirrel@dancol.org> In-Reply-To: <8b2e879676c6ecc1371d50e033164424.squirrel@dancol.org> From: Pip Cet Date: Mon, 6 Jan 2020 17:13:40 +0000 Message-ID: Content-Type: text/plain; charset="UTF-8" X-Spam-Score: 0.0 (/) 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 (-) Summary, since I'm CCing emacs-devel: For bytecode objects, equal-equality does not imply sxhash-equality. That led to an assertion failure in the pdumper code, even though the pdumper code itself is apparently correct; it simply does not allow for paradoxical behavior of hash tables with bytecode keys. (The muffled sound you hear in the background is my trying not to point out that eq-vs-eql leads to similar paradoxes). On Mon, Jan 6, 2020 at 5:01 PM Daniel Colascione wrote: > >> Again, I doubt this is related to the original bug. That `equal' > >> behaves weirdly like this is a problem I've mentioned before (when > >> (equal a b) signals but (equal b a) succeeds), but the consensus then > >> was not to change it, so it's possible this is only the rehashing > >> check needing to be more careful. > This consensus is wrong. We need to make equality imply sxhash equality or > very odd things (like this) will happen. I agree absolutely, of course, and maybe there's a consensus for fixing equal for bytecodes but leaving it unfixed for cases in which (equal a b) signals but (equal b a) does not. > C++ and Java both require this > relationship between hash code equality and object equality, and we should > too. We do document it, we just don't obey our documented API. > Can we just fix the bytecode sxhash bug? Is it too late to fix this for Emacs 27? If the answer is no, would a good fix be to make equal=eq for bytecode objects? That should come close to the old behavior, and we can fix things properly (by fixing sxhash to hash byte code objects) on master. From unknown Sat Jun 14 18:56:05 2025 X-Loop: help-debbugs@gnu.org Subject: bug#38912: 27.0.60; PDumper meets segmentation fault when evil is loaded Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 06 Jan 2020 17:21:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 38912 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Pip Cet Cc: niwtrx@icloud.com, 38912@debbugs.gnu.org, dancol@dancol.org Received: via spool by 38912-submit@debbugs.gnu.org id=B38912.15783312341667 (code B ref 38912); Mon, 06 Jan 2020 17:21:02 +0000 Received: (at 38912) by debbugs.gnu.org; 6 Jan 2020 17:20:34 +0000 Received: from localhost ([127.0.0.1]:46630 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ioW3O-0000Qp-0v for submit@debbugs.gnu.org; Mon, 06 Jan 2020 12:20:34 -0500 Received: from eggs.gnu.org ([209.51.188.92]:42943) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ioW3M-0000Qb-65 for 38912@debbugs.gnu.org; Mon, 06 Jan 2020 12:20:32 -0500 Received: from fencepost.gnu.org ([2001:470:142:3::e]:58849) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ioW3G-0004BM-5y; Mon, 06 Jan 2020 12:20:26 -0500 Received: from [176.228.60.248] (port=2058 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1ioW3E-0002a8-AU; Mon, 06 Jan 2020 12:20:25 -0500 Date: Mon, 06 Jan 2020 19:20:32 +0200 Message-Id: <83k164ec2n.fsf@gnu.org> From: Eli Zaretskii In-reply-to: (message from Pip Cet on Mon, 6 Jan 2020 16:38:48 +0000) References: <333553AC-68DE-4F1C-9586-5A13248AD6DD@icloud.com> <83ftgvh96l.fsf@gnu.org> <83a771g2tc.fsf@gnu.org> <83o8vgee85.fsf@gnu.org> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Spam-Score: -2.3 (--) 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: Pip Cet > Date: Mon, 6 Jan 2020 16:38:48 +0000 > Cc: niwtrx@icloud.com, Daniel Colascione , 38912@debbugs.gnu.org > > > > Can you confirm table_orig is cl--generic-dispatchers? > > > > I don't think I know how. > > I meant something like > > p Fsymbol_value(intern("cl--generic-dispatchers")) > > in gdb. Will that work on your platform? Yes, of course: (gdb) p/x Fsymbol_value(intern("cl--generic-dispatchers")) $2 = 0xa000000006288090 (gdb) p table_orig $3 = XIL(0xa000000006288090) So yes, that's cl--generic-dispatchers. > > If you can suggest how to make that check more careful, please do. > > I'd suggest just skipping the entire check for hashfn_equal, at least > on the Emacs 27 branch. On master, I'd prefer to make equal-equality > imply sxhash-equality. Patches will be welcome, thanks. From unknown Sat Jun 14 18:56:05 2025 X-Loop: help-debbugs@gnu.org Subject: bug#38912: 27.0.60; PDumper meets segmentation fault when evil is loaded Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 06 Jan 2020 17:26:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 38912 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: "Daniel Colascione" , Stefan Monnier Cc: niwtrx@icloud.com, 38912@debbugs.gnu.org, pipcet@gmail.com Received: via spool by 38912-submit@debbugs.gnu.org id=B38912.15783315352202 (code B ref 38912); Mon, 06 Jan 2020 17:26:01 +0000 Received: (at 38912) by debbugs.gnu.org; 6 Jan 2020 17:25:35 +0000 Received: from localhost ([127.0.0.1]:46634 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ioW8E-0000ZS-M4 for submit@debbugs.gnu.org; Mon, 06 Jan 2020 12:25:34 -0500 Received: from eggs.gnu.org ([209.51.188.92]:46365) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ioW8D-0000ZH-Qf for 38912@debbugs.gnu.org; Mon, 06 Jan 2020 12:25:34 -0500 Received: from fencepost.gnu.org ([2001:470:142:3::e]:58903) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ioW87-00011E-Mt; Mon, 06 Jan 2020 12:25:27 -0500 Received: from [176.228.60.248] (port=2364 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1ioW81-0002yI-2b; Mon, 06 Jan 2020 12:25:26 -0500 Date: Mon, 06 Jan 2020 19:25:30 +0200 Message-Id: <83imloebud.fsf@gnu.org> From: Eli Zaretskii In-reply-to: <8b2e879676c6ecc1371d50e033164424.squirrel@dancol.org> References: <333553AC-68DE-4F1C-9586-5A13248AD6DD@icloud.com> <83ftgvh96l.fsf@gnu.org> <83a771g2tc.fsf@gnu.org> <83o8vgee85.fsf@gnu.org> <8b2e879676c6ecc1371d50e033164424.squirrel@dancol.org> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Spam-Score: -2.3 (--) 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 (---) > Date: Mon, 6 Jan 2020 09:01:24 -0800 > From: "Daniel Colascione" > Cc: "Pip Cet" , > niwtrx@icloud.com, > dancol@dancol.org, > 38912@debbugs.gnu.org > > >> Again, I doubt this is related to the original bug. That `equal' > >> behaves weirdly like this is a problem I've mentioned before (when > >> (equal a b) signals but (equal b a) succeeds), but the consensus then > >> was not to change it, so it's possible this is only the rehashing > >> check needing to be more careful. > > This consensus is wrong. We need to make equality imply sxhash equality or > very odd things (like this) will happen. C++ and Java both require this > relationship between hash code equality and object equality, and we should > too. Can we just fix the bytecode sxhash bug? That'd be fine with me, especially since the ELisp manual seems to say this is indeed a bug. From unknown Sat Jun 14 18:56:05 2025 X-Loop: help-debbugs@gnu.org Subject: bug#38912: 27.0.60; PDumper meets segmentation fault when evil is loaded Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 06 Jan 2020 17:31:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 38912 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Pip Cet , Stefan Monnier Cc: niwtrx@icloud.com, 38912@debbugs.gnu.org, dancol@dancol.org Received: via spool by 38912-submit@debbugs.gnu.org id=B38912.15783318042676 (code B ref 38912); Mon, 06 Jan 2020 17:31:01 +0000 Received: (at 38912) by debbugs.gnu.org; 6 Jan 2020 17:30:04 +0000 Received: from localhost ([127.0.0.1]:46640 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ioWCa-0000h6-C0 for submit@debbugs.gnu.org; Mon, 06 Jan 2020 12:30:04 -0500 Received: from eggs.gnu.org ([209.51.188.92]:50477) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ioWCY-0000g9-S7 for 38912@debbugs.gnu.org; Mon, 06 Jan 2020 12:30:03 -0500 Received: from fencepost.gnu.org ([2001:470:142:3::e]:58974) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ioWCT-0000Cs-NA; Mon, 06 Jan 2020 12:29:57 -0500 Received: from [176.228.60.248] (port=2644 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1ioWCT-0001Bw-0X; Mon, 06 Jan 2020 12:29:57 -0500 Date: Mon, 06 Jan 2020 19:30:04 +0200 Message-Id: <83h818ebmr.fsf@gnu.org> From: Eli Zaretskii In-reply-to: (message from Pip Cet on Mon, 6 Jan 2020 17:13:40 +0000) References: <333553AC-68DE-4F1C-9586-5A13248AD6DD@icloud.com> <83ftgvh96l.fsf@gnu.org> <83a771g2tc.fsf@gnu.org> <83o8vgee85.fsf@gnu.org> <8b2e879676c6ecc1371d50e033164424.squirrel@dancol.org> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Spam-Score: -2.3 (--) 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: Pip Cet > Date: Mon, 6 Jan 2020 17:13:40 +0000 > Cc: Eli Zaretskii , niwtrx@icloud.com, 38912@debbugs.gnu.org > > Summary, since I'm CCing emacs-devel: Please don't, I added Stefan instead. > > Can we just fix the bytecode sxhash bug? > > Is it too late to fix this for Emacs 27? Depends on the fix and its potential side effects. OTOH, being able to pdump a customized Emacs is not a goal for Emacs 27.1 (we already know that it doesn't work 100%, and needs more work), so if the fix is somewhat risky, we could do that on master. From unknown Sat Jun 14 18:56:05 2025 X-Loop: help-debbugs@gnu.org Subject: bug#38912: 27.0.60; PDumper meets segmentation fault when evil is loaded Resent-From: Stefan Monnier Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 06 Jan 2020 18:14:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 38912 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Eli Zaretskii Cc: niwtrx@icloud.com, 38912@debbugs.gnu.org, dancol@dancol.org, Pip Cet Received: via spool by 38912-submit@debbugs.gnu.org id=B38912.15783344227038 (code B ref 38912); Mon, 06 Jan 2020 18:14:01 +0000 Received: (at 38912) by debbugs.gnu.org; 6 Jan 2020 18:13:42 +0000 Received: from localhost ([127.0.0.1]:46675 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ioWso-0001pS-7E for submit@debbugs.gnu.org; Mon, 06 Jan 2020 13:13:42 -0500 Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:53226) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ioWsm-0001pG-Dy for 38912@debbugs.gnu.org; Mon, 06 Jan 2020 13:13:40 -0500 Received: from pmg1.iro.umontreal.ca (localhost.localdomain [127.0.0.1]) by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id DCFE6100A09; Mon, 6 Jan 2020 13:13:34 -0500 (EST) Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id 4B1071003B1; Mon, 6 Jan 2020 13:13:33 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1578334413; bh=zc/2EZEkEbbGQARl4neb/TSqbomVguZk+9jUOZiP/mM=; h=From:To:Cc:Subject:References:Date:In-Reply-To:From; b=TDOAa0S/9A8v29WhlmFQeOFy7DppnbA48hdch4dcN25BVgAI0qq9elW7NXTeMN1XB H2k2Rev8CCILc+bFvDoTttyrPm2AAOGZJ6f3nauCc21a2DM4sCZOMKbpUZTEzZErd3 5mJsnMT1OP3BMRGVn2rjSQqF70+fFYC9iQ//mk3n8nGyp68nJnvmW2sjWLX/9z0+xo MMwxeJm05WswLF+8/FBjprPGLb9y/FogZLhcEgJ666k3r9B8EXPtqn88qDwCcWQSom Rxe73Ojtt96kGrAOAjzsSrWc+No1oKKT4t27YlAzps/yZlRuTXeTTjf38EcLbFh7rp WVuqP0RmZ8h4w== Received: from alfajor (modemcable157.163-203-24.mc.videotron.ca [24.203.163.157]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 0EE081203D6; Mon, 6 Jan 2020 13:13:33 -0500 (EST) From: Stefan Monnier Message-ID: References: <333553AC-68DE-4F1C-9586-5A13248AD6DD@icloud.com> <83ftgvh96l.fsf@gnu.org> <83a771g2tc.fsf@gnu.org> <83o8vgee85.fsf@gnu.org> <8b2e879676c6ecc1371d50e033164424.squirrel@dancol.org> <83h818ebmr.fsf@gnu.org> Date: Mon, 06 Jan 2020 13:13:31 -0500 In-Reply-To: <83h818ebmr.fsf@gnu.org> (Eli Zaretskii's message of "Mon, 06 Jan 2020 19:30:04 +0200") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-SPAM-INFO: Spam detection results: 0 ALL_TRUSTED -1 Passed through trusted hosts only via SMTP AWL 0.033 Adjusted score from AWL reputation of From: address BAYES_00 -1.9 Bayes spam probability is 0 to 1% DKIM_SIGNED 0.1 Message has a DKIM or DK signature, not necessarily valid DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's domain X-SPAM-LEVEL: X-Spam-Score: -2.3 (--) 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 (---) The problem is simply that `sxhash` doesn't use the same "rules" about which objects are compared by identity and which objects are compared by contents. In `src/fns.c`, when we compare `internal_equal` and `sxhash`, we see that `sxhash` only looks at the contents of vectorlikes if they are: BIGNUMP, VECTORP, RECORDP, or BOOL_VECTOR_P whereas `internal_equal` looks inside many more vectorlikes: if (BIGNUMP (o1)) return mpz_cmp (*xbignum_val (o1), *xbignum_val (o2)) == 0; if (OVERLAYP (o1)) { if (!internal_equal (OVERLAY_START (o1), OVERLAY_START (o2), equal_kind, depth + 1, ht) || !internal_equal (OVERLAY_END (o1), OVERLAY_END (o2), equal_kind, depth + 1, ht)) return false; o1 = XOVERLAY (o1)->plist; o2 = XOVERLAY (o2)->plist; depth++; goto tail_recurse; } if (MARKERP (o1)) { return (XMARKER (o1)->buffer == XMARKER (o2)->buffer && (XMARKER (o1)->buffer == 0 || XMARKER (o1)->bytepos == XMARKER (o2)->bytepos)); } /* Boolvectors are compared much like strings. */ if (BOOL_VECTOR_P (o1)) { EMACS_INT size = bool_vector_size (o1); if (size != bool_vector_size (o2)) return false; if (memcmp (bool_vector_data (o1), bool_vector_data (o2), bool_vector_bytes (size))) return false; return true; } if (WINDOW_CONFIGURATIONP (o1)) { eassert (equal_kind != EQUAL_NO_QUIT); return compare_window_configurations (o1, o2, false); } /* Aside from them, only true vectors, char-tables, compiled functions, and fonts (font-spec, font-entity, font-object) are sensible to compare, so eliminate the others now. */ if (size & PSEUDOVECTOR_FLAG) { if (((size & PVEC_TYPE_MASK) >> PSEUDOVECTOR_AREA_BITS) < PVEC_COMPILED) return false; size &= PSEUDOVECTOR_SIZE_MASK; } for (ptrdiff_t i = 0; i < size; i++) { Lisp_Object v1, v2; v1 = AREF (o1, i); v2 = AREF (o2, i); if (!internal_equal (v1, v2, equal_kind, depth + 1, ht)) return false; } return true; } break; so the problem doesn't affect only byte-compiled objects but also overlays, markers, windowconfigs, chartables, and fonts, AFAICT. The fix should be to make `sxhash` follow the same rules as `internal_equal`. This is a fairly long-standing problem, so unless it is newly triggered in "normal" circumstances in Emacs-27, the fix is probably best on `master`. Stefan From unknown Sat Jun 14 18:56:05 2025 X-Loop: help-debbugs@gnu.org Subject: bug#38912: 27.0.60; PDumper meets segmentation fault when evil is loaded Resent-From: Noam Postavsky Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 06 Jan 2020 18:20:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 38912 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Stefan Monnier Cc: niwtrx@icloud.com, 38912@debbugs.gnu.org, Eli Zaretskii , dancol@dancol.org, Pip Cet Received: via spool by 38912-submit@debbugs.gnu.org id=B38912.15783347957654 (code B ref 38912); Mon, 06 Jan 2020 18:20:01 +0000 Received: (at 38912) by debbugs.gnu.org; 6 Jan 2020 18:19:55 +0000 Received: from localhost ([127.0.0.1]:46683 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ioWyp-0001zO-45 for submit@debbugs.gnu.org; Mon, 06 Jan 2020 13:19:55 -0500 Received: from mail-qv1-f52.google.com ([209.85.219.52]:45166) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ioWyn-0001zA-BT for 38912@debbugs.gnu.org; Mon, 06 Jan 2020 13:19:53 -0500 Received: by mail-qv1-f52.google.com with SMTP id l14so19407315qvu.12 for <38912@debbugs.gnu.org>; Mon, 06 Jan 2020 10:19:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:subject:references:date:in-reply-to:message-id :user-agent:mime-version; bh=KJ7HcGTjp1PGjXHi2d0OmH09Ff4vJIFIo+bZHkg1uKQ=; b=ISASgGa8I2XpTGVmMcvWNq5D+QmUxatCpO1qCFf1kgRj0XLKcBcmgUIhSKUFsTMdvN MEuCFN3Rq2MQpWnpxYc61IVaUPJZS8L09gn0m3Zc/fb6a8GgSN4CHL4K2zRgKcY8Mk73 VWXp+uwVcBvqObiK+s+FOaicA4l/7EH7KcQOtq0Lpu3TtW2QiOpKHxNVV7JZ8NXvvVCz dZl0sDLcnrI9/cX9fajiiYkpsRExwOB6ecAjsnmV88TefF6o+6VVXyMjUVVknOqhor79 simI5H4PkjQxPsRgkx6PkEiA/7TeYx9RxNbW9EAY5mSliVzLd3Rm7GyzAGZz0HvAHsyU QbWQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:references:date:in-reply-to :message-id:user-agent:mime-version; bh=KJ7HcGTjp1PGjXHi2d0OmH09Ff4vJIFIo+bZHkg1uKQ=; b=Eer/emnbtTS9zznfKsoXcNes4ghK/SMWCSrNGsLPPqmIA/3iPHUwbDnPvvE/QQ3Bok Uku7BVfb8m2ndOj9FnvlW9b4keQMOV8PbAUzGMiqsI8QG9a+hcBtFf+sy+5Folh+xHkJ 7bgYTxKdjP8DyixAndvcYRRcgFtpEcp4Mya3iTKlcsMueNO+8S1QSvcIZU1l2Mqm6gfQ rAj/N/UwyHBYQ95L4VPWFapPteeH5OTQLLE+QfMWSpHYHdoBZ+jIFClQblF2iDz6KwaC YdbitoeD9tKhYpuMkaVKWScr0WSMxn6ALExzTQwxlnEt4sp3w1j+Idib429qpNZ7jtHy +6ug== X-Gm-Message-State: APjAAAVcvkt4VS67EWqo95Yz998IkleIonCjmq2wntWvdP6s3VJ7k9IK jMo3cfq5QhrnzEvFOc2+bDM= X-Google-Smtp-Source: APXvYqwabWHT974rn0igHIVuZysUFuFZu+H+I7R2789YCtiTGUVFd29m4K4/ghxLI2CKOyeT9BXMPQ== X-Received: by 2002:ad4:46e4:: with SMTP id h4mr82823225qvw.181.1578334787943; Mon, 06 Jan 2020 10:19:47 -0800 (PST) Received: from vhost2 (CPE001143542e1f-CMf81d0f809fa0.cpe.net.cable.rogers.com. [99.230.38.42]) by smtp.gmail.com with ESMTPSA id o6sm20970076qkk.53.2020.01.06.10.19.46 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Mon, 06 Jan 2020 10:19:47 -0800 (PST) From: Noam Postavsky References: <333553AC-68DE-4F1C-9586-5A13248AD6DD@icloud.com> <83ftgvh96l.fsf@gnu.org> <83a771g2tc.fsf@gnu.org> <83o8vgee85.fsf@gnu.org> <8b2e879676c6ecc1371d50e033164424.squirrel@dancol.org> <83h818ebmr.fsf@gnu.org> Date: Mon, 06 Jan 2020 13:19:47 -0500 In-Reply-To: (Stefan Monnier's message of "Mon, 06 Jan 2020 13:13:31 -0500") Message-ID: <85pnfwfnwc.fsf@gmail.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.3 (windows-nt) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: 0.0 (/) 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 (-) Stefan Monnier writes: > The problem is simply that `sxhash` doesn't use the same "rules" about > which objects are compared by identity and which objects are compared > by contents. > The fix should be to make `sxhash` follow the same rules as `internal_equal`. > > This is a fairly long-standing problem, so unless it is newly triggered > in "normal" circumstances in Emacs-27, the fix is probably best on > `master`. This was earlier reported as Bug#32503, by the way. From unknown Sat Jun 14 18:56:05 2025 X-Loop: help-debbugs@gnu.org Subject: bug#38912: 27.0.60; PDumper meets segmentation fault when evil is loaded Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 06 Jan 2020 18:30:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 38912 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Stefan Monnier Cc: niwtrx@icloud.com, 38912@debbugs.gnu.org, dancol@dancol.org, pipcet@gmail.com Received: via spool by 38912-submit@debbugs.gnu.org id=B38912.15783353448938 (code B ref 38912); Mon, 06 Jan 2020 18:30:02 +0000 Received: (at 38912) by debbugs.gnu.org; 6 Jan 2020 18:29:04 +0000 Received: from localhost ([127.0.0.1]:46773 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ioX7g-0002K5-Fp for submit@debbugs.gnu.org; Mon, 06 Jan 2020 13:29:04 -0500 Received: from eggs.gnu.org ([209.51.188.92]:38269) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ioX7f-0002Io-Fa for 38912@debbugs.gnu.org; Mon, 06 Jan 2020 13:29:03 -0500 Received: from fencepost.gnu.org ([2001:470:142:3::e]:59988) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ioX7Z-0007HZ-KA; Mon, 06 Jan 2020 13:28:57 -0500 Received: from [176.228.60.248] (port=2353 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1ioX7X-0005Ns-R9; Mon, 06 Jan 2020 13:28:56 -0500 Date: Mon, 06 Jan 2020 20:29:04 +0200 Message-Id: <838smke8wf.fsf@gnu.org> From: Eli Zaretskii In-reply-to: (message from Stefan Monnier on Mon, 06 Jan 2020 13:13:31 -0500) References: <333553AC-68DE-4F1C-9586-5A13248AD6DD@icloud.com> <83ftgvh96l.fsf@gnu.org> <83a771g2tc.fsf@gnu.org> <83o8vgee85.fsf@gnu.org> <8b2e879676c6ecc1371d50e033164424.squirrel@dancol.org> <83h818ebmr.fsf@gnu.org> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Spam-Score: -2.3 (--) 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: Stefan Monnier > Cc: Pip Cet , niwtrx@icloud.com, 38912@debbugs.gnu.org, > dancol@dancol.org > Date: Mon, 06 Jan 2020 13:13:31 -0500 > > This is a fairly long-standing problem, so unless it is newly triggered > in "normal" circumstances in Emacs-27, the fix is probably best on > `master`. I tend to agree, since the capability of pdumping a customized Emacs is from my POV not a goal for Emacs 27.1: we know that needs some more work, and I wouldn't delay Emacs 27.1 to get it 100% right. From debbugs-submit-bounces@debbugs.gnu.org Mon Jan 06 13:31:19 2020 Received: (at control) by debbugs.gnu.org; 6 Jan 2020 18:31:19 +0000 Received: from localhost ([127.0.0.1]:46782 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ioX9q-0002Ox-Uj for submit@debbugs.gnu.org; Mon, 06 Jan 2020 13:31:19 -0500 Received: from eggs.gnu.org ([209.51.188.92]:38929) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ioX9q-0002Of-5Z for control@debbugs.gnu.org; Mon, 06 Jan 2020 13:31:18 -0500 Received: from fencepost.gnu.org ([2001:470:142:3::e]:60035) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ioX9l-0001IS-20 for control@debbugs.gnu.org; Mon, 06 Jan 2020 13:31:13 -0500 Received: from [176.228.60.248] (port=2492 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1ioX9e-0004Eq-S8 for control@debbugs.gnu.org; Mon, 06 Jan 2020 13:31:12 -0500 Date: Mon, 06 Jan 2020 20:31:16 +0200 Message-Id: <837e24e8sr.fsf@gnu.org> From: Eli Zaretskii To: control@debbugs.gnu.org In-reply-to: <85pnfwfnwc.fsf@gmail.com> (message from Noam Postavsky on Mon, 06 Jan 2020 13:19:47 -0500) Subject: Re: bug#38912: 27.0.60; PDumper meets segmentation fault when evil is loaded References: <333553AC-68DE-4F1C-9586-5A13248AD6DD@icloud.com> <83ftgvh96l.fsf@gnu.org> <83a771g2tc.fsf@gnu.org> <83o8vgee85.fsf@gnu.org> <8b2e879676c6ecc1371d50e033164424.squirrel@dancol.org> <83h818ebmr.fsf@gnu.org> <85pnfwfnwc.fsf@gmail.com> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: control 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 (---) merge 32503 38912 thanks From unknown Sat Jun 14 18:56:05 2025 X-Loop: help-debbugs@gnu.org Subject: bug#38912: 27.0.60; PDumper meets segmentation fault when evil is loaded Resent-From: Paul Eggert Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 07 Jan 2020 02:39:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 38912 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Pip Cet Cc: niwtrx@icloud.com, 38912@debbugs.gnu.org, Eli Zaretskii , Daniel Colascione , emacs-devel@gnu.org Received: via spool by 38912-submit@debbugs.gnu.org id=B38912.15783647068954 (code B ref 38912); Tue, 07 Jan 2020 02:39:01 +0000 Received: (at 38912) by debbugs.gnu.org; 7 Jan 2020 02:38:26 +0000 Received: from localhost ([127.0.0.1]:47098 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ioelG-0002KL-9h for submit@debbugs.gnu.org; Mon, 06 Jan 2020 21:38:26 -0500 Received: from zimbra.cs.ucla.edu ([131.179.128.68]:51264) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ioelE-0002K6-7A for 38912@debbugs.gnu.org; Mon, 06 Jan 2020 21:38:25 -0500 Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id 3B9F9160068; Mon, 6 Jan 2020 18:38:18 -0800 (PST) Received: from zimbra.cs.ucla.edu ([127.0.0.1]) by localhost (zimbra.cs.ucla.edu [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id 9h13oGq9iwcr; Mon, 6 Jan 2020 18:38:17 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id 85D83160076; Mon, 6 Jan 2020 18:38:17 -0800 (PST) X-Virus-Scanned: amavisd-new at zimbra.cs.ucla.edu Received: from zimbra.cs.ucla.edu ([127.0.0.1]) by localhost (zimbra.cs.ucla.edu [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id Gx1hmxv6A4vZ; Mon, 6 Jan 2020 18:38:17 -0800 (PST) Received: from Penguin.CS.UCLA.EDU (Penguin.CS.UCLA.EDU [131.179.64.200]) by zimbra.cs.ucla.edu (Postfix) with ESMTPSA id 66864160068; Mon, 6 Jan 2020 18:38:17 -0800 (PST) References: <333553AC-68DE-4F1C-9586-5A13248AD6DD@icloud.com> <83ftgvh96l.fsf@gnu.org> <83a771g2tc.fsf@gnu.org> <83o8vgee85.fsf@gnu.org> <8b2e879676c6ecc1371d50e033164424.squirrel@dancol.org> From: Paul Eggert Organization: UCLA Computer Science Department Message-ID: <2915772a-f280-5afa-72da-12f815c0119d@cs.ucla.edu> Date: Mon, 6 Jan 2020 18:38:17 -0800 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.3.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Spam-Score: -2.3 (--) 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 (---) On 1/6/20 9:13 AM, Pip Cet wrote: > we can fix things properly (by fixing > sxhash to hash byte code objects) on master. It's not just bytecode objects; it's also markers and some other stuff. The worst case is window configurations, where there's a nontrivial function compare_window_configurations that Fequal delegates to. Does anyone know offhand why we don't simply use eq to compare window configurations? Might save me some work in patching this in master. From unknown Sat Jun 14 18:56:05 2025 X-Loop: help-debbugs@gnu.org Subject: bug#38912: 27.0.60; PDumper meets segmentation fault when evil is loaded References: <333553AC-68DE-4F1C-9586-5A13248AD6DD@icloud.com> Resent-From: dancol@dancol.org Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 07 Jan 2020 03:35:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 38912 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Paul Eggert Cc: niwtrx@icloud.com, 38912@debbugs.gnu.org, Eli Zaretskii , Pip Cet , emacs-devel@gnu.org Received: via spool by 38912-submit@debbugs.gnu.org id=B38912.157836806014462 (code B ref 38912); Tue, 07 Jan 2020 03:35:02 +0000 Received: (at 38912) by debbugs.gnu.org; 7 Jan 2020 03:34:20 +0000 Received: from localhost ([127.0.0.1]:47126 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1iofdL-0003lC-Mn for submit@debbugs.gnu.org; Mon, 06 Jan 2020 22:34:19 -0500 Received: from dancol.org ([96.126.100.184]:41324) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1iofdK-0003l4-DQ for 38912@debbugs.gnu.org; Mon, 06 Jan 2020 22:34:18 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=dancol.org; s=x; h=Content-Transfer-Encoding:Content-Type:MIME-Version:Cc:To:From: In-Reply-To:Message-ID:Subject:Date:Sender:Reply-To:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:References:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=TsaawZ36XdbO/HIdIbpZ4BazQMMhNksTFzwgTwukS2Y=; b=OSa4jTiZ+iYAmZ1aMX84gabkQ/ 7u+aCnhU44PFnv42THyIEaQop+FNB3ADYxr04kc+s/Y9oHN4XQLEVRipSWJfjLv6b3hsFCxyZeXRP pb/j9KXbCgaXVTo54s6Sdic5W1IjVK53i98mRuYAQfjXOLCLU2ySEVdB2PB3PfY8vm35pFKe7TcTl zZJWQRrIeDx7ex5DBeo2bLZLbBMie6IcKXCPJD87XQddNM8ZWQrdbmmEVdVvioEJ5NrYs5la+w9Q6 uRidOIhsVGgwowEftt4cV928gX19V7XuQpWlIUh3UqDrp6DnS2L94HSS/HgWa6+uKstj67hAY41ab 7ktQykJw==; Received: from [2607:fb90:8372:bfb3:aa7a:32a1:7a8d:bd5f] by dancol.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.89) (envelope-from ) id 1iofdA-0001VT-Ox; Mon, 06 Jan 2020 19:34:09 -0800 Date: Mon, 06 Jan 2020 19:34:06 -0800 Message-ID: X-Android-Message-ID: In-Reply-To: <2915772a-f280-5afa-72da-12f815c0119d@cs.ucla.edu> From: dancol@dancol.org Importance: Normal X-Priority: 3 X-MSMail-Priority: Normal MIME-Version: 1.0 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: base64 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: On Jan 6, 2020 6:38 PM, Paul Eggert wrote: On 1/6/20 9:13 AM, Pip Cet wrote: > we can fix things properly (by fixing > sxhash to hash byte code objects) on master. It's not just bytecode objects; it's also markers and some other stuff. The worst case is window configurations, where there's a nontrivial function compare_window_configurations that Fequal delegates [...] Content analysis details: (2.6 points, 10.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- 0.0 URIBL_BLOCKED ADMINISTRATOR NOTICE: The query to URIBL was blocked. See http://wiki.apache.org/spamassassin/DnsBlocklists#dnsbl-block for more information. [URIs: dancol.org] -0.0 SPF_PASS SPF: sender matches SPF record -0.0 SPF_HELO_PASS SPF: HELO matches SPF record 0.0 HTML_MESSAGE BODY: HTML included in message 0.1 MIME_HTML_ONLY BODY: Message only has text/html MIME parts 0.6 HTML_MIME_NO_HTML_TAG HTML-only message, but there is no HTML tag 1.8 MISSING_MIMEOLE Message has X-MSMail-Priority, but no X-MimeOLE 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.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: On Jan 6, 2020 6:38 PM, Paul Eggert wrote: On 1/6/20 9:13 AM, Pip Cet wrote: > we can fix things properly (by fixing > sxhash to hash byte code objects) on master. It's not just bytecode objects; it's also markers and some other stuff. The worst case is window configurations, where there's a nontrivial function compare_window_configurations that Fequal delegates [...] Content analysis details: (1.6 points, 10.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- 0.0 URIBL_BLOCKED ADMINISTRATOR NOTICE: The query to URIBL was blocked. See http://wiki.apache.org/spamassassin/DnsBlocklists#dnsbl-block for more information. [URIs: ucla.edu] -0.0 SPF_PASS SPF: sender matches SPF record -0.0 SPF_HELO_PASS SPF: HELO matches SPF record 0.0 HTML_MESSAGE BODY: HTML included in message 0.1 MIME_HTML_ONLY BODY: Message only has text/html MIME parts 0.6 HTML_MIME_NO_HTML_TAG HTML-only message, but there is no HTML tag -1.0 MAILING_LIST_MULTI Multiple indicators imply a widely-seen list manager 1.8 MISSING_MIMEOLE Message has X-MSMail-Priority, but no X-MimeOLE PGRpdiBkaXI9J2F1dG8nPjxkaXY+PGRpdiBjbGFzcz0iZ21haWxfZXh0cmEiPjxkaXYgY2xhc3M9 ImdtYWlsX3F1b3RlIj5PbiBKYW4gNiwgMjAyMCA2OjM4IFBNLCBQYXVsIEVnZ2VydCAmbHQ7ZWdn ZXJ0QGNzLnVjbGEuZWR1Jmd0OyB3cm90ZTo8YnIgdHlwZT0iYXR0cmlidXRpb24iPjxibG9ja3F1 b3RlIGNsYXNzPSJxdW90ZSIgc3R5bGU9Im1hcmdpbjowIDAgMCAuOGV4O2JvcmRlci1sZWZ0OjFw eCAjY2NjIHNvbGlkO3BhZGRpbmctbGVmdDoxZXgiPjxwIGRpcj0ibHRyIj5PbiAxLzYvMjAgOTox MyBBTSwgUGlwIENldCB3cm90ZToKPGJyPgomZ3Q7IHdlIGNhbiBmaXggdGhpbmdzIHByb3Blcmx5 IChieSBmaXhpbmcKPGJyPgomZ3Q7IHN4aGFzaCB0byBoYXNoIGJ5dGUgY29kZSBvYmplY3RzKSBv biBtYXN0ZXIuCjxicj4KCjxicj4KSXQncyBub3QganVzdCBieXRlY29kZSBvYmplY3RzOyBpdCdz IGFsc28gbWFya2VycyBhbmQgc29tZSBvdGhlciBzdHVmZi4gCjxicj4KVGhlIHdvcnN0IGNhc2Ug aXMgd2luZG93IGNvbmZpZ3VyYXRpb25zLCB3aGVyZSB0aGVyZSdzIGEgbm9udHJpdmlhbCAKPGJy PgpmdW5jdGlvbiBjb21wYXJlX3dpbmRvd19jb25maWd1cmF0aW9ucyB0aGF0IEZlcXVhbCBkZWxl Z2F0ZXMgdG8uCjxicj4KCjxicj4KRG9lcyBhbnlvbmUga25vdyBvZmZoYW5kIHdoeSB3ZSBkb24n dCBzaW1wbHkgdXNlIGVxIHRvIGNvbXBhcmUgd2luZG93IAo8YnI+CmNvbmZpZ3VyYXRpb25zPyBN aWdodCBzYXZlIG1lIHNvbWUgd29yayBpbiBwYXRjaGluZyB0aGlzIGluIG1hc3Rlci4KPGJyPgo8 L3A+CjwvYmxvY2txdW90ZT48L2Rpdj5JIHRoaW5rIGNoYW5naW5nIHRoZSBlcXVhbCBiZWhhdmlv ciBvZiB0aGVzZSBvYmplY3RzIHdvdWxkIGJlIGEgY29tcGF0aWJpbGl0eSBjaGFuZ2UuIE1heWJl IHdlIG5lZWQgYSBzaW5nbGUgY2FsbGJhY2sgYmFzZWQgYXBwcm9hY2ggZm9yIGRvaW5nIGJvdGgg ZXF1YWxpdHkgY29tcGFyaXNvbiBhbmQgaGFzaGluZyBvZiBjb21wb3NpdGUgb2JqZWN0cy48L2Rp dj48L2Rpdj48L2Rpdj4= From unknown Sat Jun 14 18:56:05 2025 X-Loop: help-debbugs@gnu.org Subject: bug#38912: 27.0.60; PDumper meets segmentation fault when evil is loaded Resent-From: Stefan Monnier Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 07 Jan 2020 14:17:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 38912 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: dancol@dancol.org Cc: niwtrx@icloud.com, Paul Eggert , emacs-devel@gnu.org, 38912@debbugs.gnu.org, Pip Cet , Eli Zaretskii Received: via spool by 38912-submit@debbugs.gnu.org id=B38912.157840660129502 (code B ref 38912); Tue, 07 Jan 2020 14:17:01 +0000 Received: (at 38912) by debbugs.gnu.org; 7 Jan 2020 14:16:41 +0000 Received: from localhost ([127.0.0.1]:47571 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1iopez-0007fl-Iy for submit@debbugs.gnu.org; Tue, 07 Jan 2020 09:16:41 -0500 Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:23873) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1iopex-0007fY-Qh for 38912@debbugs.gnu.org; Tue, 07 Jan 2020 09:16:40 -0500 Received: from pmg3.iro.umontreal.ca (localhost [127.0.0.1]) by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id 778F244DB40; Tue, 7 Jan 2020 09:16:34 -0500 (EST) Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id 167FB44DB31; Tue, 7 Jan 2020 09:16:33 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1578406593; bh=zxUboq5LytD/4W/Ut4E6NtVStQB2KAac4+raK1g9y8A=; h=From:To:Cc:Subject:References:Date:In-Reply-To:From; b=e7jNooL8UlQ2XwIn9BPt4v1bACti7H8j1MIwJgMsl87jxgi8fTmNMt8SUf+TdQxXo qsXeAQJ7z0jAa6IjsKpZdHFVBtc0iWmokBnuhwXGnlHVxMjq3/C+xpcO+JbdbpyOhT wSbVCQfCgN0hi3mof+JDnkmfjJwjBZe7675c5nMGNFAfD0yHAQ53pIDqCLpvV8v7Nd lDmFeFmNA6+Ir0zFQwUB8UjXaj9yus3gkv7tNEYH8aVhN4qMq/ebLPNepA5JzLyWfN wcw7Nv07fBjukyJzWMS1QJM6HYQ7oANAHPFdSci8FNkDYvmIVO6zBPZjzZxJMg5Pgn qN6mA5PM3OaIg== Received: from pastel (unknown [45.72.147.220]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id B8E17120422; Tue, 7 Jan 2020 09:16:32 -0500 (EST) From: Stefan Monnier Message-ID: References: Date: Tue, 07 Jan 2020 09:16:31 -0500 In-Reply-To: (dancol@dancol.org's message of "Mon, 06 Jan 2020 19:34:06 -0800") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-SPAM-INFO: Spam detection results: 0 ALL_TRUSTED -1 Passed through trusted hosts only via SMTP AWL 0.031 Adjusted score from AWL reputation of From: address BAYES_00 -1.9 Bayes spam probability is 0 to 1% DKIM_SIGNED 0.1 Message has a DKIM or DK signature, not necessarily valid DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's domain X-SPAM-LEVEL: X-Spam-Score: -2.3 (--) 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 (---) > The worst case is window configurations, where there's a nontrivial > function compare_window_configurations that Fequal delegates to. Indeed, this is very strange. > Does anyone know offhand why we don't simply use eq to compare window > configurations? I'm curious about it too. As a long-time Elisp coder, I find this behavior very odd (I just discovered it while looking at the code) and I think having them compared by identity would make a lot more sense. > I think changing the equal behavior of these objects would be > a compatibility change. Indeed. It's clearly out of the question for Emacs-27. But I'd be in favor of introducing this backward incompatibility in Emacs-28, unless we can find a good use case where the structural-equality is needed for them. Stefan From unknown Sat Jun 14 18:56:05 2025 X-Loop: help-debbugs@gnu.org Subject: bug#38912: 27.0.60; PDumper meets segmentation fault when evil is loaded Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 07 Jan 2020 15:48:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 38912 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Paul Eggert Cc: niwtrx@icloud.com, 38912@debbugs.gnu.org, dancol@dancol.org, pipcet@gmail.com, emacs-devel@gnu.org Received: via spool by 38912-submit@debbugs.gnu.org id=B38912.15784120297149 (code B ref 38912); Tue, 07 Jan 2020 15:48:02 +0000 Received: (at 38912) by debbugs.gnu.org; 7 Jan 2020 15:47:09 +0000 Received: from localhost ([127.0.0.1]:49046 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ior4X-0001rF-5R for submit@debbugs.gnu.org; Tue, 07 Jan 2020 10:47:09 -0500 Received: from eggs.gnu.org ([209.51.188.92]:44241) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ior4V-0001r2-FJ for 38912@debbugs.gnu.org; Tue, 07 Jan 2020 10:47:07 -0500 Received: from fencepost.gnu.org ([2001:470:142:3::e]:48790) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ior4P-00062x-N5; Tue, 07 Jan 2020 10:47:01 -0500 Received: from [176.228.60.248] (port=4321 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1ior4P-0007tH-5C; Tue, 07 Jan 2020 10:47:01 -0500 Date: Tue, 07 Jan 2020 17:47:13 +0200 Message-Id: <83sgkrclq6.fsf@gnu.org> From: Eli Zaretskii In-reply-to: <2915772a-f280-5afa-72da-12f815c0119d@cs.ucla.edu> (message from Paul Eggert on Mon, 6 Jan 2020 18:38:17 -0800) References: <333553AC-68DE-4F1C-9586-5A13248AD6DD@icloud.com> <83ftgvh96l.fsf@gnu.org> <83a771g2tc.fsf@gnu.org> <83o8vgee85.fsf@gnu.org> <8b2e879676c6ecc1371d50e033164424.squirrel@dancol.org> <2915772a-f280-5afa-72da-12f815c0119d@cs.ucla.edu> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Spam-Score: -2.3 (--) 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: Daniel Colascione , emacs-devel@gnu.org, > niwtrx@icloud.com, 38912@debbugs.gnu.org, Eli Zaretskii > From: Paul Eggert > Date: Mon, 6 Jan 2020 18:38:17 -0800 > > Does anyone know offhand why we don't simply use eq to compare window > configurations? I guess because not all of that is Lisp data. struct save_window_data isn't. From unknown Sat Jun 14 18:56:05 2025 X-Loop: help-debbugs@gnu.org Subject: bug#38912: 27.0.60; PDumper meets segmentation fault when evil is loaded Resent-From: Stefan Monnier Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 07 Jan 2020 17:38:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 38912 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Eli Zaretskii Cc: niwtrx@icloud.com, Paul Eggert , emacs-devel@gnu.org, 38912@debbugs.gnu.org, pipcet@gmail.com, dancol@dancol.org Received: via spool by 38912-submit@debbugs.gnu.org id=B38912.157841863426166 (code B ref 38912); Tue, 07 Jan 2020 17:38:02 +0000 Received: (at 38912) by debbugs.gnu.org; 7 Jan 2020 17:37:14 +0000 Received: from localhost ([127.0.0.1]:49193 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1iosn4-0006nw-7V for submit@debbugs.gnu.org; Tue, 07 Jan 2020 12:37:14 -0500 Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:43262) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1iosn2-0006nR-1N for 38912@debbugs.gnu.org; Tue, 07 Jan 2020 12:37:12 -0500 Received: from pmg2.iro.umontreal.ca (localhost.localdomain [127.0.0.1]) by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id A570B83464; Tue, 7 Jan 2020 12:37:06 -0500 (EST) Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id 0C73781E26; Tue, 7 Jan 2020 12:37:05 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1578418625; bh=PcqB+Hvw+uociQMMXZUAI1QGoVoGi4Laoe2OXlAGdLE=; h=From:To:Cc:Subject:References:Date:In-Reply-To:From; b=Tbo89zL4jIsiJlZzIKCfALyym0cR1/VgXcsK36H7rSQd39QWVh4i3WMqJBoM7Jc9A XJxEzdSCJUKbezA8STS/aM8qwZZUH/AMKf7bzC34VuOGS571WQ19Fc1cH4TVOlln/z JMTIQzPdS5Pt+rHrvW/TjQWmmGQE+dr8oHd59oQAtMMLlo70xW9R6Yfum7kzgMI16s pTunLKgsqiwXlDNf7Pr4NG0awtYd/P2pMwFt1Sv85M9jePBd/CeN7o3GyLD7DkkJou tTpiMRQ/kuknS2+XJhWYSwDY621WheIYyG2JwhrFuC5qm0wYvBelA9yg8pUdGCiuxU yo1oX1REisifA== Received: from alfajor (modemcable157.163-203-24.mc.videotron.ca [24.203.163.157]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id C0B0D1204BF; Tue, 7 Jan 2020 12:37:04 -0500 (EST) From: Stefan Monnier Message-ID: References: <333553AC-68DE-4F1C-9586-5A13248AD6DD@icloud.com> <83ftgvh96l.fsf@gnu.org> <83a771g2tc.fsf@gnu.org> <83o8vgee85.fsf@gnu.org> <8b2e879676c6ecc1371d50e033164424.squirrel@dancol.org> <2915772a-f280-5afa-72da-12f815c0119d@cs.ucla.edu> <83sgkrclq6.fsf@gnu.org> Date: Tue, 07 Jan 2020 12:37:00 -0500 In-Reply-To: <83sgkrclq6.fsf@gnu.org> (Eli Zaretskii's message of "Tue, 07 Jan 2020 17:47:13 +0200") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-SPAM-INFO: Spam detection results: 0 ALL_TRUSTED -1 Passed through trusted hosts only via SMTP AWL 0.118 Adjusted score from AWL reputation of From: address BAYES_00 -1.9 Bayes spam probability is 0 to 1% DKIM_SIGNED 0.1 Message has a DKIM or DK signature, not necessarily valid DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's domain X-SPAM-LEVEL: X-Spam-Score: -2.3 (--) 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 (---) >> Does anyone know offhand why we don't simply use eq to compare window >> configurations? > I guess because not all of that is Lisp data. struct save_window_data > isn't. I think he meant: why doesn't `equal` applied on window configs behave like `eq`? Stefan From unknown Sat Jun 14 18:56:05 2025 X-Loop: help-debbugs@gnu.org Subject: bug#38912: 27.0.60; PDumper meets segmentation fault when evil is loaded Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 07 Jan 2020 17:44:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 38912 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Stefan Monnier Cc: niwtrx@icloud.com, eggert@cs.ucla.edu, emacs-devel@gnu.org, 38912@debbugs.gnu.org, pipcet@gmail.com, dancol@dancol.org Received: via spool by 38912-submit@debbugs.gnu.org id=B38912.157841899126742 (code B ref 38912); Tue, 07 Jan 2020 17:44:01 +0000 Received: (at 38912) by debbugs.gnu.org; 7 Jan 2020 17:43:11 +0000 Received: from localhost ([127.0.0.1]:49204 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1iossl-0006x9-8S for submit@debbugs.gnu.org; Tue, 07 Jan 2020 12:43:11 -0500 Received: from eggs.gnu.org ([209.51.188.92]:60218) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1iossj-0006wY-R0 for 38912@debbugs.gnu.org; Tue, 07 Jan 2020 12:43:06 -0500 Received: from fencepost.gnu.org ([2001:470:142:3::e]:51427) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1iosse-0004Cr-1E; Tue, 07 Jan 2020 12:43:00 -0500 Received: from [176.228.60.248] (port=3730 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1iossb-0002fT-3e; Tue, 07 Jan 2020 12:42:57 -0500 Date: Tue, 07 Jan 2020 19:43:07 +0200 Message-Id: <8336crcgd0.fsf@gnu.org> From: Eli Zaretskii In-reply-to: (message from Stefan Monnier on Tue, 07 Jan 2020 12:37:00 -0500) References: <333553AC-68DE-4F1C-9586-5A13248AD6DD@icloud.com> <83ftgvh96l.fsf@gnu.org> <83a771g2tc.fsf@gnu.org> <83o8vgee85.fsf@gnu.org> <8b2e879676c6ecc1371d50e033164424.squirrel@dancol.org> <2915772a-f280-5afa-72da-12f815c0119d@cs.ucla.edu> <83sgkrclq6.fsf@gnu.org> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Spam-Score: -2.3 (--) 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 (-) > From: Stefan Monnier > Cc: Paul Eggert , niwtrx@icloud.com, > 38912@debbugs.gnu.org, dancol@dancol.org, pipcet@gmail.com, > emacs-devel@gnu.org > Date: Tue, 07 Jan 2020 12:37:00 -0500 > > I think he meant: why doesn't `equal` applied on window configs behave > like `eq`? That's an entirely different question. From unknown Sat Jun 14 18:56:05 2025 X-Loop: help-debbugs@gnu.org Subject: bug#38912: 27.0.60; PDumper meets segmentation fault when evil is loaded Resent-From: Stefan Monnier Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 07 Jan 2020 18:02:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 38912 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Eli Zaretskii Cc: niwtrx@icloud.com, eggert@cs.ucla.edu, emacs-devel@gnu.org, 38912@debbugs.gnu.org, pipcet@gmail.com, dancol@dancol.org Received: via spool by 38912-submit@debbugs.gnu.org id=B38912.157842009428806 (code B ref 38912); Tue, 07 Jan 2020 18:02:02 +0000 Received: (at 38912) by debbugs.gnu.org; 7 Jan 2020 18:01:34 +0000 Received: from localhost ([127.0.0.1]:49229 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1iotAb-0007UY-VE for submit@debbugs.gnu.org; Tue, 07 Jan 2020 13:01:34 -0500 Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:62659) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1iotAa-0007UM-79 for 38912@debbugs.gnu.org; Tue, 07 Jan 2020 13:01:32 -0500 Received: from pmg1.iro.umontreal.ca (localhost.localdomain [127.0.0.1]) by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id C6732100A82; Tue, 7 Jan 2020 13:01:26 -0500 (EST) Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id 08CE810040C; Tue, 7 Jan 2020 13:01:21 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1578420081; bh=Gll88rcV2E7885JaI+z6WQ0nt/i9/reU5vt+/iNUVhM=; h=From:To:Cc:Subject:References:Date:In-Reply-To:From; b=V/qYw7mPxZxwn9GMhbC35CQFa0obY83aj00cHeHgHkRlkhaxKT8srVq/eMqpI5ulp dRjBmUePRmh18+Lw8oajoIGgiF3l3PNCgPkCOAw/3WG7A7ACpbJ5/rjrjFVL2pPY/P ruGs+oWGhX4CnTkp4Gu5uHb4SxRM6wu8XdAH/lqkVp4qk2pQHWaxabmc/Xny/3hsbD +IDR+jtp5r+MoQvZgqmWY1RM629PHFf4+9z//ci6E1kghH8OaXbgp+AE+QWvp64uaU 7s0/ZDAH+oykmKQwfslqNCFhw8Ey2vF4FUW3nQjYp6NpEFyrHgHe13LnmecMS+ThL2 edr3TbKDnYARg== Received: from alfajor (modemcable157.163-203-24.mc.videotron.ca [24.203.163.157]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id C346C12055F; Tue, 7 Jan 2020 13:01:20 -0500 (EST) From: Stefan Monnier Message-ID: References: <333553AC-68DE-4F1C-9586-5A13248AD6DD@icloud.com> <83ftgvh96l.fsf@gnu.org> <83a771g2tc.fsf@gnu.org> <83o8vgee85.fsf@gnu.org> <8b2e879676c6ecc1371d50e033164424.squirrel@dancol.org> <2915772a-f280-5afa-72da-12f815c0119d@cs.ucla.edu> <83sgkrclq6.fsf@gnu.org> <8336crcgd0.fsf@gnu.org> Date: Tue, 07 Jan 2020 13:01:17 -0500 In-Reply-To: <8336crcgd0.fsf@gnu.org> (Eli Zaretskii's message of "Tue, 07 Jan 2020 19:43:07 +0200") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-SPAM-INFO: Spam detection results: 0 ALL_TRUSTED -1 Passed through trusted hosts only via SMTP AWL 0.027 Adjusted score from AWL reputation of From: address BAYES_00 -1.9 Bayes spam probability is 0 to 1% DKIM_SIGNED 0.1 Message has a DKIM or DK signature, not necessarily valid DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's domain X-SPAM-LEVEL: X-Spam-Score: -2.3 (--) 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 (---) >> I think he meant: why doesn't `equal` applied on window configs behave >> like `eq`? > That's an entirely different question. Indeed, but I think that's the only question that's actually been asked (Dan will hopefully correct me if I'm wrong). I actually *expected* that `equal` on window configs would behave like `eq`. It would have never occurred to me (before I looked at the code) that it could be different (although in retrospect, I can see reasons why it could make sense). Stefan From unknown Sat Jun 14 18:56:05 2025 X-Loop: help-debbugs@gnu.org Subject: bug#38912: 27.0.60; PDumper meets segmentation fault when evil is loaded Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 07 Jan 2020 18:12:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 38912 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Stefan Monnier Cc: niwtrx@icloud.com, eggert@cs.ucla.edu, emacs-devel@gnu.org, 38912@debbugs.gnu.org, pipcet@gmail.com, dancol@dancol.org Received: via spool by 38912-submit@debbugs.gnu.org id=B38912.157842068529850 (code B ref 38912); Tue, 07 Jan 2020 18:12:01 +0000 Received: (at 38912) by debbugs.gnu.org; 7 Jan 2020 18:11:25 +0000 Received: from localhost ([127.0.0.1]:49244 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1iotK5-0007lH-5J for submit@debbugs.gnu.org; Tue, 07 Jan 2020 13:11:25 -0500 Received: from eggs.gnu.org ([209.51.188.92]:56247) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1iotK3-0007ky-Jb for 38912@debbugs.gnu.org; Tue, 07 Jan 2020 13:11:19 -0500 Received: from fencepost.gnu.org ([2001:470:142:3::e]:52203) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1iotJy-0006Jz-AE; Tue, 07 Jan 2020 13:11:14 -0500 Received: from [176.228.60.248] (port=1517 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1iotJv-0001vn-N5; Tue, 07 Jan 2020 13:11:13 -0500 Date: Tue, 07 Jan 2020 20:11:23 +0200 Message-Id: <83y2ujb0hg.fsf@gnu.org> From: Eli Zaretskii In-reply-to: (message from Stefan Monnier on Tue, 07 Jan 2020 13:01:17 -0500) References: <333553AC-68DE-4F1C-9586-5A13248AD6DD@icloud.com> <83ftgvh96l.fsf@gnu.org> <83a771g2tc.fsf@gnu.org> <83o8vgee85.fsf@gnu.org> <8b2e879676c6ecc1371d50e033164424.squirrel@dancol.org> <2915772a-f280-5afa-72da-12f815c0119d@cs.ucla.edu> <83sgkrclq6.fsf@gnu.org> <8336crcgd0.fsf@gnu.org> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Spam-Score: -2.3 (--) 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 (-) > From: Stefan Monnier > Date: Tue, 07 Jan 2020 13:01:17 -0500 > Cc: niwtrx@icloud.com, eggert@cs.ucla.edu, emacs-devel@gnu.org, > 38912@debbugs.gnu.org, pipcet@gmail.com, dancol@dancol.org > > I actually *expected* that `equal` on window configs would behave like > `eq`. It would have never occurred to me (before I looked at the code) > that it could be different (although in retrospect, I can see reasons > why it could make sense). Since we have a dedicated comparison function there, why is it important what eq and equal do with these objects? From unknown Sat Jun 14 18:56:05 2025 X-Loop: help-debbugs@gnu.org Subject: bug#38912: 27.0.60; PDumper meets segmentation fault when evil is loaded Resent-From: martin rudalics Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 07 Jan 2020 18:30:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 38912 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Stefan Monnier , Eli Zaretskii Cc: niwtrx@icloud.com, 38912@debbugs.gnu.org, eggert@cs.ucla.edu, pipcet@gmail.com, emacs-devel@gnu.org Received: via spool by 38912-submit@debbugs.gnu.org id=B38912.15784217846744 (code B ref 38912); Tue, 07 Jan 2020 18:30:02 +0000 Received: (at 38912) by debbugs.gnu.org; 7 Jan 2020 18:29:44 +0000 Received: from localhost ([127.0.0.1]:49266 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1iotbs-0001kg-41 for submit@debbugs.gnu.org; Tue, 07 Jan 2020 13:29:44 -0500 Received: from mout.gmx.net ([212.227.15.15]:41025) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1iotbq-0001kI-21 for 38912@debbugs.gnu.org; Tue, 07 Jan 2020 13:29:42 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1578421759; bh=Gagp5FbQkDcYsILDqNtJcvZPWlx104yiV2icvNwqkjE=; h=X-UI-Sender-Class:Subject:To:Cc:References:From:Date:In-Reply-To; b=Ru/H0u4r74EPR1Ih1cIsS2AT/pMzjOC2zDU8B1Z+9zfNgzhjbg4IA1dU3ty84eWml MxhbL7grJ1g1GIrK5GcD7f7ENO2EHZE0ZkZeqK03anN060fV8ADHbTigy57dgec1+e c0exvQ5JVwvbqhjF+PADwXR1GqtUUWpVJViPjlho= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Received: from [192.168.1.101] ([46.125.249.116]) by mail.gmx.com (mrgmx004 [212.227.17.190]) with ESMTPSA (Nemesis) id 1MPokD-1j2rwi0lZT-00Mrvx; Tue, 07 Jan 2020 19:29:19 +0100 References: <333553AC-68DE-4F1C-9586-5A13248AD6DD@icloud.com> <83ftgvh96l.fsf@gnu.org> <83a771g2tc.fsf@gnu.org> <83o8vgee85.fsf@gnu.org> <8b2e879676c6ecc1371d50e033164424.squirrel@dancol.org> <2915772a-f280-5afa-72da-12f815c0119d@cs.ucla.edu> <83sgkrclq6.fsf@gnu.org> <8336crcgd0.fsf@gnu.org> From: martin rudalics Message-ID: <1e33c53e-f6ae-a3bf-6ce0-5c1894cb9b35@gmx.at> Date: Tue, 7 Jan 2020 19:29:14 +0100 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: de-AT Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K1:eOYIgtw4nOdC6it2VgzZhNfndmxZl+IvWlvcMwXsY9KcyGnztTy 0Xa51TYeJFYR42bXiCkaGjhd9itJGh51oMn0CFNwfTynrgE2GAV2xHiIkVa+RYwMg7g3hct JI8goDI9Aw0+CVawp7NBa8D/V/3P1K8Weqv1jAW0CGQOJdFWae7Zl4Ayy5o+PHCw33BTztw BdfDfkvD11xAx+xkQN8Zw== X-Spam-Flag: NO X-UI-Out-Filterresults: notjunk:1;V03:K0:Xd5HeOGYWms=:wyXFN1uvcrvAoUPjKkGbfI RkCSBG5QbmE0Ww5u21fluXsVEHAGF1q+rZ6ao4BdqmQtpMBi/YaVah7Q/8c/UMWX3ophj+MZ8 SbjdvowLs7pERD/c9s3V5WX6A8SzzCTqyatU0KXiPyh7UYvlpy4gBCHDPRhvPZkAYLh2Y7ELe GuiKY3BtJW/OCTmZeeqs6fHB5O0yEzc8gtIQVtWUNI6hAulntxCdc8fLuJuwqXU/kFtwGJ8Kt RiSZWVtlB//WrRi4G0zqWRzm+iGR9s4XsB3UnstewWayvYwPR1M5n7sCJFPA/UkNXg4VWhQcG s5v71FUgKIxLrcFuLhH4viYImUju2hKfuCtZKbbIzF+tDrwxmgSd4fs3rpwKqGYp6QFpnCxKG ZW7mZZgKNKd+zY9qblhwPIz6Q3CnnftaDkuoOkWxT5JzqnQT0LsfBovVp6otlLCULRWWV+gRO 97cZY5/6al9LWgL1WVwtKqlztbIYvXg4aM9/4/atgg3EBCF/D8p1xmMYMc4me88X5QU7TeuKh cfyhcGOZltQnDrMo8qmEIUTCNOtSvI39qjMdwwL1tH29dhjO04LvzdexGeuGuXtfkJ8AovItx exvO4PQGrSXIo15MORQaOTUu+K75huv6t7TWyrgXUMlUfzNKRNB+e/rj596zntYmJixzLo7PL pozvPjA7eOsrT8ROt+r1FBoQkWv7DHRiafySY3kl5UyjNl3urcVLK/e8kMhuB+1AoHsgcaMIE eAZTIpmpGW2VeRGGDMzazOX5TfBCVIKGurPaW6chPn/FWghMFCMTl9Vfi9Vnd/rWBQxa1sKlc jJbVmPofd9S7jjWoRjwTHJr4rJdsgvf8y62d4hjuTyviykRGhPdm95PFtI4L20Jy4RQYcajz0 AcDOYPTN5cCk5LqR4rk2CH9X2AUrLRXNsnY51CKA73hXrQ8SIQaFW9jDNRN0y4n6dZQBglMvr STr84as51yXaolp6qfrUFrvKAAhHzytGez5T3wDrsTQzkLTUtrjIQsI6uhAlEo3raHEt5Gvbx edGbb9XumwhikNgPhO64uaAruN3IXpWIKlDOMTtKRScAMVxgc3yCIDmVFHuII8k3Sydysk43i 74I3+hLIJQgm5v83ek00KCx50HWj1BR14diVSNw3akqSuGq+C8LPJP/zSK6bnLEahsI6W/ys2 oLNaOTVxOCWBOxeeFEaZjn7UEMMUrbM3a6eBj/eZlGTIM6JLSH656q4H1wFUBOHR6v4f5HwAS 6jB+cyIP+aKcrGJjMWT5fjMz0XPn1ie17oTTRSvbw6gjX5juLdN/MBmdlvV4= X-Spam-Score: 0.0 (/) 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 actually *expected* that `equal` on window configs would behave like > `eq`. It would have never occurred to me (before I looked at the code) > that it could be different (although in retrospect, I can see reasons > why it could make sense). `eq' wouldn't make any sense at all. 'compare-window-configurations' per se is a misconception. But I have no intention to dig into strokes.el to find out why on earth it would need such a thing and how to remove it. martin From unknown Sat Jun 14 18:56:05 2025 X-Loop: help-debbugs@gnu.org Subject: bug#38912: 27.0.60; PDumper meets segmentation fault when evil is loaded Resent-From: Stefan Monnier Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 07 Jan 2020 18:44:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 38912 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: martin rudalics Cc: niwtrx@icloud.com, eggert@cs.ucla.edu, emacs-devel@gnu.org, 38912@debbugs.gnu.org, pipcet@gmail.com, Eli Zaretskii Received: via spool by 38912-submit@debbugs.gnu.org id=B38912.15784226068094 (code B ref 38912); Tue, 07 Jan 2020 18:44:01 +0000 Received: (at 38912) by debbugs.gnu.org; 7 Jan 2020 18:43:26 +0000 Received: from localhost ([127.0.0.1]:49287 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1iotp8-00026U-5t for submit@debbugs.gnu.org; Tue, 07 Jan 2020 13:43:26 -0500 Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:29553) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1iotp6-00026I-CY for 38912@debbugs.gnu.org; Tue, 07 Jan 2020 13:43:24 -0500 Received: from pmg1.iro.umontreal.ca (localhost.localdomain [127.0.0.1]) by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id EE344100A82; Tue, 7 Jan 2020 13:43:18 -0500 (EST) Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id 79D3B10040C; Tue, 7 Jan 2020 13:43:17 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1578422597; bh=WLZuk6zpi3Sua5OL1aeJJwjTBELp+HAYC4h8fv0axUk=; h=From:To:Cc:Subject:References:Date:In-Reply-To:From; b=nH5/tx/hA71PM/e9vPsw0+qeKUxnYktz11BPncycn2DqXTZ5BfP3eAwDrWetnasvz UdvPnrfLtJK9m+SGKTNE7v8eG2mW4Q5NwjuUUty00POfdF7Td2BrQ8VaECdQO96oA2 YVVpMkmdfl42tkogwyXBEuNkscFSZ4BQdSPusdL/wv3ykwDwuJgZ1Bj474maVqeR7Q q01bfyJUgc89sW8ixgmT/33Fc+USshOKF4F4RncczXUW+TvAobX24M2Q6K46yCN/VT uACApJJaVNJWeYEtZjYGMB7s3P0R41zLBpkH9ONTFkDeUvWcngfOYWaE+wmm0PT2j8 HQR+KP6Ge60/Q== Received: from alfajor (modemcable157.163-203-24.mc.videotron.ca [24.203.163.157]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 14704120312; Tue, 7 Jan 2020 13:43:17 -0500 (EST) From: Stefan Monnier Message-ID: References: <333553AC-68DE-4F1C-9586-5A13248AD6DD@icloud.com> <83ftgvh96l.fsf@gnu.org> <83a771g2tc.fsf@gnu.org> <83o8vgee85.fsf@gnu.org> <8b2e879676c6ecc1371d50e033164424.squirrel@dancol.org> <2915772a-f280-5afa-72da-12f815c0119d@cs.ucla.edu> <83sgkrclq6.fsf@gnu.org> <8336crcgd0.fsf@gnu.org> <1e33c53e-f6ae-a3bf-6ce0-5c1894cb9b35@gmx.at> Date: Tue, 07 Jan 2020 13:43:15 -0500 In-Reply-To: <1e33c53e-f6ae-a3bf-6ce0-5c1894cb9b35@gmx.at> (martin rudalics's message of "Tue, 7 Jan 2020 19:29:14 +0100") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-SPAM-INFO: Spam detection results: 0 ALL_TRUSTED -1 Passed through trusted hosts only via SMTP AWL 0.024 Adjusted score from AWL reputation of From: address BAYES_00 -1.9 Bayes spam probability is 0 to 1% DKIM_SIGNED 0.1 Message has a DKIM or DK signature, not necessarily valid DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's domain X-SPAM-LEVEL: X-Spam-Score: -2.3 (--) 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 (---) >> I actually *expected* that `equal` on window configs would behave like >> `eq`. It would have never occurred to me (before I looked at the code) >> that it could be different (although in retrospect, I can see reasons >> why it could make sense). > `eq' wouldn't make any sense at all. Why not? > 'compare-window-configurations' per se is a misconception. We're talking about the behavior of `equal`, not that of `compare-window-configurations`. Stefan From unknown Sat Jun 14 18:56:05 2025 X-Loop: help-debbugs@gnu.org Subject: bug#38912: 27.0.60; PDumper meets segmentation fault when evil is loaded Resent-From: Stefan Monnier Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 07 Jan 2020 18:48:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 38912 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Eli Zaretskii Cc: niwtrx@icloud.com, eggert@cs.ucla.edu, emacs-devel@gnu.org, 38912@debbugs.gnu.org, pipcet@gmail.com, dancol@dancol.org Received: via spool by 38912-submit@debbugs.gnu.org id=B38912.15784228758583 (code B ref 38912); Tue, 07 Jan 2020 18:48:02 +0000 Received: (at 38912) by debbugs.gnu.org; 7 Jan 2020 18:47:55 +0000 Received: from localhost ([127.0.0.1]:49301 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1iottT-0002EN-2b for submit@debbugs.gnu.org; Tue, 07 Jan 2020 13:47:55 -0500 Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:38562) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1iottR-0002EA-2w for 38912@debbugs.gnu.org; Tue, 07 Jan 2020 13:47:53 -0500 Received: from pmg2.iro.umontreal.ca (localhost.localdomain [127.0.0.1]) by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id 92C7981E26; Tue, 7 Jan 2020 13:47:47 -0500 (EST) Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id 05C8881245; Tue, 7 Jan 2020 13:47:46 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1578422866; bh=paEG0AU1DhNGda+wldgtQT2rnTBQMDQheHu4Bt778sk=; h=From:To:Cc:Subject:References:Date:In-Reply-To:From; b=h6Q92q1ngUnUuAgsTnyQYa516YNita0tGoe19awscHp/FqHgj3PSz0+I0gGoejb88 a0TPuxwSbKQsc66cEDv74iWUrFCDEL4med5B6f8CzR7k3lcswYfKjsFTPZCj9VckOM d6g1egD2AFvvarFk8dm7Gnn+DhoE/J0SA3ezOhn/+j/T9W5DUQEmm1VRVSiADO3dCS mlVmwfq2Q4JQtGKKTjHd4/Fhpr3sBML+JvWA9/6OyyKi6O8ZI5zseC5gu89l7O9ffd nCvmvwHElEbG2ii+LOBvGjhmT92J8lyfAzeTHCsD+gh9jM63jIa0YK4tEBSx4pCYyF ee4tXjrTadU0w== Received: from alfajor (modemcable157.163-203-24.mc.videotron.ca [24.203.163.157]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id AA93112049E; Tue, 7 Jan 2020 13:47:45 -0500 (EST) From: Stefan Monnier Message-ID: References: <333553AC-68DE-4F1C-9586-5A13248AD6DD@icloud.com> <83ftgvh96l.fsf@gnu.org> <83a771g2tc.fsf@gnu.org> <83o8vgee85.fsf@gnu.org> <8b2e879676c6ecc1371d50e033164424.squirrel@dancol.org> <2915772a-f280-5afa-72da-12f815c0119d@cs.ucla.edu> <83sgkrclq6.fsf@gnu.org> <8336crcgd0.fsf@gnu.org> <83y2ujb0hg.fsf@gnu.org> Date: Tue, 07 Jan 2020 13:47:44 -0500 In-Reply-To: <83y2ujb0hg.fsf@gnu.org> (Eli Zaretskii's message of "Tue, 07 Jan 2020 20:11:23 +0200") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-SPAM-INFO: Spam detection results: 0 ALL_TRUSTED -1 Passed through trusted hosts only via SMTP AWL 0.113 Adjusted score from AWL reputation of From: address BAYES_00 -1.9 Bayes spam probability is 0 to 1% DKIM_SIGNED 0.1 Message has a DKIM or DK signature, not necessarily valid DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's domain X-SPAM-LEVEL: X-Spam-Score: -2.3 (--) 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 (---) >> I actually *expected* that `equal` on window configs would behave like >> `eq`. It would have never occurred to me (before I looked at the code) >> that it could be different (although in retrospect, I can see reasons >> why it could make sense). > Since we have a dedicated comparison function there, why is it > important what eq and equal do with these objects? The immediate reason why it's relevant is that it affects what `sxhash` needs to do. The existence of `compare-window-configurations` is not directly relevant to the question (tho it arguably makes it less important for `equal` to behave structurally since it provides an alternative for those callers who would need it). Stefan From unknown Sat Jun 14 18:56:05 2025 X-Loop: help-debbugs@gnu.org Subject: bug#38912: 27.0.60; PDumper meets segmentation fault when evil is loaded Resent-From: martin rudalics Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 07 Jan 2020 18:59:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 38912 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Stefan Monnier Cc: niwtrx@icloud.com, eggert@cs.ucla.edu, emacs-devel@gnu.org, 38912@debbugs.gnu.org, pipcet@gmail.com, Eli Zaretskii Received: via spool by 38912-submit@debbugs.gnu.org id=B38912.15784235269621 (code B ref 38912); Tue, 07 Jan 2020 18:59:01 +0000 Received: (at 38912) by debbugs.gnu.org; 7 Jan 2020 18:58:46 +0000 Received: from localhost ([127.0.0.1]:49332 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1iou3x-0002V7-Oh for submit@debbugs.gnu.org; Tue, 07 Jan 2020 13:58:46 -0500 Received: from mout.gmx.net ([212.227.15.19]:49657) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1iou3v-0002Ur-Nc for 38912@debbugs.gnu.org; Tue, 07 Jan 2020 13:58:44 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1578423501; bh=MtEB3ucIwJT4YA1G4tiCJQGZyVjokvae42sz8O5jKFE=; h=X-UI-Sender-Class:Subject:To:Cc:References:From:Date:In-Reply-To; b=FkIjnaR82Z601GiO9Kdc1c+HD8IO18aW1XLgE82p/r2O8C550K5a5LCyUrQBKVTrW wCA5TlcautXixgDH3/1U6jarn3DZ3ccoxRzV+7sbRbR7le1sKZzX5iYAMkbFGNidGb krMQdgMu3bsPIpu9Te8vWqrHPf6Kk+SZKfjxS50U= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Received: from [192.168.1.101] ([46.125.249.116]) by mail.gmx.com (mrgmx005 [212.227.17.190]) with ESMTPSA (Nemesis) id 1Md6Mj-1jOn6c1eex-00aH00; Tue, 07 Jan 2020 19:58:21 +0100 References: <333553AC-68DE-4F1C-9586-5A13248AD6DD@icloud.com> <83ftgvh96l.fsf@gnu.org> <83a771g2tc.fsf@gnu.org> <83o8vgee85.fsf@gnu.org> <8b2e879676c6ecc1371d50e033164424.squirrel@dancol.org> <2915772a-f280-5afa-72da-12f815c0119d@cs.ucla.edu> <83sgkrclq6.fsf@gnu.org> <8336crcgd0.fsf@gnu.org> <1e33c53e-f6ae-a3bf-6ce0-5c1894cb9b35@gmx.at> From: martin rudalics Message-ID: <9abdeab4-2382-1115-7872-57fb243c5ed1@gmx.at> Date: Tue, 7 Jan 2020 19:58:20 +0100 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: de-AT Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K1:QUEjL57II1XdXN7e3SxBg1ygpsT3c8YET/iq9BIf40WfI6YIiRg 9eJHfJBl8Th5dcex8GenwIY8ZAh2DNx1vKiNh7lK+Pw3+nE/KMZotODaIGU5GSE502LX9f5 obXUqFRhrRJpjlCia8TtD1ZG3ZS4mFbF34oa4DAPXWQiTTEVl8L74gVh7OJz89yRd/LC9n8 fMYnBEvdaFxEX+HoyUTVA== X-Spam-Flag: NO X-UI-Out-Filterresults: notjunk:1;V03:K0:Qb0zbk6ZgPQ=:A/BjO9NlFgpY79wGjCN6YN JR1CHkY73EtoVkq84ITn8qsV/ftyW+0bjgUR8OeHoBJxDHSo+QO3GA4tF7Q/qB5NHBf4v5EUl /CtoToctNVqDZo8jku/mnOaTBWtM/bxL61CaKoyz5m84BH4tTNM/0Co7sW9fgJmSsPdRn0Iaw NSilqrw0XMlPhitVXICDOC/x+ajWbJqPZ2hsR6hXEJnVhDSIeulrD0ddqYE5xtGGfE1h1xpYh 28mW0An+hkEKDhKWbe3yI5tY8uEbKV+lOGGMbcVNh8AOL15l5/n4Wy5R68KlEAVH5laYwaSGU ks2/NwPMyQcdxUGfugrfeooTL7vjxQclXP9XhDoApxxxJn6gGlwqy6qY7CfAZmpcepvZVJNWF 8lw4X8QeLwI0bzGyx0xPiBaLRPkBMPdd1LuA7XRExzSteTtwDJPm2z0+H6wTXR/iv2/XFa9Zb +5os+ql1z6zsaq7FlxBQ7P7bvrXMbobz+Rld2QvENOr3sXYqKNPa5HCeA01GKK5hpBSa8HYcz FfAEjedDyv73CB2dH9Es231Mve71LopGMbqwVH6bcLOjjwhG2vhPMRePTwj3LY+Fc9zOkf8Lw wwvFOU3aY/aofLOHNEyAmN0MKmNdBbyrjxlACb1FzGmuKuN/pNvFuMq8hueqV1tUngj6YOaWk Cw1Fv2u6zo2ZusW54HsriUl8TZkzYZQvKgjON6Cxx1CTIgDIrGRz/NmMBdI58s60IMR1bdnfa eYN76l7jf4H0iCgu0lC94eGRetUFCujEv44JlBcJpajx7WyPaWhbF8tdnSjAfQegkGjEBfPGG 8Kf5P9j43VFc4kO5Fge0vHoHbw/XbPIxvmSbnfBbkCygRNS7Be0qlsQs3akUvNDg/j0InK5T3 ehZU2Ql5XIFmzlXwzqFNCmJWFDcyPv6ZOVBGFNyNcFwG3rAnuz+yCetLI2K+WeCTax75emInc JOH7USAZUmapRjyh4NhVyix+bz/dWrqod9VPtAYGR4is71EV2ji8l3HiMQX5FuJCF+TtiMMzj fMZbcT8wM+516CDpSnrHoMXaLr4PMhl2Uca0KP3sQOoQqXkBpY0e21mj/2XNWXgHS/s2y3M7Z 8gs4ykF61GvnMOVV7JtMT8LnWLGmR3KY002JqaQ+CIRVftpe81OPlCuJvYyjwbCJlfRHJH9Ao RYxdz7TFQqJadw8GzvGIhfmgsTAxnzAeLonPYbbNYzzDIhuf45bBrGwPjXdAurVUbSA30ph5p JEr3CfgcCCKb9XVsPUz9sJzUAXOGjNjvF8Y9D0iSC95x3GSOMJoD+quUhRRE= X-Spam-Score: 0.0 (/) 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 (-) >> `eq' wouldn't make any sense at all. > > Why not? Where and how would you use it? >> 'compare-window-configurations' per se is a misconception. > > We're talking about the behavior of `equal`, not that of > `compare-window-configurations`. 'equal' is specified via compare_window_configurations which is a misconception just a 'compare-window-configurations' is. martin From unknown Sat Jun 14 18:56:05 2025 X-Loop: help-debbugs@gnu.org Subject: bug#38912: 27.0.60; PDumper meets segmentation fault when evil is loaded Resent-From: Pip Cet Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 07 Jan 2020 19:32:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 38912 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Stefan Monnier Cc: niwtrx@icloud.com, 38912@debbugs.gnu.org, Eli Zaretskii , Daniel Colascione Received: via spool by 38912-submit@debbugs.gnu.org id=B38912.157842551312878 (code B ref 38912); Tue, 07 Jan 2020 19:32:02 +0000 Received: (at 38912) by debbugs.gnu.org; 7 Jan 2020 19:31:53 +0000 Received: from localhost ([127.0.0.1]:49385 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ioua1-0003Le-H7 for submit@debbugs.gnu.org; Tue, 07 Jan 2020 14:31:53 -0500 Received: from mail-ot1-f41.google.com ([209.85.210.41]:46441) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ioua0-0003LS-L3 for 38912@debbugs.gnu.org; Tue, 07 Jan 2020 14:31:53 -0500 Received: by mail-ot1-f41.google.com with SMTP id r9so1083646otp.13 for <38912@debbugs.gnu.org>; Tue, 07 Jan 2020 11:31:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=P9Ebq4IN9swzJgDzfPz+29patSACP5RWHsq46t/B1W4=; b=UFjA21DrbHUKJbmYItRf7bJRthqht9yRnFhJhDZfAkwIbOjv65v0PuwDeh+YJrfxjG muEzaTLUgH3v6RVQUWJApL9nZ/WSKhqdlCUelPV0vymvCV62aRrPqHExFLvna8f/9HqX hPPANjZP1DVRmu83niihEUjU3xmBhD55AhPcbU4drLmJ8xjIAGL27Cd0GZ4nw8FAGDXM 08mpcE2HO1FEwZWaZMUOP4SlDRyOaOJedOMa42yxn/mA+GrZnlhTOVGrdmNjHcWhJXNa juTOOzuwkkH1VFg4L1DhHx7R8Enc/XWW+i7LJUQyO319kSWT9DGmCxddAxSoQWJpZM1F fZ4g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=P9Ebq4IN9swzJgDzfPz+29patSACP5RWHsq46t/B1W4=; b=lV4EfSCwFsLHVFVa+Kud8ltamjOA7U9GJdX4MeMpVbgWP5l6wbsYamyEt3SYRaphL/ URVI9FmRIOUwPbMLSc2VGKLQdDnjRAT2AKI+BBhthMMu3HP98s7hZVAwiadxz+X5SrmP gvULQq9KviczWFBYjGZS0oaSN9zJWiVMpXZvIFX1TWyk1pD7zyaDtoDC4xyxH6NNOC66 OPSN74EWCxdBxWm19enGx1MGtNotDNVmikd4+3I23uqDAsJDXWIIjffk1Do0t9soqrSW TUWpi3MQP+ZQBsdTkS5eGnZwBN9Rakc+BuDx006YoIsO58SydmrjTBiv08lc4EAYcvMz q4NQ== X-Gm-Message-State: APjAAAWOLRB2p13cCK/B/Q0uSINzsuF8WS6Y+NdAQXxaB3jONPxmY0zN 8iIpoJ+JEbxKQQyJNM88YJoYSKtTHM4iEZN3j9k= X-Google-Smtp-Source: APXvYqxLYdm75LjoMXp/g45nRtOW2SL6IWhE02sKEq11ACRNhkLj/9IrpdoDEpH32BfN397kQU9aAY42/mvoa3kMt5Y= X-Received: by 2002:a9d:68cb:: with SMTP id i11mr1389179oto.210.1578425507060; Tue, 07 Jan 2020 11:31:47 -0800 (PST) MIME-Version: 1.0 References: <333553AC-68DE-4F1C-9586-5A13248AD6DD@icloud.com> <83ftgvh96l.fsf@gnu.org> <83a771g2tc.fsf@gnu.org> <83o8vgee85.fsf@gnu.org> <8b2e879676c6ecc1371d50e033164424.squirrel@dancol.org> <83h818ebmr.fsf@gnu.org> In-Reply-To: From: Pip Cet Date: Tue, 7 Jan 2020 19:31:10 +0000 Message-ID: Content-Type: text/plain; charset="UTF-8" X-Spam-Score: 0.0 (/) 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 Mon, Jan 6, 2020 at 6:13 PM Stefan Monnier wrote: > The problem is simply that `sxhash` doesn't use the same "rules" about > which objects are compared by identity and which objects are compared > by contents. I agree. > so the problem doesn't affect only byte-compiled objects but also > overlays, markers, windowconfigs, chartables, and fonts, AFAICT. True, but then, those don't make much sense as hash keys in an equal-based hash table. I don't think bytecode objects make sense as hash keys in an equal-based hash table, either: two bytecode objects can be `equal` yet be non-equivalent, even though it's somewhat unlikely to occur in practice. > The fix should be to make `sxhash` follow the same rules as `internal_equal`. I think the two should largely follow the same rules, because all of those objects should be equal iff they're eq. Hashing a marker based on its position, for example, makes little sense: when the marker moves, the hash value would change. Bytecode objects could be compared based on their string representation, I guess, and maybe should be hash-consed based on that (deduplicating identical bytecode objects used as constants in other bytecode objects appears to save quite a bit of space), once they're made immutable. From unknown Sat Jun 14 18:56:05 2025 X-Loop: help-debbugs@gnu.org Subject: bug#38912: 27.0.60; PDumper meets segmentation fault when evil is loaded Resent-From: Paul Eggert Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 07 Jan 2020 19:34:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 38912 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Stefan Monnier , dancol@dancol.org Cc: niwtrx@icloud.com, 38912@debbugs.gnu.org, Eli Zaretskii , Pip Cet , emacs-devel@gnu.org Received: via spool by 38912-submit@debbugs.gnu.org id=B38912.157842559213014 (code B ref 38912); Tue, 07 Jan 2020 19:34:02 +0000 Received: (at 38912) by debbugs.gnu.org; 7 Jan 2020 19:33:12 +0000 Received: from localhost ([127.0.0.1]:49389 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ioubH-0003Np-SM for submit@debbugs.gnu.org; Tue, 07 Jan 2020 14:33:12 -0500 Received: from zimbra.cs.ucla.edu ([131.179.128.68]:35640) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ioubF-0003Nb-CE for 38912@debbugs.gnu.org; Tue, 07 Jan 2020 14:33:10 -0500 Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id C0076160063; Tue, 7 Jan 2020 11:33:03 -0800 (PST) Received: from zimbra.cs.ucla.edu ([127.0.0.1]) by localhost (zimbra.cs.ucla.edu [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id TxD7haS5Wzl6; Tue, 7 Jan 2020 11:33:02 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id 08AD5160085; Tue, 7 Jan 2020 11:33:02 -0800 (PST) X-Virus-Scanned: amavisd-new at zimbra.cs.ucla.edu Received: from zimbra.cs.ucla.edu ([127.0.0.1]) by localhost (zimbra.cs.ucla.edu [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id hm4_vfemddkJ; Tue, 7 Jan 2020 11:33:01 -0800 (PST) Received: from Penguin.CS.UCLA.EDU (Penguin.CS.UCLA.EDU [131.179.64.200]) by zimbra.cs.ucla.edu (Postfix) with ESMTPSA id D77D7160063; Tue, 7 Jan 2020 11:33:01 -0800 (PST) References: From: Paul Eggert Organization: UCLA Computer Science Department Message-ID: <4b0e8ed0-87c4-f0b3-f610-080e3be3b3db@cs.ucla.edu> Date: Tue, 7 Jan 2020 11:32:58 -0800 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.3.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/mixed; boundary="------------15BD182135ABD8D2D136F3F2" Content-Language: en-US X-Spam-Score: -2.3 (--) 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 (---) This is a multi-part message in MIME format. --------------15BD182135ABD8D2D136F3F2 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit On 1/7/20 6:16 AM, Stefan Monnier wrote: > I'd be in > favor of introducing this backward incompatibility in Emacs-28, unless > we can find a good use case where the structural-equality is needed > for them. I looked for use cases within Emacs, and found only one: a test case that I changed to use compare-window-configurations instead. I don't think this was a good use case; it's just a hack in a test. I agree with Martin that comparing window configurations is something of a botch. Despite some documentation to the contrary, neither 'equal' nor compare-window-configurations compares all components of window configurations (though the two functions do compare different sets of components). If there's a solid need for comparing different sets of components of window configurations (and I doubt whether the test case establishes a need), it could be implemented by adding an argument to compare-window-configurations to say how to do the comparison. However, there doesn't seem to be a significant need to make all this part of 'equal'. So, after writing some sxhash-equal test cases and then fixing Emacs to handle these test cases properly, I boldly installed the attached patch into master. This should make sxhash-equal compatible with 'equal'. Comments welcome as usual. --------------15BD182135ABD8D2D136F3F2 Content-Type: text/x-patch; charset=UTF-8; name="0001-Fix-sxhash-equal-on-bytecodes-markers-etc.patch" Content-Disposition: attachment; filename="0001-Fix-sxhash-equal-on-bytecodes-markers-etc.patch" Content-Transfer-Encoding: quoted-printable >From 724af7671590cd91df37f64df6be73f6dca0144d Mon Sep 17 00:00:00 2001 From: Paul Eggert Date: Tue, 7 Jan 2020 11:23:11 -0800 Subject: [PATCH] Fix sxhash-equal on bytecodes, markers, etc. MIME-Version: 1.0 Content-Type: text/plain; charset=3DUTF-8 Content-Transfer-Encoding: 8bit Problem reported by Pip Cet (Bug#38912#14). * doc/lispref/objects.texi (Equality Predicates): Document better when =E2=80=98equal=E2=80=99 looks inside objects. * doc/lispref/windows.texi (Window Configurations): Don=E2=80=99t say that =E2=80=98equal=E2=80=99 looks inside window config= urations. * etc/NEWS: Mention the change. * src/fns.c (internal_equal): Do not look inside window configurations. (sxhash_obj): Hash markers, byte-code function objects, char-tables, and font objects consistently with Fequal. * src/window.c (compare_window_configurations): Now static. Remove last argument. Caller changed. * test/lisp/ffap-tests.el (ffap-other-window--bug-25352): Use compare-window-configurations, not =E2=80=98equal=E2=80=99. * test/src/fns-tests.el (test-sxhash-equal): New test. --- doc/lispref/objects.texi | 8 +++++-- doc/lispref/windows.texi | 4 ---- etc/NEWS | 6 +++++ src/fns.c | 52 ++++++++++++++++++++++++---------------- src/lisp.h | 4 ++-- src/window.c | 21 ++++------------ src/window.h | 1 - test/lisp/ffap-tests.el | 2 +- test/src/fns-tests.el | 16 +++++++++++++ 9 files changed, 67 insertions(+), 47 deletions(-) diff --git a/doc/lispref/objects.texi b/doc/lispref/objects.texi index 4be2eb6918..4242223a48 100644 --- a/doc/lispref/objects.texi +++ b/doc/lispref/objects.texi @@ -2336,8 +2336,12 @@ Equality Predicates @end group @end example =20 -However, two distinct buffers are never considered @code{equal}, even if -their textual contents are the same. +The @code{equal} function recursively compares the contents of objects +if they are integers, strings, markers, vectors, bool-vectors, +byte-code function objects, char-tables, records, or font objects. +Other objects are considered @code{equal} only if they are @code{eq}. +For example, two distinct buffers are never considered @code{equal}, +even if their textual contents are the same. @end defun =20 For @code{equal}, equality is defined recursively; for example, given diff --git a/doc/lispref/windows.texi b/doc/lispref/windows.texi index c9301c9d18..d0791d4019 100644 --- a/doc/lispref/windows.texi +++ b/doc/lispref/windows.texi @@ -5915,10 +5915,6 @@ Window Configurations structure of windows, but ignores the values of point and the saved scrolling positions---it can return @code{t} even if those aspects differ. - -The function @code{equal} can also compare two window configurations; it -regards configurations as unequal if they differ in any respect, even a -saved point. @end defun =20 @defun window-configuration-frame config diff --git a/etc/NEWS b/etc/NEWS index d6cabf8e9e..0784160ce2 100644 --- a/etc/NEWS +++ b/etc/NEWS @@ -42,6 +42,12 @@ applies, and please also update docstrings as needed. =0C * Incompatible Lisp Changes in Emacs 28.1 =20 +** 'equal' no longer examines some contents of window configurations. +Instead, it considers window configurations to be equal only if they +are eq. To compare contents, use compare-window-configurations +instead. This change helps fix a bug in sxhash-equal, which returned +incorrect hashes for window configurations and some other objects. + =0C * Lisp Changes in Emacs 28.1 =20 diff --git a/src/fns.c b/src/fns.c index 4a0a8fd96d..4a463a8feb 100644 --- a/src/fns.c +++ b/src/fns.c @@ -2434,6 +2434,9 @@ internal_equal (Lisp_Object o1, Lisp_Object o2, enu= m equal_kind equal_kind, same size. */ if (ASIZE (o2) !=3D size) return false; + + /* Compare bignums, overlays, markers, and boolvectors + specially, by comparing their values. */ if (BIGNUMP (o1)) return mpz_cmp (*xbignum_val (o1), *xbignum_val (o2)) =3D=3D 0; if (OVERLAYP (o1)) @@ -2454,7 +2457,6 @@ internal_equal (Lisp_Object o1, Lisp_Object o2, enu= m equal_kind equal_kind, && (XMARKER (o1)->buffer =3D=3D 0 || XMARKER (o1)->bytepos =3D=3D XMARKER (o2)->bytepos)); } - /* Boolvectors are compared much like strings. */ if (BOOL_VECTOR_P (o1)) { EMACS_INT size =3D bool_vector_size (o1); @@ -2465,11 +2467,6 @@ internal_equal (Lisp_Object o1, Lisp_Object o2, en= um equal_kind equal_kind, return false; return true; } - if (WINDOW_CONFIGURATIONP (o1)) - { - eassert (equal_kind !=3D EQUAL_NO_QUIT); - return compare_window_configurations (o1, o2, false); - } =20 /* Aside from them, only true vectors, char-tables, compiled functions, and fonts (font-spec, font-entity, font-object) @@ -4703,22 +4700,35 @@ sxhash_obj (Lisp_Object obj, int depth) hash =3D sxhash_string (SSDATA (obj), SBYTES (obj)); break; =20 - /* This can be everything from a vector to an overlay. */ case Lisp_Vectorlike: - if (BIGNUMP (obj)) - hash =3D sxhash_bignum (obj); - else if (VECTORP (obj) || RECORDP (obj)) - /* According to the CL HyperSpec, two arrays are equal only if - they are `eq', except for strings and bit-vectors. In - Emacs, this works differently. We have to compare element - by element. Same for records. */ - hash =3D sxhash_vector (obj, depth); - else if (BOOL_VECTOR_P (obj)) - hash =3D sxhash_bool_vector (obj); - else - /* Others are `equal' if they are `eq', so let's take their - address as hash. */ - hash =3D XHASH (obj); + { + enum pvec_type pvec_type =3D PSEUDOVECTOR_TYPE (XVECTOR (obj)); + if (! (PVEC_NORMAL_VECTOR < pvec_type && pvec_type < PVEC_COMPILED)) + { + /* According to the CL HyperSpec, two arrays are equal only if + they are 'eq', except for strings and bit-vectors. In + Emacs, this works differently. We have to compare element + by element. Same for pseudovectors that internal_equal + examines the Lisp contents of. */ + hash =3D sxhash_vector (obj, depth); + break; + } + else if (pvec_type =3D=3D PVEC_BIGNUM) + hash =3D sxhash_bignum (obj); + else if (pvec_type =3D=3D PVEC_MARKER) + { + ptrdiff_t bytepos + =3D XMARKER (obj)->buffer ? XMARKER (obj)->bytepos : 0; + hash =3D sxhash_combine ((intptr_t) XMARKER (obj)->buffer, bytepos)= ; + hash =3D SXHASH_REDUCE (hash); + } + else if (pvec_type =3D=3D PVEC_BOOL_VECTOR) + hash =3D sxhash_bool_vector (obj); + else + /* Others are 'equal' if they are 'eq', so take their + address as hash. */ + hash =3D XHASH (obj); + } break; =20 case Lisp_Cons: diff --git a/src/lisp.h b/src/lisp.h index 1a1ae0399b..3681b7b2a7 100644 --- a/src/lisp.h +++ b/src/lisp.h @@ -1069,7 +1069,7 @@ DEFINE_GDB_SYMBOL_END (PSEUDOVECTOR_FLAG) with PVEC_TYPE_MASK to indicate the actual type. */ enum pvec_type { - PVEC_NORMAL_VECTOR, + PVEC_NORMAL_VECTOR, /* Should be first, for sxhash_obj. */ PVEC_FREE, PVEC_BIGNUM, PVEC_MARKER, @@ -1094,7 +1094,7 @@ DEFINE_GDB_SYMBOL_END (PSEUDOVECTOR_FLAG) PVEC_CONDVAR, PVEC_MODULE_FUNCTION, =20 - /* These should be last, check internal_equal to see why. */ + /* These should be last, for internal_equal and sxhash_obj. */ PVEC_COMPILED, PVEC_CHAR_TABLE, PVEC_SUB_CHAR_TABLE, diff --git a/src/window.c b/src/window.c index ff17cd88f3..8cdad27b66 100644 --- a/src/window.c +++ b/src/window.c @@ -7976,19 +7976,17 @@ foreach_window_1 (struct window *w, bool (*fn) (s= truct window *, void *), /* Return true if window configurations CONFIGURATION1 and CONFIGURATION= 2 describe the same state of affairs. This is used by Fequal. =20 - IGNORE_POSITIONS means ignore non-matching scroll positions - and the like. + Ignore non-matching scroll positions and the like. =20 This ignores a couple of things like the dedication status of window, combination_limit and the like. This might have to be fixed. */ =20 -bool +static bool compare_window_configurations (Lisp_Object configuration1, - Lisp_Object configuration2, - bool ignore_positions) + Lisp_Object configuration2) { - register struct save_window_data *d1, *d2; + struct save_window_data *d1, *d2; struct Lisp_Vector *sws1, *sws2; ptrdiff_t i; =20 @@ -8006,9 +8004,6 @@ compare_window_configurations (Lisp_Object configur= ation1, || d1->frame_menu_bar_lines !=3D d2->frame_menu_bar_lines || !EQ (d1->selected_frame, d2->selected_frame) || !EQ (d1->f_current_buffer, d2->f_current_buffer) - || (!ignore_positions - && (!EQ (d1->minibuf_scroll_window, d2->minibuf_scroll_window) - || !EQ (d1->minibuf_selected_window, d2->minibuf_selected_window)= )) || !EQ (d1->focus_frame, d2->focus_frame) /* Verify that the two configurations have the same number of wind= ows. */ || sws1->header.size !=3D sws2->header.size) @@ -8041,12 +8036,6 @@ compare_window_configurations (Lisp_Object configu= ration1, equality. */ || !EQ (sw1->parent, sw2->parent) || !EQ (sw1->prev, sw2->prev) - || (!ignore_positions - && (!EQ (sw1->hscroll, sw2->hscroll) - || !EQ (sw1->min_hscroll, sw2->min_hscroll) - || !EQ (sw1->start_at_line_beg, sw2->start_at_line_beg) - || NILP (Fequal (sw1->start, sw2->start)) - || NILP (Fequal (sw1->pointm, sw2->pointm)))) || !EQ (sw1->left_margin_cols, sw2->left_margin_cols) || !EQ (sw1->right_margin_cols, sw2->right_margin_cols) || !EQ (sw1->left_fringe_width, sw2->left_fringe_width) @@ -8071,7 +8060,7 @@ DEFUN ("compare-window-configurations", Fcompare_wi= ndow_configurations, and scrolling positions. */) (Lisp_Object x, Lisp_Object y) { - if (compare_window_configurations (x, y, true)) + if (compare_window_configurations (x, y)) return Qt; return Qnil; } diff --git a/src/window.h b/src/window.h index aa8d2c8d1d..167d1be7ab 100644 --- a/src/window.h +++ b/src/window.h @@ -1184,7 +1184,6 @@ #define CHECK_LIVE_WINDOW(WINDOW) \ extern Lisp_Object window_parameter (struct window *, Lisp_Object parame= ter); extern struct window *decode_live_window (Lisp_Object); extern struct window *decode_any_window (Lisp_Object); -extern bool compare_window_configurations (Lisp_Object, Lisp_Object, boo= l); extern void mark_window_cursors_off (struct window *); extern bool window_wants_mode_line (struct window *); extern bool window_wants_header_line (struct window *); diff --git a/test/lisp/ffap-tests.el b/test/lisp/ffap-tests.el index eaf39680e4..30c8f79457 100644 --- a/test/lisp/ffap-tests.el +++ b/test/lisp/ffap-tests.el @@ -74,7 +74,7 @@ ffap-other-window--bug-25352 (urls nil) (ffap-url-fetcher (lambda (url) (push url urls) nil))) (should-not (ffap-other-window "https://www.gnu.org")) - (should (equal (current-window-configuration) old)) + (should (compare-window-configurations (current-window-configuration= ) old)) (should (equal urls '("https://www.gnu.org"))))) =20 (provide 'ffap-tests) diff --git a/test/src/fns-tests.el b/test/src/fns-tests.el index 60be2c6c2d..c6ceae4a00 100644 --- a/test/src/fns-tests.el +++ b/test/src/fns-tests.el @@ -858,6 +858,22 @@ test-hash-function-that-mutates-hash-table (puthash k k h))) (should (=3D 100 (hash-table-count h))))) =20 +(ert-deftest test-sxhash-equal () + (should (=3D (sxhash-equal (* most-positive-fixnum most-negative-fixnu= m)) + (sxhash-equal (* most-positive-fixnum most-negative-fixnum)))) + (should (=3D (sxhash-equal (make-string 1000 ?a)) + (sxhash-equal (make-string 1000 ?a)))) + (should (=3D (sxhash-equal (point-marker)) + (sxhash-equal (point-marker)))) + (should (=3D (sxhash-equal (make-vector 1000 (make-string 10 ?a))) + (sxhash-equal (make-vector 1000 (make-string 10 ?a))))) + (should (=3D (sxhash-equal (make-bool-vector 1000 t)) + (sxhash-equal (make-bool-vector 1000 t)))) + (should (=3D (sxhash-equal (make-char-table nil (make-string 10 ?a))) + (sxhash-equal (make-char-table nil (make-string 10 ?a))))) + (should (=3D (sxhash-equal (record 'a (make-string 10 ?a))) + (sxhash-equal (record 'a (make-string 10 ?a)))))) + (ert-deftest test-secure-hash () (should (equal (secure-hash 'md5 "foobar") "3858f62230ac3c915f300c664312c63f")) --=20 2.24.1 --------------15BD182135ABD8D2D136F3F2-- From unknown Sat Jun 14 18:56:05 2025 X-Loop: help-debbugs@gnu.org Subject: bug#38912: 27.0.60; PDumper meets segmentation fault when evil is loaded Resent-From: Stefan Monnier Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 07 Jan 2020 20:04:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 38912 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Pip Cet Cc: niwtrx@icloud.com, 38912@debbugs.gnu.org, Eli Zaretskii , Daniel Colascione Received: via spool by 38912-submit@debbugs.gnu.org id=B38912.157842742416105 (code B ref 38912); Tue, 07 Jan 2020 20:04:01 +0000 Received: (at 38912) by debbugs.gnu.org; 7 Jan 2020 20:03:44 +0000 Received: from localhost ([127.0.0.1]:49421 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1iov4q-0004Bh-J4 for submit@debbugs.gnu.org; Tue, 07 Jan 2020 15:03:44 -0500 Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:36800) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1iov4o-0004BV-Ne for 38912@debbugs.gnu.org; Tue, 07 Jan 2020 15:03:43 -0500 Received: from pmg1.iro.umontreal.ca (localhost.localdomain [127.0.0.1]) by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id 46B6910080B; Tue, 7 Jan 2020 15:03:37 -0500 (EST) Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id 9EC5F1002E2; Tue, 7 Jan 2020 15:03:35 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1578427415; bh=+g4TlEiPn0jUqnBe4G4pxqEk9RLmbiNoyw/M8sDk/u0=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=URMnt9vGI4/CD8ndlL8PygtzB4bJup9oe9eJD80yRrysw8f1ezLbkmZpynaXzoyW1 hPg4i1H/+6XjBS+/XAruMZdacnwrfzcdLiQY4gmyavdzDV5JmKLFa6IcOPcd9G+s9j 8kpSfqZNvdnzmy4xhqqa/GggVoTo399MwYtbhKdL1tV7TqlBgdXFl8iH8CKqQ/MppP zfhqL4nHG0kuGInDn38d7Y4Cw5xZqH2fOlz4VbU4IeNe9/zlA+GowtlYc4ybXL3CuO kxOWsiVcHvhwVJbeJEoxOhbnz2FgK/3qwSUS9QTnMSuBUYtozDNN1BVHGECNGv0BTs Zl9z+BVrdJwKQ== Received: from pastel (unknown [45.72.147.220]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 574BA12065C; Tue, 7 Jan 2020 15:03:34 -0500 (EST) From: Stefan Monnier In-Reply-To: (Pip Cet's message of "Tue, 7 Jan 2020 19:31:10 +0000") Message-ID: References: <333553AC-68DE-4F1C-9586-5A13248AD6DD@icloud.com> <83ftgvh96l.fsf@gnu.org> <83a771g2tc.fsf@gnu.org> <83o8vgee85.fsf@gnu.org> <8b2e879676c6ecc1371d50e033164424.squirrel@dancol.org> <83h818ebmr.fsf@gnu.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux) Date: Tue, 07 Jan 2020 15:03:21 -0500 MIME-Version: 1.0 Content-Type: text/plain X-SPAM-INFO: Spam detection results: 0 ALL_TRUSTED -1 Passed through trusted hosts only via SMTP AWL -0.038 Adjusted score from AWL reputation of From: address BAYES_00 -1.9 Bayes spam probability is 0 to 1% DKIM_SIGNED 0.1 Message has a DKIM or DK signature, not necessarily valid DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's domain X-SPAM-LEVEL: X-Spam-Score: -2.3 (--) 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 (---) >> so the problem doesn't affect only byte-compiled objects but also >> overlays, markers, windowconfigs, chartables, and fonts, AFAICT. > True, but then, those don't make much sense as hash keys in an > equal-based hash table. Comparing markers with `equal` does make some kind of sense. And `sxhash-equal` needs to be consistent with it, regardless if we think it makes sense to index an equal-hash-table with markers (or objects containing markers). > I don't think bytecode objects make sense as > hash keys in an equal-based hash table, I agree that comparing function objects is fundamentally unreliable, yet we do that in several places in Elisp: it's not super common, but it's not rare either, and having a better approximation of "behaves identically" than `eq` is occasionally useful. > on its position, for example, makes little sense: when the marker > moves, the hash value would change. Comparison with `equal` suffers from this problem in many more cases than just markers (cons cells, vectors, strings, ...). > (deduplicating identical bytecode objects used as constants in other > bytecode objects appears to save quite a bit of space), I'm curious where you've seen that (I haven't looked at it, but indeed it's quite possible that the byte-compiler "often" ends up generating identical byte objects). Stefan From unknown Sat Jun 14 18:56:05 2025 X-Loop: help-debbugs@gnu.org Subject: bug#38912: 27.0.60; PDumper meets segmentation fault when evil is loaded Resent-From: Richard Stallman Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 07 Jan 2020 23:44:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 38912 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: "Daniel Colascione" Cc: niwtrx@icloud.com, 38912@debbugs.gnu.org, eliz@gnu.org, pipcet@gmail.com Reply-To: rms@gnu.org Received: via spool by 38912-submit@debbugs.gnu.org id=B38912.15784406347463 (code B ref 38912); Tue, 07 Jan 2020 23:44:01 +0000 Received: (at 38912) by debbugs.gnu.org; 7 Jan 2020 23:43:54 +0000 Received: from localhost ([127.0.0.1]:49601 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ioyVt-0001wJ-UW for submit@debbugs.gnu.org; Tue, 07 Jan 2020 18:43:54 -0500 Received: from eggs.gnu.org ([209.51.188.92]:44091) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ioyVs-0001w5-7T for 38912@debbugs.gnu.org; Tue, 07 Jan 2020 18:43:52 -0500 Received: from fencepost.gnu.org ([2001:470:142:3::e]:57654) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ioyVm-00052D-Mb; Tue, 07 Jan 2020 18:43:46 -0500 Received: from rms by fencepost.gnu.org with local (Exim 4.82) (envelope-from ) id 1ioyVl-0000UV-35; Tue, 07 Jan 2020 18:43:45 -0500 Content-Type: text/plain; charset=Utf-8 From: Richard Stallman In-Reply-To: <8b2e879676c6ecc1371d50e033164424.squirrel@dancol.org> References: <333553AC-68DE-4F1C-9586-5A13248AD6DD@icloud.com> <83ftgvh96l.fsf@gnu.org> <83a771g2tc.fsf@gnu.org> <83o8vgee85.fsf@gnu.org> <8b2e879676c6ecc1371d50e033164424.squirrel@dancol.org> Message-Id: Date: Tue, 07 Jan 2020 18:43:45 -0500 X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Spam-Score: -2.3 (--) 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 (---) [[[ To any NSA and FBI agents reading my email: please consider ]]] [[[ whether defending the US Constitution against all enemies, ]]] [[[ foreign or domestic, requires you to follow Snowden's example. ]]] > This consensus is wrong. We need to make equality imply sxhash equality or > very odd things (like this) will happen. I agree. The basic idea of sxhash is that comparing hashes is a quick way to detect most cases where two values are not equal. If sxhash comparison gives false negatives, that method is not trustworthy. -- Dr Richard Stallman Chief GNUisance of the GNU Project (https://gnu.org) Founder, Free Software Foundation (https://fsf.org) Internet Hall-of-Famer (https://internethalloffame.org) From unknown Sat Jun 14 18:56:05 2025 X-Loop: help-debbugs@gnu.org Subject: bug#38912: 27.0.60; PDumper meets segmentation fault when evil is loaded Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 05 Mar 2020 07:16:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 38912 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: "Daniel Colascione" Cc: niwtrx@icloud.com, 38912@debbugs.gnu.org, dancol@dancol.org Received: via spool by 38912-submit@debbugs.gnu.org id=B38912.15833925051774 (code B ref 38912); Thu, 05 Mar 2020 07:16:02 +0000 Received: (at 38912) by debbugs.gnu.org; 5 Mar 2020 07:15:05 +0000 Received: from localhost ([127.0.0.1]:42116 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1j9kin-0000SY-9J for submit@debbugs.gnu.org; Thu, 05 Mar 2020 02:15:05 -0500 Received: from eggs.gnu.org ([209.51.188.92]:50036) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1j9kil-0000Rl-R6 for 38912@debbugs.gnu.org; Thu, 05 Mar 2020 02:15:04 -0500 Received: from fencepost.gnu.org ([2001:470:142:3::e]:39541) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1j9kig-0004Cw-Dr; Thu, 05 Mar 2020 02:14:58 -0500 Received: from [176.228.60.248] (port=3252 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1j9kif-00072p-S0; Thu, 05 Mar 2020 02:14:58 -0500 Date: Thu, 05 Mar 2020 09:14:38 +0200 Message-Id: <83zhcvuvc1.fsf@gnu.org> From: Eli Zaretskii In-Reply-To: References: <333553AC-68DE-4F1C-9586-5A13248AD6DD@icloud.com> <83ftgvh96l.fsf@gnu.org> <83a771g2tc.fsf@gnu.org> MIME-version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Spam-Score: -0.7 (/) 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 (-) Ping! Any news in debugging this? > Date: Mon, 6 Jan 2020 09:10:20 -0800 > From: "Daniel Colascione" > Cc: "NiwTinray" , > "Daniel Colascione" , > 38912@debbugs.gnu.org > > > [Please use "Reply All" to reply, so that the bug address is kept on > > the CC list.] > > > >> From: NiwTinray > >> Date: Sun, 5 Jan 2020 13:25:07 +0800 > >> > >> > I cannot reproduce this from "emacs -Q" because 'use-package' is not a > >> > known function. Can you show a recipe starting from "emacs -Q", > >> > please? > >> > >> Here. I've attached a minimal script file that helps reproduce this bug. > >> > >> (require 'package) > >> (package-initialize) > >> (add-to-list 'package-archives > >> '("melpa-stable" . "https://stable.melpa.org/packages/") t) > >> (unless (package-installed-p 'evil) > >> (package-refresh-contents) > >> (package-install 'evil)) > >> (require 'evil) > >> (dump-emacs-portable "/tmp/test.pdmp") > >> > >> The script downloads the package "evil" from Melpa stable, load the evil > >> package > >> and dumps an image to /tmp/test.pdmp. > >> > >> > Also, does this happen if you add -Q to the Emacs invocation after > >> > dumping? If not, there's more detail missing in your report: the > >> > customizations in your init files. > >> > >> > >> Sure. Please download this file, and run the command: > >> > >> emacs --batch -Q --script evil.el > >> > >> To see the bug happen, load the test.pdmp file: > >> > >> emacs -Q --dump-file /tmp/test.pdmp > >> > >> You should see a segmentation fault: > >> > >> [1] 23369 segmentation fault (core dumped) emacs -Q --dump-file > >> /tmp/test.pdmp > >> > >> I run debugger inside src/.gdbinit using the command: > >> > >> gdb -x .gdbinit --args ./emacs --dump-file /tmp/test.pdmp > >> > >> And logged backtrace. See my second attachment: > >> > >> (base) omnisky :: ~/emacs/src ‹emacs-27*› » gdb -x .gdbinit --args > >> ./emacs --dump-file /tmp/test.pdmp > >> GNU gdb (Ubuntu 7.11.1-0ubuntu1~16.5) 7.11.1 > >> Copyright (C) 2016 Free Software Foundation, Inc. > >> License GPLv3+: GNU GPL version 3 or later > >> > >> This is free software: you are free to change and redistribute it. > >> There is NO WARRANTY, to the extent permitted by law. Type "show > >> copying" > >> and "show warranty" for details. > >> This GDB was configured as "x86_64-linux-gnu". > >> Type "show configuration" for configuration details. > >> For bug reporting instructions, please see: > >> . > >> Find the GDB manual and other documentation resources online at: > >> . > >> For help, type "help". > >> Type "apropos word" to search for commands related to "word"... > >> Reading symbols from ./emacs...done. > >> warning: File "/home/ntr/emacs/src/.gdbinit" auto-loading has been > >> declined by your `auto-load safe-path' set to > >> "$debugdir:$datadir/auto-load". > >> To enable execution of this file add > >> add-auto-load-safe-path /home/ntr/emacs/src/.gdbinit > >> line to your configuration file "/home/ntr/.gdbinit". > >> To completely disable this security protection add > >> set auto-load safe-path / > >> line to your configuration file "/home/ntr/.gdbinit". > >> For more information about this security protection see the > >> "Auto-loading safe path" section in the GDB manual. E.g., run from the > >> shell: > >> info "(gdb)Auto-loading safe path" > >> SIGINT is used by the debugger. > >> Are you sure you want to change it? (y or n) [answered Y; input not from > >> terminal] > >> Environment variable "DISPLAY" not defined. > >> TERM = xterm-24bits > >> Breakpoint 1 at 0x411df0: file emacs.c, line 370. > >> Breakpoint 2 at 0x4bfe60: file xterm.c, line 10130. > >> (gdb) r > >> Starting program: /home/ntr/emacs/src/emacs --dump-file /tmp/test.pdmp > >> /home/ntr/emacs/src/emacs: > >> /raid_sdc/home/ntr/anaconda3/lib/libtiff.so.5: no version information > >> available (required by /home/ntr/emacs/src/emacs) > >> [Thread debugging using libthread_db enabled] > >> Using host libthread_db library > >> "/lib/x86_64-linux-gnu/libthread_db.so.1". > >> > >> Program received signal SIGSEGV, Segmentation fault. > >> 0x00000000004f12d0 in Fcurrent_active_maps (olp=olp@entry=XIL(0x30), > >> position=position@entry=XIL(0)) at keymap.c:1541 > >> 1541 && NILP (KVAR (current_kboard, > >> Voverriding_terminal_local_map)) > >> (gdb) xbacktrace > >> "key-binding" (0xffffd5c8) > >> "turn-on-undo-tree-mode" (0xffffd758) > >> "global-undo-tree-mode-enable-in-buffers" (0xffffd948) > >> "run-hooks" (0xffffd9e8) > >> "run-mode-hooks" (0xffffdbc0) > >> "minibuffer-inactive-mode" (0xffffdd40) > >> (gdb) > > > > In my debug build of Emacs 27.0.60 I get an assertion violation while > > dumping, which probably is already a sign of trouble. > > > > Daniel, any ideas? > > I haven't had a chance over the past few days to repro this problem, but I > hope to do so this weeekend. The messages about the assertion failure > *during* dumping do seem likely unrelated. The easiest way to debug this > particular crash is with rr. Run the original test as "rr record emacs > [args]", then run "rr replay". The latter will dump you in a GDB prompt. > Type "cont" and run the replay of Emacs until you get to the SIGSEGV. Run > "watch -l [expression]" to break out of execution whenever that value > changes, then run "reverse-cont" to run the replay *backwards* until you > get to the code that changed the variable with the bad value. > > From unknown Sat Jun 14 18:56:05 2025 X-Loop: help-debbugs@gnu.org Subject: bug#38912: 27.0.60; PDumper meets segmentation fault when evil is loaded Resent-From: "Daniel Colascione" Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 09 Mar 2020 02:16:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 38912 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: "Eli Zaretskii" Cc: niwtrx@icloud.com, 38912@debbugs.gnu.org, Daniel Colascione Received: via spool by 38912-submit@debbugs.gnu.org id=B38912.158372014017562 (code B ref 38912); Mon, 09 Mar 2020 02:16:02 +0000 Received: (at 38912) by debbugs.gnu.org; 9 Mar 2020 02:15:40 +0000 Received: from localhost ([127.0.0.1]:49599 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jB7xD-0004ZC-JT for submit@debbugs.gnu.org; Sun, 08 Mar 2020 22:15:40 -0400 Received: from dancol.org ([96.126.100.184]:34072) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jB7xA-0004Z1-64 for 38912@debbugs.gnu.org; Sun, 08 Mar 2020 22:15:38 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=dancol.org; s=x; h=Content-Transfer-Encoding:Content-Type:MIME-Version:Cc:To:From: Subject:Date:References:In-Reply-To:Message-ID:Sender:Reply-To:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=l8WGbP9oe2NHhTn2Xjtq5Azpde+Ldnr7VAgJ8CXO4TU=; b=raLeQT5vmSBC7d0ZMRMaDM92/i vYje4dOQl9+1c/eKvfm7KPKjmNU3GGmu7E6xyHfzdiFA9F3S6nCQzYTKQ1xjJBsAmNtyrsVFBRzCm eDauXM7k5SgU95jGP/TjjLUm5WKsmgfA2pYyaVfUOV20u3sFF+9bdUR2VDp/aTfqQcHyFXoTctr1P Mv84KMnkrue5NX8hvyvDZOA+D2PaUdn/k1UfpiNpIDCIVoaEE7V452cIwj055crlWAr6Vh17unPO+ TUwFo5ELNhMHYwD6RPIpLKbp/k5dNnEjK0Xk7UIdxRIlMDlCTwm6VrUuYYL2KnNUEaNMHaACEbR84 QJD1pewg==; Received: from localhost ([127.0.0.1] helo=dancol.org) by dancol.org with esmtp (Exim 4.89) (envelope-from ) id 1jB7x5-0003o6-0r; Sun, 08 Mar 2020 19:15:31 -0700 Received: from 127.0.0.1 (SquirrelMail authenticated user dancol) by dancol.org with HTTP; Sun, 8 Mar 2020 19:15:31 -0700 Message-ID: In-Reply-To: <83zhcvuvc1.fsf@gnu.org> References: <333553AC-68DE-4F1C-9586-5A13248AD6DD@icloud.com> <83ftgvh96l.fsf@gnu.org> <83a771g2tc.fsf@gnu.org> <83zhcvuvc1.fsf@gnu.org> Date: Sun, 8 Mar 2020 19:15:31 -0700 From: "Daniel Colascione" User-Agent: SquirrelMail/1.4.23 [SVN] MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal X-Spam-Score: -0.0 (/) 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 (-) Sorry, haven't had a chance to look at it yet. I've been treating it as low-ish priority because pdumping outside loadup isn't supported yet. Is there some reason to expedite this work? > Ping! Any news in debugging this? > >> Date: Mon, 6 Jan 2020 09:10:20 -0800 >> From: "Daniel Colascione" >> Cc: "NiwTinray" , >> "Daniel Colascione" , >> 38912@debbugs.gnu.org >> >> > [Please use "Reply All" to reply, so that the bug address is kept on >> > the CC list.] >> > >> >> From: NiwTinray >> >> Date: Sun, 5 Jan 2020 13:25:07 +0800 >> >> >> >> > I cannot reproduce this from "emacs -Q" because 'use-package' is >> not a >> >> > known function. Can you show a recipe starting from "emacs -Q", >> >> > please? >> >> >> >> Here. I've attached a minimal script file that helps reproduce this >> bug. >> >> >> >> (require 'package) >> >> (package-initialize) >> >> (add-to-list 'package-archives >> >> '("melpa-stable" . "https://stable.melpa.org/packages/") >> t) >> >> (unless (package-installed-p 'evil) >> >> (package-refresh-contents) >> >> (package-install 'evil)) >> >> (require 'evil) >> >> (dump-emacs-portable "/tmp/test.pdmp") >> >> >> >> The script downloads the package "evil" from Melpa stable, load the >> evil >> >> package >> >> and dumps an image to /tmp/test.pdmp. >> >> >> >> > Also, does this happen if you add -Q to the Emacs invocation after >> >> > dumping? If not, there's more detail missing in your report: the >> >> > customizations in your init files. >> >> >> >> >> >> Sure. Please download this file, and run the command: >> >> >> >> emacs --batch -Q --script evil.el >> >> >> >> To see the bug happen, load the test.pdmp file: >> >> >> >> emacs -Q --dump-file /tmp/test.pdmp >> >> >> >> You should see a segmentation fault: >> >> >> >> [1] 23369 segmentation fault (core dumped) emacs -Q --dump-file >> >> /tmp/test.pdmp >> >> >> >> I run debugger inside src/.gdbinit using the command: >> >> >> >> gdb -x .gdbinit --args ./emacs --dump-file /tmp/test.pdmp >> >> >> >> And logged backtrace. See my second attachment: >> >> >> >> (base) omnisky :: ~/emacs/src ‹emacs-27*› » gdb -x .gdbinit >> --args >> >> ./emacs --dump-file /tmp/test.pdmp >> >> GNU gdb (Ubuntu 7.11.1-0ubuntu1~16.5) 7.11.1 >> >> Copyright (C) 2016 Free Software Foundation, Inc. >> >> License GPLv3+: GNU GPL version 3 or later >> >> >> >> This is free software: you are free to change and redistribute it. >> >> There is NO WARRANTY, to the extent permitted by law. Type "show >> >> copying" >> >> and "show warranty" for details. >> >> This GDB was configured as "x86_64-linux-gnu". >> >> Type "show configuration" for configuration details. >> >> For bug reporting instructions, please see: >> >> . >> >> Find the GDB manual and other documentation resources online at: >> >> . >> >> For help, type "help". >> >> Type "apropos word" to search for commands related to "word"... >> >> Reading symbols from ./emacs...done. >> >> warning: File "/home/ntr/emacs/src/.gdbinit" auto-loading has been >> >> declined by your `auto-load safe-path' set to >> >> "$debugdir:$datadir/auto-load". >> >> To enable execution of this file add >> >> add-auto-load-safe-path /home/ntr/emacs/src/.gdbinit >> >> line to your configuration file "/home/ntr/.gdbinit". >> >> To completely disable this security protection add >> >> set auto-load safe-path / >> >> line to your configuration file "/home/ntr/.gdbinit". >> >> For more information about this security protection see the >> >> "Auto-loading safe path" section in the GDB manual. E.g., run from >> the >> >> shell: >> >> info "(gdb)Auto-loading safe path" >> >> SIGINT is used by the debugger. >> >> Are you sure you want to change it? (y or n) [answered Y; input not >> from >> >> terminal] >> >> Environment variable "DISPLAY" not defined. >> >> TERM = xterm-24bits >> >> Breakpoint 1 at 0x411df0: file emacs.c, line 370. >> >> Breakpoint 2 at 0x4bfe60: file xterm.c, line 10130. >> >> (gdb) r >> >> Starting program: /home/ntr/emacs/src/emacs --dump-file >> /tmp/test.pdmp >> >> /home/ntr/emacs/src/emacs: >> >> /raid_sdc/home/ntr/anaconda3/lib/libtiff.so.5: no version information >> >> available (required by /home/ntr/emacs/src/emacs) >> >> [Thread debugging using libthread_db enabled] >> >> Using host libthread_db library >> >> "/lib/x86_64-linux-gnu/libthread_db.so.1". >> >> >> >> Program received signal SIGSEGV, Segmentation fault. >> >> 0x00000000004f12d0 in Fcurrent_active_maps (olp=olp@entry=XIL(0x30), >> >> position=position@entry=XIL(0)) at keymap.c:1541 >> >> 1541 && NILP (KVAR (current_kboard, >> >> Voverriding_terminal_local_map)) >> >> (gdb) xbacktrace >> >> "key-binding" (0xffffd5c8) >> >> "turn-on-undo-tree-mode" (0xffffd758) >> >> "global-undo-tree-mode-enable-in-buffers" (0xffffd948) >> >> "run-hooks" (0xffffd9e8) >> >> "run-mode-hooks" (0xffffdbc0) >> >> "minibuffer-inactive-mode" (0xffffdd40) >> >> (gdb) >> > >> > In my debug build of Emacs 27.0.60 I get an assertion violation while >> > dumping, which probably is already a sign of trouble. >> > >> > Daniel, any ideas? >> >> I haven't had a chance over the past few days to repro this problem, but >> I >> hope to do so this weeekend. The messages about the assertion failure >> *during* dumping do seem likely unrelated. The easiest way to debug this >> particular crash is with rr. Run the original test as "rr record emacs >> [args]", then run "rr replay". The latter will dump you in a GDB prompt. >> Type "cont" and run the replay of Emacs until you get to the SIGSEGV. >> Run >> "watch -l [expression]" to break out of execution whenever that value >> changes, then run "reverse-cont" to run the replay *backwards* until you >> get to the code that changed the variable with the bad value. >> >> > From unknown Sat Jun 14 18:56:05 2025 X-Loop: help-debbugs@gnu.org Subject: bug#38912: 27.0.60; PDumper meets segmentation fault when evil is loaded Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 09 Mar 2020 03:28:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 38912 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: "Daniel Colascione" Cc: niwtrx@icloud.com, 38912@debbugs.gnu.org Received: via spool by 38912-submit@debbugs.gnu.org id=B38912.158372442423936 (code B ref 38912); Mon, 09 Mar 2020 03:28:02 +0000 Received: (at 38912) by debbugs.gnu.org; 9 Mar 2020 03:27:04 +0000 Received: from localhost ([127.0.0.1]:49636 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jB94K-0006Dz-Kq for submit@debbugs.gnu.org; Sun, 08 Mar 2020 23:27:04 -0400 Received: from eggs.gnu.org ([209.51.188.92]:50219) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jB94I-0006DW-JF for 38912@debbugs.gnu.org; Sun, 08 Mar 2020 23:27:03 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:35655) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1jB94D-0004MI-19; Sun, 08 Mar 2020 23:26:57 -0400 Received: from [176.228.60.248] (port=3492 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1jB949-0007MT-6R; Sun, 08 Mar 2020 23:26:56 -0400 Date: Mon, 09 Mar 2020 05:26:50 +0200 Message-Id: <83eeu2b43p.fsf@gnu.org> From: Eli Zaretskii In-Reply-To: References: <333553AC-68DE-4F1C-9586-5A13248AD6DD@icloud.com> <83ftgvh96l.fsf@gnu.org> <83a771g2tc.fsf@gnu.org> <83zhcvuvc1.fsf@gnu.org> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Spam-Score: -0.7 (/) 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 (-) > Date: Sun, 8 Mar 2020 19:15:31 -0700 > From: "Daniel Colascione" > Cc: "Daniel Colascione" , > niwtrx@icloud.com, > 38912@debbugs.gnu.org > > Sorry, haven't had a chance to look at it yet. I've been treating it as > low-ish priority because pdumping outside loadup isn't supported yet. Is > there some reason to expedite this work? Not that I can see, no. I just wanted to be sure this isn't forgotten. Thanks. From unknown Sat Jun 14 18:56:05 2025 X-Loop: help-debbugs@gnu.org Subject: bug#38912: bug#32503: 26.1; Byte-compiled functions don't hash consistently Resent-From: Lars Ingebrigtsen Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 24 Jun 2021 16:31:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 38912 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Eli Zaretskii Cc: 32503@debbugs.gnu.org, niwtrx@icloud.com, Daniel Colascione , Adam Porter , 38912@debbugs.gnu.org Received: via spool by 38912-submit@debbugs.gnu.org id=B38912.162455224513709 (code B ref 38912); Thu, 24 Jun 2021 16:31:02 +0000 Received: (at 38912) by debbugs.gnu.org; 24 Jun 2021 16:30:45 +0000 Received: from localhost ([127.0.0.1]:43980 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lwSFY-0003Yl-QU for submit@debbugs.gnu.org; Thu, 24 Jun 2021 12:30:45 -0400 Received: from quimby.gnus.org ([95.216.78.240]:33968) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lwSFW-0003RX-Vd; Thu, 24 Jun 2021 12:30:43 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnus.org; s=20200322; h=Content-Type:MIME-Version:Message-ID:In-Reply-To:Date: References:Subject:Cc:To:From:Sender:Reply-To:Content-Transfer-Encoding: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=RX78u0heOTPS0Pebb3M9KRCZ81hS9UvGY9m5Okq9h88=; b=Nxs50OJ0VLG7b49bIWnZpY1AX8 xkrJCfZYCfTeG7Yv9Jpht46mMRDeKs8Ie/+La2B94lznahXis31dfes41K4SozPT84k+MNJDj2+j3 iYE9lUe0z1vmaHT87TVUQnSVSUixMerRVuiR16/MJnYI5QfsUeprwpxlNW4nweyquD2A=; Received: from cm-84.212.220.105.getinternet.no ([84.212.220.105] helo=elva) by quimby.gnus.org with esmtpsa (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1lwSFH-0002PD-BC; Thu, 24 Jun 2021 18:30:30 +0200 From: Lars Ingebrigtsen References: <333553AC-68DE-4F1C-9586-5A13248AD6DD@icloud.com> <83ftgvh96l.fsf@gnu.org> <83a771g2tc.fsf@gnu.org> <83zhcvuvc1.fsf@gnu.org> <83eeu2b43p.fsf@gnu.org> X-Now-Playing: Fingerprintz's _Methods of Dance (1)_: "The Beat Escape" Date: Thu, 24 Jun 2021 18:30:26 +0200 In-Reply-To: <83eeu2b43p.fsf@gnu.org> (Eli Zaretskii's message of "Mon, 09 Mar 2020 05:26:50 +0200") Message-ID: <87h7hngr8d.fsf_-_@gnus.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Report: Spam detection software, running on the system "quimby.gnus.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 @@CONTACT_ADDRESS@@ for details. Content preview: Eli Zaretskii writes: >> Sorry, haven't had a chance to look at it yet. I've been treating it as >> low-ish priority because pdumping outside loadup isn't supported yet. Is >> there some reason to expedite this work? > > N [...] Content analysis details: (-2.9 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-Spam-Score: -2.3 (--) 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 (---) Eli Zaretskii writes: >> Sorry, haven't had a chance to look at it yet. I've been treating it as >> low-ish priority because pdumping outside loadup isn't supported yet. Is >> there some reason to expedite this work? > > Not that I can see, no. I just wanted to be sure this isn't > forgotten. > > Thanks. This was a long thread, and I only skimmed it lightly. But I noticed that it was merged with this bug report: Adam Porter writes: > I noticed that byte-compiled functions don't hash consistently. Here's > an ECM from Noam Postavsky > : > > (let ((obj1 (byte-compile (lambda (x) x))) > (obj2 (byte-compile (lambda (x) x)))) > (list (equal obj1 obj2) > (eq obj1 obj2) > (= (sxhash obj1) > (sxhash obj2)))) > ;=> (t nil nil) And this test case no longer fails in Emacs 28 (but it fails in Emacs 27). So is there more to be done in these merged bug reports? -- (domestic pets only, the antidote for overdose, milk.) bloggy blog: http://lars.ingebrigtsen.no From unknown Sat Jun 14 18:56:05 2025 X-Loop: help-debbugs@gnu.org Subject: bug#38912: 27.0.60; PDumper meets segmentation fault when evil is loaded Resent-From: Lars Ingebrigtsen Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 28 Apr 2022 11:42:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 38912 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Eli Zaretskii Cc: 32503@debbugs.gnu.org, niwtrx@icloud.com, Daniel Colascione , Adam Porter , 38912@debbugs.gnu.org Received: via spool by 38912-submit@debbugs.gnu.org id=B38912.16511460796658 (code B ref 38912); Thu, 28 Apr 2022 11:42:02 +0000 Received: (at 38912) by debbugs.gnu.org; 28 Apr 2022 11:41:19 +0000 Received: from localhost ([127.0.0.1]:45628 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nk2WM-0001jI-MX for submit@debbugs.gnu.org; Thu, 28 Apr 2022 07:41:18 -0400 Received: from quimby.gnus.org ([95.216.78.240]:53778) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nk2WK-0001iz-FK; Thu, 28 Apr 2022 07:41:16 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnus.org; s=20200322; h=Content-Type:MIME-Version:Message-ID:In-Reply-To:Date: References:Subject:Cc:To:From:Sender:Reply-To:Content-Transfer-Encoding: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=SRBV3gJ5PGbVRRKBovBGSWJWnFHVyPaJ076HFgPFTg8=; b=o6Y/Nc9mVYx5ynhmDisb+5rziT ffZtuDtMILrHPZt5zebJtE+tfI1oHzWnD958VaAY/crdSgLaIJaiUaEKxJ8sWvUcUgwACPCXmzVHe oVvckrIRh6M2aGb2NfeSRzD9wXz2SKC1jsgOAkpz8wXXR8b47FyCbFdxcSopB19BQbBo=; Received: from [84.212.220.105] (helo=xo) by quimby.gnus.org with esmtpsa (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1nk2W6-0000I4-Os; Thu, 28 Apr 2022 13:41:05 +0200 From: Lars Ingebrigtsen References: <333553AC-68DE-4F1C-9586-5A13248AD6DD@icloud.com> <83ftgvh96l.fsf@gnu.org> <83a771g2tc.fsf@gnu.org> <83zhcvuvc1.fsf@gnu.org> <83eeu2b43p.fsf@gnu.org> <87h7hngr8d.fsf_-_@gnus.org> X-Now-Playing: Coldcut's _This Is Fascism (1)_: "This Is Fascism (Angry Ninja Mix)" Date: Thu, 28 Apr 2022 13:41:02 +0200 In-Reply-To: <87h7hngr8d.fsf_-_@gnus.org> (Lars Ingebrigtsen's message of "Thu, 24 Jun 2021 18:30:26 +0200") Message-ID: <87sfpxl9kh.fsf_-_@gnus.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Report: Spam detection software, running on the system "quimby.gnus.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 @@CONTACT_ADDRESS@@ for details. Content preview: Lars Ingebrigtsen writes: >> I noticed that byte-compiled functions don't hash consistently. Here's >> an ECM from Noam Postavsky >> : >> >> (let ((obj1 ( [...] Content analysis details: (-2.9 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-Spam-Score: -2.3 (--) 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 (---) Lars Ingebrigtsen writes: >> I noticed that byte-compiled functions don't hash consistently. Here's >> an ECM from Noam Postavsky >> : >> >> (let ((obj1 (byte-compile (lambda (x) x))) >> (obj2 (byte-compile (lambda (x) x)))) >> (list (equal obj1 obj2) >> (eq obj1 obj2) >> (= (sxhash obj1) >> (sxhash obj2)))) >> ;=> (t nil nil) > > And this test case no longer fails in Emacs 28 (but it fails in Emacs > 27). So is there more to be done in these merged bug reports? There wasn't any response in 43 weeks, so it seems like the issue has been fixed for Emacs 28, and I'm therefore closing it. If there are other problems in this area, I think it would be better to open a new bug report for those problems. -- (domestic pets only, the antidote for overdose, milk.) bloggy blog: http://lars.ingebrigtsen.no From debbugs-submit-bounces@debbugs.gnu.org Thu Apr 28 07:41:24 2022 Received: (at control) by debbugs.gnu.org; 28 Apr 2022 11:41:24 +0000 Received: from localhost ([127.0.0.1]:45633 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nk2WS-0001ji-78 for submit@debbugs.gnu.org; Thu, 28 Apr 2022 07:41:24 -0400 Received: from quimby.gnus.org ([95.216.78.240]:53790) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nk2WO-0001j3-CS for control@debbugs.gnu.org; Thu, 28 Apr 2022 07:41:20 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnus.org; s=20200322; h=Subject:From:To:Message-Id:Date:Sender:Reply-To:Cc: MIME-Version:Content-Type:Content-Transfer-Encoding:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:In-Reply-To:References:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=tEVSPmCbAH08vHrWPOPXsfRPSnLQA6jAyIdohLZPFPk=; b=croKYAVDrQZKk4EHSkS2+JyF1J VKBOMmZnXXqtoRWdWsl7AHHA32wVb8zFUYo/lqJWCJmV554uDTgrGqQne/QcdrB6+WStCBiz02Mnp NcRyp+RQhiOgsAIxo776aU5wcDvrTSjg/Vii/xXB5+Mbxn8/CW4BZWfg4GDhNXEUnBp8=; Received: from [84.212.220.105] (helo=xo) by quimby.gnus.org with esmtpsa (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1nk2WG-0000II-Uw for control@debbugs.gnu.org; Thu, 28 Apr 2022 13:41:14 +0200 Date: Thu, 28 Apr 2022 13:41:11 +0200 Message-Id: <87r15hl9k8.fsf@gnus.org> To: control@debbugs.gnu.org From: Lars Ingebrigtsen Subject: control message for bug #38912 X-Spam-Report: Spam detection software, running on the system "quimby.gnus.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 @@CONTACT_ADDRESS@@ for details. Content preview: close 38912 quit Content analysis details: (-2.9 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: control 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 (---) close 38912 quit