* bug#71744: 29.4; SIGSEGV during completion-at-point in lsp-mode with corfu and cape
@ 2024-06-23 21:16 Matthew Rothlisberger
2024-06-24 12:28 ` Eli Zaretskii
2024-08-14 13:22 ` Sigve Indregard via Bug reports for GNU Emacs, the Swiss army knife of text editors
0 siblings, 2 replies; 18+ messages in thread
From: Matthew Rothlisberger @ 2024-06-23 21:16 UTC (permalink / raw)
To: 71744
[-- Attachment #1: Type: text/plain, Size: 9026 bytes --]
Hello,
Since updating to 29.4, my Emacs has suffered segmentation faults when I
attempt my usual Rust programming workflow.
The crash occurs during live update of a Corfu completion window in a
buffer containing Rust code, with lsp-mode enabled and connected to
rust-analyzer.
When I first triggered the bug, quick inputs (like rolling a finger from
key to key) which changed the current completion list, would cause the
crash.
With my minimal configuration, the most effective reproduction is to
trigger completion on a pair of characters, for which different completions
appear if their order is swapped, then transpose them until the crash
occurs.
The crash seems to only happen when the cape-capf-buster function from Cape
is installed to refresh the completion candidates.
I did not succeed in reproducing this issue with the clangd LSP backend.
I know that this is a bug in Emacs because it occurs in 29.4 and not in
29.3, with no changes to any other piece of the system. A cursory check
indicates no issue on dev version 31.0.50.173746.
Thank you for reading. See below for specific information.
Matthew Rothlisberger
* Minimal system packages required:
emacs (29.4), rust-analyzer, rustup.
* Minimal Emacs configuration:
#+BEGIN_SRC emacs-lisp
(require 'package)
(add-to-list 'package-archives
'("melpa" . "https://melpa.org/packages/") t)
(package-initialize)
(unless package-archive-contents
(package-refresh-contents))
(require 'use-package-ensure)
(setq use-package-always-ensure t)
(use-package cape)
(use-package corfu
:custom
(corfu-auto t)
:init
(global-corfu-mode))
(setq lsp-rust-server 'rust-analyzer)
(use-package lsp-mode
:custom
(lsp-completion-provider :none)
:init
(defun my/lsp-mode-setup-completion ()
(setf (alist-get 'styles (alist-get 'lsp-capf
completion-category-defaults))
'(flex))
(setq-local completion-at-point-functions (list (cape-capf-buster
#'lsp-completion-at-point))) ;; <-- this line appears to make the difference
)
:hook
(lsp-completion-mode . my/lsp-mode-setup-completion)
:commands lsp)
#+END_SRC
* Minimal local file generation:
$ rustup install stable
$ cargo new testproj
* Minimal reproduction steps:
C-x C-f testproj/src/main.rs
M-x lsp
<RET>
<RET>
C-<
use std::at
(completion box should appear after entering the above)
C-t
... (hold C-t until segmentation fault; usually happens promptly)
* Output from coredumpctl gdb
(gdb) bt full
#0 0x00007a516d01fe44 in ?? () from /usr/lib/libc.so.6
No symbol table info available.
#1 0x00007a516cfc7a30 in raise () from /usr/lib/libc.so.6
No symbol table info available.
#2 0x0000588eed79a982 in ?? ()
No symbol table info available.
#3 0x0000588eed79b75a in ?? ()
No symbol table info available.
#4 0x0000588eeda4a545 in ?? ()
No symbol table info available.
#5 <signal handler called>
No symbol table info available.
#6 0x0000588eed99a22b in ?? ()
No symbol table info available.
#7 0x0000588eed8ef5f1 in ?? ()
No symbol table info available.
... (and so on for dozens of lines (this is the case even with debuginfo
loaded))
(gdb) xbacktrace
Undefined command: "xbacktrace". Try "help".
* Output from report-emacs-bug
In GNU Emacs 29.4 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.24.42,
cairo version 1.18.0)
Windowing system distributor 'The X.Org Foundation', version 11.0.12101013
System Description: Arch Linux
Configured using:
'configure --sysconfdir=/etc --prefix=/usr --libexecdir=/usr/lib
--with-tree-sitter --localstatedir=/var --with-cairo
--disable-build-details --with-harfbuzz --with-libsystemd
--with-modules --with-x-toolkit=gtk3 'CFLAGS=-march=x86-64
-mtune=generic -O2 -pipe -fno-plt -fexceptions -Wp,-D_FORTIFY_SOURCE=3
-Wformat -Werror=format-security -fstack-clash-protection
-fcf-protection -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -g
-ffile-prefix-map=/build/emacs/src=/usr/src/debug/emacs -flto=auto'
'LDFLAGS=-Wl,-O1 -Wl,--sort-common -Wl,--as-needed -Wl,-z,relro
-Wl,-z,now -Wl,-z,pack-relative-relocs -flto=auto''
Configured features:
ACL CAIRO DBUS FREETYPE GIF GLIB GMP GNUTLS GPM GSETTINGS HARFBUZZ JPEG
JSON LCMS2 LIBOTF LIBSYSTEMD LIBXML2 M17N_FLT MODULES NOTIFY INOTIFY
PDUMPER PNG RSVG SECCOMP SOUND SQLITE3 THREADS TIFF TOOLKIT_SCROLL_BARS
TREE_SITTER WEBP X11 XDBE XIM XINPUT2 XPM GTK3 ZLIB
Important settings:
value of $LANG: C.UTF-8
locale-coding-system: utf-8-unix
Major mode: Fundamental
Minor modes in effect:
flymake-mode: t
lsp-diagnostics-mode: t
lsp-headerline-breadcrumb-mode: t
lsp-modeline-workspace-status-mode: t
lsp-modeline-diagnostics-mode: t
lsp-modeline-code-actions-mode: t
lsp-lens-mode: t
lsp-completion-mode: t
lsp-managed-mode: t
lsp-mode: t
global-corfu-mode: t
corfu-mode: t
tooltip-mode: t
global-eldoc-mode: t
eldoc-mode: t
show-paren-mode: t
electric-indent-mode: t
mouse-wheel-mode: t
tool-bar-mode: t
menu-bar-mode: t
file-name-shadow-mode: t
global-font-lock-mode: t
font-lock-mode: t
blink-cursor-mode: t
line-number-mode: t
indent-tabs-mode: t
transient-mark-mode: t
auto-composition-mode: t
auto-encryption-mode: t
auto-compression-mode: t
Load-path shadows:
None found.
Features:
(shadow sort mail-extr emacsbug message yank-media dired dired-loaddefs
rfc822 mml mml-sec epa derived gnus-util mm-decode mm-bodies mm-encode
mail-parse rfc2231 mailabbrev gmm-utils mailheader sendmail rfc2047
rfc2045 ietf-drums mm-util mail-prsvr mail-utils time-date flymake-proc
flymake warnings lsp-diagnostics lsp-headerline lsp-icons lsp-modeline
lsp-lens view lsp-zig lsp-yang lsp-yaml lsp-xml lsp-wgsl lsp-volar
lsp-vimscript lsp-vhdl lsp-vetur lsp-html lsp-verilog lsp-vala lsp-v
lsp-typeprof lsp-ttcn3 lsp-trunk lsp-toml lsp-tilt lsp-tex lsp-terraform
lsp-svelte lsp-steep lsp-sqls lsp-sql lsp-sorbet lsp-solidity
lsp-solargraph lsp-semgrep lsp-rust lsp-ruff-lsp lsp-ruby-syntax-tree
lsp-ruby-lsp lsp-rubocop lsp-rf lsp-remark lsp-racket lsp-r lsp-qml
lsp-pylsp lsp-pyls lsp-pwsh lsp-purescript lsp-pls lsp-php
lsp-perlnavigator lsp-perl lsp-openscad lsp-ocaml lsp-nushell lsp-nix
lsp-nim lsp-nginx lsp-move lsp-mojo lsp-mint lsp-meson lsp-mdx
lsp-marksman lsp-markdown lsp-magik lsp-lua lsp-lisp lsp-kotlin lsp-json
lsp-jq lsp-javascript lsp-idris lsp-haxe lsp-hack lsp-groovy lsp-graphql
lsp-golangci-lint lsp-glsl lsp-gleam lsp-gdscript lsp-fsharp lsp-fortran
lsp-eslint lsp-erlang lsp-emmet lsp-elm lsp-elixir lsp-earthly
lsp-dockerfile lsp-dhall lsp-d lsp-cypher lsp-cucumber lsp-css
lsp-csharp gnutls lsp-crystal lsp-credo lsp-cobol lsp-cmake lsp-clojure
lsp-clangd dom lsp-bufls lsp-go lsp-completion lsp-beancount lsp-bash
lsp-awk lsp-autotools lsp-astro lsp-asm lsp-ansible lsp-angular lsp-ada
lsp-semantic-tokens lsp-actionscript lsp-mode lsp-protocol xref project
tree-widget wid-edit spinner pcase network-stream puny nsm markdown-mode
rx color thingatpt noutline outline icons lv inline imenu ht filenotify
f s ewoc epg rfc6068 epg-config dash compile text-property-search comint
ansi-osc ansi-color ring vc-git diff-mode easy-mmode vc-dispatcher corfu
cape compat cl-extra help-mode use-package-ensure use-package-core
finder-inf cape-autoloads corfu-autoloads compat-autoloads
lsp-mode-autoloads ht-autoloads f-autoloads info dash-autoloads
lv-autoloads markdown-mode-autoloads s-autoloads spinner-autoloads
package browse-url url url-proxy url-privacy url-expand url-methods
url-history url-cookie generate-lisp-file url-domsuf url-util mailcap
url-handlers url-parse auth-source cl-seq eieio eieio-core cl-macs
password-cache json subr-x map byte-opt gv bytecomp byte-compile
url-vars cl-loaddefs cl-lib rmc iso-transl tooltip cconv eldoc paren
electric uniquify ediff-hook vc-hooks lisp-float-type elisp-mode mwheel
term/x-win x-win term/common-win x-dnd tool-bar dnd fontset image
regexp-opt fringe tabulated-list replace newcomment text-mode lisp-mode
prog-mode register page tab-bar menu-bar rfn-eshadow isearch easymenu
timer select scroll-bar mouse jit-lock font-lock syntax font-core
term/tty-colors frame minibuffer nadvice seq simple cl-generic
indonesian philippine cham georgian utf-8-lang misc-lang vietnamese
tibetan thai tai-viet lao korean japanese eucjp-ms cp51932 hebrew greek
romanian slovak czech european ethiopic indian cyrillic chinese
composite emoji-zwj charscript charprop case-table epa-hook
jka-cmpr-hook help abbrev obarray oclosure cl-preloaded button loaddefs
theme-loaddefs faces cus-face macroexp files window text-properties
overlay sha1 md5 base64 format env code-pages mule custom widget keymap
hashtable-print-readable backquote threads dbusbind inotify lcms2
dynamic-setting system-font-setting font-render-setting cairo
move-toolbar gtk x-toolkit xinput2 x multi-tty make-network-process
emacs)
Memory information:
((conses 16 385317 19912)
(symbols 48 28244 0)
(strings 32 141070 3514)
(string-bytes 1 3381789)
(vectors 16 56432)
(vector-slots 8 876785 30432)
(floats 8 186 41)
(intervals 56 436 0)
(buffers 984 15))
[-- Attachment #2: Type: text/html, Size: 10447 bytes --]
^ permalink raw reply [flat|nested] 18+ messages in thread* bug#71744: 29.4; SIGSEGV during completion-at-point in lsp-mode with corfu and cape 2024-06-23 21:16 bug#71744: 29.4; SIGSEGV during completion-at-point in lsp-mode with corfu and cape Matthew Rothlisberger @ 2024-06-24 12:28 ` Eli Zaretskii 2024-06-26 23:27 ` Matthew Rothlisberger 2024-08-14 13:22 ` Sigve Indregard via Bug reports for GNU Emacs, the Swiss army knife of text editors 1 sibling, 1 reply; 18+ messages in thread From: Eli Zaretskii @ 2024-06-24 12:28 UTC (permalink / raw) To: Matthew Rothlisberger; +Cc: 71744 > From: Matthew Rothlisberger <mattjrothlis@gmail.com> > Date: Sun, 23 Jun 2024 17:16:57 -0400 > > Since updating to 29.4, my Emacs has suffered segmentation faults when I attempt my usual Rust > programming workflow. > > The crash occurs during live update of a Corfu completion window in a buffer containing Rust code, with > lsp-mode enabled and connected to rust-analyzer. > > When I first triggered the bug, quick inputs (like rolling a finger from key to key) which changed the current > completion list, would cause the crash. > > With my minimal configuration, the most effective reproduction is to trigger completion on a pair of characters, > for which different completions appear if their order is swapped, then transpose them until the crash occurs. > > The crash seems to only happen when the cape-capf-buster function from Cape is installed to refresh the > completion candidates. > > I did not succeed in reproducing this issue with the clangd LSP backend. > > I know that this is a bug in Emacs because it occurs in 29.4 and not in 29.3, with no changes to any other > piece of the system. A cursory check indicates no issue on dev version 31.0.50.173746. > > Thank you for reading. See below for specific information. Thanks, but we need a full GDB backtrace in order to investigate this, since your use case involves a lot of moving parts that are not part of Emacs. > * Output from coredumpctl gdb > (gdb) bt full > #0 0x00007a516d01fe44 in ?? () from /usr/lib/libc.so.6 > No symbol table info available. > #1 0x00007a516cfc7a30 in raise () from /usr/lib/libc.so.6 > No symbol table info available. > #2 0x0000588eed79a982 in ?? () > No symbol table info available. > #3 0x0000588eed79b75a in ?? () > No symbol table info available. > #4 0x0000588eeda4a545 in ?? () > No symbol table info available. > #5 <signal handler called> > No symbol table info available. > #6 0x0000588eed99a22b in ?? () > No symbol table info available. > #7 0x0000588eed8ef5f1 in ?? () > No symbol table info available. > ... (and so on for dozens of lines (this is the case even with debuginfo loaded)) How many dozens? Could it indicate some kind of infinite recursion (followed by C stack overflow)? Anyway, please run Emacs under GDB, and show the backtrace produced by GDB. I'm guessing your Emacs binary is stripped of debug symbols (thus the ?? question marks instead of function names), in which case please rebuild Emacs with debug info and don't strip it. > (gdb) xbacktrace > Undefined command: "xbacktrace". Try "help". "xbacktrace" is defined by src/.gdbinit in the Emacs source tree. If you don't have the sources, you can download them from the nearest GNU FTP site. Thanks. ^ permalink raw reply [flat|nested] 18+ messages in thread
* bug#71744: 29.4; SIGSEGV during completion-at-point in lsp-mode with corfu and cape 2024-06-24 12:28 ` Eli Zaretskii @ 2024-06-26 23:27 ` Matthew Rothlisberger 2024-06-27 10:05 ` Eli Zaretskii 0 siblings, 1 reply; 18+ messages in thread From: Matthew Rothlisberger @ 2024-06-26 23:27 UTC (permalink / raw) To: Eli Zaretskii; +Cc: 71744 [-- Attachment #1: Type: text/plain, Size: 48518 bytes --] Thanks for your reply. > On Mon, Jun 24, 2024 at 08:28 Eli Zaretskii <eliz@gnu.org> wrote: > Thanks, but we need a full GDB backtrace in order to investigate this, since your use case involves a lot of moving parts that are not part of Emacs. Here's GDB output after triggering the crash: Thread 1 "emacs" received signal SIGSEGV, Segmentation fault. Fget (symbol=XIL(0x555555f430d0), propname=XIL(0x6a20)) at /usr/src/debug/emacs/emacs-29.4/src/lisp.h:1152 1152 return p; (gdb) bt full #0 Fget (symbol=XIL(0x555555f430d0), propname=XIL(0x6a20)) at /usr/src/debug/emacs/emacs-29.4/src/lisp.h:1152 propval = <optimized out> propval = <optimized out> #1 Fget (symbol=XIL(0x555555f430d0), propname=XIL(0x6a20)) at /usr/src/debug/emacs/emacs-29.4/src/fns.c:2516 propval = <optimized out> #2 0x0000555555727621 in parse_modifiers (symbol=XIL(0x555555f430d0)) at /usr/src/debug/emacs/emacs-29.4/src/keyboard.c:6897 elements = <optimized out> elements = <optimized out> end = <optimized out> modifiers = <optimized out> unmodified = <optimized out> mask = <optimized out> #3 parse_modifiers (symbol=XIL(0x555555f430d0)) at /usr/src/debug/emacs/emacs-29.4/src/keyboard.c:6888 elements = <optimized out> end = <optimized out> modifiers = <optimized out> unmodified = <optimized out> mask = <optimized out> #4 0x00005555557377b8 in reorder_modifiers (symbol=<optimized out>) at /usr/src/debug/emacs/emacs-29.4/src/keyboard.c:7028 parsed = <optimized out> parsed = <optimized out> #5 access_keymap_1 (map=XIL(0x7ffff23971d3), idx=<optimized out>, t_ok=false, noinherit=false, autoload=true) at /usr/src/debug/emacs/emacs-29.4/src/keymap.c:342 No locals. #6 0x000055555572ce9b in access_keymap (noinherit=false, autoload=true, map=<optimized out>, idx=<optimized out>, t_ok=false) at /usr/src/debug/emacs/emacs-29.4/src/keymap.c:496 val = <optimized out> val = <optimized out> #7 read_char (commandflag=0, map=XIL(0), prev_event=XIL(0), used_mouse_menu=0x0, end_time=0x7fffffffd7c0) at /usr/src/debug/emacs/emacs-29.4/src/keyboard.c:3018 c = <optimized out> local_getcjmp = {{ __jmpbuf = {93825000565504, 4667065109654990781, 1, 4611686019484352512, 2, 140737238796840, 4667065109726293949, 1554282726522023869}, __mask_was_saved = 0, __saved_mask = { __val = {1, 93825000490048, 93825000490048, 2, 93825000490064, 140737488344640, 140737315869326, 140737488344608, 17179869184, 93825015026096, 93825002289856, 0, 140737334369465, 93825000490048, 93825002294160, 1} } }} save_jump = {{ __jmpbuf = {140737488344256, 93825042270568, 65, 93824995310266, 0, 1, 140737488344304, -2652607782311200768}, __mask_was_saved = 1478277908, __saved_mask = { __val = {1, 93825015026096, 140737488344512, 2, 140737488344560, 140737488344496, 140737318847622, 1, 140737318848059, 17910663985227853824, 93211218036, 140737238797520, 93825039174099, 140737488344400, 93824994824941, 1} } }} tem = <optimized out> save = XIL(0x17b9d60) previous_echo_area_message = XIL(0) also_record = XIL(0) reread = false recorded = false polling_stopped_here = false orig_kboard = 0x555555f430d0 retry = <optimized out> jmpcount = <optimized out> #8 0x00005555557f7c92 in read_filtered_event (no_switch_frame=false, ascii_required=false, error_nonascii=false, input_method=<optimized out>, seconds=XIL(0x555558272a9f)) at /usr/src/debug/emacs/emacs-29.4/src/lread.c:702 val = <optimized out> delayed_switch_frame = <optimized out> end_time = { tv_sec = 1719443489, tv_nsec = 949531303 } retry = <optimized out> #9 0x0000555555817c4c in exec_byte_code (fun=XIL(0), args_template=1, nargs=3, args=0x7ffff1200a28) at /usr/src/debug/emacs/emacs-29.4/src/bytecode.c:809 call_nargs = 3 call_fun = <optimized out> count1 = <optimized out> template = <optimized out> val = XIL(0xaaaaabc77570) call_args = 0x7ffff1200a28 original_fun = <optimized out> bytecode = <optimized out> op = <optimized out> type = (unknown: 0x6a20) targets = <optimized out> quitcounter = <optimized out> bc = <optimized out> top = <optimized out> pc = <optimized out> bytestr = XIL(0x6a20) vector = <optimized out> maxdepth = <optimized out> const_length = <optimized out> bytestr_length = <optimized out> vectorp = <optimized out> max_stack = <optimized out> frame_base = <optimized out> fp = 0xaaaaabc77570 bytestr_data = <optimized out> rest = <optimized out> mandatory = 5 nonrest = 10 pushedargs = 0 result = <optimized out> targets = {0x55555581c531 <exec_byte_code+19777>, 0x5555558180bb <exec_byte_code+2251>, 0x5555558180cd <exec_byte_code+2269>, 0x5555558180c4 <exec_byte_code+2260>, 0x555555817a29 <exec_byte_code+569>, 0x555555817a2d <exec_byte_code+573>, 0x55555581a4cd <exec_byte_code+11485>, 0x555555818075 <exec_byte_code+2181>, 0x555555819e5d <exec_byte_code+9837>, 0x555555819e54 <exec_byte_code+9828>, 0x555555819e4b <exec_byte_code+9819>, 0x555555819e30 <exec_byte_code+9792>, 0x555555817d05 <exec_byte_code+1301>, 0x555555817d10 <exec_byte_code+1312>, 0x555555817e1a <exec_byte_code+1578>, 0x555555819e39 <exec_byte_code+9801>, 0x55555581a15c <exec_byte_code+10604>, 0x555555819e8a <exec_byte_code+9882>, 0x555555819e81 <exec_byte_code+9873>, 0x555555819e78 <exec_byte_code+9864>, 0x555555817997 <exec_byte_code+423>, 0x5555558179a0 <exec_byte_code+432>, 0x55555581a06e <exec_byte_code+10366>, 0x55555581a080 <exec_byte_code+10384>, 0x55555581a053 <exec_byte_code+10339>, 0x55555581a04a <exec_byte_code+10330>, 0x555555817e47 <exec_byte_code+1623>, 0x555555817e3e <exec_byte_code+1614>, 0x555555817ca5 <exec_byte_code+1205>, 0x555555817cb0 <exec_byte_code+1216>, 0x555555819ffc <exec_byte_code+10252>, 0x55555581a05c <exec_byte_code+10348>, 0x555555819e27 <exec_byte_code+9783>, 0x555555819e1e <exec_byte_code+9774>, 0x55555581a126 <exec_byte_code+10550>, 0x55555581a11d <exec_byte_code+10541>, 0x555555817ac3 <exec_byte_code+723>, 0x555555817ad0 <exec_byte_code+736>, 0x555555817e2c <exec_byte_code+1596>, 0x55555581a092 <exec_byte_code+10402>, 0x55555581a141 <exec_byte_code+10577>, 0x55555581a138 <exec_byte_code+10568>, 0x55555581a12f <exec_byte_code+10559>, 0x555555817e50 <exec_byte_code+1632>, 0x555555817a6f <exec_byte_code+639>, 0x555555817a78 <exec_byte_code+648>, 0x555555819e66 <exec_byte_code+9846>, 0x55555581a14a <exec_byte_code+10586>, 0x55555581a6ca <exec_byte_code+11994>, 0x55555581a701 <exec_byte_code+12049>, 0x55555581a787 <exec_byte_code+12183>, 0x55555581c535 <exec_byte_code+19781>, 0x55555581c535 <exec_byte_code+19781>, 0x55555581c535 <exec_byte_code+19781>, 0x55555581c535 <exec_byte_code+19781>, 0x55555581c535 <exec_byte_code+19781>, 0x55555581a1f3 <exec_byte_code+10755>, 0x5555558199b2 <exec_byte_code+8642>, 0x555555819965 <exec_byte_code+8565>, 0x555555819918 <exec_byte_code+8488>, 0x555555819be2 <exec_byte_code+9202>, 0x555555819edc <exec_byte_code+9964>, 0x555555819e93 <exec_byte_code+9891>, 0x555555819b61 <exec_byte_code+9073>, 0x555555819f77 <exec_byte_code+10119>, 0x55555581a165 <exec_byte_code+10613>, 0x555555819b99 <exec_byte_code+9129>, 0x555555819cc5 <exec_byte_code+9429>, 0x5555558197f6 <exec_byte_code+8198>, 0x555555819c67 <exec_byte_code+9335>, 0x555555819cfd <exec_byte_code+9485>, 0x555555819de8 <exec_byte_code+9720>, 0x555555819d71 <exec_byte_code+9601>, 0x5555558192f8 <exec_byte_code+6920>, 0x55555581957b <exec_byte_code+7563>, 0x555555819c31 <exec_byte_code+9281>, 0x55555581952b <exec_byte_code+7483>, 0x5555558194e2 <exec_byte_code+7410>, 0x555555819499 <exec_byte_code+7337>, 0x55555581944c <exec_byte_code+7260>, 0x555555819409 <exec_byte_code+7193>, 0x5555558193c6 <exec_byte_code+7126>, 0x5555558196e3 <exec_byte_code+7923>, 0x55555581967e <exec_byte_code+7822>, 0x555555819619 <exec_byte_code+7721>, 0x5555558195be <exec_byte_code+7630>, 0x555555819798 <exec_byte_code+8104>, 0x55555581984c <exec_byte_code+8284>, 0x55555581929a <exec_byte_code+6826>, 0x55555581923c <exec_byte_code+6732>, 0x555555819726 <exec_byte_code+7990>, 0x555555819167 <exec_byte_code+6519>, 0x5555558191cd <exec_byte_code+6621>, 0x555555819067 <exec_byte_code+6263>, 0x5555558190e7 <exec_byte_code+6391>, 0x555555818ff4 <exec_byte_code+6148>, 0x555555818f3c <exec_byte_code+5964>, 0x555555817d99 <exec_byte_code+1449>, 0x555555818e59 <exec_byte_code+5737>, 0x555555818e0a <exec_byte_code+5658>, 0x555555818d53 <exec_byte_code+5475>, 0x555555818d00 <exec_byte_code+5392>, 0x555555818cca <exec_byte_code+5338>, 0x555555818c8f <exec_byte_code+5279>, 0x555555818f01 <exec_byte_code+5905>, 0x555555818c4c <exec_byte_code+5212>, 0x555555818c14 <exec_byte_code+5156>, 0x55555581c535 <exec_byte_code+19781>, 0x555555818bd9 <exec_byte_code+5097>, 0x555555818b7e <exec_byte_code+5006>, 0x555555818b43 <exec_byte_code+4947>, 0x555555818ae8 <exec_byte_code+4856>, 0x555555818a6a <exec_byte_code+4730>, 0x555555818ab2 <exec_byte_code+4802>, 0x555555817d9d <exec_byte_code+1453>, 0x55555581c535 <exec_byte_code+19781>, 0x555555818a18 <exec_byte_code+4648>, 0x5555558189d9 <exec_byte_code+4585>, 0x5555558189a3 <exec_byte_code+4531>, 0x555555818955 <exec_byte_code+4453>, 0x555555818878 <exec_byte_code+4232>, 0x555555818842 <exec_byte_code+4178>, 0x55555581880c <exec_byte_code+4124>, 0x55555581890c <exec_byte_code+4380>, 0x555555818781 <exec_byte_code+3985>, 0x555555818738 <exec_byte_code+3912>, 0x5555558186fd <exec_byte_code+3853>, 0x5555558186c7 <exec_byte_code+3799>, 0x55555581c535 <exec_byte_code+19781>, 0x55555581a53c <exec_byte_code+11596>, 0x55555581a0a4 <exec_byte_code+10420>, 0x555555819fb7 <exec_byte_code+10183>, 0x555555817f90 <exec_byte_code+1952>, 0x555555817f4e <exec_byte_code+1886>, 0x555555817e59 <exec_byte_code+1641>, 0x555555817e9b <exec_byte_code+1707>, 0x55555581a582 <exec_byte_code+11666>, 0x55555581a00e <exec_byte_code+10270>, 0x55555581a513 <exec_byte_code+11555>, 0x55555581a5fe <exec_byte_code+11790>, 0x55555581a885 <exec_byte_code+12437>, 0x55555581a5ae <exec_byte_code+11710>, 0x55555581a7e6 <exec_byte_code+12278>, 0x55555581a799 <exec_byte_code+12201>, 0x55555581a269 <exec_byte_code+10873>, 0x555555819a2e <exec_byte_code+8766>, 0x55555581c535 <exec_byte_code+19781>, 0x555555818678 <exec_byte_code+3720>, 0x55555581863d <exec_byte_code+3661>, 0x5555558185cd <exec_byte_code+3549>, 0x555555818605 <exec_byte_code+3605>, 0x555555818592 <exec_byte_code+3490>, 0x555555818549 <exec_byte_code+3417>, 0x555555818500 <exec_byte_code+3344>, 0x5555558184a5 <exec_byte_code+3253>, 0x55555581845c <exec_byte_code+3180>, 0x5555558183ee <exec_byte_code+3070>, 0x5555558182d6 <exec_byte_code+2790>, 0x5555558188c3 <exec_byte_code+4307>, 0x5555558182a0 <exec_byte_code+2736>, 0x555555818232 <exec_byte_code+2626>, 0x5555558181c4 <exec_byte_code+2516>, 0x555555818365 <exec_byte_code+2933>, 0x55555581831f <exec_byte_code+2863>, 0x5555558183ab <exec_byte_code+3003>, 0x555555818f8f <exec_byte_code+6047>, 0x555555818e8f <exec_byte_code+5791>, 0x5555558180d6 <exec_byte_code+2278>, 0x55555581814e <exec_byte_code+2398>, 0x55555581c535 <exec_byte_code+19781>, 0x55555581c535 <exec_byte_code+19781>, 0x55555581c535 <exec_byte_code+19781>, 0x55555581c535 <exec_byte_code+19781>, 0x55555581c535 <exec_byte_code+19781>, 0x55555581c535 <exec_byte_code+19781>, 0x5555558198aa <exec_byte_code+8378>, 0x555555819376 <exec_byte_code+7046>, 0x555555818da6 <exec_byte_code+5558>, 0x55555581a1a5 <exec_byte_code+10677>, 0x555555818027 <exec_byte_code+2103>, 0x55555581c535 <exec_byte_code+19781>, 0x55555581c535 <exec_byte_code+19781>, 0x555555817fd5 <exec_byte_code+2021>, 0x55555581a464 <exec_byte_code+11380>, 0x55555581c535 <exec_byte_code+19781>, 0x55555581c535 <exec_byte_code+19781>, 0x55555581c535 <exec_byte_code+19781>, 0x55555581c535 <exec_byte_code+19781>, 0x55555581c535 <exec_byte_code+19781>, 0x55555581c535 <exec_byte_code+19781>, 0x55555581c535 <exec_byte_code+19781>, 0x55555581c535 <exec_byte_code+19781>, 0x55555581a41f <exec_byte_code+11311> <repeats 64 times>} #10 0x00005555557cd2ed in Ffuncall (nargs=4, args=0x7fffffffda10) at /usr/src/debug/emacs/emacs-29.4/src/eval.c:2999 count = <optimized out> val = <optimized out> #11 0x00005555557623c2 in call3 (fn=XIL(0x5555582280b5), arg1=XIL(0x7ffff239f304), arg2=XIL(0), arg3=XIL(0x30)) at /usr/src/debug/emacs/emacs-29.4/src/lisp.h:3262 No locals. #12 Fall_completions (string=XIL(0x7ffff239f304), collection=XIL(0x5555582280b5), predicate=XIL(0), hide_spaces=XIL(0)) at /usr/src/debug/emacs/emacs-29.4/src/minibuf.c:1869 tail = <optimized out> elt = <optimized out> eltstring = <optimized out> allmatches = <optimized out> type = 0 idx = 0 obsize = 0 bucket = <optimized out> tem = <optimized out> zero = <optimized out> #13 0x0000555555817c4c in exec_byte_code (fun=XIL(0), args_template=1, nargs=3, args=0x7ffff12006f8) at /usr/src/debug/emacs/emacs-29.4/src/bytecode.c:809 call_nargs = 3 call_fun = <optimized out> count1 = <optimized out> template = <optimized out> val = XIL(0xaaaaabc77570) call_args = 0x7ffff12006f8 original_fun = <optimized out> bytecode = <optimized out> op = <optimized out> type = (unknown: 0x6a20) targets = <optimized out> quitcounter = <optimized out> bc = <optimized out> top = <optimized out> pc = <optimized out> bytestr = XIL(0x6a20) vector = <optimized out> maxdepth = <optimized out> const_length = <optimized out> bytestr_length = <optimized out> vectorp = <optimized out> max_stack = <optimized out> frame_base = <optimized out> fp = 0xaaaaabc77570 bytestr_data = <optimized out> rest = <optimized out> mandatory = 5 nonrest = 7 pushedargs = 0 result = <optimized out> targets = {0x55555581c531 <exec_byte_code+19777>, 0x5555558180bb <exec_byte_code+2251>, 0x5555558180cd <exec_byte_code+2269>, 0x5555558180c4 <exec_byte_code+2260>, 0x555555817a29 <exec_byte_code+569>, 0x555555817a2d <exec_byte_code+573>, 0x55555581a4cd <exec_byte_code+11485>, 0x555555818075 <exec_byte_code+2181>, 0x555555819e5d <exec_byte_code+9837>, 0x555555819e54 <exec_byte_code+9828>, 0x555555819e4b <exec_byte_code+9819>, 0x555555819e30 <exec_byte_code+9792>, 0x555555817d05 <exec_byte_code+1301>, 0x555555817d10 <exec_byte_code+1312>, 0x555555817e1a <exec_byte_code+1578>, 0x555555819e39 <exec_byte_code+9801>, 0x55555581a15c <exec_byte_code+10604>, 0x555555819e8a <exec_byte_code+9882>, 0x555555819e81 <exec_byte_code+9873>, 0x555555819e78 <exec_byte_code+9864>, 0x555555817997 <exec_byte_code+423>, 0x5555558179a0 <exec_byte_code+432>, 0x55555581a06e <exec_byte_code+10366>, 0x55555581a080 <exec_byte_code+10384>, 0x55555581a053 <exec_byte_code+10339>, 0x55555581a04a <exec_byte_code+10330>, 0x555555817e47 <exec_byte_code+1623>, 0x555555817e3e <exec_byte_code+1614>, 0x555555817ca5 <exec_byte_code+1205>, 0x555555817cb0 <exec_byte_code+1216>, 0x555555819ffc <exec_byte_code+10252>, 0x55555581a05c <exec_byte_code+10348>, 0x555555819e27 <exec_byte_code+9783>, 0x555555819e1e <exec_byte_code+9774>, 0x55555581a126 <exec_byte_code+10550>, 0x55555581a11d <exec_byte_code+10541>, 0x555555817ac3 <exec_byte_code+723>, 0x555555817ad0 <exec_byte_code+736>, 0x555555817e2c <exec_byte_code+1596>, 0x55555581a092 <exec_byte_code+10402>, 0x55555581a141 <exec_byte_code+10577>, 0x55555581a138 <exec_byte_code+10568>, 0x55555581a12f <exec_byte_code+10559>, 0x555555817e50 <exec_byte_code+1632>, 0x555555817a6f <exec_byte_code+639>, 0x555555817a78 <exec_byte_code+648>, 0x555555819e66 <exec_byte_code+9846>, 0x55555581a14a <exec_byte_code+10586>, 0x55555581a6ca <exec_byte_code+11994>, 0x55555581a701 <exec_byte_code+12049>, 0x55555581a787 <exec_byte_code+12183>, 0x55555581c535 <exec_byte_code+19781>, 0x55555581c535 <exec_byte_code+19781>, 0x55555581c535 <exec_byte_code+19781>, 0x55555581c535 <exec_byte_code+19781>, 0x55555581c535 <exec_byte_code+19781>, 0x55555581a1f3 <exec_byte_code+10755>, 0x5555558199b2 <exec_byte_code+8642>, 0x555555819965 <exec_byte_code+8565>, 0x555555819918 <exec_byte_code+8488>, 0x555555819be2 <exec_byte_code+9202>, 0x555555819edc <exec_byte_code+9964>, 0x555555819e93 <exec_byte_code+9891>, 0x555555819b61 <exec_byte_code+9073>, 0x555555819f77 <exec_byte_code+10119>, 0x55555581a165 <exec_byte_code+10613>, 0x555555819b99 <exec_byte_code+9129>, 0x555555819cc5 <exec_byte_code+9429>, 0x5555558197f6 <exec_byte_code+8198>, 0x555555819c67 <exec_byte_code+9335>, 0x555555819cfd <exec_byte_code+9485>, 0x555555819de8 <exec_byte_code+9720>, 0x555555819d71 <exec_byte_code+9601>, 0x5555558192f8 <exec_byte_code+6920>, 0x55555581957b <exec_byte_code+7563>, 0x555555819c31 <exec_byte_code+9281>, 0x55555581952b <exec_byte_code+7483>, 0x5555558194e2 <exec_byte_code+7410>, 0x555555819499 <exec_byte_code+7337>, 0x55555581944c <exec_byte_code+7260>, 0x555555819409 <exec_byte_code+7193>, 0x5555558193c6 <exec_byte_code+7126>, 0x5555558196e3 <exec_byte_code+7923>, 0x55555581967e <exec_byte_code+7822>, 0x555555819619 <exec_byte_code+7721>, 0x5555558195be <exec_byte_code+7630>, 0x555555819798 <exec_byte_code+8104>, 0x55555581984c <exec_byte_code+8284>, 0x55555581929a <exec_byte_code+6826>, 0x55555581923c <exec_byte_code+6732>, 0x555555819726 <exec_byte_code+7990>, 0x555555819167 <exec_byte_code+6519>, 0x5555558191cd <exec_byte_code+6621>, 0x555555819067 <exec_byte_code+6263>, 0x5555558190e7 <exec_byte_code+6391>, 0x555555818ff4 <exec_byte_code+6148>, 0x555555818f3c <exec_byte_code+5964>, 0x555555817d99 <exec_byte_code+1449>, 0x555555818e59 <exec_byte_code+5737>, 0x555555818e0a <exec_byte_code+5658>, 0x555555818d53 <exec_byte_code+5475>, 0x555555818d00 <exec_byte_code+5392>, 0x555555818cca <exec_byte_code+5338>, 0x555555818c8f <exec_byte_code+5279>, 0x555555818f01 <exec_byte_code+5905>, 0x555555818c4c <exec_byte_code+5212>, 0x555555818c14 <exec_byte_code+5156>, 0x55555581c535 <exec_byte_code+19781>, 0x555555818bd9 <exec_byte_code+5097>, 0x555555818b7e <exec_byte_code+5006>, 0x555555818b43 <exec_byte_code+4947>, 0x555555818ae8 <exec_byte_code+4856>, 0x555555818a6a <exec_byte_code+4730>, 0x555555818ab2 <exec_byte_code+4802>, 0x555555817d9d <exec_byte_code+1453>, 0x55555581c535 <exec_byte_code+19781>, 0x555555818a18 <exec_byte_code+4648>, 0x5555558189d9 <exec_byte_code+4585>, 0x5555558189a3 <exec_byte_code+4531>, 0x555555818955 <exec_byte_code+4453>, 0x555555818878 <exec_byte_code+4232>, 0x555555818842 <exec_byte_code+4178>, 0x55555581880c <exec_byte_code+4124>, 0x55555581890c <exec_byte_code+4380>, 0x555555818781 <exec_byte_code+3985>, 0x555555818738 <exec_byte_code+3912>, 0x5555558186fd <exec_byte_code+3853>, 0x5555558186c7 <exec_byte_code+3799>, 0x55555581c535 <exec_byte_code+19781>, 0x55555581a53c <exec_byte_code+11596>, 0x55555581a0a4 <exec_byte_code+10420>, 0x555555819fb7 <exec_byte_code+10183>, 0x555555817f90 <exec_byte_code+1952>, 0x555555817f4e <exec_byte_code+1886>, 0x555555817e59 <exec_byte_code+1641>, 0x555555817e9b <exec_byte_code+1707>, 0x55555581a582 <exec_byte_code+11666>, 0x55555581a00e <exec_byte_code+10270>, 0x55555581a513 <exec_byte_code+11555>, 0x55555581a5fe <exec_byte_code+11790>, 0x55555581a885 <exec_byte_code+12437>, 0x55555581a5ae <exec_byte_code+11710>, 0x55555581a7e6 <exec_byte_code+12278>, 0x55555581a799 <exec_byte_code+12201>, 0x55555581a269 <exec_byte_code+10873>, 0x555555819a2e <exec_byte_code+8766>, 0x55555581c535 <exec_byte_code+19781>, 0x555555818678 <exec_byte_code+3720>, 0x55555581863d <exec_byte_code+3661>, 0x5555558185cd <exec_byte_code+3549>, 0x555555818605 <exec_byte_code+3605>, 0x555555818592 <exec_byte_code+3490>, 0x555555818549 <exec_byte_code+3417>, 0x555555818500 <exec_byte_code+3344>, 0x5555558184a5 <exec_byte_code+3253>, 0x55555581845c <exec_byte_code+3180>, 0x5555558183ee <exec_byte_code+3070>, 0x5555558182d6 <exec_byte_code+2790>, 0x5555558188c3 <exec_byte_code+4307>, 0x5555558182a0 <exec_byte_code+2736>, 0x555555818232 <exec_byte_code+2626>, 0x5555558181c4 <exec_byte_code+2516>, 0x555555818365 <exec_byte_code+2933>, 0x55555581831f <exec_byte_code+2863>, 0x5555558183ab <exec_byte_code+3003>, 0x555555818f8f <exec_byte_code+6047>, 0x555555818e8f <exec_byte_code+5791>, 0x5555558180d6 <exec_byte_code+2278>, 0x55555581814e <exec_byte_code+2398>, 0x55555581c535 <exec_byte_code+19781>, 0x55555581c535 <exec_byte_code+19781>, 0x55555581c535 <exec_byte_code+19781>, 0x55555581c535 <exec_byte_code+19781>, 0x55555581c535 <exec_byte_code+19781>, 0x55555581c535 <exec_byte_code+19781>, 0x5555558198aa <exec_byte_code+8378>, 0x555555819376 <exec_byte_code+7046>, 0x555555818da6 <exec_byte_code+5558>, 0x55555581a1a5 <exec_byte_code+10677>, 0x555555818027 <exec_byte_code+2103>, 0x55555581c535 <exec_byte_code+19781>, 0x55555581c535 <exec_byte_code+19781>, 0x555555817fd5 <exec_byte_code+2021>, 0x55555581a464 <exec_byte_code+11380>, 0x55555581c535 <exec_byte_code+19781>, 0x55555581c535 <exec_byte_code+19781>, 0x55555581c535 <exec_byte_code+19781>, 0x55555581c535 <exec_byte_code+19781>, 0x55555581c535 <exec_byte_code+19781>, 0x55555581c535 <exec_byte_code+19781>, 0x55555581c535 <exec_byte_code+19781>, 0x55555581c535 <exec_byte_code+19781>, 0x55555581a41f <exec_byte_code+11311> <repeats 64 times>} #14 0x00005555557cd2ed in Ffuncall (nargs=nargs@entry=5, args=0x7fffffffdc30) at /usr/src/debug/emacs/emacs-29.4/src/eval.c:2999 count = <optimized out> val = <optimized out> #15 0x00005555557cdbc0 in Fapply (nargs=2, args=0x7ffff1200520) at /usr/src/debug/emacs/emacs-29.4/src/eval.c:2670 i = <optimized out> funcall_nargs = 5 funcall_args = <optimized out> spread_arg = XIL(0) fun = <optimized out> sa_avail = <optimized out> sa_count = <optimized out> numargs = <optimized out> retval = <optimized out> #16 0x0000555555817c4c in exec_byte_code (fun=XIL(0), args_template=1, nargs=2, args=0x7ffff1200520) at /usr/src/debug/emacs/emacs-29.4/src/bytecode.c:809 call_nargs = 2 call_fun = <optimized out> count1 = <optimized out> template = <optimized out> val = XIL(0xaaaaabc77570) call_args = 0x7ffff1200520 original_fun = <optimized out> bytecode = <optimized out> op = <optimized out> type = (unknown: 0x6a20) targets = <optimized out> quitcounter = <optimized out> bc = <optimized out> top = <optimized out> pc = <optimized out> bytestr = XIL(0x6a20) vector = <optimized out> maxdepth = <optimized out> const_length = <optimized out> bytestr_length = <optimized out> vectorp = <optimized out> max_stack = <optimized out> frame_base = <optimized out> fp = 0xaaaaabc77570 bytestr_data = <optimized out> rest = <optimized out> mandatory = 5 nonrest = 5 pushedargs = 0 result = <optimized out> targets = {0x55555581c531 <exec_byte_code+19777>, 0x5555558180bb <exec_byte_code+2251>, 0x5555558180cd <exec_byte_code+2269>, 0x5555558180c4 <exec_byte_code+2260>, 0x555555817a29 <exec_byte_code+569>, 0x555555817a2d <exec_byte_code+573>, 0x55555581a4cd <exec_byte_code+11485>, 0x555555818075 <exec_byte_code+2181>, 0x555555819e5d <exec_byte_code+9837>, 0x555555819e54 <exec_byte_code+9828>, 0x555555819e4b <exec_byte_code+9819>, 0x555555819e30 <exec_byte_code+9792>, 0x555555817d05 <exec_byte_code+1301>, 0x555555817d10 <exec_byte_code+1312>, 0x555555817e1a <exec_byte_code+1578>, 0x555555819e39 <exec_byte_code+9801>, 0x55555581a15c <exec_byte_code+10604>, 0x555555819e8a <exec_byte_code+9882>, 0x555555819e81 <exec_byte_code+9873>, 0x555555819e78 <exec_byte_code+9864>, 0x555555817997 <exec_byte_code+423>, 0x5555558179a0 <exec_byte_code+432>, 0x55555581a06e <exec_byte_code+10366>, 0x55555581a080 <exec_byte_code+10384>, 0x55555581a053 <exec_byte_code+10339>, 0x55555581a04a <exec_byte_code+10330>, 0x555555817e47 <exec_byte_code+1623>, 0x555555817e3e <exec_byte_code+1614>, 0x555555817ca5 <exec_byte_code+1205>, 0x555555817cb0 <exec_byte_code+1216>, 0x555555819ffc <exec_byte_code+10252>, 0x55555581a05c <exec_byte_code+10348>, 0x555555819e27 <exec_byte_code+9783>, 0x555555819e1e <exec_byte_code+9774>, 0x55555581a126 <exec_byte_code+10550>, 0x55555581a11d <exec_byte_code+10541>, 0x555555817ac3 <exec_byte_code+723>, 0x555555817ad0 <exec_byte_code+736>, 0x555555817e2c <exec_byte_code+1596>, 0x55555581a092 <exec_byte_code+10402>, 0x55555581a141 <exec_byte_code+10577>, 0x55555581a138 <exec_byte_code+10568>, 0x55555581a12f <exec_byte_code+10559>, 0x555555817e50 <exec_byte_code+1632>, 0x555555817a6f <exec_byte_code+639>, 0x555555817a78 <exec_byte_code+648>, 0x555555819e66 <exec_byte_code+9846>, 0x55555581a14a <exec_byte_code+10586>, 0x55555581a6ca <exec_byte_code+11994>, 0x55555581a701 <exec_byte_code+12049>, 0x55555581a787 <exec_byte_code+12183>, 0x55555581c535 <exec_byte_code+19781>, 0x55555581c535 <exec_byte_code+19781>, 0x55555581c535 <exec_byte_code+19781>, 0x55555581c535 <exec_byte_code+19781>, 0x55555581c535 <exec_byte_code+19781>, 0x55555581a1f3 <exec_byte_code+10755>, 0x5555558199b2 <exec_byte_code+8642>, 0x555555819965 <exec_byte_code+8565>, 0x555555819918 <exec_byte_code+8488>, 0x555555819be2 <exec_byte_code+9202>, 0x555555819edc <exec_byte_code+9964>, 0x555555819e93 <exec_byte_code+9891>, 0x555555819b61 <exec_byte_code+9073>, 0x555555819f77 <exec_byte_code+10119>, 0x55555581a165 <exec_byte_code+10613>, 0x555555819b99 <exec_byte_code+9129>, 0x555555819cc5 <exec_byte_code+9429>, 0x5555558197f6 <exec_byte_code+8198>, 0x555555819c67 <exec_byte_code+9335>, 0x555555819cfd <exec_byte_code+9485>, 0x555555819de8 <exec_byte_code+9720>, 0x555555819d71 <exec_byte_code+9601>, 0x5555558192f8 <exec_byte_code+6920>, 0x55555581957b <exec_byte_code+7563>, 0x555555819c31 <exec_byte_code+9281>, 0x55555581952b <exec_byte_code+7483>, 0x5555558194e2 <exec_byte_code+7410>, 0x555555819499 <exec_byte_code+7337>, 0x55555581944c <exec_byte_code+7260>, 0x555555819409 <exec_byte_code+7193>, 0x5555558193c6 <exec_byte_code+7126>, 0x5555558196e3 <exec_byte_code+7923>, 0x55555581967e <exec_byte_code+7822>, 0x555555819619 <exec_byte_code+7721>, 0x5555558195be <exec_byte_code+7630>, 0x555555819798 <exec_byte_code+8104>, 0x55555581984c <exec_byte_code+8284>, 0x55555581929a <exec_byte_code+6826>, 0x55555581923c <exec_byte_code+6732>, 0x555555819726 <exec_byte_code+7990>, 0x555555819167 <exec_byte_code+6519>, 0x5555558191cd <exec_byte_code+6621>, 0x555555819067 <exec_byte_code+6263>, 0x5555558190e7 <exec_byte_code+6391>, 0x555555818ff4 <exec_byte_code+6148>, 0x555555818f3c <exec_byte_code+5964>, 0x555555817d99 <exec_byte_code+1449>, 0x555555818e59 <exec_byte_code+5737>, 0x555555818e0a <exec_byte_code+5658>, 0x555555818d53 <exec_byte_code+5475>, 0x555555818d00 <exec_byte_code+5392>, 0x555555818cca <exec_byte_code+5338>, 0x555555818c8f <exec_byte_code+5279>, 0x555555818f01 <exec_byte_code+5905>, 0x555555818c4c <exec_byte_code+5212>, 0x555555818c14 <exec_byte_code+5156>, 0x55555581c535 <exec_byte_code+19781>, 0x555555818bd9 <exec_byte_code+5097>, 0x555555818b7e <exec_byte_code+5006>, 0x555555818b43 <exec_byte_code+4947>, 0x555555818ae8 <exec_byte_code+4856>, 0x555555818a6a <exec_byte_code+4730>, 0x555555818ab2 <exec_byte_code+4802>, 0x555555817d9d <exec_byte_code+1453>, 0x55555581c535 <exec_byte_code+19781>, 0x555555818a18 <exec_byte_code+4648>, 0x5555558189d9 <exec_byte_code+4585>, 0x5555558189a3 <exec_byte_code+4531>, 0x555555818955 <exec_byte_code+4453>, 0x555555818878 <exec_byte_code+4232>, 0x555555818842 <exec_byte_code+4178>, 0x55555581880c <exec_byte_code+4124>, 0x55555581890c <exec_byte_code+4380>, 0x555555818781 <exec_byte_code+3985>, 0x555555818738 <exec_byte_code+3912>, 0x5555558186fd <exec_byte_code+3853>, 0x5555558186c7 <exec_byte_code+3799>, 0x55555581c535 <exec_byte_code+19781>, 0x55555581a53c <exec_byte_code+11596>, 0x55555581a0a4 <exec_byte_code+10420>, 0x555555819fb7 <exec_byte_code+10183>, 0x555555817f90 <exec_byte_code+1952>, 0x555555817f4e <exec_byte_code+1886>, 0x555555817e59 <exec_byte_code+1641>, 0x555555817e9b <exec_byte_code+1707>, 0x55555581a582 <exec_byte_code+11666>, 0x55555581a00e <exec_byte_code+10270>, 0x55555581a513 <exec_byte_code+11555>, 0x55555581a5fe <exec_byte_code+11790>, 0x55555581a885 <exec_byte_code+12437>, 0x55555581a5ae <exec_byte_code+11710>, 0x55555581a7e6 <exec_byte_code+12278>, 0x55555581a799 <exec_byte_code+12201>, 0x55555581a269 <exec_byte_code+10873>, 0x555555819a2e <exec_byte_code+8766>, 0x55555581c535 <exec_byte_code+19781>, 0x555555818678 <exec_byte_code+3720>, 0x55555581863d <exec_byte_code+3661>, 0x5555558185cd <exec_byte_code+3549>, 0x555555818605 <exec_byte_code+3605>, 0x555555818592 <exec_byte_code+3490>, 0x555555818549 <exec_byte_code+3417>, 0x555555818500 <exec_byte_code+3344>, 0x5555558184a5 <exec_byte_code+3253>, 0x55555581845c <exec_byte_code+3180>, 0x5555558183ee <exec_byte_code+3070>, 0x5555558182d6 <exec_byte_code+2790>, 0x5555558188c3 <exec_byte_code+4307>, 0x5555558182a0 <exec_byte_code+2736>, 0x555555818232 <exec_byte_code+2626>, 0x5555558181c4 <exec_byte_code+2516>, 0x555555818365 <exec_byte_code+2933>, 0x55555581831f <exec_byte_code+2863>, 0x5555558183ab <exec_byte_code+3003>, 0x555555818f8f <exec_byte_code+6047>, 0x555555818e8f <exec_byte_code+5791>, 0x5555558180d6 <exec_byte_code+2278>, 0x55555581814e <exec_byte_code+2398>, 0x55555581c535 <exec_byte_code+19781>, 0x55555581c535 <exec_byte_code+19781>, 0x55555581c535 <exec_byte_code+19781>, 0x55555581c535 <exec_byte_code+19781>, 0x55555581c535 <exec_byte_code+19781>, 0x55555581c535 <exec_byte_code+19781>, 0x5555558198aa <exec_byte_code+8378>, 0x555555819376 <exec_byte_code+7046>, 0x555555818da6 <exec_byte_code+5558>, 0x55555581a1a5 <exec_byte_code+10677>, 0x555555818027 <exec_byte_code+2103>, 0x55555581c535 <exec_byte_code+19781>, 0x55555581c535 <exec_byte_code+19781>, 0x555555817fd5 <exec_byte_code+2021>, 0x55555581a464 <exec_byte_code+11380>, 0x55555581c535 <exec_byte_code+19781>, 0x55555581c535 <exec_byte_code+19781>, 0x55555581c535 <exec_byte_code+19781>, 0x55555581c535 <exec_byte_code+19781>, 0x55555581c535 <exec_byte_code+19781>, 0x55555581c535 <exec_byte_code+19781>, 0x55555581c535 <exec_byte_code+19781>, 0x55555581c535 <exec_byte_code+19781>, 0x55555581a41f <exec_byte_code+11311> <repeats 64 times>} #17 0x00005555557cd2ed in Ffuncall (nargs=nargs@entry=6, args=0x7fffffffde90) at /usr/src/debug/emacs/emacs-29.4/src/eval.c:2999 count = <optimized out> val = <optimized out> #18 0x00005555557cdbc0 in Fapply (nargs=2, args=0x7ffff12002f8) at /usr/src/debug/emacs/emacs-29.4/src/eval.c:2670 i = <optimized out> funcall_nargs = 6 funcall_args = <optimized out> spread_arg = XIL(0) fun = <optimized out> sa_avail = <optimized out> sa_count = <optimized out> numargs = <optimized out> retval = <optimized out> #19 0x0000555555817c4c in exec_byte_code (fun=XIL(0), args_template=1, nargs=2, args=0x7ffff12002f8) at /usr/src/debug/emacs/emacs-29.4/src/bytecode.c:809 call_nargs = 2 call_fun = <optimized out> count1 = <optimized out> template = <optimized out> val = XIL(0xaaaaabc77570) call_args = 0x7ffff12002f8 original_fun = <optimized out> bytecode = <optimized out> op = <optimized out> type = (unknown: 0x6a20) targets = <optimized out> quitcounter = <optimized out> bc = <optimized out> top = <optimized out> pc = <optimized out> bytestr = XIL(0x6a20) vector = <optimized out> maxdepth = <optimized out> const_length = <optimized out> bytestr_length = <optimized out> vectorp = <optimized out> max_stack = <optimized out> frame_base = <optimized out> fp = 0xaaaaabc77570 bytestr_data = <optimized out> rest = <optimized out> mandatory = 5 nonrest = 8 pushedargs = 0 result = <optimized out> targets = {0x55555581c531 <exec_byte_code+19777>, 0x5555558180bb <exec_byte_code+2251>, 0x5555558180cd <exec_byte_code+2269>, 0x5555558180c4 <exec_byte_code+2260>, 0x555555817a29 <exec_byte_code+569>, 0x555555817a2d <exec_byte_code+573>, 0x55555581a4cd <exec_byte_code+11485>, 0x555555818075 <exec_byte_code+2181>, 0x555555819e5d <exec_byte_code+9837>, 0x555555819e54 <exec_byte_code+9828>, 0x555555819e4b <exec_byte_code+9819>, 0x555555819e30 <exec_byte_code+9792>, 0x555555817d05 <exec_byte_code+1301>, 0x555555817d10 <exec_byte_code+1312>, 0x555555817e1a <exec_byte_code+1578>, 0x555555819e39 <exec_byte_code+9801>, 0x55555581a15c <exec_byte_code+10604>, 0x555555819e8a <exec_byte_code+9882>, 0x555555819e81 <exec_byte_code+9873>, 0x555555819e78 <exec_byte_code+9864>, 0x555555817997 <exec_byte_code+423>, 0x5555558179a0 <exec_byte_code+432>, 0x55555581a06e <exec_byte_code+10366>, 0x55555581a080 <exec_byte_code+10384>, 0x55555581a053 <exec_byte_code+10339>, 0x55555581a04a <exec_byte_code+10330>, 0x555555817e47 <exec_byte_code+1623>, 0x555555817e3e <exec_byte_code+1614>, 0x555555817ca5 <exec_byte_code+1205>, 0x555555817cb0 <exec_byte_code+1216>, 0x555555819ffc <exec_byte_code+10252>, 0x55555581a05c <exec_byte_code+10348>, 0x555555819e27 <exec_byte_code+9783>, 0x555555819e1e <exec_byte_code+9774>, 0x55555581a126 <exec_byte_code+10550>, 0x55555581a11d <exec_byte_code+10541>, 0x555555817ac3 <exec_byte_code+723>, 0x555555817ad0 <exec_byte_code+736>, 0x555555817e2c <exec_byte_code+1596>, 0x55555581a092 <exec_byte_code+10402>, 0x55555581a141 <exec_byte_code+10577>, 0x55555581a138 <exec_byte_code+10568>, 0x55555581a12f <exec_byte_code+10559>, 0x555555817e50 <exec_byte_code+1632>, 0x555555817a6f <exec_byte_code+639>, 0x555555817a78 <exec_byte_code+648>, 0x555555819e66 <exec_byte_code+9846>, 0x55555581a14a <exec_byte_code+10586>, 0x55555581a6ca <exec_byte_code+11994>, 0x55555581a701 <exec_byte_code+12049>, 0x55555581a787 <exec_byte_code+12183>, 0x55555581c535 <exec_byte_code+19781>, 0x55555581c535 <exec_byte_code+19781>, 0x55555581c535 <exec_byte_code+19781>, 0x55555581c535 <exec_byte_code+19781>, 0x55555581c535 <exec_byte_code+19781>, 0x55555581a1f3 <exec_byte_code+10755>, 0x5555558199b2 <exec_byte_code+8642>, 0x555555819965 <exec_byte_code+8565>, 0x555555819918 <exec_byte_code+8488>, 0x555555819be2 <exec_byte_code+9202>, 0x555555819edc <exec_byte_code+9964>, 0x555555819e93 <exec_byte_code+9891>, 0x555555819b61 <exec_byte_code+9073>, 0x555555819f77 <exec_byte_code+10119>, 0x55555581a165 <exec_byte_code+10613>, 0x555555819b99 <exec_byte_code+9129>, 0x555555819cc5 <exec_byte_code+9429>, 0x5555558197f6 <exec_byte_code+8198>, 0x555555819c67 <exec_byte_code+9335>, 0x555555819cfd <exec_byte_code+9485>, 0x555555819de8 <exec_byte_code+9720>, 0x555555819d71 <exec_byte_code+9601>, 0x5555558192f8 <exec_byte_code+6920>, 0x55555581957b <exec_byte_code+7563>, 0x555555819c31 <exec_byte_code+9281>, 0x55555581952b <exec_byte_code+7483>, 0x5555558194e2 <exec_byte_code+7410>, 0x555555819499 <exec_byte_code+7337>, 0x55555581944c <exec_byte_code+7260>, 0x555555819409 <exec_byte_code+7193>, 0x5555558193c6 <exec_byte_code+7126>, 0x5555558196e3 <exec_byte_code+7923>, 0x55555581967e <exec_byte_code+7822>, 0x555555819619 <exec_byte_code+7721>, 0x5555558195be <exec_byte_code+7630>, 0x555555819798 <exec_byte_code+8104>, 0x55555581984c <exec_byte_code+8284>, 0x55555581929a <exec_byte_code+6826>, 0x55555581923c <exec_byte_code+6732>, 0x555555819726 <exec_byte_code+7990>, 0x555555819167 <exec_byte_code+6519>, 0x5555558191cd <exec_byte_code+6621>, 0x555555819067 <exec_byte_code+6263>, 0x5555558190e7 <exec_byte_code+6391>, 0x555555818ff4 <exec_byte_code+6148>, 0x555555818f3c <exec_byte_code+5964>, 0x555555817d99 <exec_byte_code+1449>, 0x555555818e59 <exec_byte_code+5737>, 0x555555818e0a <exec_byte_code+5658>, 0x555555818d53 <exec_byte_code+5475>, 0x555555818d00 <exec_byte_code+5392>, 0x555555818cca <exec_byte_code+5338>, 0x555555818c8f <exec_byte_code+5279>, 0x555555818f01 <exec_byte_code+5905>, 0x555555818c4c <exec_byte_code+5212>, 0x555555818c14 <exec_byte_code+5156>, 0x55555581c535 <exec_byte_code+19781>, 0x555555818bd9 <exec_byte_code+5097>, 0x555555818b7e <exec_byte_code+5006>, 0x555555818b43 <exec_byte_code+4947>, 0x555555818ae8 <exec_byte_code+4856>, 0x555555818a6a <exec_byte_code+4730>, 0x555555818ab2 <exec_byte_code+4802>, 0x555555817d9d <exec_byte_code+1453>, 0x55555581c535 <exec_byte_code+19781>, 0x555555818a18 <exec_byte_code+4648>, 0x5555558189d9 <exec_byte_code+4585>, 0x5555558189a3 <exec_byte_code+4531>, 0x555555818955 <exec_byte_code+4453>, 0x555555818878 <exec_byte_code+4232>, 0x555555818842 <exec_byte_code+4178>, 0x55555581880c <exec_byte_code+4124>, 0x55555581890c <exec_byte_code+4380>, 0x555555818781 <exec_byte_code+3985>, 0x555555818738 <exec_byte_code+3912>, 0x5555558186fd <exec_byte_code+3853>, 0x5555558186c7 <exec_byte_code+3799>, 0x55555581c535 <exec_byte_code+19781>, 0x55555581a53c <exec_byte_code+11596>, 0x55555581a0a4 <exec_byte_code+10420>, 0x555555819fb7 <exec_byte_code+10183>, 0x555555817f90 <exec_byte_code+1952>, 0x555555817f4e <exec_byte_code+1886>, 0x555555817e59 <exec_byte_code+1641>, 0x555555817e9b <exec_byte_code+1707>, 0x55555581a582 <exec_byte_code+11666>, 0x55555581a00e <exec_byte_code+10270>, 0x55555581a513 <exec_byte_code+11555>, 0x55555581a5fe <exec_byte_code+11790>, 0x55555581a885 <exec_byte_code+12437>, 0x55555581a5ae <exec_byte_code+11710>, 0x55555581a7e6 <exec_byte_code+12278>, 0x55555581a799 <exec_byte_code+12201>, 0x55555581a269 <exec_byte_code+10873>, 0x555555819a2e <exec_byte_code+8766>, 0x55555581c535 <exec_byte_code+19781>, 0x555555818678 <exec_byte_code+3720>, 0x55555581863d <exec_byte_code+3661>, 0x5555558185cd <exec_byte_code+3549>, 0x555555818605 <exec_byte_code+3605>, 0x555555818592 <exec_byte_code+3490>, 0x555555818549 <exec_byte_code+3417>, 0x555555818500 <exec_byte_code+3344>, 0x5555558184a5 <exec_byte_code+3253>, 0x55555581845c <exec_byte_code+3180>, 0x5555558183ee <exec_byte_code+3070>, 0x5555558182d6 <exec_byte_code+2790>, 0x5555558188c3 <exec_byte_code+4307>, 0x5555558182a0 <exec_byte_code+2736>, 0x555555818232 <exec_byte_code+2626>, 0x5555558181c4 <exec_byte_code+2516>, 0x555555818365 <exec_byte_code+2933>, 0x55555581831f <exec_byte_code+2863>, 0x5555558183ab <exec_byte_code+3003>, 0x555555818f8f <exec_byte_code+6047>, 0x555555818e8f <exec_byte_code+5791>, 0x5555558180d6 <exec_byte_code+2278>, 0x55555581814e <exec_byte_code+2398>, 0x55555581c535 <exec_byte_code+19781>, 0x55555581c535 <exec_byte_code+19781>, 0x55555581c535 <exec_byte_code+19781>, 0x55555581c535 <exec_byte_code+19781>, 0x55555581c535 <exec_byte_code+19781>, 0x55555581c535 <exec_byte_code+19781>, 0x5555558198aa <exec_byte_code+8378>, 0x555555819376 <exec_byte_code+7046>, 0x555555818da6 <exec_byte_code+5558>, 0x55555581a1a5 <exec_byte_code+10677>, 0x555555818027 <exec_byte_code+2103>, 0x55555581c535 <exec_byte_code+19781>, 0x55555581c535 <exec_byte_code+19781>, 0x555555817fd5 <exec_byte_code+2021>, 0x55555581a464 <exec_byte_code+11380>, 0x55555581c535 <exec_byte_code+19781>, 0x55555581c535 <exec_byte_code+19781>, 0x55555581c535 <exec_byte_code+19781>, 0x55555581c535 <exec_byte_code+19781>, 0x55555581c535 <exec_byte_code+19781>, 0x55555581c535 <exec_byte_code+19781>, 0x55555581c535 <exec_byte_code+19781>, 0x55555581c535 <exec_byte_code+19781>, 0x55555581a41f <exec_byte_code+11311> <repeats 64 times>} #20 0x00005555557cd2ed in Ffuncall (nargs=1, args=0x7fffffffe148) at /usr/src/debug/emacs/emacs-29.4/src/eval.c:2999 count = <optimized out> val = <optimized out> #21 0x00005555558936ae in internal_condition_case_n.constprop.0 (bfun=bfun@entry=0x55555571a7d0 <safe_run_hooks_1>, nargs=nargs@entry=2, args=args@entry=0x7fffffffe140, hfun=hfun@entry=0x55555571ae70 <safe_run_hooks_error>, handlers=XIL(0x30)) at /usr/src/debug/emacs/emacs-29.4/src/eval.c:1558 val = <optimized out> old_deep = 0x0 c = 0x555555e9ee60 #22 0x000055555571b4b2 in safe_run_hook_funcall (nargs=2, args=0x7fffffffe230) at /usr/src/debug/emacs/emacs-29.4/src/keyboard.c:1893 fun = <optimized out> hook = <optimized out> sa_avail = <optimized out> sa_count = <optimized out> newargs = 0x7fffffffe140 #23 0x00005555557cab01 in run_hook_with_args (nargs=2, args=0x7fffffffe230, funcall=0x55555571b3c0 <safe_run_hook_funcall>) at /usr/src/debug/emacs/emacs-29.4/src/eval.c:2851 global_vals = XIL(0x5555582c2163) sym = XIL(0xd290) val = XIL(0x55555666ffa3) ret = XIL(0) #24 0x00005555558a7cdd in safe_run_hooks_maybe_narrowed.isra.0 (hook=hook@entry=XIL(0xd290), w=<optimized out>) at /usr/src/debug/emacs/emacs-29.4/src/keyboard.c:1931 count = <optimized out> #25 0x000055555571d967 in command_loop_1 () at /usr/src/debug/emacs/emacs-29.4/src/keyboard.c:1518 cmd = <optimized out> keybuf = {make_fixnum(20), make_fixnum(6), XIL(0x1), XIL(0x7ffff24a6323), XIL(0x80), XIL(0x7ffff1ed38fd), XIL(0x7fffffffe4e0), XIL(0xdb300b46aee77800), XIL(0x7fffffffe3b0), XIL(0x7ffff1ed38fd), XIL(0x2aaa9c19f428), XIL(0x80), XIL(0), XIL(0x9c19f428), XIL(0x7fffffffe460), XIL(0x5555557c1c0d), XIL(0xb), make_fixnum(4), XIL(0x555500000000), XIL(0x555555e9ed20), XIL(0), XIL(0xdb300b46aee77800), make_fixnum(4), XIL(0x5555555b12bc), XIL(0x60), XIL(0x30), XIL(0), XIL(0x98a0), XIL(0x7fffffffe480), XIL(0x5555557cb891)} i = <optimized out> count = <optimized out> prev_modiff = 36 prev_buffer = 0x5555575e5140 #26 0x00005555557baf7e in internal_condition_case (bfun=0x55555571d4a0 <command_loop_1>, handlers=<optimized out>, hfun=0x55555571ccd0 <cmd_error>) at /usr/src/debug/emacs/emacs-29.4/src/eval.c:1474 val = <optimized out> c = 0x555555e9ed20 #27 0x000055555571ad46 in command_loop_2 (handlers=handlers@entry=XIL(0x90)) at /usr/src/debug/emacs/emacs-29.4/src/keyboard.c:1133 val = <optimized out> #28 0x00005555557baed8 in internal_catch (tag=<optimized out>, func=0x55555571ad10 <command_loop_2>, arg=XIL(0x90)) at /usr/src/debug/emacs/emacs-29.4/src/eval.c:1197 val = <optimized out> c = 0x555555e9ebe0 #29 0x000055555571d46b in command_loop () at /usr/src/debug/emacs/emacs-29.4/src/keyboard.c:1111 No locals. #30 0x00005555558a7b6f in recursive_edit_1.isra.0 () at /usr/src/debug/emacs/emacs-29.4/src/keyboard.c:720 count = <optimized out> val = <optimized out> #31 0x000055555571f59d in Frecursive_edit () at /usr/src/debug/emacs/emacs-29.4/src/keyboard.c:803 count = <optimized out> buffer = <optimized out> #32 0x0000555555721f4d in main (argc=5, argv=0x7fffffffe848) at /usr/src/debug/emacs/emacs-29.4/src/emacs.c:2521 stack_bottom_variable = 0x0 no_loadup = <optimized out> junk = 0x0 dname_arg = 0x0 ch_to_dir = 0x0 original_pwd = 0x0 dump_mode = <optimized out> skip_args = 0 temacs = 0x0 attempt_load_pdump = <optimized out> only_version = false rlim = { rlim_cur = 10022912, rlim_max = 18446744073709551615 } lc_all = <optimized out> sockfd = -1 module_assertions = <optimized out> Lisp Backtrace: "read-event" (0xf1200a28) "sit-for" (0xf12009a0) "lsp-request-while-no-input" (0xf12008d8) 0x5850c6e0 PVEC_COMPILED 0x5850c740 PVEC_COMPILED "complete-with-action" (0xf1200790) 0x582280b0 PVEC_COMPILED "all-completions" (0xf12006f8) "completion-pcm--all-completions" (0xf1200680) "completion-substring--all-completions" (0xf1200578) 0xf1faece8 PVEC_COMPILED "apply" (0xf1200520) "completion-flex-all-completions" (0xf12004c8) 0x583041f8 PVEC_COMPILED "completion--some" (0xf1200408) "completion--nth-completion" (0xf1200358) "completion-all-completions" (0xffffde98) "apply" (0xf12002f8) "corfu--filter-completions" (0xf1200208) "corfu--recompute" (0xf1200178) "corfu--update" (0xf1200070) "corfu--exhibit" (0xf1200038) "corfu--post-command" (0xffffe150) (gdb) I notice plenty of items GDB couldn't track; if it would help I can try to adjust compilation options and run it again. Regards. [-- Attachment #2: Type: text/html, Size: 58068 bytes --] ^ permalink raw reply [flat|nested] 18+ messages in thread
* bug#71744: 29.4; SIGSEGV during completion-at-point in lsp-mode with corfu and cape 2024-06-26 23:27 ` Matthew Rothlisberger @ 2024-06-27 10:05 ` Eli Zaretskii 0 siblings, 0 replies; 18+ messages in thread From: Eli Zaretskii @ 2024-06-27 10:05 UTC (permalink / raw) To: Matthew Rothlisberger; +Cc: 71744 > From: Matthew Rothlisberger <mattjrothlis@gmail.com> > Date: Wed, 26 Jun 2024 19:27:00 -0400 > Cc: 71744@debbugs.gnu.org > > Thanks for your reply. > > > On Mon, Jun 24, 2024 at 08:28 Eli Zaretskii <eliz@gnu.org> wrote: > > Thanks, but we need a full GDB backtrace in order to investigate this, since your use case involves a lot of > moving parts that are not part of Emacs. > > Here's GDB output after triggering the crash: > > Thread 1 "emacs" received signal SIGSEGV, Segmentation fault. > Fget (symbol=XIL(0x555555f430d0), propname=XIL(0x6a20)) > at /usr/src/debug/emacs/emacs-29.4/src/lisp.h:1152 > 1152 return p; > (gdb) bt full > #0 Fget (symbol=XIL(0x555555f430d0), propname=XIL(0x6a20)) at > /usr/src/debug/emacs/emacs-29.4/src/lisp.h:1152 > propval = <optimized out> > propval = <optimized out> > #1 Fget (symbol=XIL(0x555555f430d0), propname=XIL(0x6a20)) at > /usr/src/debug/emacs/emacs-29.4/src/fns.c:2516 > propval = <optimized out> > #2 0x0000555555727621 in parse_modifiers (symbol=XIL(0x555555f430d0)) at > /usr/src/debug/emacs/emacs-29.4/src/keyboard.c:6897 > elements = <optimized out> > elements = <optimized out> > end = <optimized out> > modifiers = <optimized out> > unmodified = <optimized out> > mask = <optimized out> > #3 parse_modifiers (symbol=XIL(0x555555f430d0)) at > /usr/src/debug/emacs/emacs-29.4/src/keyboard.c:6888 > elements = <optimized out> > end = <optimized out> > modifiers = <optimized out> > unmodified = <optimized out> > mask = <optimized out> > #4 0x00005555557377b8 in reorder_modifiers (symbol=<optimized out>) at > /usr/src/debug/emacs/emacs-29.4/src/keyboard.c:7028 > parsed = <optimized out> > parsed = <optimized out> Thanks. I don't see any obvious reasons for the crash, sorry, not with so many variables "optimized out". I do notice that your build was done with many non-default compilation and link switches, so maybe one of them causes this in some way. Perhaps try reproducing this in an unoptimized build, maybe this will give us more information regarding where and why this happens. You mentioned earlier this doesn't happen in Emacs 31, does it mean the master branch of the Emacs Git repository doesn't have this problem? How about the emacs-30 release branch (which will become Emacs 30.1)? ^ permalink raw reply [flat|nested] 18+ messages in thread
* bug#71744: 29.4; SIGSEGV during completion-at-point in lsp-mode with corfu and cape 2024-06-23 21:16 bug#71744: 29.4; SIGSEGV during completion-at-point in lsp-mode with corfu and cape Matthew Rothlisberger 2024-06-24 12:28 ` Eli Zaretskii @ 2024-08-14 13:22 ` Sigve Indregard via Bug reports for GNU Emacs, the Swiss army knife of text editors 2024-08-14 13:57 ` Eli Zaretskii 1 sibling, 1 reply; 18+ messages in thread From: Sigve Indregard via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2024-08-14 13:22 UTC (permalink / raw) To: 71744@debbugs.gnu.org [-- Attachment #1.1: Type: text/plain, Size: 4506 bytes --] I experience the exact same bug, in that the backtrace looks identical. Similar to the original reporter, it occurs while completing symbols for Rust, and my setup also involves Corfu. It does not happen on every complete, but usually within 10 minutes of development. But some differences are probably important: my setup is with eglot, not lsp-mode, and I do not use Cape. Maybe it is relevant that the trace ending with the failing Fget starts with jsonrpc. Is there a way to monitor the exact communication emacs has with the language server? * Backtrace (snippet): Thread 1 (Thread 0x7ffff2837080 (LWP 150113) "emacs"): #0 Fget (symbol=0x5555564e3dc0, propname=0x66f0) at /usr/src/debug/emacs/emacs-29.4-wayland/src/lisp.h:1152 propval = <optimized out> propval = <optimized out> #1 Fget (symbol=0x5555564e3dc0, propname=0x66f0) at /usr/src/debug/emacs/emacs-29.4-wayland/src/fns.c:2516 propval = <optimized out> #2 0x0000555555681201 in parse_modifiers (symbol=0x5555564e3dc0) at /usr/src/debug/emacs/emacs-29.4-wayland/src/keyboard.c:6897 elements = <optimized out> elements = <optimized out> end = <optimized out> modifiers = <optimized out> unmodified = <optimized out> mask = <optimized out> #3 parse_modifiers (symbol=0x5555564e3dc0) at /usr/src/debug/emacs/emacs-29.4-wayland/src/keyboard.c:6888 elements = <optimized out> end = <optimized out> modifiers = <optimized out> unmodified = <optimized out> mask = <optimized out> #4 0x000055555568e7c8 in reorder_modifiers (symbol=<optimized out>) at /usr/src/debug/emacs/emacs-29.4-wayland/src/keyboard.c:7028 parsed = <optimized out> parsed = <optimized out> #5 access_keymap_1 (map=0x7fffefe131b3, idx=<optimized out>, t_ok=false, noinherit=false, autoload=true) at /usr/src/debug/emacs/emacs-29.4-wayland/src/keymap.c:342 No locals. #6 0x000055555567d16b in access_keymap (noinherit=false, autoload=true, map=<optimized out>, idx=<optimized out>, t_ok=false) at /usr/src/debug/emacs/emacs-29.4-wayland/src/keymap.c:496 val = <optimized out> val = <optimized out> #7 read_char (commandflag=0, map=0x0, prev_event=0x0, used_mouse_menu=0x0, end_time=0x7fffffffb5b0) at /usr/src/debug/emacs/emacs-29.4-wayland/src/keyboard.c:3018 c = <optimized out> local_getcjmp = {{__jmpbuf = {93825000405056, -5147324661749537557, 1, 4611686019484352512, 5, 0, -5147324661946669845, -1313834696378178325}, __mask_was_saved = 0, __saved_mask = {__val = {0, 93825010269488, 93825104789632, 140737488335792, 18446744073709550936, 11, 93825104789616, 140737488335856, 140737279378894, 140737488335856, 140737488335920, 0, 140737488335920, 0, 93825010269488, 140737488336000}}}} save_jump = {{__jmpbuf = {12048, 140737188459256, 140737488335856, 93825095637120, 16, -7692597586030666240, 48, 1}, __mask_was_saved = 1453957408, __saved_mask = {__val = {140737488335776, 2, 140737488335824, 140737488335760, 140737321006214, 1, 140737321006651, 14319535557742690304, 6, 140737488335696, 140737279373914, 93825000331312, 0, 1, 1, 93823560581122}}}} tem = <optimized out> save = 0x0 previous_echo_area_message = 0x0 also_record = 0x0 reread = false recorded = false polling_stopped_here = false orig_kboard = 0x5555564e3dc0 retry = <optimized out> jmpcount = <optimized out> #8 0x0000555555742662 in read_filtered_event (no_switch_frame=false, ascii_required=false, error_nonascii=false, input_method=<optimized out>, seconds=0x7a) at /usr/src/debug/emacs/emacs-29.4-wayland/src/lread.c:702 val = <optimized out> delayed_switch_frame = <optimized out> end_time = {tv_sec = 1723636772, tv_nsec = 958651372} retry = <optimized out> #9 0x00007fffef3c3337 in F7369742d666f72_sit_for_0 () from /usr/bin/../lib/emacs/29.4/native-lisp/29.4-ebb0abfe/preloaded/subr-13adf6a6-bfb9f448.eln No symbol table info available. #10 0x000055555571364d in Ffuncall (nargs=2, args=0x7fffffffb718) at /usr/src/debug/emacs/emacs-29.4-wayland/src/eval.c:2999 count = <optimized out> val = <optimized out> #11 0x00007fffce347844 in F6a736f6e7270632d72657175657374_jsonrpc_request_0 () from /usr/lib/emacs/29.4/native-lisp/29.4-ebb0abfe/jsonrpc-e62a9c36-62ae7160.eln No symbol table info available. -- Sigve Indregard [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 249 bytes --] ^ permalink raw reply [flat|nested] 18+ messages in thread
* bug#71744: 29.4; SIGSEGV during completion-at-point in lsp-mode with corfu and cape 2024-08-14 13:22 ` Sigve Indregard via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2024-08-14 13:57 ` Eli Zaretskii 2024-08-14 15:40 ` Sigve Indregard via Bug reports for GNU Emacs, the Swiss army knife of text editors 0 siblings, 1 reply; 18+ messages in thread From: Eli Zaretskii @ 2024-08-14 13:57 UTC (permalink / raw) To: Sigve Indregard; +Cc: 71744 > Date: Wed, 14 Aug 2024 13:22:18 +0000 > From: Sigve Indregard via "Bug reports for GNU Emacs, > the Swiss army knife of text editors" <bug-gnu-emacs@gnu.org> > > I experience the exact same bug, in that the backtrace looks identical. > > Similar to the original reporter, it occurs while completing symbols for Rust, and my setup also involves Corfu. It does not happen on every complete, but usually within 10 minutes of development. > > But some differences are probably important: my setup is with eglot, not lsp-mode, and I do not use Cape. > > Maybe it is relevant that the trace ending with the failing Fget starts with jsonrpc. Is there a way to monitor the exact communication emacs has with the language server? > > * Backtrace (snippet): > > Thread 1 (Thread 0x7ffff2837080 (LWP 150113) "emacs"): > #0 Fget (symbol=0x5555564e3dc0, propname=0x66f0) at /usr/src/debug/emacs/emacs-29.4-wayland/src/lisp.h:1152 > propval = <optimized out> > propval = <optimized out> > #1 Fget (symbol=0x5555564e3dc0, propname=0x66f0) at /usr/src/debug/emacs/emacs-29.4-wayland/src/fns.c:2516 > propval = <optimized out> > #2 0x0000555555681201 in parse_modifiers (symbol=0x5555564e3dc0) at /usr/src/debug/emacs/emacs-29.4-wayland/src/keyboard.c:6897 > elements = <optimized out> > elements = <optimized out> > end = <optimized out> > modifiers = <optimized out> > unmodified = <optimized out> > mask = <optimized out> > #3 parse_modifiers (symbol=0x5555564e3dc0) at /usr/src/debug/emacs/emacs-29.4-wayland/src/keyboard.c:6888 ^^^^^^^^^^^^^^^^^^^^^ Please show what is this symbol. Something like this: (gdb) source /path/to/emacs/src/.gdbinit (gdb) p symbol (gdb) xsymbol Also, what is the value of globals.f_Voverriding_plist_environment? ^ permalink raw reply [flat|nested] 18+ messages in thread
* bug#71744: 29.4; SIGSEGV during completion-at-point in lsp-mode with corfu and cape 2024-08-14 13:57 ` Eli Zaretskii @ 2024-08-14 15:40 ` Sigve Indregard via Bug reports for GNU Emacs, the Swiss army knife of text editors 2024-08-14 16:03 ` Eli Zaretskii 0 siblings, 1 reply; 18+ messages in thread From: Sigve Indregard via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2024-08-14 15:40 UTC (permalink / raw) To: Eli Zaretskii; +Cc: 71744 [-- Attachment #1.1: Type: text/plain, Size: 836 bytes --] On Wednesday, August 14th, 2024 at 15:57, Eli Zaretskii <eliz@gnu.org> wrote: > > #3 parse_modifiers (symbol=0x5555564e3dc0) at /usr/src/debug/emacs/emacs-29.4-wayland/src/keyboard.c:6888 > > ^^^^^^^^^^^^^^^^^^^^^ > Please show what is this symbol. Something like this: > > (gdb) source /path/to/emacs/src/.gdbinit > (gdb) p symbol > (gdb) xsymbol (gdb) frame 3 #3 parse_modifiers (symbol=XIL(0x5555564e3dc0)) at /usr/src/debug/emacs/emacs-29.4-wayland/src/keyboard.c:6888 6888 parse_modifiers (Lisp_Object symbol) (gdb) print symbol $11 = XIL(0x5555564e3dc0) (gdb) xsymbol $12 = (struct Lisp_Symbol *) 0xaaaaac1f1640 Cannot access memory at address 0xaaaaac1f1648 > Also, what is the value of globals.f_Voverriding_plist_environment? (gdb) p globals.f_Voverriding_plist_environment $13 = XIL(0) [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 249 bytes --] ^ permalink raw reply [flat|nested] 18+ messages in thread
* bug#71744: 29.4; SIGSEGV during completion-at-point in lsp-mode with corfu and cape 2024-08-14 15:40 ` Sigve Indregard via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2024-08-14 16:03 ` Eli Zaretskii 2024-08-14 16:22 ` Eli Zaretskii 0 siblings, 1 reply; 18+ messages in thread From: Eli Zaretskii @ 2024-08-14 16:03 UTC (permalink / raw) To: Sigve Indregard; +Cc: 71744 > Date: Wed, 14 Aug 2024 15:40:34 +0000 > From: Sigve Indregard <sigve.indregard@pm.me> > Cc: 71744@debbugs.gnu.org > > (gdb) frame 3 > #3 parse_modifiers (symbol=XIL(0x5555564e3dc0)) at /usr/src/debug/emacs/emacs-29.4-wayland/src/keyboard.c:6888 > 6888 parse_modifiers (Lisp_Object symbol) > (gdb) print symbol > $11 = XIL(0x5555564e3dc0) > (gdb) xsymbol > $12 = (struct Lisp_Symbol *) 0xaaaaac1f1640 > Cannot access memory at address 0xaaaaac1f1648 Hmm.. so we need to go up the callstack, but the interesting data there is all "optimized out". Can you reproduce this in Emacs built without optimizations (the -O0 switch to the compiler)? If so, please reproduce the problem and then do: (gdb) frame 5 (gdb) p idx (gdb) xtype If xtype says idx is a cons, try (gdb) pp idx to see the event's Lisp representation. ^ permalink raw reply [flat|nested] 18+ messages in thread
* bug#71744: 29.4; SIGSEGV during completion-at-point in lsp-mode with corfu and cape 2024-08-14 16:03 ` Eli Zaretskii @ 2024-08-14 16:22 ` Eli Zaretskii 2024-08-14 16:37 ` Sigve Indregard via Bug reports for GNU Emacs, the Swiss army knife of text editors ` (2 more replies) 0 siblings, 3 replies; 18+ messages in thread From: Eli Zaretskii @ 2024-08-14 16:22 UTC (permalink / raw) To: sigve.indregard; +Cc: 71744 > Cc: 71744@debbugs.gnu.org > Date: Wed, 14 Aug 2024 19:03:10 +0300 > From: Eli Zaretskii <eliz@gnu.org> > > > Date: Wed, 14 Aug 2024 15:40:34 +0000 > > From: Sigve Indregard <sigve.indregard@pm.me> > > Cc: 71744@debbugs.gnu.org > > > > (gdb) frame 3 > > #3 parse_modifiers (symbol=XIL(0x5555564e3dc0)) at /usr/src/debug/emacs/emacs-29.4-wayland/src/keyboard.c:6888 > > 6888 parse_modifiers (Lisp_Object symbol) > > (gdb) print symbol > > $11 = XIL(0x5555564e3dc0) > > (gdb) xsymbol > > $12 = (struct Lisp_Symbol *) 0xaaaaac1f1640 > > Cannot access memory at address 0xaaaaac1f1648 Btw, this 0x5555564e3dc0 value is the same as the pointer to old_kbd inside read_char: #7 read_char (commandflag=0, map=0x0, prev_event=0x0, used_mouse_menu=0x0, end_time=0x7fffffffb5b0) at /usr/src/debug/emacs/emacs-29.4-wayland/src/keyboard.c:3018 c = <optimized out> local_getcjmp = {{__jmpbuf = {93825000405056, -5147324661749537557, 1, 4611686019484352512, 5, 0, -5147324661946669845, -1313834696378178325}, __mask_was_saved = 0, __saved_mask = {__val = {0, 93825010269488, 93825104789632, 140737488335792, 18446744073709550936, 11, 93825104789616, 140737488335856, 140737279378894, 140737488335856, 140737488335920, 0, 140737488335920, 0, 93825010269488, 140737488336000}}}} save_jump = {{__jmpbuf = {12048, 140737188459256, 140737488335856, 93825095637120, 16, -7692597586030666240, 48, 1}, __mask_was_saved = 1453957408, __saved_mask = {__val = {140737488335776, 2, 140737488335824, 140737488335760, 140737321006214, 1, 140737321006651, 14319535557742690304, 6, 140737488335696, 140737279373914, 93825000331312, 0, 1, 1, 93823560581122}}}} tem = <optimized out> save = 0x0 previous_echo_area_message = 0x0 also_record = 0x0 reread = false recorded = false polling_stopped_here = false orig_kboard = 0x5555564e3dc0 <<<<<<<<<<<<<<<<<<<<<<< So either the value of orig_kboard here is bogus (perhaps due to optimizations), or somehow the variable C, which is supposed to hold an input event, holds something very different instead, and then it's a small surprise that we crash. Which version of what compiler did you use to build Emacs, and what were the compilation switches? ^ permalink raw reply [flat|nested] 18+ messages in thread
* bug#71744: 29.4; SIGSEGV during completion-at-point in lsp-mode with corfu and cape 2024-08-14 16:22 ` Eli Zaretskii @ 2024-08-14 16:37 ` Sigve Indregard via Bug reports for GNU Emacs, the Swiss army knife of text editors 2024-08-14 17:03 ` Pip Cet via Bug reports for GNU Emacs, the Swiss army knife of text editors 2024-08-15 9:07 ` Pip Cet via Bug reports for GNU Emacs, the Swiss army knife of text editors 2 siblings, 0 replies; 18+ messages in thread From: Sigve Indregard via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2024-08-14 16:37 UTC (permalink / raw) To: Eli Zaretskii; +Cc: 71744 [-- Attachment #1.1: Type: text/plain, Size: 1446 bytes --] > Which version of what compiler did you use to build Emacs, and what > were the compilation switches? This was from emacs-wayland Arch package for x86_64. It is compiled with GCC 14.1.1, according to the .comment section. Here is what emacs has recorded in `system-configuration-options`: "--with-pgtk --with-native-compilation=aot --sysconfdir=/etc --prefix=/usr --libexecdir=/usr/lib --with-tree-sitter --localstatedir=/var --with-cairo --disable-build-details --with-harfbuzz --with-libsystemd --with-modules 'CFLAGS=-march=x86-64 -mtune=generic -O2 -pipe -fno-plt -fexceptions -Wp,-D_FORTIFY_SOURCE=3 -Wformat -Werror=format-security -fstack-clash-protection -fcf-protection -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -g -ffile-prefix-map=/build/emacs/src=/usr/src/debug/emacs -flto=auto' 'LDFLAGS=-Wl,-O1 -Wl,--sort-common -Wl,--as-needed -Wl,-z,relro -Wl,-z,now -Wl,-z,pack-relative-relocs -flto=auto' 'CXXFLAGS=-march=x86-64 -mtune=generic -O2 -pipe -fno-plt -fexceptions -Wp,-D_FORTIFY_SOURCE=3 -Wformat -Werror=format-security -fstack-clash-protection -fcf-protection -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -Wp,-D_GLIBCXX_ASSERTIONS -g -ffile-prefix-map=/build/emacs/src=/usr/src/debug/emacs -flto=auto'" I am currently building a debug version without optimizations as well, I will get back to your other question when that is complete. [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 249 bytes --] ^ permalink raw reply [flat|nested] 18+ messages in thread
* bug#71744: 29.4; SIGSEGV during completion-at-point in lsp-mode with corfu and cape 2024-08-14 16:22 ` Eli Zaretskii 2024-08-14 16:37 ` Sigve Indregard via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2024-08-14 17:03 ` Pip Cet via Bug reports for GNU Emacs, the Swiss army knife of text editors 2024-08-15 9:07 ` Pip Cet via Bug reports for GNU Emacs, the Swiss army knife of text editors 2 siblings, 0 replies; 18+ messages in thread From: Pip Cet via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2024-08-14 17:03 UTC (permalink / raw) To: Eli Zaretskii; +Cc: sigve.indregard, 71744 "Eli Zaretskii" <eliz@gnu.org> writes: >> Cc: 71744@debbugs.gnu.org >> Date: Wed, 14 Aug 2024 19:03:10 +0300 >> From: Eli Zaretskii <eliz@gnu.org> >> >> > Date: Wed, 14 Aug 2024 15:40:34 +0000 >> > From: Sigve Indregard <sigve.indregard@pm.me> >> > Cc: 71744@debbugs.gnu.org >> > >> > (gdb) frame 3 >> > #3 parse_modifiers (symbol=XIL(0x5555564e3dc0)) at /usr/src/debug/emacs/emacs-29.4-wayland/src/keyboard.c:6888 >> > 6888 parse_modifiers (Lisp_Object symbol) >> > (gdb) print symbol >> > $11 = XIL(0x5555564e3dc0) >> > (gdb) xsymbol >> > $12 = (struct Lisp_Symbol *) 0xaaaaac1f1640 >> > Cannot access memory at address 0xaaaaac1f1648 > > Btw, this 0x5555564e3dc0 value is the same as the pointer to old_kbd > inside read_char: > > #7 read_char (commandflag=0, map=0x0, prev_event=0x0, used_mouse_menu=0x0, end_time=0x7fffffffb5b0) at /usr/src/debug/emacs/emacs-29.4-wayland/src/keyboard.c:3018 > c = <optimized out> > local_getcjmp = {{__jmpbuf = {93825000405056, -5147324661749537557, 1, 4611686019484352512, 5, 0, -5147324661946669845, -1313834696378178325}, __mask_was_saved = 0, __saved_mask = {__val = {0, 93825010269488, 93825104789632, 140737488335792, 18446744073709550936, 11, 93825104789616, 140737488335856, 140737279378894, 140737488335856, 140737488335920, 0, 140737488335920, 0, 93825010269488, 140737488336000}}}} > save_jump = {{__jmpbuf = {12048, 140737188459256, 140737488335856, 93825095637120, 16, -7692597586030666240, 48, 1}, __mask_was_saved = 1453957408, __saved_mask = {__val = {140737488335776, 2, 140737488335824, 140737488335760, 140737321006214, 1, 140737321006651, 14319535557742690304, 6, 140737488335696, 140737279373914, 93825000331312, 0, 1, 1, 93823560581122}}}} > tem = <optimized out> > save = 0x0 > previous_echo_area_message = 0x0 > also_record = 0x0 > reread = false > recorded = false > polling_stopped_here = false > orig_kboard = 0x5555564e3dc0 <<<<<<<<<<<<<<<<<<<<<<< > > So either the value of orig_kboard here is bogus (perhaps due to > optimizations), or somehow the variable C, which is supposed to hold > an input event, holds something very different instead, and then it's > a small surprise that we crash. I think this looks like a setjmp-related bug. If this sys_setjmp in read_char: specpdl_ref jmpcount = SPECPDL_INDEX (); if (sys_setjmp (local_getcjmp)) { /* Handle quits while reading the keyboard. */ returns true, we goto non_reread, where we test NILP (c). However, 'c' is not declared volatile, and it might have changed, which would lead to undefined behavior, including the possibility of holding another value like orig_kboard. I'm afraid the only way to know for sure whether there's anything to that theory is to look at the output of "disass/rs read_char" in gdb, using the exact same binary that crashed, and check it line by line (about 3,000 lines here...) Pip ^ permalink raw reply [flat|nested] 18+ messages in thread
* bug#71744: 29.4; SIGSEGV during completion-at-point in lsp-mode with corfu and cape 2024-08-14 16:22 ` Eli Zaretskii 2024-08-14 16:37 ` Sigve Indregard via Bug reports for GNU Emacs, the Swiss army knife of text editors 2024-08-14 17:03 ` Pip Cet via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2024-08-15 9:07 ` Pip Cet via Bug reports for GNU Emacs, the Swiss army knife of text editors 2024-08-16 15:08 ` Pip Cet via Bug reports for GNU Emacs, the Swiss army knife of text editors 2 siblings, 1 reply; 18+ messages in thread From: Pip Cet via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2024-08-15 9:07 UTC (permalink / raw) To: Eli Zaretskii; +Cc: sigve.indregard, 71744 Pip Cet <pipcet@protonmail.com> writes: > "Eli Zaretskii" <eliz@gnu.org> writes: > >>> Cc: 71744@debbugs.gnu.org >>> Date: Wed, 14 Aug 2024 19:03:10 +0300 >>> From: Eli Zaretskii <eliz@gnu.org> >>> >>> > Date: Wed, 14 Aug 2024 15:40:34 +0000 >>> > From: Sigve Indregard <sigve.indregard@pm.me> >>> > Cc: 71744@debbugs.gnu.org >>> > >>> > (gdb) frame 3 >>> > #3 parse_modifiers (symbol=XIL(0x5555564e3dc0)) at /usr/src/debug/emacs/emacs-29.4-wayland/src/keyboard.c:6888 >>> > 6888 parse_modifiers (Lisp_Object symbol) >>> > (gdb) print symbol >>> > $11 = XIL(0x5555564e3dc0) >>> > (gdb) xsymbol >>> > $12 = (struct Lisp_Symbol *) 0xaaaaac1f1640 >>> > Cannot access memory at address 0xaaaaac1f1648 >> >> Btw, this 0x5555564e3dc0 value is the same as the pointer to old_kbd >> inside read_char: >> >> #7 read_char (commandflag=0, map=0x0, prev_event=0x0, used_mouse_menu=0x0, end_time=0x7fffffffb5b0) at /usr/src/debug/emacs/emacs-29.4-wayland/src/keyboard.c:3018 >> c = <optimized out> >> local_getcjmp = {{__jmpbuf = {93825000405056, -5147324661749537557, 1, 4611686019484352512, 5, 0, -5147324661946669845, -1313834696378178325}, __mask_was_saved = 0, __saved_mask = {__val = {0, 93825010269488, 93825104789632, 140737488335792, 18446744073709550936, 11, 93825104789616, 140737488335856, 140737279378894, 140737488335856, 140737488335920, 0, 140737488335920, 0, 93825010269488, 140737488336000}}}} >> save_jump = {{__jmpbuf = {12048, 140737188459256, 140737488335856, 93825095637120, 16, -7692597586030666240, 48, 1}, __mask_was_saved = 1453957408, __saved_mask = {__val = {140737488335776, 2, 140737488335824, 140737488335760, 140737321006214, 1, 140737321006651, 14319535557742690304, 6, 140737488335696, 140737279373914, 93825000331312, 0, 1, 1, 93823560581122}}}} >> tem = <optimized out> >> save = 0x0 >> previous_echo_area_message = 0x0 >> also_record = 0x0 >> reread = false >> recorded = false >> polling_stopped_here = false >> orig_kboard = 0x5555564e3dc0 <<<<<<<<<<<<<<<<<<<<<<< >> >> So either the value of orig_kboard here is bogus (perhaps due to >> optimizations), or somehow the variable C, which is supposed to hold >> an input event, holds something very different instead, and then it's >> a small surprise that we crash. > > I think this looks like a setjmp-related bug. If this sys_setjmp in > read_char: > > specpdl_ref jmpcount = SPECPDL_INDEX (); > if (sys_setjmp (local_getcjmp)) > { > /* Handle quits while reading the keyboard. */ > > returns true, we goto non_reread, where we test NILP (c). However, 'c' > is not declared volatile, and it might have changed, which would lead to > undefined behavior, including the possibility of holding another value > like orig_kboard. > > I'm afraid the only way to know for sure whether there's anything to > that theory is to look at the output of "disass/rs read_char" in gdb, > using the exact same binary that crashed, and check it line by line > (about 3,000 lines here...) I've done that now, and the bug is as I've described: the location -0x4e8(%rbp) sometimes holds orig_kboard, but is assumed to hold 'c' after a longjmp. This should fix it: diff --git a/src/keyboard.c b/src/keyboard.c index b312d529e59..148b9ee4dbf 100644 --- a/src/keyboard.c +++ b/src/keyboard.c @@ -2522,7 +2522,7 @@ read_char (int commandflag, Lisp_Object map, Lisp_Object prev_event, bool *used_mouse_menu, struct timespec *end_time) { - Lisp_Object c; + volatile Lisp_Object c; sys_jmp_buf local_getcjmp; sys_jmp_buf save_jump; Lisp_Object tem, save; But it'd be really nice to recreate the buggy build and apply just this patch and see whether that fixes things. Unfortunately, Arch builds are very hard to reproduce precisely, so I'm not sure I can do it. Pip ^ permalink raw reply related [flat|nested] 18+ messages in thread
* bug#71744: 29.4; SIGSEGV during completion-at-point in lsp-mode with corfu and cape 2024-08-15 9:07 ` Pip Cet via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2024-08-16 15:08 ` Pip Cet via Bug reports for GNU Emacs, the Swiss army knife of text editors 2024-08-17 4:37 ` Paul Eggert 0 siblings, 1 reply; 18+ messages in thread From: Pip Cet via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2024-08-16 15:08 UTC (permalink / raw) To: Eli Zaretskii; +Cc: sigve.indregard, Paul Eggert, 71744 "Pip Cet" <pipcet@protonmail.com> writes: > Pip Cet <pipcet@protonmail.com> writes: > >> "Eli Zaretskii" <eliz@gnu.org> writes: >> >>>> Cc: 71744@debbugs.gnu.org >>>> Date: Wed, 14 Aug 2024 19:03:10 +0300 >>>> From: Eli Zaretskii <eliz@gnu.org> >>>> >>>> > Date: Wed, 14 Aug 2024 15:40:34 +0000 >>>> > From: Sigve Indregard <sigve.indregard@pm.me> >>>> > Cc: 71744@debbugs.gnu.org >>>> > >>>> > (gdb) frame 3 >>>> > #3 parse_modifiers (symbol=XIL(0x5555564e3dc0)) at /usr/src/debug/emacs/emacs-29.4-wayland/src/keyboard.c:6888 >>>> > 6888 parse_modifiers (Lisp_Object symbol) >>>> > (gdb) print symbol >>>> > $11 = XIL(0x5555564e3dc0) >>>> > (gdb) xsymbol >>>> > $12 = (struct Lisp_Symbol *) 0xaaaaac1f1640 >>>> > Cannot access memory at address 0xaaaaac1f1648 >>> >>> Btw, this 0x5555564e3dc0 value is the same as the pointer to old_kbd >>> inside read_char: >>> >>> #7 read_char (commandflag=0, map=0x0, prev_event=0x0, used_mouse_menu=0x0, end_time=0x7fffffffb5b0) at /usr/src/debug/emacs/emacs-29.4-wayland/src/keyboard.c:3018 >>> c = <optimized out> >>> local_getcjmp = {{__jmpbuf = {93825000405056, -5147324661749537557, 1, 4611686019484352512, 5, 0, -5147324661946669845, -1313834696378178325}, __mask_was_saved = 0, __saved_mask = {__val = {0, 93825010269488, 93825104789632, 140737488335792, 18446744073709550936, 11, 93825104789616, 140737488335856, 140737279378894, 140737488335856, 140737488335920, 0, 140737488335920, 0, 93825010269488, 140737488336000}}}} >>> save_jump = {{__jmpbuf = {12048, 140737188459256, 140737488335856, 93825095637120, 16, -7692597586030666240, 48, 1}, __mask_was_saved = 1453957408, __saved_mask = {__val = {140737488335776, 2, 140737488335824, 140737488335760, 140737321006214, 1, 140737321006651, 14319535557742690304, 6, 140737488335696, 140737279373914, 93825000331312, 0, 1, 1, 93823560581122}}}} >>> tem = <optimized out> >>> save = 0x0 >>> previous_echo_area_message = 0x0 >>> also_record = 0x0 >>> reread = false >>> recorded = false >>> polling_stopped_here = false >>> orig_kboard = 0x5555564e3dc0 <<<<<<<<<<<<<<<<<<<<<<< >>> >>> So either the value of orig_kboard here is bogus (perhaps due to >>> optimizations), or somehow the variable C, which is supposed to hold >>> an input event, holds something very different instead, and then it's >>> a small surprise that we crash. >> >> I think this looks like a setjmp-related bug. If this sys_setjmp in >> read_char: >> >> specpdl_ref jmpcount = SPECPDL_INDEX (); >> if (sys_setjmp (local_getcjmp)) >> { >> /* Handle quits while reading the keyboard. */ >> >> returns true, we goto non_reread, where we test NILP (c). However, 'c' >> is not declared volatile, and it might have changed, which would lead to >> undefined behavior, including the possibility of holding another value >> like orig_kboard. >> >> I'm afraid the only way to know for sure whether there's anything to >> that theory is to look at the output of "disass/rs read_char" in gdb, >> using the exact same binary that crashed, and check it line by line >> (about 3,000 lines here...) > > I've done that now, and the bug is as I've described: the location > -0x4e8(%rbp) sometimes holds orig_kboard, but is assumed to hold 'c' > after a longjmp. > > This should fix it: > > diff --git a/src/keyboard.c b/src/keyboard.c > index b312d529e59..148b9ee4dbf 100644 > --- a/src/keyboard.c > +++ b/src/keyboard.c > @@ -2522,7 +2522,7 @@ read_char (int commandflag, Lisp_Object map, > Lisp_Object prev_event, > bool *used_mouse_menu, struct timespec *end_time) > { > - Lisp_Object c; > + volatile Lisp_Object c; > sys_jmp_buf local_getcjmp; > sys_jmp_buf save_jump; > Lisp_Object tem, save; > > > But it'd be really nice to recreate the buggy build and apply just this > patch and see whether that fixes things. Unfortunately, Arch builds are > very hard to reproduce precisely, so I'm not sure I can do it. The whole thing should have resulted in a compiler warning, of course, but there's this code in keyboard.c: /* Work around GCC bug 54561. */ #if GNUC_PREREQ (4, 3, 0) # pragma GCC diagnostic ignored "-Wclobbered" #endif which means we won't get any warnings at all about such bugs. However, even with that part removed, I don't get a compiler warning about 'c'. The code is also rather weird: 0x00000000001254a0 <+5456>: 48 8b 05 a1 17 75 00 mov 0x7517a1(%rip),%rax # 0x876c48 <all_kboards.lto_priv.0> 0x00000000001254a7 <+5463>: 48 89 85 18 fb ff ff mov %rax,-0x4e8(%rbp) 0x00000000001254ae <+5470>: 48 85 c0 test %rax,%rax 0x00000000001254b1 <+5473>: 0f 84 3a f5 ff ff je 0x1249f1 <read_char+2721> 0x00000000001254b7 <+5479>: 48 8b 85 18 fb ff ff mov -0x4e8(%rbp),%rax (There is no branch to +5470, +5473, or +5479). What's weird about this is that the store at +5463 that's causing our problem isn't necessary, and neither is the load at +5479. The variable in question, 'kb', is not marked volatile, so it seems strange to me it's stored, then loaded, unnecessarily. Paul, do you agree that we should simply mark 'c' as volatile, or do you think this needs further investigation on the GCC side (because of the lack of a -Wclobbered warning being issued, or because of the weird code)? Pip ^ permalink raw reply [flat|nested] 18+ messages in thread
* bug#71744: 29.4; SIGSEGV during completion-at-point in lsp-mode with corfu and cape 2024-08-16 15:08 ` Pip Cet via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2024-08-17 4:37 ` Paul Eggert 2024-08-17 6:14 ` Eli Zaretskii 2024-08-17 7:46 ` Pip Cet via Bug reports for GNU Emacs, the Swiss army knife of text editors 0 siblings, 2 replies; 18+ messages in thread From: Paul Eggert @ 2024-08-17 4:37 UTC (permalink / raw) To: Pip Cet, Eli Zaretskii; +Cc: sigve.indregard, 71744 [-- Attachment #1: Type: text/plain, Size: 2475 bytes --] On 2024-08-16 08:08, Pip Cet wrote: > /* Work around GCC bug 54561. */ > #if GNUC_PREREQ (4, 3, 0) > # pragma GCC diagnostic ignored "-Wclobbered" > #endif > > which means we won't get any warnings at all about such bugs. > > However, even with that part removed, I don't get a compiler warning > about 'c'. With that part removed I got a warning about 'kb', not 'c'. The 'kb' warning was a false positive, the 'c' warning a false negative. The most likely explanation, I think, is that GCC got confused and put the wrong identifier name in its diagnostic. This would help to explain a lot of the -Wclobbered false positives we've gotten over the years, which has caused us to ignore -Wclobbered. > What's weird about this is that the store at +5463 that's causing our > problem isn't necessary, and neither is the load at +5479. The variable > in question, 'kb', is not marked volatile, so it seems strange to me it's > stored, then loaded, unnecessarily. My guess is that GCC internally coalesced the two variables, and got confused because one was clobbered and the other was not, and issued a warning that it clobbered the variable but mistakenly said 'kb' not 'c'. The C standard entitles GCC to clobber 'c' so this isn't wrong code, it's just a bad (a *really* bad) diagnostic. > Paul, do you agree that we should simply mark 'c' as volatile, or do you > think this needs further investigation on the GCC side (because of the > lack of a -Wclobbered warning being issued, or because of the weird > code)? We definitely should mark 'c' as volatile, or do something equivalent, because the Emacs code violates the C standard. Also, if my hypothesis of the mistaken identifier is correct, we should stop ignoring -Wclobbered, and instead pacify GCC without using -Wclobbered. That way, when we screw up in setjmp related code, we'll get *some* warning that *something* is being clobbered, and can investigate. To do that, I installed the attached patches into the Emacs master branch. While looking into this I noticed several uses of clobbered variables (i.e., violations of the C standard) and fixed them. Patches 0001-0004 fix these similar bugs elsewhere. Patch 0005 implements your suggestion and should fix Bug#71744. Patch 0006 is a minor performance improvement over Patch 0005. Please give these patches a try. Patch 0005 is simple and if it works for the original bug reporter we should be able to close the bug report as fixed. [-- Attachment #2: 0001-Don-t-ignore-Wclobbered-in-bytecode.c.patch --] [-- Type: text/x-patch, Size: 3451 bytes --] From 2169a9387a5ac22b969d37ece4ec1aaa0fd830d9 Mon Sep 17 00:00:00 2001 From: Paul Eggert <eggert@cs.ucla.edu> Date: Fri, 16 Aug 2024 16:29:51 -0700 Subject: [PATCH 1/6] =?UTF-8?q?Don=E2=80=99t=20ignore=20-Wclobbered=20in?= =?UTF-8?q?=20bytecode.c?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit This fix is prompted by Emacs bug#71744. The working hypothesis is that there are some bugs in Emacs, and some in GCC’s diagnostics, and that this patch fixes the Emacs bugs and works around the GCC diagnostic bugs. The hypothesis is that GCC diagnostic bugs occur when GCC coalesces variables or temporaries and some variables are clobbered by setjmp and some vars/temps are not. Part of this hypothesis involves GCC diagnosing the wrong variables. Instead of ignoring the diagnostics, which the hypothesis suggests indicate either problems in Emacs or in GCC, fix the Emacs bugs and pacify the GCC false positives, with comments about the GCC bugs. GCC’s true positives are helpful enough in squashing obscure bugs like Emacs bug#71744, that it’s worth going to some effort to pacify -Wclobbered instead of ignoring it. * src/bytecode.c: Do not ignore -Wclobbered. (exec_byte_code): Fix violations of the C standard, where setjmp clobbered quitcounter and bc. If GCC_LINT && __GNUC__ && !__clang__, work around GCC -Wclobbered warnings for bytestr_data and vectorp. --- src/bytecode.c | 24 +++++++++++++++++++----- 1 file changed, 19 insertions(+), 5 deletions(-) diff --git a/src/bytecode.c b/src/bytecode.c index ce075c86afd..48a29c22d55 100644 --- a/src/bytecode.c +++ b/src/bytecode.c @@ -29,11 +29,6 @@ #include "window.h" #include "puresize.h" -/* Work around GCC bug 54561. */ -#if GNUC_PREREQ (4, 3, 0) -# pragma GCC diagnostic ignored "-Wclobbered" -#endif - /* Define BYTE_CODE_SAFE true to enable some minor sanity checking, useful for debugging the byte compiler. It defaults to false. */ @@ -536,6 +531,12 @@ exec_byte_code (Lisp_Object fun, ptrdiff_t args_template, for (ptrdiff_t i = nargs - rest; i < nonrest; i++) PUSH (Qnil); + unsigned char volatile saved_quitcounter; +#if GCC_LINT && __GNUC__ && !__clang__ + Lisp_Object *volatile saved_vectorp; + unsigned char const *volatile saved_bytestr_data; +#endif + while (true) { int op; @@ -967,15 +968,23 @@ #define DEFINE(name, value) [name] = &&insn_ ## name, if (sys_setjmp (c->jmp)) { + quitcounter = saved_quitcounter; struct handler *c = handlerlist; handlerlist = c->next; top = c->bytecode_top; op = c->bytecode_dest; + bc = ¤t_thread->bc; struct bc_frame *fp = bc->fp; Lisp_Object fun = fp->fun; Lisp_Object bytestr = AREF (fun, CLOSURE_CODE); Lisp_Object vector = AREF (fun, CLOSURE_CONSTANTS); +#if GCC_LINT && __GNUC__ && !__clang__ + /* These useless assignments pacify GCC 14.2.1 x86-64 + <https://gcc.gnu.org/bugzilla/show_bug.cgi?id=21161>. */ + bytestr_data = saved_bytestr_data; + vectorp = saved_vectorp; +#endif bytestr_data = SDATA (bytestr); vectorp = XVECTOR (vector)->contents; if (BYTE_CODE_SAFE) @@ -989,6 +998,11 @@ #define DEFINE(name, value) [name] = &&insn_ ## name, goto op_branch; } + saved_quitcounter = quitcounter; +#if GCC_LINT && __GNUC__ && !__clang__ + saved_vectorp = vectorp; + saved_bytestr_data = bytestr_data; +#endif NEXT; } -- 2.43.0 [-- Attachment #3: 0002-Don-t-ignore-Wclobbered-in-emacs-module.c.patch --] [-- Type: text/x-patch, Size: 3138 bytes --] From cfa5a634e91f5c232a71ec212679165074dc480b Mon Sep 17 00:00:00 2001 From: Paul Eggert <eggert@cs.ucla.edu> Date: Fri, 16 Aug 2024 16:59:08 -0700 Subject: [PATCH 2/6] =?UTF-8?q?Don=E2=80=99t=20ignore=20-Wclobbered=20in?= =?UTF-8?q?=20emacs-module.c?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit This fix is also prompted by Emacs bug#71744. * src/emacs-module.c: Do not ignore -Wclobbered. (MODULE_HANDLE_NONLOCAL_EXIT): Fix violations of the C standard, where setjmp clobbered env and internal_cleanup. (module_extract_big_integer) [GCC_LINT && __GNUC__ && !__clang__]: Work around GCC -Wclobbered false positive for ‘sign’. --- src/emacs-module.c | 27 +++++++++++++++++---------- 1 file changed, 17 insertions(+), 10 deletions(-) diff --git a/src/emacs-module.c b/src/emacs-module.c index 05aa0baef74..5aa4cfa0ae8 100644 --- a/src/emacs-module.c +++ b/src/emacs-module.c @@ -96,11 +96,6 @@ Copyright (C) 2015-2024 Free Software Foundation, Inc. #include <intprops.h> #include <verify.h> -/* Work around GCC bug 83162. */ -#if GNUC_PREREQ (4, 3, 0) -# pragma GCC diagnostic ignored "-Wclobbered" -#endif - /* We use different strategies for allocating the user-visible objects (struct emacs_runtime, emacs_env, emacs_value), depending on whether the user supplied the -module-assertions flag. If @@ -273,14 +268,17 @@ #define MODULE_HANDLE_NONLOCAL_EXIT(retval) \ module_out_of_memory (env); \ return retval; \ } \ - struct handler *internal_cleanup \ + emacs_env *env_volatile = env; \ + struct handler *volatile internal_cleanup \ = internal_handler; \ - if (sys_setjmp (internal_cleanup->jmp)) \ + if (sys_setjmp (internal_handler->jmp)) \ { \ + emacs_env *env = env_volatile; \ + struct handler *internal_handler = internal_cleanup; \ module_handle_nonlocal_exit (env, \ - internal_cleanup->nonlocal_exit, \ - internal_cleanup->val); \ - module_reset_handlerlist (internal_cleanup); \ + internal_handler->nonlocal_exit, \ + internal_handler->val); \ + module_reset_handlerlist (internal_handler); \ return retval; \ } \ do { } while (false) @@ -1045,6 +1043,15 @@ verify ((sizeof (emacs_limb_t) == 4 && EMACS_LIMB_MAX == 0xFFFFFFFF) module_extract_big_integer (emacs_env *env, emacs_value arg, int *sign, ptrdiff_t *count, emacs_limb_t *magnitude) { +#if GCC_LINT && __GNUC__ && !__clang__ + /* These useless assignments pacify GCC 14.2.1 x86-64 + <https://gcc.gnu.org/bugzilla/show_bug.cgi?id=21161>. */ + { + int *volatile sign_volatile = sign; + sign = sign_volatile; + } +#endif + MODULE_FUNCTION_BEGIN (false); Lisp_Object o = value_to_lisp (arg); CHECK_INTEGER (o); -- 2.43.0 [-- Attachment #4: 0003-Don-t-ignore-Wclobbered-in-eval.c.patch --] [-- Type: text/x-patch, Size: 7071 bytes --] From 1282714da55cd4bbc1c7f2e49edeb43503427e5e Mon Sep 17 00:00:00 2001 From: Paul Eggert <eggert@cs.ucla.edu> Date: Fri, 16 Aug 2024 17:08:36 -0700 Subject: [PATCH 3/6] =?UTF-8?q?Don=E2=80=99t=20ignore=20-Wclobbered=20in?= =?UTF-8?q?=20eval.c?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit This fix is also prompted by Emacs bug#71744. * src/eval.c (CACHEABLE): Remove. All uses removed. Do not ignore -Wclobbered. (internal_lisp_condition_case): Fix violations of the C standard, where setjmp clobbered oldhandlerlist, var, and clauses. Rewrite to pacify GCC, by using a sentinel rather than a count, which GCC incorrectly complained about, and by coalescing some duplicate code. If GCC_LINT && __GNUC__ && !__clang__ add a useless assignment to pacify GCC. --- src/eval.c | 109 +++++++++++++++++++++++------------------------------ 1 file changed, 47 insertions(+), 62 deletions(-) diff --git a/src/eval.c b/src/eval.c index b4103acd28f..ce7b08e894a 100644 --- a/src/eval.c +++ b/src/eval.c @@ -31,15 +31,6 @@ Copyright (C) 1985-1987, 1993-1995, 1999-2024 Free Software Foundation, #include "pdumper.h" #include "atimer.h" -/* CACHEABLE is ordinarily nothing, except it is 'volatile' if - necessary to cajole GCC into not warning incorrectly that a - variable should be volatile. */ -#if defined GCC_LINT || defined lint -# define CACHEABLE volatile -#else -# define CACHEABLE /* empty */ -#endif - /* Non-nil means record all fset's and provide's, to be undone if the file being autoloaded is not fully loaded. They are recorded by being consed onto the front of Vautoload_queue: @@ -430,7 +421,7 @@ DEFUN ("progn", Fprogn, Sprogn, 0, UNEVALLED, 0, usage: (progn BODY...) */) (Lisp_Object body) { - Lisp_Object CACHEABLE val = Qnil; + Lisp_Object val = Qnil; while (CONSP (body)) { @@ -1257,12 +1248,6 @@ DEFUN ("catch", Fcatch, Scatch, 1, UNEVALLED, 0, return internal_catch (tag, Fprogn, XCDR (args)); } -/* Work around GCC bug 61118 - <https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61118>. */ -#if GNUC_PREREQ (4, 9, 0) -# pragma GCC diagnostic ignored "-Wclobbered" -#endif - /* Assert that E is true, but do not evaluate E. Use this instead of eassert (E) when E contains variables that might be clobbered by a longjmp. */ @@ -1488,8 +1473,10 @@ DEFUN ("handler-bind-1", Fhandler_bind_1, Shandler_bind_1, 1, MANY, 0, internal_lisp_condition_case (Lisp_Object var, Lisp_Object bodyform, Lisp_Object handlers) { - struct handler *oldhandlerlist = handlerlist; - ptrdiff_t CACHEABLE clausenb = 0; + struct handler *volatile oldhandlerlist = handlerlist; + + /* The number of non-success handlers, plus 1 for a sentinel. */ + ptrdiff_t clausenb = 1; var = maybe_remove_pos_from_symbol (var); CHECK_TYPE (BARE_SYMBOL_P (var), Qsymbolp, var); @@ -1521,69 +1508,67 @@ internal_lisp_condition_case (Lisp_Object var, Lisp_Object bodyform, memory_full (SIZE_MAX); Lisp_Object volatile *clauses = alloca (clausenb * sizeof *clauses); clauses += clausenb; + *--clauses = make_fixnum (0); for (Lisp_Object tail = handlers; CONSP (tail); tail = XCDR (tail)) { Lisp_Object tem = XCAR (tail); if (!(CONSP (tem) && EQ (XCAR (tem), QCsuccess))) *--clauses = tem; } - for (ptrdiff_t i = 0; i < clausenb; i++) + Lisp_Object volatile var_volatile = var; + Lisp_Object val, handler_body; + for (Lisp_Object volatile *pcl = clauses; ; pcl++) { - Lisp_Object clause = clauses[i]; + if (BASE_EQ (*pcl, make_fixnum (0))) + { + val = eval_sub (bodyform); + handlerlist = oldhandlerlist; + if (NILP (success_handler)) + return val; +#if GCC_LINT && __GNUC__ && !__clang__ + /* This useless assignment pacifies GCC 14.2.1 x86-64 + <https://gcc.gnu.org/bugzilla/show_bug.cgi?id=21161>. */ + var = var_volatile; +#endif + handler_body = XCDR (success_handler); + break; + } + Lisp_Object clause = *pcl; Lisp_Object condition = CONSP (clause) ? XCAR (clause) : Qnil; if (!CONSP (condition)) condition = list1 (condition); struct handler *c = push_handler (condition, CONDITION_CASE); + Lisp_Object volatile *clauses_volatile = clauses; if (sys_setjmp (c->jmp)) { - Lisp_Object val = handlerlist->val; - Lisp_Object volatile *chosen_clause = clauses; - for (struct handler *h = handlerlist->next; h != oldhandlerlist; - h = h->next) + var = var_volatile; + val = handlerlist->val; + Lisp_Object volatile *chosen_clause = clauses_volatile; + struct handler *oldh = oldhandlerlist; + for (struct handler *h = handlerlist->next; h != oldh; h = h->next) chosen_clause++; - Lisp_Object handler_body = XCDR (*chosen_clause); - handlerlist = oldhandlerlist; - - if (NILP (var)) - return Fprogn (handler_body); + handler_body = XCDR (*chosen_clause); + handlerlist = oldh; - Lisp_Object handler_var = var; - if (!NILP (Vinternal_interpreter_environment)) - { - val = Fcons (Fcons (var, val), - Vinternal_interpreter_environment); - handler_var = Qinternal_interpreter_environment; - } - - /* Bind HANDLER_VAR to VAL while evaluating HANDLER_BODY. - The unbind_to undoes just this binding; whoever longjumped - to us unwound the stack to C->pdlcount before throwing. */ - specpdl_ref count = SPECPDL_INDEX (); - specbind (handler_var, val); - return unbind_to (count, Fprogn (handler_body)); + /* Whoever longjumped to us unwound the stack to C->pdlcount before + throwing, so the unbind_to will undo just this binding. */ + break; } } - Lisp_Object CACHEABLE result = eval_sub (bodyform); - handlerlist = oldhandlerlist; - if (!NILP (success_handler)) - { - if (NILP (var)) - return Fprogn (XCDR (success_handler)); + if (NILP (var)) + return Fprogn (handler_body); - Lisp_Object handler_var = var; - if (!NILP (Vinternal_interpreter_environment)) - { - result = Fcons (Fcons (var, result), - Vinternal_interpreter_environment); - handler_var = Qinternal_interpreter_environment; - } - - specpdl_ref count = SPECPDL_INDEX (); - specbind (handler_var, result); - return unbind_to (count, Fprogn (XCDR (success_handler))); + if (!NILP (Vinternal_interpreter_environment)) + { + val = Fcons (Fcons (var, val), + Vinternal_interpreter_environment); + var = Qinternal_interpreter_environment; } - return result; + + specpdl_ref count = SPECPDL_INDEX (); + specbind (var, val); + return unbind_to (count, Fprogn (handler_body)); } /* Call the function BFUN with no arguments, catching errors within it @@ -1740,7 +1725,7 @@ push_handler (Lisp_Object tag_ch_val, enum handlertype handlertype) struct handler * push_handler_nosignal (Lisp_Object tag_ch_val, enum handlertype handlertype) { - struct handler *CACHEABLE c = handlerlist->nextfree; + struct handler *c = handlerlist->nextfree; if (!c) { c = malloc (sizeof *c); -- 2.43.0 [-- Attachment #5: 0004-Don-t-ignore-Wclobbered-in-image.c.patch --] [-- Type: text/x-patch, Size: 5402 bytes --] From 3b24ac538858d994a74826361a1af3f802dd065a Mon Sep 17 00:00:00 2001 From: Paul Eggert <eggert@cs.ucla.edu> Date: Fri, 16 Aug 2024 17:19:12 -0700 Subject: [PATCH 4/6] =?UTF-8?q?Don=E2=80=99t=20ignore=20-Wclobbered=20in?= =?UTF-8?q?=20image.c?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit This fix is also prompted by Emacs bug#71744. * src/image.c: Do not ignore -Wclobbered. (png_load_body): Fix violations of the C standard, where setjmp clobbered c. Move mask_img decl to pacify GCC. (jpeg_load_body): Don’t make fp volatile; solve that problem in a better way, via a new fp_volatile local. Fix violations of the C standard, where setjmp clobbered mgr, img, and ximg. If __GNUC__ && !__clang__, add useless assignments to pacify GCC. --- src/image.c | 44 +++++++++++++++++++++++++++++++++++--------- 1 file changed, 35 insertions(+), 9 deletions(-) diff --git a/src/image.c b/src/image.c index 3965a6ce6f8..48694a13341 100644 --- a/src/image.c +++ b/src/image.c @@ -63,11 +63,6 @@ Copyright (C) 1989-2024 Free Software Foundation, Inc. #include TERM_HEADER #endif /* HAVE_WINDOW_SYSTEM */ -/* Work around GCC bug 54561. */ -#if GNUC_PREREQ (4, 3, 0) -# pragma GCC diagnostic ignored "-Wclobbered" -#endif - #ifdef HAVE_X_WINDOWS typedef struct x_bitmap_record Bitmap_Record; #ifndef USE_CAIRO @@ -8188,7 +8183,7 @@ png_load_body (struct frame *f, struct image *img, struct png_load_context *c) bool transparent_p; struct png_memory_storage tbr; /* Data to be read */ ptrdiff_t nbytes; - Emacs_Pix_Container ximg, mask_img = NULL; + Emacs_Pix_Container ximg; /* Find out what file to load. */ specified_file = image_spec_value (img->spec, QCfile, NULL); @@ -8279,9 +8274,12 @@ png_load_body (struct frame *f, struct image *img, struct png_load_context *c) /* Set error jump-back. We come back here when the PNG library detects an error. */ + + struct png_load_context *volatile c_volatile = c; if (FAST_SETJMP (PNG_JMPBUF (png_ptr))) { error: + c = c_volatile; if (c->png_ptr) png_destroy_read_struct (&c->png_ptr, &c->info_ptr, &c->end_info); xfree (c->pixels); @@ -8291,6 +8289,13 @@ png_load_body (struct frame *f, struct image *img, struct png_load_context *c) return 0; } +#if GCC_LINT && __GNUC__ && !__clang__ + /* These useless assignments pacify GCC 14.2.1 x86-64 + <https://gcc.gnu.org/bugzilla/show_bug.cgi?id=21161>. */ + c = c_volatile; + fp = c->fp; +#endif + /* Read image info. */ if (!NILP (specified_data)) png_set_read_fn (png_ptr, &tbr, png_read_from_memory); @@ -8417,6 +8422,7 @@ png_load_body (struct frame *f, struct image *img, struct png_load_context *c) /* Create an image and pixmap serving as mask if the PNG image contains an alpha channel. */ + Emacs_Pix_Container mask_img = NULL; if (channels == 4 && transparent_p && !image_create_x_image_and_pixmap (f, img, width, height, 1, @@ -8912,13 +8918,13 @@ jpeg_load_body (struct frame *f, struct image *img, struct my_jpeg_error_mgr *mgr) { Lisp_Object specified_file, specified_data; - FILE *volatile fp = NULL; + FILE *fp = NULL; JSAMPARRAY buffer; int row_stride, x, y; int width, height; int i, ir, ig, ib; unsigned long *colors; - Emacs_Pix_Container ximg = NULL; + Emacs_Pix_Container volatile ximg_volatile = NULL; /* Open the JPEG file. */ specified_file = image_spec_value (img->spec, QCfile, NULL); @@ -8953,8 +8959,15 @@ jpeg_load_body (struct frame *f, struct image *img, error is detected. This function will perform a longjmp. */ mgr->cinfo.err = jpeg_std_error (&mgr->pub); mgr->pub.error_exit = my_error_exit; + struct my_jpeg_error_mgr *volatile mgr_volatile = mgr; + struct image *volatile img_volatile = img; + FILE *volatile fp_volatile = fp; if (sys_setjmp (mgr->setjmp_buffer)) { + mgr = mgr_volatile; + img = img_volatile; + fp = fp_volatile; + switch (mgr->failure_code) { case MY_JPEG_ERROR_EXIT: @@ -8980,6 +8993,7 @@ jpeg_load_body (struct frame *f, struct image *img, jpeg_destroy_decompress (&mgr->cinfo); /* If we already have an XImage, free that. */ + Emacs_Pix_Container ximg = ximg_volatile; if (ximg) image_destroy_x_image (ximg); /* Free pixmap and colors. */ @@ -8987,6 +9001,14 @@ jpeg_load_body (struct frame *f, struct image *img, return 0; } +#if GCC_LINT && __GNUC__ && !__clang__ + /* These useless assignments pacify GCC 14.2.1 x86-64 + <https://gcc.gnu.org/bugzilla/show_bug.cgi?id=21161>. */ + mgr = mgr_volatile; + img = img_volatile; + fp = fp_volatile; +#endif + /* Create the JPEG decompression object. Let it read from fp. Read the JPEG image header. */ jpeg_CreateDecompress (&mgr->cinfo, JPEG_LIB_VERSION, sizeof *&mgr->cinfo); @@ -9013,7 +9035,11 @@ jpeg_load_body (struct frame *f, struct image *img, } /* Create X image and pixmap. */ - if (!image_create_x_image_and_pixmap (f, img, width, height, 0, &ximg, 0)) + Emacs_Pix_Container ximg; + bool ximg_ok = image_create_x_image_and_pixmap (f, img, width, height, 0, + &ximg, 0); + ximg_volatile = ximg; + if (!ximg_ok) { mgr->failure_code = MY_JPEG_CANNOT_CREATE_X; sys_longjmp (mgr->setjmp_buffer, 1); -- 2.43.0 [-- Attachment #6: 0005-Don-t-ignore-Wclobbered-in-keyboard.c.patch --] [-- Type: text/x-patch, Size: 1398 bytes --] From a967efdd2a5b77e35657f9bdd7098b79241e3aa5 Mon Sep 17 00:00:00 2001 From: Paul Eggert <eggert@cs.ucla.edu> Date: Fri, 16 Aug 2024 17:20:58 -0700 Subject: [PATCH 5/6] =?UTF-8?q?Don=E2=80=99t=20ignore=20-Wclobbered=20in?= =?UTF-8?q?=20keyboard.c?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit This fixes Emacs bug#71744. * src/keyboard.c: Do not ignore -Wclobbered. (read_char): Fix violation of the C standard, where setjmp clobbered c. Fix suggested by Pip Cet in <https://debbugs.gnu.org/cgi/bugreport.cgi?bug=71744#38> --- src/keyboard.c | 7 +------ 1 file changed, 1 insertion(+), 6 deletions(-) diff --git a/src/keyboard.c b/src/keyboard.c index b312d529e59..b519ccdf9f0 100644 --- a/src/keyboard.c +++ b/src/keyboard.c @@ -88,11 +88,6 @@ Copyright (C) 1985-1989, 1993-1997, 1999-2024 Free Software Foundation, #include TERM_HEADER #endif /* HAVE_WINDOW_SYSTEM */ -/* Work around GCC bug 54561. */ -#if GNUC_PREREQ (4, 3, 0) -# pragma GCC diagnostic ignored "-Wclobbered" -#endif - #ifdef WINDOWSNT char const DEV_TTY[] = "CONOUT$"; #else @@ -2522,7 +2517,7 @@ read_char (int commandflag, Lisp_Object map, Lisp_Object prev_event, bool *used_mouse_menu, struct timespec *end_time) { - Lisp_Object c; + Lisp_Object volatile c; sys_jmp_buf local_getcjmp; sys_jmp_buf save_jump; Lisp_Object tem, save; -- 2.43.0 [-- Attachment #7: 0006-Tune-volatile-in-read_char.patch --] [-- Type: text/x-patch, Size: 3680 bytes --] From 8c81818673ae9ff788c6e65fb90984f327b27964 Mon Sep 17 00:00:00 2001 From: Paul Eggert <eggert@cs.ucla.edu> Date: Fri, 16 Aug 2024 19:02:55 -0700 Subject: [PATCH 6/6] Tune volatile in read_char * src/keyboard.c (read_char): Optimize access to a local volatile. --- src/keyboard.c | 23 ++++++++++++++++++++--- 1 file changed, 20 insertions(+), 3 deletions(-) diff --git a/src/keyboard.c b/src/keyboard.c index b519ccdf9f0..0d3506bc59b 100644 --- a/src/keyboard.c +++ b/src/keyboard.c @@ -2517,7 +2517,7 @@ read_char (int commandflag, Lisp_Object map, Lisp_Object prev_event, bool *used_mouse_menu, struct timespec *end_time) { - Lisp_Object volatile c; + Lisp_Object c; sys_jmp_buf local_getcjmp; sys_jmp_buf save_jump; Lisp_Object tem, save; @@ -2752,8 +2752,10 @@ read_char (int commandflag, Lisp_Object map, it *must not* be in effect when we call redisplay. */ specpdl_ref jmpcount = SPECPDL_INDEX (); + Lisp_Object volatile c_volatile; if (sys_setjmp (local_getcjmp)) { + c = c_volatile; /* Handle quits while reading the keyboard. */ /* We must have saved the outer value of getcjmp here, so restore it now. */ @@ -2798,6 +2800,13 @@ read_char (int commandflag, Lisp_Object map, goto non_reread; } + c_volatile = c; +#if GCC_LINT && __GNUC__ && !__clang__ + /* This useless assignment pacifies GCC 14.2.1 x86-64 + <https://gcc.gnu.org/bugzilla/show_bug.cgi?id=21161>. */ + c = c_volatile; +#endif + /* Start idle timers if no time limit is supplied. We don't do it if a time limit is supplied to avoid an infinite recursion in the situation where an idle timer calls `sit-for'. */ @@ -2959,6 +2968,8 @@ read_char (int commandflag, Lisp_Object map, } reread = true; } + + c_volatile = c; } /* Read something from current KBOARD's side queue, if possible. */ @@ -2970,6 +2981,7 @@ read_char (int commandflag, Lisp_Object map, if (!CONSP (KVAR (current_kboard, kbd_queue))) emacs_abort (); c = XCAR (KVAR (current_kboard, kbd_queue)); + c_volatile = c; kset_kbd_queue (current_kboard, XCDR (KVAR (current_kboard, kbd_queue))); if (NILP (KVAR (current_kboard, kbd_queue))) @@ -3025,6 +3037,8 @@ read_char (int commandflag, Lisp_Object map, c = XCDR (c); recorded = true; } + + c_volatile = c; } non_reread: @@ -3108,7 +3122,7 @@ read_char (int commandflag, Lisp_Object map, d = Faref (KVAR (current_kboard, Vkeyboard_translate_table), c); /* nil in keyboard-translate-table means no translation. */ if (!NILP (d)) - c = d; + c_volatile = c = d; } } @@ -3148,6 +3162,7 @@ read_char (int commandflag, Lisp_Object map, Vunread_command_events = Fcons (c, Vunread_command_events); } c = posn; + c_volatile = c; } } @@ -3273,6 +3288,7 @@ read_char (int commandflag, Lisp_Object map, } /* It returned one event or more. */ c = XCAR (tem); + c_volatile = c; Vunread_post_input_method_events = nconc2 (XCDR (tem), Vunread_post_input_method_events); } @@ -3347,6 +3363,7 @@ read_char (int commandflag, Lisp_Object map, do { c = read_char (0, Qnil, Qnil, 0, NULL); + c_volatile = c; if (EVENT_HAS_PARAMETERS (c) && EQ (EVENT_HEAD_KIND (EVENT_HEAD (c)), Qmouse_click)) XSETCAR (help_form_saved_window_configs, Qnil); @@ -3360,7 +3377,7 @@ read_char (int commandflag, Lisp_Object map, { cancel_echoing (); do - c = read_char (0, Qnil, Qnil, 0, NULL); + c_volatile = c = read_char (0, Qnil, Qnil, 0, NULL); while (BUFFERP (c)); } } -- 2.43.0 ^ permalink raw reply related [flat|nested] 18+ messages in thread
* bug#71744: 29.4; SIGSEGV during completion-at-point in lsp-mode with corfu and cape 2024-08-17 4:37 ` Paul Eggert @ 2024-08-17 6:14 ` Eli Zaretskii 2024-08-17 18:23 ` Paul Eggert 2024-08-17 7:46 ` Pip Cet via Bug reports for GNU Emacs, the Swiss army knife of text editors 1 sibling, 1 reply; 18+ messages in thread From: Eli Zaretskii @ 2024-08-17 6:14 UTC (permalink / raw) To: Paul Eggert; +Cc: pipcet, 71744, sigve.indregard > Date: Fri, 16 Aug 2024 21:37:29 -0700 > Cc: sigve.indregard@pm.me, 71744@debbugs.gnu.org > From: Paul Eggert <eggert@cs.ucla.edu> > > > Paul, do you agree that we should simply mark 'c' as volatile, or do you > > think this needs further investigation on the GCC side (because of the > > lack of a -Wclobbered warning being issued, or because of the weird > > code)? > > We definitely should mark 'c' as volatile, or do something equivalent, > because the Emacs code violates the C standard. > > Also, if my hypothesis of the mistaken identifier is correct, we should > stop ignoring -Wclobbered, and instead pacify GCC without using > -Wclobbered. That way, when we screw up in setjmp related code, we'll > get *some* warning that *something* is being clobbered, and can investigate. > > To do that, I installed the attached patches into the Emacs master > branch. While looking into this I noticed several uses of clobbered > variables (i.e., violations of the C standard) and fixed them. Patches > 0001-0004 fix these similar bugs elsewhere. Patch 0005 implements your > suggestion and should fix Bug#71744. Patch 0006 is a minor performance > improvement over Patch 0005. > > Please give these patches a try. Patch 0005 is simple and if it works > for the original bug reporter we should be able to close the bug report > as fixed. Thanks, but since the original bug exists on the emacs-30 release branch and causes crashes, we need to install some part of these patches on the emacs-30 branch. Can you please suggest for the release branch some safe subset of this, which targets the known issue in read_char? Is it Patch #5 without removing the -Wclobbered diagnostic? Or is it something else? ^ permalink raw reply [flat|nested] 18+ messages in thread
* bug#71744: 29.4; SIGSEGV during completion-at-point in lsp-mode with corfu and cape 2024-08-17 6:14 ` Eli Zaretskii @ 2024-08-17 18:23 ` Paul Eggert 0 siblings, 0 replies; 18+ messages in thread From: Paul Eggert @ 2024-08-17 18:23 UTC (permalink / raw) To: Eli Zaretskii; +Cc: pipcet, 71744, sigve.indregard On 2024-08-16 23:14, Eli Zaretskii wrote: > Can you please suggest for the > release branch some safe subset of this, which targets the known issue > in read_char? Is it Patch #5 without removing the -Wclobbered > diagnostic? Yes, that should do it. ^ permalink raw reply [flat|nested] 18+ messages in thread
* bug#71744: 29.4; SIGSEGV during completion-at-point in lsp-mode with corfu and cape 2024-08-17 4:37 ` Paul Eggert 2024-08-17 6:14 ` Eli Zaretskii @ 2024-08-17 7:46 ` Pip Cet via Bug reports for GNU Emacs, the Swiss army knife of text editors 2024-08-17 18:27 ` Paul Eggert 1 sibling, 1 reply; 18+ messages in thread From: Pip Cet via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2024-08-17 7:46 UTC (permalink / raw) To: Paul Eggert; +Cc: Eli Zaretskii, 71744, sigve.indregard "Paul Eggert" <eggert@cs.ucla.edu> writes: > On 2024-08-16 08:08, Pip Cet wrote: >> /* Work around GCC bug 54561. */ >> #if GNUC_PREREQ (4, 3, 0) >> # pragma GCC diagnostic ignored "-Wclobbered" >> #endif >> >> which means we won't get any warnings at all about such bugs. >> >> However, even with that part removed, I don't get a compiler warning >> about 'c'. > > With that part removed I got a warning about 'kb', not 'c'. The 'kb' Oh, that's interesting! Can you let me know which GCC version that was, and which compiler flags? I don't get that diagnostic here. > warning was a false positive, the 'c' warning a false negative. The most > likely explanation, I think, is that GCC got confused and put the wrong > identifier name in its diagnostic. This would help to explain a lot of > the -Wclobbered false positives we've gotten over the years, which has > caused us to ignore -Wclobbered. Hmm. I've looked at the (current) GCC code, and I don't see how it got confused, but I'll look again :-) >> What's weird about this is that the store at +5463 that's causing our >> problem isn't necessary, and neither is the load at +5479. The variable >> in question, 'kb', is not marked volatile, so it seems strange to me it's >> stored, then loaded, unnecessarily. > > My guess is that GCC internally coalesced the two variables, and got > confused because one was clobbered and the other was not, and issued a > warning that it clobbered the variable but mistakenly said 'kb' not 'c'. > The C standard entitles GCC to clobber 'c' so this isn't wrong code, > it's just a bad (a *really* bad) diagnostic. I agree. It is, however, suspiciously badly-optimized code, and it only happens with -flto here... Note that, by my reading of the source code, GCC warns only about variables that it actually clobbered, not variables that might have been clobbered by another compiler obeying the C standard differently. Maybe the best way to deal with that is to default to making "clobbered" an error, not a warning. >> Paul, do you agree that we should simply mark 'c' as volatile, or do you >> think this needs further investigation on the GCC side (because of the >> lack of a -Wclobbered warning being issued, or because of the weird >> code)? > > We definitely should mark 'c' as volatile, or do something equivalent, > because the Emacs code violates the C standard. > > Also, if my hypothesis of the mistaken identifier is correct, we should > stop ignoring -Wclobbered, and instead pacify GCC without using > -Wclobbered. That way, when we screw up in setjmp related code, we'll > get *some* warning that *something* is being clobbered, and can investigate. > > To do that, I installed the attached patches into the Emacs master > branch. While looking into this I noticed several uses of clobbered > variables (i.e., violations of the C standard) and fixed them. Patches > 0001-0004 fix these similar bugs elsewhere. Patch 0005 implements your > suggestion and should fix Bug#71744. Patch 0006 is a minor performance > improvement over Patch 0005. > > Please give these patches a try. Patch 0005 is simple and if it works > for the original bug reporter we should be able to close the bug report > as fixed. Thank you very much! This seems like the best course of action. Pip ^ permalink raw reply [flat|nested] 18+ messages in thread
* bug#71744: 29.4; SIGSEGV during completion-at-point in lsp-mode with corfu and cape 2024-08-17 7:46 ` Pip Cet via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2024-08-17 18:27 ` Paul Eggert 0 siblings, 0 replies; 18+ messages in thread From: Paul Eggert @ 2024-08-17 18:27 UTC (permalink / raw) To: Pip Cet; +Cc: Eli Zaretskii, 71744, sigve.indregard On 2024-08-17 00:46, Pip Cet wrote: > Oh, that's interesting! Can you let me know which GCC version that was, > and which compiler flags? gcc (GCC) 14.2.1 20240801 (Red Hat 14.2.1-1) on Fedora 40 x86-64. I built with --enable-gcc-warnings, so the full command was: gcc -c -Demacs -I. -I. -I../lib -I../lib -isystem /usr/include/gtk-3.0 -isystem /usr/include/pango-1.0 -isystem /usr/include/cairo -isystem /usr/include/gdk-pixbuf-2.0 -isystem /usr/include/atk-1.0 -isystem /usr/include/freetype2 -isystem /usr/include/harfbuzz -isystem /usr/include/glib-2.0 -isystem /usr/lib64/glib-2.0/include -isystem /usr/include/libmount -isystem /usr/include/blkid -isystem /usr/include/sysprof-6 -pthread -isystem /usr/include/webp -DWITH_GZFILEOP -isystem /usr/include/libpng16 -isystem /usr/include/libxml2 -isystem /usr/include/pixman-1 -isystem /usr/include/cloudproviders -isystem /usr/include/at-spi2-atk/2.0 -isystem /usr/include/at-spi-2.0 -isystem /usr/include/dbus-1.0 -isystem /usr/lib64/dbus-1.0/include -isystem /usr/include/fribidi -isystem /usr/include/gio-unix-2.0 -isystem /usr/include/libpng16 -DWITH_GZFILEOP -isystem /usr/include/libxml2 -DWITH_GZFILEOP -isystem /usr/include/dbus-1.0 -isystem /usr/lib64/dbus-1.0/include -isystem /usr/include/webp -isystem /usr/include/glib-2.0 -isystem /usr/lib64/glib-2.0/include -DWITH_GZFILEOP -isystem /usr/include/libmount -isystem /usr/include/blkid -isystem /usr/include/sysprof-6 -pthread -isystem /usr/include/glib-2.0 -isystem /usr/lib64/glib-2.0/include -isystem /usr/include/sysprof-6 -pthread -isystem /usr/include/freetype2 -isystem /usr/include/libpng16 -DWITH_GZFILEOP -isystem /usr/include/harfbuzz -isystem /usr/include/glib-2.0 -isystem /usr/lib64/glib-2.0/include -isystem /usr/include/sysprof-6 -pthread -isystem /usr/include/freetype2 -isystem /usr/include/libpng16 -isystem /usr/include/harfbuzz -isystem /usr/include/glib-2.0 -isystem /usr/lib64/glib-2.0/include -isystem /usr/include/sysprof-6 -pthread -isystem /usr/include/libxml2 -DWITH_GZFILEOP -isystem /usr/include/harfbuzz -isystem /usr/include/freetype2 -isystem /usr/include/libpng16 -DWITH_GZFILEOP -isystem /usr/include/glib-2.0 -isystem /usr/lib64/glib-2.0/include -isystem /usr/include/sysprof-6 -pthread -isystem /usr/include/freetype2 -isystem /usr/include/libpng16 -isystem /usr/include/harfbuzz -isystem /usr/include/sysprof-6 -isystem /usr/include/glib-2.0 -isystem /usr/lib64/glib-2.0/include -DWITH_GZFILEOP -pthread -MMD -MF deps/keyboard.d -MP -isystem /usr/include/p11-kit-1 -DWITH_GZFILEOP -isystem /usr/include/cairo -isystem /usr/include/freetype2 -isystem /usr/include/libpng16 -isystem /usr/include/harfbuzz -isystem /usr/include/glib-2.0 -isystem /usr/lib64/glib-2.0/include -isystem /usr/include/sysprof-6 -pthread -isystem /usr/include/libxml2 -DWITH_GZFILEOP -isystem /usr/include/pixman-1 -Werror -fanalyzer -fstrict-flex-arrays -Wall -Warith-conversion -Wdate-time -Wdisabled-optimization -Wdouble-promotion -Wduplicated-cond -Wextra -Wformat-signedness -Wflex-array-member-not-at-end -Winit-self -Winvalid-pch -Wlogical-op -Wmissing-declarations -Wmissing-include-dirs -Wmissing-prototypes -Wmissing-variable-declarations -Wnested-externs -Wnull-dereference -Wold-style-definition -Wopenmp-simd -Wpacked -Wpointer-arith -Wstrict-flex-arrays -Wstrict-prototypes -Wsuggest-attribute=format -Wsuggest-attribute=malloc -Wsuggest-attribute=noreturn -Wsuggest-final-methods -Wsuggest-final-types -Wtrampolines -Wuninitialized -Wunknown-pragmas -Wunused-macros -Wvariadic-macros -Wvector-operation-performance -Wwrite-strings -Warray-bounds=2 -Wattribute-alias=2 -Wformat=2 -Wformat-truncation=2 -Wimplicit-fallthrough=5 -Wshift-overflow=2 -Wuse-after-free=3 -Wvla-larger-than=4031 -Wno-analyzer-malloc-leak -Wredundant-decls -Wno-missing-field-initializers -Wno-override-init -Wno-sign-compare -Wno-type-limits -Wno-unused-parameter -Wno-format-nonliteral -Wno-bidi-chars -Wno-analyzer-fd-leak -g3 -O2 keyboard.c > Note that, by my reading of the source code, GCC warns only about > variables that it actually clobbered, not variables that might have been > clobbered by another compiler obeying the C standard differently. That matches the intuition I get from the false positives over the years. ^ permalink raw reply [flat|nested] 18+ messages in thread
end of thread, other threads:[~2024-08-17 18:27 UTC | newest] Thread overview: 18+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2024-06-23 21:16 bug#71744: 29.4; SIGSEGV during completion-at-point in lsp-mode with corfu and cape Matthew Rothlisberger 2024-06-24 12:28 ` Eli Zaretskii 2024-06-26 23:27 ` Matthew Rothlisberger 2024-06-27 10:05 ` Eli Zaretskii 2024-08-14 13:22 ` Sigve Indregard via Bug reports for GNU Emacs, the Swiss army knife of text editors 2024-08-14 13:57 ` Eli Zaretskii 2024-08-14 15:40 ` Sigve Indregard via Bug reports for GNU Emacs, the Swiss army knife of text editors 2024-08-14 16:03 ` Eli Zaretskii 2024-08-14 16:22 ` Eli Zaretskii 2024-08-14 16:37 ` Sigve Indregard via Bug reports for GNU Emacs, the Swiss army knife of text editors 2024-08-14 17:03 ` Pip Cet via Bug reports for GNU Emacs, the Swiss army knife of text editors 2024-08-15 9:07 ` Pip Cet via Bug reports for GNU Emacs, the Swiss army knife of text editors 2024-08-16 15:08 ` Pip Cet via Bug reports for GNU Emacs, the Swiss army knife of text editors 2024-08-17 4:37 ` Paul Eggert 2024-08-17 6:14 ` Eli Zaretskii 2024-08-17 18:23 ` Paul Eggert 2024-08-17 7:46 ` Pip Cet via Bug reports for GNU Emacs, the Swiss army knife of text editors 2024-08-17 18:27 ` Paul Eggert
Code repositories for project(s) associated with this public inbox https://git.savannah.gnu.org/cgit/emacs.git This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).