Package: emacs;
Reported by: Evgeniy Dushistov <dushistov <at> mail.ru>
Date: Sun, 16 Feb 2025 08:47:01 UTC
Severity: normal
Found in version 29.4
To reply to this bug, email your comments to 76327 AT debbugs.gnu.org.
Toggle the display of automated, internal messages from the tracker.
View this report as an mbox folder, status mbox, maintainer mbox
bug-gnu-emacs <at> gnu.org:bug#76327; Package emacs.
(Sun, 16 Feb 2025 08:47:02 GMT) Full text and rfc822 format available.Evgeniy Dushistov <dushistov <at> mail.ru>:bug-gnu-emacs <at> gnu.org.
(Sun, 16 Feb 2025 08:47:02 GMT) Full text and rfc822 format available.Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
From: Evgeniy Dushistov <dushistov <at> mail.ru> To: bug-gnu-emacs <at> gnu.org Subject: 29.4; random segfaults after switch to tree-sitter Date: Sun, 16 Feb 2025 11:45:38 +0300
Just random crash during editing text (cut or delete text).
(gdb) bt full
#0 SYMBOL_NAME (sym=0x55555e5d3ba0) at /usr/src/debug/emacs/emacs-29.4/src/lisp.h:1152
#1 print_object (obj=0x55555e5d3ba0, printcharfun=<optimized out>, escapeflag=true) at print.c:2398
len = 288
i = <optimized out>
name = <optimized out>
size_byte = <optimized out>
p = <optimized out>
signedp = <optimized out>
confusing = <optimized out>
base_depth = <optimized out>
base_sp = <optimized out>
buf = " \001", '\000' <repeats 23 times>, "\025\271|\222\203б\360\324\377\377\377\177\000\0000\362\210UUU\000\000 \001\000\000\000"
print_obj = <optimized out>
#2 0x00005555557c718d in print (obj=<optimized out>, printcharfun=<optimized out>, escapeflag=<optimized out>) at print.c:1301
#3 0x00005555557c72d3 in Fprin1 (object=0x55555e5d3ba0, printcharfun=printcharfun <at> entry=0x30, overrides=overrides <at> entry=0x0) at print.c:776
count = {
bytes = <optimized out>
}
pc = {
printcharfun = 0x30,
old_printcharfun = 0x30,
old_point = -1,
start_point = -1,
old_point_byte = -1,
start_point_byte = -1,
specpdl_count = {
bytes = 224
}
}
#4 0x00005555557c7af9 in print_error_message (data=<optimized out>, data <at> entry=0x55555a8e65c3, stream=stream <at> entry=0x30, context=<optimized out>, caller=caller <at> entry=0x7fe0) at print.c:1134
obj = <optimized out>
li = {
tortoise = <optimized out>,
max = <optimized out>,
n = <optimized out>,
q = <optimized out>
}
sep = 0x55555587c951 ", "
errname = 0x11f70
errmsg = <optimized out>
file_error = <optimized out>
tail = 0x55555a8e66c3
#5 0x000055555570603b in Fcommand_error_default_function (data=0x55555a8e65c3, context=0x7ffff1880284, signal=0x7fe0) at /usr/src/debug/emacs/emacs-29.4/src/lisp.h:1679
sf = 0x5555561a9d40
conditions = <optimized out>
is_minibuffer_quit = <optimized out>
#6 0x00005555557ecd6c in exec_byte_code (fun=<optimized out>, args_template=<optimized out>, nargs=<optimized out>, args=<optimized out>) at bytecode.c:809
call_nargs = 3
call_fun = <optimized out>
count1 = {
bytes = <optimized out>
}
template = <optimized out>
--Type <RET> for more, q to quit, c to continue without paging--
val = <optimized out>
call_args = 0x7ffff0fff050
original_fun = 0x2aaa9bf19470
bytecode = <optimized out>
op = 3
type = <optimized out>
targets = {0x5555555b837a <exec_byte_code-2311590>, 0x5555557ed1c5 <exec_byte_code+2213>, 0x5555557ed1bc <exec_byte_code+2204>, 0x5555557ed1b3 <exec_byte_code+2195>, 0x5555557ecb35 <exec_byte_code+533>, 0x5555557ecb39 <exec_byte_code+537>, 0x5555557ed177 <exec_byte_code+2135>, 0x5555557ed13b <exec_byte_code+2075>, 0x5555557eda2e <exec_byte_code+4366>, 0x5555557eda25 <exec_byte_code+4357>, 0x5555557eda1c <exec_byte_code+4348>, 0x5555557eda13 <exec_byte_code+4339>, 0x5555557ecb71 <exec_byte_code+593>, 0x5555557ecb80 <exec_byte_code+608>, 0x5555557eda03 <exec_byte_code+4323>, 0x5555557eda37 <exec_byte_code+4375>, 0x5555557edae9 <exec_byte_code+4553>, 0x5555557edae0 <exec_byte_code+4544>, 0x5555557edad7 <exec_byte_code+4535>, 0x5555557edace <exec_byte_code+4526>, 0x5555557ecaad <exec_byte_code+397>, 0x5555557ecac0 <exec_byte_code+416>, 0x5555557edaad <exec_byte_code+4493>, 0x5555557edabd <exec_byte_code+4509>, 0x5555557eda51 <exec_byte_code+4401>, 0x5555557eda48 <exec_byte_code+4392>, 0x5555557edd9f <exec_byte_code+5247>, 0x5555557edd96 <exec_byte_code+5238>, 0x5555557ecdec <exec_byte_code+1228>, 0x5555557ecdf0 <exec_byte_code+1232>, 0x5555557eda6b <exec_byte_code+4427>, 0x5555557eda5a <exec_byte_code+4410>, 0x5555557edd6c <exec_byte_code+5196>, 0x5555557edd63 <exec_byte_code+5187>, 0x5555557edd5a <exec_byte_code+5178>, 0x5555557edd51 <exec_byte_code+5169>, 0x5555557ecbf1 <exec_byte_code+721>, 0x5555557ecc00 <exec_byte_code+736>, 0x5555557edd86 <exec_byte_code+5222>, 0x5555557edd75 <exec_byte_code+5205>, 0x5555557edd27 <exec_byte_code+5127>, 0x5555557edd1e <exec_byte_code+5118>, 0x5555557edd15 <exec_byte_code+5109>, 0x5555557edd0c <exec_byte_code+5100>, 0x5555557ece39 <exec_byte_code+1305>, 0x5555557ece40 <exec_byte_code+1312>, 0x5555557edd41 <exec_byte_code+5153>, 0x5555557edd30 <exec_byte_code+5136>, 0x5555557edc58 <exec_byte_code+4920>, 0x5555557edc8b <exec_byte_code+4971>, 0x5555557edd00 <exec_byte_code+5088>, 0x5555555b837e <exec_byte_code-2311586>, 0x5555555b837e <exec_byte_code-2311586>, 0x5555555b837e <exec_byte_code-2311586>, 0x5555555b837e <exec_byte_code-2311586>, 0x5555555b837e <exec_byte_code-2311586>, 0x5555557ef0a1 <exec_byte_code+10113>, 0x5555557ef02f <exec_byte_code+9999>, 0x5555557eefe9 <exec_byte_code+9929>, 0x5555557eefa3 <exec_byte_code+9859>, 0x5555557eef5f <exec_byte_code+9791>, 0x5555557edb6a <exec_byte_code+4682>, 0x5555557edb2a <exec_byte_code+4618>, 0x5555557eef2e <exec_byte_code+9742>, 0x5555557edc1e <exec_byte_code+4862>, 0x5555557edaf2 <exec_byte_code+4562>, 0x5555557eeeee <exec_byte_code+9678>, 0x5555557eeebe <exec_byte_code+9630>, 0x5555557eee7e <exec_byte_code+9566>, 0x5555557eee41 <exec_byte_code+9505>, 0x5555557eee00 <exec_byte_code+9440>, 0x5555557eed89 <exec_byte_code+9321>, 0x5555557eed14 <exec_byte_code+9204>, 0x5555557eec98 <exec_byte_code+9080>, 0x5555557eec68 <exec_byte_code+9032>, 0x5555557eec38 <exec_byte_code+8984>, 0x5555557eebf8 <exec_byte_code+8920>, 0x5555557eebb8 <exec_byte_code+8856>, 0x5555557eeb78 <exec_byte_code+8792>, 0x5555557eeb34 <exec_byte_code+8724>, 0x5555557eeafa <exec_byte_code+8666>, 0x5555557eeac0 <exec_byte_code+8608>, 0x5555557eea86 <exec_byte_code+8550>, 0x5555557ee9e4 <exec_byte_code+8388>, 0x5555557ee989 <exec_byte_code+8297>, 0x5555557ee938 <exec_byte_code+8216>, 0x5555557ee8e4 <exec_byte_code+8132>, 0x5555557ee890 <exec_byte_code+8048>, 0x5555557ee83c <exec_byte_code+7964>, 0x5555557ee7e8 <exec_byte_code+7880>, 0x5555557ee790 <exec_byte_code+7792>, 0x5555557ee734 <exec_byte_code+7700>, 0x5555557ee6dc <exec_byte_code+7612>, 0x5555557ee684 <exec_byte_code+7524>, 0x5555557ee62c <exec_byte_code+7436>, 0x5555557ee5d3 <exec_byte_code+7347>, 0x5555557ee4e3 <exec_byte_code+7107>, 0x5555557ece88 <exec_byte_code+1384>, 0x5555557ee4b3 <exec_byte_code+7059>, 0x5555557ee47e <exec_byte_code+7006>, 0x5555557ee3ee <exec_byte_code+6862>, 0x5555557ee3a5 <exec_byte_code+6789>, 0x5555557ee375 <exec_byte_code+6741>, 0x5555557ee343 <exec_byte_code+6691>, 0x5555557ee311 <exec_byte_code+6641>, 0x5555557ee2d7 <exec_byte_code+6583>, 0x5555557ee2a5 <exec_byte_code+6533>, 0x5555555b837e <exec_byte_code-2311586>, 0x5555557ee273 <exec_byte_code+6483>, 0x5555557ee241 <exec_byte_code+6433>, 0x5555557ee20f <exec_byte_code+6383>, 0x5555557ee1dd <exec_byte_code+6333>, 0x5555557ee1ab <exec_byte_code+6283>, 0x5555557ee17b <exec_byte_code+6235>, 0x5555557ece8c <exec_byte_code+1388>, 0x5555555b837e <exec_byte_code-2311586>, 0x5555557ee138 <exec_byte_code+6168>, 0x5555557ee108 <exec_byte_code+6120>, 0x5555557ee0d8 <exec_byte_code+6072>, 0x5555557ed8ea <exec_byte_code+4042>, 0x5555557ed8aa <exec_byte_code+3978>, 0x5555557ed87a <exec_byte_code+3930>, 0x5555557ed84a <exec_byte_code+3882>, 0x5555557ed80a <exec_byte_code+3818>, 0x5555557ed7ca <exec_byte_code+3754>, 0x5555557ed78a <exec_byte_code+3690>, 0x5555557ed758 <exec_byte_code+3640>, 0x5555557ed728 <exec_byte_code+3592>, 0x5555555b837e <exec_byte_code-2311586>, 0x5555557edda8 <exec_byte_code+5256>, 0x5555557edf59 <exec_byte_code+5689>, 0x5555557ed9c4 <exec_byte_code+4260>, 0x5555557edf1a <exec_byte_code+5626>, 0x5555557edede <exec_byte_code+5566>, 0x5555557edea2 <exec_byte_code+5506>, 0x5555557ede05 <exec_byte_code+5349>, 0x5555557edde1 <exec_byte_code+5313>, 0x5555557eda7b <exec_byte_code+4443>, 0x5555557ee06c <exec_byte_code+5964>, 0x5555557ee006 <exec_byte_code+5862>, 0x5555557edfd0 <exec_byte_code+5808>, 0x5555557ee091 <exec_byte_code+6001>, 0x5555557ef1da <exec_byte_code+10426>, 0x5555557ef196 <exec_byte_code+10358>, 0x5555557ef14c <exec_byte_code+10284>, 0x5555557ef0ee <exec_byte_code+10190>, 0x5555555b837e <exec_byte_code-2311586>, 0x5555557ed6e4 <exec_byte_code+3524>, 0x5555557ed6b4 <exec_byte_code+3476>, 0x5555557ed684 <exec_byte_code+3428>, 0x5555557ed654 <exec_byte_code+3380>, 0x5555557ed624 <exec_byte_code+3332>, 0x5555557ed5e4 <exec_byte_code+3268>, 0x5555557ed5a4 <exec_byte_code+3204>, 0x5555557ed564 <exec_byte_code+3140>, 0x5555557ed524 <exec_byte_code+3076>, 0x5555557ed4d0 <exec_byte_code+2992>, 0x5555557ed490 <exec_byte_code+2928>, 0x5555557ed450 <exec_byte_code+2864>, 0x5555557ed420 <exec_byte_code+2816>, 0x5555557ed3bd <exec_byte_code+2717>, 0x5555557ed35a <exec_byte_code+2618>, 0x5555557ed31e <exec_byte_code+2558>, 0x5555557ed2e2 <exec_byte_code+2498>, 0x5555557ed2a8 <exec_byte_code+2440>, 0x5555557ee57b <exec_byte_code+7259>, 0x5555557ee52c <exec_byte_code+7180>, 0x5555557ed23a <exec_byte_code+2330>, 0x5555557ed1ce <exec_byte_code+2222>, 0x5555555b837e <exec_byte_code-2311586>, 0x5555555b837e <exec_byte_code-2311586>, 0x5555555b837e <exec_byte_code-2311586>, 0x5555555b837e <exec_byte_code-2311586>, 0x5555555b837e <exec_byte_code-2311586>, 0x5555555b837e <exec_byte_code-2311586>, 0x5555557eedb9 <exec_byte_code+9369>, 0x5555557eea3f <exec_byte_code+8479>, 0x5555557ee437 <exec_byte_code+6935>, 0x5555557ed0f7 <exec_byte_code+2007>, 0x5555557ed0b3 <exec_byte_code+1939>, 0x5555555b837e <exec_byte_code-2311586>, 0x5555555b837e <exec_byte_code-2311586>, 0x5555557ed07c <exec_byte_code+1884>, 0x5555557ed962 <exec_byte_code+4162>, 0x5555555b837e <exec_byte_code-2311586>, 0x5555555b837e <exec_byte_code-2311586>, 0x5555555b837e <exec_byte_code-2311586>, 0x5555555b837e <exec_byte_code-2311586>, 0x5555555b837e <exec_byte_code-2311586>, 0x5555555b837e <exec_byte_code-2311586>, 0x5555555b837e <exec_byte_code-2311586>, 0x5555555b837e <exec_byte_code-2311586>, 0x5555557ed92a <exec_byte_code+4106> <repeats 64 times>}
quitcounter = <optimized out>
bc = 0x555555d421b0 <main_thread+496>
top = 0x7ffff0fff048
pc = <optimized out>
bytestr = <optimized out>
vector = <optimized out>
maxdepth = <optimized out>
const_length = <optimized out>
--Type <RET> for more, q to quit, c to continue without paging--
bytestr_length = <optimized out>
vectorp = 0x7ffff1ce5e80
max_stack = <optimized out>
frame_base = <optimized out>
fp = <optimized out>
bytestr_data = <optimized out>
rest = <optimized out>
mandatory = <optimized out>
nonrest = <optimized out>
pushedargs = <optimized out>
result = <optimized out>
#7 0x000055555579f0c5 in Ffuncall (nargs=nargs <at> entry=4, args=args <at> entry=0x7fffffffd890) at eval.c:2999
count = {
bytes = <optimized out>
}
val = <optimized out>
#8 0x000055555570691e in call3 (fn=<optimized out>, arg1=0x55555a8e65c3, arg2=<optimized out>, arg3=0x7fe0) at /usr/src/debug/emacs/emacs-29.4/src/lisp.h:3262
#9 cmd_error_internal (data=data <at> entry=0x55555a8e65c3, context=context <at> entry=0x7fffffffd900 "") at keyboard.c:1013
#10 0x0000555555706aa2 in cmd_error (data=0x55555a8e65c3) at keyboard.c:981
old_level = <optimized out>
old_length = <optimized out>
count = {
bytes = <optimized out>
}
conditions = <optimized out>
macroerror = "\000\000\000\000\000\000\000\000\240\230\000\000\000\000\000\000\200\331\377\377\377\177\000\000B\256yUUU\000\000\022\000\000\000\000\000\000\000\000\025\271|\222\203б\v"
#11 0x0000555555799771 in internal_condition_case (bfun=bfun <at> entry=0x555555714360 <command_loop_1>, handlers=handlers <at> entry=0x90, hfun=hfun <at> entry=0x555555706950 <cmd_error>) at eval.c:1470
val = <optimized out>
c = 0x555555ec4c50
#12 0x00005555556fe73f in command_loop_2 (handlers=handlers <at> entry=0x90) at keyboard.c:1133
val = <optimized out>
#13 0x00005555557996d8 in internal_catch (tag=tag <at> entry=0x10080, func=func <at> entry=0x5555556fe700 <command_loop_2>, arg=arg <at> entry=0x90) at eval.c:1197
val = <optimized out>
c = 0x555555ec4b10
#14 0x00005555556fe6c5 in command_loop () at keyboard.c:1111
#15 0x0000555555706461 in recursive_edit_1 () at keyboard.c:720
count = {
bytes = <optimized out>
}
val = <optimized out>
#16 0x000055555570683d in Frecursive_edit () at keyboard.c:803
count = {
bytes = <optimized out>
}
buffer = <optimized out>
#17 0x00005555555be0e6 in main (argc=1, argv=0x7fffffffdd18) at emacs.c:2521
stack_bottom_variable = 0x12f
no_loadup = false
junk = 0x0
dname_arg = 0x0
ch_to_dir = 0x0
original_pwd = <optimized out>
--Type <RET> for more, q to quit, c to continue without paging--
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:
"command-error-default-function" (0xf0fff050)
"help-command-error-confusable-suggestions" (0xffffd898)
In GNU Emacs 29.4 (build 5, x86_64-pc-linux-gnu, GTK+ Version 3.24.48,
cairo version 1.18.2)
Repository revision: f33dddcc776e901abd1bb8f444c87d7e51128fec
Repository branch: main
Windowing system distributor 'The X.Org Foundation', version 11.0.12101015
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=nehalem
-mtune=znver1 -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=/home/evgeniy/bigdisk1/linux-infra/arch_build/modified-packages/emacs/src=/usr/src/debug/emacs'
'LDFLAGS=-Wl,-O1 -Wl,--sort-common -Wl,--as-needed -Wl,-z,relro
-Wl,-z,now -Wl,-z,pack-relative-relocs''
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: ru_RU.UTF-8
locale-coding-system: utf-8-unix
Major mode: Dired by name
Minor modes in effect:
ivy-prescient-mode: t
reverse-im-mode: t
which-key-mode: t
ivy-mode: t
shell-dirtrack-mode: t
winner-mode: t
global-auto-revert-mode: t
save-place-mode: t
override-global-mode: t
straight-use-package-mode: t
straight-package-neutering-mode: t
tooltip-mode: t
global-eldoc-mode: t
show-paren-mode: t
electric-indent-mode: t
mouse-wheel-mode: t
file-name-shadow-mode: t
global-font-lock-mode: t
font-lock-mode: t
blink-cursor-mode: t
buffer-read-only: 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:
/home/evgeniy/.config/emacs/straight/build/cmake-mode/cmake-mode hides /usr/share/emacs/site-lisp/cmake-mode
/home/evgeniy/.config/emacs/straight/build/transient/transient hides /usr/share/emacs/29.4/lisp/transient
/home/evgeniy/.config/emacs/straight/build/use-package/use-package-ensure hides /usr/share/emacs/29.4/lisp/use-package/use-package-ensure
/home/evgeniy/.config/emacs/straight/build/bind-key/bind-key hides /usr/share/emacs/29.4/lisp/use-package/bind-key
/home/evgeniy/.config/emacs/straight/build/use-package/use-package-ensure-system-package hides /usr/share/emacs/29.4/lisp/use-package/use-package-ensure-system-package
/home/evgeniy/.config/emacs/straight/build/use-package/use-package-core hides /usr/share/emacs/29.4/lisp/use-package/use-package-core
/home/evgeniy/.config/emacs/straight/build/use-package/use-package-delight hides /usr/share/emacs/29.4/lisp/use-package/use-package-delight
/home/evgeniy/.config/emacs/straight/build/use-package/use-package-lint hides /usr/share/emacs/29.4/lisp/use-package/use-package-lint
/home/evgeniy/.config/emacs/straight/build/use-package/use-package-bind-key hides /usr/share/emacs/29.4/lisp/use-package/use-package-bind-key
/home/evgeniy/.config/emacs/straight/build/use-package/use-package-diminish hides /usr/share/emacs/29.4/lisp/use-package/use-package-diminish
/home/evgeniy/.config/emacs/straight/build/use-package/use-package-jump hides /usr/share/emacs/29.4/lisp/use-package/use-package-jump
/home/evgeniy/.config/emacs/straight/build/use-package/use-package hides /usr/share/emacs/29.4/lisp/use-package/use-package
/home/evgeniy/.config/emacs/straight/build/org-mode-ox-odt/ox-odt hides /usr/share/emacs/29.4/lisp/org/ox-odt
/home/evgeniy/.config/emacs/straight/build/seq/seq hides /usr/share/emacs/29.4/lisp/emacs-lisp/seq
/home/evgeniy/.config/emacs/straight/build/let-alist/let-alist hides /usr/share/emacs/29.4/lisp/emacs-lisp/let-alist
/home/evgeniy/.config/emacs/straight/build/eldoc/eldoc hides /usr/share/emacs/29.4/lisp/emacs-lisp/eldoc
Features:
(shadow sort mail-extr emacsbug message mailcap yank-media puny rfc822
mml mml-sec epa derived epg rfc6068 epg-config 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 wdired
vterm bookmark face-remap term disp-table ehelp vterm-module term/xterm
xterm vterm-toggle tramp-sh misearch multi-isearch dired-aux
ivy-prescient prescient reverse-im avy quail char-fold ffap url-parse
url-vars dired dired-loaddefs tramp tramp-loaddefs trampver
tramp-integration tramp-compat parse-time auth-source password-cache
which-key company-oddmuse company-keywords company-etags etags fileloop
company-gtags company-dabbrev-code company-dabbrev company-files
company-clang company-capf company-cmake company-semantic
company-template company-bbdb company rainbow-delimiters
column-enforce-mode chronos-autoloads gptel-autoloads rfc-mode-autoloads
plantuml-mode dash plantuml-mode-autoloads dap-mode-autoloads
lsp-docker-autoloads yaml-autoloads lsp-treemacs-autoloads
treemacs-autoloads cfrs-autoloads posframe-autoloads hydra-autoloads
pfuture-autoloads ace-window-autoloads avy-autoloads bui-autoloads
yaml-mode-autoloads zeal-at-point-autoloads string-inflection
string-inflection-autoloads rust-playground-autoloads cargo-autoloads
rust-mode-autoloads go-mode-autoloads clang-format-autoloads
cmake-mode-autoloads qml-mode-autoloads rainbow-mode-autoloads
rainbow-delimiters-autoloads yasnippet-autoloads company-lsp-autoloads
company-autoloads lsp-ui-autoloads lsp-mode-autoloads eldoc-autoloads
lv-autoloads markdown-mode-autoloads spinner-autoloads ht-autoloads
f-autoloads s-autoloads projectile-autoloads ripgrep ripgrep-autoloads
combobulate combobulate-autoloads combobulate-go combobulate-json
combobulate-yaml combobulate-css combobulate-js-ts combobulate-python
combobulate-html combobulate-toml combobulate-cursor multiple-cursors
mc-separate-operations rectangular-region-mode mc-mark-pop mc-edit-lines
mc-hide-unmatched-lines-mode mc-mark-more sgml-mode facemenu thingatpt
mc-cycle-cursors multiple-cursors-core advice rect combobulate-query
savehist xref files-x scheme combobulate-ui transient compat compat-30
combobulate-display combobulate-ztree combobulate-envelope
combobulate-manipulation eieio eieio-core combobulate-procedure
combobulate-navigation combobulate-misc combobulate-setup
combobulate-interface combobulate-settings diff-mode combobulate-rules
column-enforce-mode-autoloads use-package-diminish
vterm-toggle-autoloads vterm-autoloads eshell-toggle-autoloads
mingus-autoloads libmpdee-autoloads wgrep grep compile
text-property-search wgrep-autoloads peep-dired-autoloads
magit-autoloads with-editor-autoloads transient-autoloads
magit-section-autoloads dash-autoloads compat-autoloads
ivy-prescient-autoloads prescient-autoloads ivy delsel ivy-faces
ivy-overlay colir color ivy-autoloads org-pdftools-autoloads
pdf-tools-autoloads let-alist-autoloads tablist-autoloads
org-noter-autoloads ox-odt oc-csl json bibtex iso8601 pp rng-loc rng-uri
rng-parse rng-match rng-dt rng-util rng-pttrn nxml-parse nxml-ns
nxml-enc xmltok nxml-util odt dom map ox-latex ox-icalendar org-agenda
ox-html table ox-ascii ox-publish ox org-element org-persist xdg org-id
org-refile avl-tree generator xml org-mode-ox-odt-autoloads org-tempo
tempo ob-python python project byte-opt pcase treesit ob-shell shell
toc-org-autoloads multiple-cursors-autoloads expand-region-autoloads
winner autorevert filenotify cal-julian theme-changer solar cal-dst
theme-changer-autoloads finder-inf saveplace which-key-autoloads edmacro
kmacro reverse-im-autoloads seq-autoloads use-package-bind-key bind-key
easy-mmode use-package-core use-package-autoloads info
bind-key-autoloads straight-autoloads cl-seq cl-extra help-mode straight
cl-macs gv bytecomp byte-compile org ob ob-tangle ob-ref ob-lob ob-table
ob-exp org-macro org-src ob-comint org-pcomplete pcomplete comint
ansi-osc ansi-color ring org-list org-footnote org-faces org-entities
time-date subr-x noutline outline icons ob-emacs-lisp ob-core ob-eval
org-cycle org-table ol rx org-fold org-fold-core org-keys oc
org-loaddefs find-func cal-menu calendar cal-loaddefs org-version
org-compat org-macs format-spec cl-loaddefs cl-lib cyril-util 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 415375 288020)
(symbols 48 30665 107)
(strings 32 150433 141680)
(string-bytes 1 4817376)
(vectors 16 63917)
(vector-slots 8 1159190 819820)
(floats 8 698 1610)
(intervals 56 1996 627)
(buffers 984 17))
--
/Evgeniy
bug-gnu-emacs <at> gnu.org:bug#76327; Package emacs.
(Sun, 16 Feb 2025 09:50:01 GMT) Full text and rfc822 format available.Message #8 received at 76327 <at> debbugs.gnu.org (full text, mbox):
From: Eli Zaretskii <eliz <at> gnu.org> To: Evgeniy Dushistov <dushistov <at> mail.ru> Cc: 76327 <at> debbugs.gnu.org Subject: Re: bug#76327: 29.4; random segfaults after switch to tree-sitter Date: Sun, 16 Feb 2025 11:48:52 +0200
> Date: Sun, 16 Feb 2025 11:45:38 +0300 > From: Evgeniy Dushistov via "Bug reports for GNU Emacs, > the Swiss army knife of text editors" <bug-gnu-emacs <at> gnu.org> > > Just random crash during editing text (cut or delete text). What do you mean by "after switch to tree-sitter"? What exactly did you change and how in order to switch? > (gdb) bt full > #0 SYMBOL_NAME (sym=0x55555e5d3ba0) at /usr/src/debug/emacs/emacs-29.4/src/lisp.h:1152 Please show this symbol: (gdb) source /path/to/emacs/src/.gdbinit (gdb) frame 0 (gdb) print sym (gdb) xtype (gdb) xsymbol > #5 0x000055555570603b in Fcommand_error_default_function (data=0x55555a8e65c3, context=0x7ffff1880284, signal=0x7fe0) at /usr/src/debug/emacs/emacs-29.4/src/lisp.h:1679 Can you show the error and its data here? Like this: (gdb) frame 5 (gdb) pp data (gdb) pp context Thanks.
bug-gnu-emacs <at> gnu.org:bug#76327; Package emacs.
(Sun, 16 Feb 2025 12:43:02 GMT) Full text and rfc822 format available.Message #11 received at 76327 <at> debbugs.gnu.org (full text, mbox):
From: Evgeniy Dushistov <dushistov <at> mail.ru> To: Eli Zaretskii <eliz <at> gnu.org> Cc: 76327 <at> debbugs.gnu.org Subject: Re: bug#76327: 29.4; random segfaults after switch to tree-sitter Date: Sun, 16 Feb 2025 15:42:33 +0300
On Sun, Feb 16, 2025 at 11:48:52AM +0200, Eli Zaretskii wrote:
> > Date: Sun, 16 Feb 2025 11:45:38 +0300
> > From: Evgeniy Dushistov via "Bug reports for GNU Emacs,
> > the Swiss army knife of text editors" <bug-gnu-emacs <at> gnu.org>
> >
> > Just random crash during editing text (cut or delete text).
>
> What do you mean by "after switch to tree-sitter"? What exactly did
> you change and how in order to switch?
For c/c++/python:
(use-package treesit
:preface
(dolist (mapping
'(
(c-mode . c-ts-mode)
(c++-mode . c++-ts-mode)
(c-or-c++-mode . c-or-c++-ts-mode)
(python-mode . python-ts-mode)
))
(add-to-list 'major-mode-remap-alist mapping))
)
For rust:
(use-package rust-mode
:init
(setq rust-mode-treesitter-derive t)
)
And after two weeks after these changes emacs start crashes.
Usually emacs crashes once every two days.
I suppose this starts after update of some arch linux's packages.
During attempts to fix issue,
I tried two variants, tree-sitter grammar build from source code (with
emacs help) and these packages from Arch distro:
tree-sitter-cpp,tree-sitter-c,tree-sitter-python,tree-sitter-rust
Both variants cause crash.
And last week after update of 3 packages:
- tree-sitter
- emacs
- tree-sitter-c
emacs works 5 days without crash,
I was hoping that everything was finally fixed,
and even reports that all ok in arch linux issue tracker:
https://gitlab.archlinux.org/archlinux/packaging/packages/emacs/-/issues/6
But today two crashes in the row happens.
>
> > (gdb) bt full
> > #0 SYMBOL_NAME (sym=0x55555e5d3ba0) at /usr/src/debug/emacs/emacs-29.4/src/lisp.h:1152
>
> Please show this symbol:
>
I already closed gdb process, so next time it crashes,
I try what you suggest.
--
/Evgeniy
bug-gnu-emacs <at> gnu.org:bug#76327; Package emacs.
(Mon, 17 Feb 2025 13:17:02 GMT) Full text and rfc822 format available.Message #14 received at 76327 <at> debbugs.gnu.org (full text, mbox):
From: Evgeniy Dushistov <dushistov <at> mail.ru> To: Eli Zaretskii <eliz <at> gnu.org> Cc: 76327 <at> debbugs.gnu.org Subject: Re: bug#76327: 29.4; random segfaults after switch to tree-sitter Date: Mon, 17 Feb 2025 16:16:06 +0300
On Sun, Feb 16, 2025 at 11:48:52AM +0200, Eli Zaretskii wrote:
> Please show this symbol:
>
> (gdb) source /path/to/emacs/src/.gdbinit
> (gdb) frame 0
> (gdb) print sym
> (gdb) xtype
> (gdb) xsymbol
>
(gdb) frame 0
#0 SYMBOL_NAME (sym=XIL(0x55555f9b3260)) at /usr/src/debug/emacs/emacs-29.4/src/lisp.h:1152
1152 return p;
(gdb) print sym
$1 = XIL(0x55555f9b3260)
(gdb) xtype
Lisp_Symbol
(gdb) xsymbol
$2 = (struct Lisp_Symbol *) 0xaaaab57810c0
Cannot access memory at address 0xaaaab57810c8
(gdb)
> > #5 0x000055555570603b in Fcommand_error_default_function (data=0x55555a8e65c3, context=0x7ffff1880284, signal=0x7fe0) at /usr/src/debug/emacs/emacs-29.4/src/lisp.h:1679
>
> Can you show the error and its data here? Like this:
>
> (gdb) frame 5
> (gdb) pp data
> (gdb) pp context
>
(gdb) frame 5
#5 0x000055555570603b in Fcommand_error_default_function (data=XIL(0x55555df52d03),
context=XIL(0x7ffff1880284), signal=XIL(0x7fe0))
at /usr/src/debug/emacs/emacs-29.4/src/lisp.h:1679
1679 return XSTRING (string)->u.s.data;
(gdb) pp data
(wrong-type-argument listp
Thread 1 "emacs-29.4" received signal SIGSEGV, Segmentation fault.
SYMBOL_NAME (sym=XIL(0x55555f9b3260)) at /usr/src/debug/emacs/emacs-29.4/src/lisp.h:1152
1152 return p;
The program being debugged was signaled while in a function called from GDB.
GDB remains in the frame where the signal was received.
To change this behavior use "set unwind-on-signal on".
Evaluation of the expression containing the function
(safe_debug_print) will be abandoned.
When the function is done executing, GDB will silently stop.
--
/Evgeniy
bug-gnu-emacs <at> gnu.org:bug#76327; Package emacs.
(Mon, 17 Feb 2025 14:48:02 GMT) Full text and rfc822 format available.Message #17 received at submit <at> debbugs.gnu.org (full text, mbox):
From: Pip Cet <pipcet <at> protonmail.com> To: bug-gnu-emacs <at> gnu.org, Eli Zaretskii <eliz <at> gnu.org>, Evgeniy Dushistov <dushistov <at> mail.ru>, 76327 <at> debbugs.gnu.org Subject: Re: bug#76327: 29.4; random segfaults after switch to tree-sitter Date: Mon, 17 Feb 2025 14:46:52 +0000
"Evgeniy Dushistov via \"Bug reports for GNU Emacs, the Swiss army knife of text editors\"" <bug-gnu-emacs <at> gnu.org> writes:
> On Sun, Feb 16, 2025 at 11:48:52AM +0200, Eli Zaretskii wrote:
>> Please show this symbol:
>>
>> (gdb) source /path/to/emacs/src/.gdbinit
>> (gdb) frame 0
>> (gdb) print sym
>> (gdb) xtype
>> (gdb) xsymbol
>>
>
> (gdb) frame 0
> #0 SYMBOL_NAME (sym=XIL(0x55555f9b3260)) at /usr/src/debug/emacs/emacs-29.4/src/lisp.h:1152
> 1152 return p;
> (gdb) print sym
> $1 = XIL(0x55555f9b3260)
> (gdb) xtype
> Lisp_Symbol
> (gdb) xsymbol
> $2 = (struct Lisp_Symbol *) 0xaaaab57810c0
> Cannot access memory at address 0xaaaab57810c8
> (gdb)
This seems like an entirely bogus object which somehow ended up in the
error list, probably by CHECK_LIST or CHECK_LIST_END. It's a pointer,
not a tagged Lisp symbol.
Can you examine the memory it points to so we get a clue, maybe?
(gdb) x/64gx 0x55555f9b3200
This may be a GC issue, where the error list is freed and the cons cell
reused (or put on a free list).
Can you reproduce this issue? It'd be great to generate a core file
("gcore" in gdb) and save it along with the emacs binary and .pdmp file
used in that run.
>> > #5 0x000055555570603b in Fcommand_error_default_function
>> (data=0x55555a8e65c3, context=0x7ffff1880284, signal=0x7fe0) at
>> /usr/src/debug/emacs/emacs-29.4/src/lisp.h:1679
>>
>> Can you show the error and its data here? Like this:
>>
>> (gdb) frame 5
>> (gdb) pp data
>> (gdb) pp context
>>
>
> (gdb) frame 5
> #5 0x000055555570603b in Fcommand_error_default_function (data=XIL(0x55555df52d03),
> context=XIL(0x7ffff1880284), signal=XIL(0x7fe0))
> at /usr/src/debug/emacs/emacs-29.4/src/lisp.h:1679
> 1679 return XSTRING (string)->u.s.data;
> (gdb) pp data
> (wrong-type-argument listp
Unfortunately, there are many places that call CHECK_LIST or
CHECK_LIST_END. If you can set a breakpoint on the function
"wrong_type_argument" (note there may be some false positives), we could
catch the bug before we unwind through the stack and lose the context.
The candidates in treesit.c don't seem obviously incorrect...
Pip
bug-gnu-emacs <at> gnu.org:bug#76327; Package emacs.
(Mon, 17 Feb 2025 14:48:02 GMT) Full text and rfc822 format available.bug-gnu-emacs <at> gnu.org:bug#76327; Package emacs.
(Mon, 17 Feb 2025 15:43:01 GMT) Full text and rfc822 format available.Message #23 received at 76327 <at> debbugs.gnu.org (full text, mbox):
From: Evgeniy Dushistov <dushistov <at> mail.ru> To: Eli Zaretskii <eliz <at> gnu.org> Cc: 76327 <at> debbugs.gnu.org Subject: Re: bug#76327: 29.4; random segfaults after switch to tree-sitter Date: Mon, 17 Feb 2025 18:42:09 +0300
On Mon, Feb 17, 2025 at 04:16:12PM +0300, Evgeniy Dushistov wrote: > On Sun, Feb 16, 2025 at 11:48:52AM +0200, Eli Zaretskii wrote: > > Please show this symbol: > > > > (gdb) source /path/to/emacs/src/.gdbinit > > (gdb) frame 0 > > (gdb) print sym > > (gdb) xtype > > (gdb) xsymbol > > > > (gdb) frame 0 > #0 SYMBOL_NAME (sym=XIL(0x55555f9b3260)) at /usr/src/debug/emacs/emacs-29.4/src/lisp.h:1152 > 1152 return p; > (gdb) print sym > $1 = XIL(0x55555f9b3260) > (gdb) xtype > Lisp_Symbol > (gdb) xsymbol > $2 = (struct Lisp_Symbol *) 0xaaaab57810c0 > Cannot access memory at address 0xaaaab57810c8 > (gdb) > > > > > #5 0x000055555570603b in Fcommand_error_default_function (data=0x55555a8e65c3, context=0x7ffff1880284, signal=0x7fe0) at /usr/src/debug/emacs/emacs-29.4/src/lisp.h:1679 > > > > Can you show the error and its data here? Like this: > > > > (gdb) frame 5 > > (gdb) pp data > > (gdb) pp context > > > And because of "pp data" cause additional segfault, I can not use "pp context", so here is "pp context", if call it before "pp data": (gdb) pp context "" -- /Evgeniy
bug-gnu-emacs <at> gnu.org:bug#76327; Package emacs.
(Mon, 17 Feb 2025 17:49:02 GMT) Full text and rfc822 format available.Message #26 received at 76327 <at> debbugs.gnu.org (full text, mbox):
From: Evgeniy Dushistov <dushistov <at> mail.ru> To: Eli Zaretskii <eliz <at> gnu.org> Cc: 76327 <at> debbugs.gnu.org Subject: Re: bug#76327: 29.4; random segfaults after switch to tree-sitter Date: Mon, 17 Feb 2025 20:48:23 +0300
[Message part 1 (text/plain, inline)]
I attached valgrind log, may be you can find something usefull. >> #0 SYMBOL_NAME (sym=XIL(0x55555f9b3260)) at /usr/src/debug/emacs/emacs-29.4/src/lisp.h:1152 > Can you examine the memory it points to so we get a clue, maybe? > (gdb) x/64gx 0x55555f9b3200 So the idea is to use p-0x60, where where p from XIL(p)? Here new crash, and x/6gx: #0 SYMBOL_NAME (sym=0x555577a7a770) at /usr/src/debug/emacs/emacs-29.4/src/lisp.h:1152 1152 return p; (gdb) print sym $1 = (Lisp_Object) 0x555577a7a770 (gdb) xtype Lisp_Symbol (gdb) xsymbol $2 = (struct Lisp_Symbol *) 0xaaaacd8485d0 Cannot access memory at address 0xaaaacd8485d8 (gdb) x/64gx 0x555577a7a710 0x555577a7a710: 0x0000000000000004 0x0000555577a7a700 0x555577a7a720: 0x0000000000000004 0x0000555577a7a710 0x555577a7a730: 0x0000000000000004 0x0000555577a7a720 0x555577a7a740: 0x0000000000000004 0x0000555577a7a730 0x555577a7a750: 0x0000000000000004 0x0000555577a7a740 0x555577a7a760: 0x0000000000000004 0x0000555577a7a750 0x555577a7a770: 0x0000000000000004 0x0000555577a7a760 0x555577a7a780: 0x0000000000000004 0x0000555577a7a770 0x555577a7a790: 0x0000000000000004 0x0000555577a7a780 0x555577a7a7a0: 0x0000000000000004 0x0000555577a7a790 0x555577a7a7b0: 0x0000000000000004 0x0000555577a7a7a0 0x555577a7a7c0: 0x0000000000000004 0x0000555577a7a7b0 0x555577a7a7d0: 0x0000000000000004 0x0000555577a7a7c0 0x555577a7a7e0: 0x0000000000000000 0x0000555577a7a800 0x555577a7a7f0: 0x5f74736574225b3a 0x0000555577a77c00 0x555577a7a800: 0x0000555577a7a400 0x00005555810353d0 0x555577a7a810: 0x0000000000000004 0x0000555577a7a800 0x555577a7a820: 0x0000000000000004 0x0000555577a7a810 0x555577a7a830: 0x0000000000000004 0x0000555577a7a820 0x555577a7a840: 0x0000000000000004 0x0000555577a7a830 0x555577a7a850: 0x0000000000000004 0x0000555577a7a840 0x555577a7a860: 0x0000000000000004 0x0000555577a7a850 0x555577a7a870: 0x0000000000000004 0x0000555577a7a860 0x555577a7a880: 0x0000000000000004 0x0000555577a7a870 0x555577a7a890: 0x0000000000000004 0x0000555577a7a880 0x555577a7a8a0: 0x0000000000000004 0x0000555577a7a890 0x555577a7a8b0: 0x0000000000000004 0x0000555577a7a8a0 0x555577a7a8c0: 0x0000000000000004 0x0000555577a7a8b0 0x555577a7a8d0: 0x0000000000000004 0x0000555577a7a8c0 0x555577a7a8e0: 0x0000000000000004 0x0000555577a7a8d0 0x555577a7a8f0: 0x0000000000000004 0x0000555577a7a8e0 0x555577a7a900: 0x0000000000000004 0x0000555577a7a8f0 > If you can set a breakpoint on the function > "wrong_type_argument" (note there may be some false positives) "wrong_type_argument" for some reason triggers on every attempt to open file. I will try to rebuild emacs with sanitizer. -- /Evgeniy
[emacs.log (text/plain, attachment)]
bug-gnu-emacs <at> gnu.org:bug#76327; Package emacs.
(Mon, 17 Feb 2025 20:32:01 GMT) Full text and rfc822 format available.Message #29 received at submit <at> debbugs.gnu.org (full text, mbox):
From: Pip Cet <pipcet <at> protonmail.com> To: bug-gnu-emacs <at> gnu.org, Eli Zaretskii <eliz <at> gnu.org>, Evgeniy Dushistov <dushistov <at> mail.ru>, 76327 <at> debbugs.gnu.org Subject: Re: bug#76327: 29.4; random segfaults after switch to tree-sitter Date: Mon, 17 Feb 2025 20:31:25 +0000
"Evgeniy Dushistov via \"Bug reports for GNU Emacs, the Swiss army knife of text editors\"" <bug-gnu-emacs <at> gnu.org> writes: > I attached valgrind log, > may be you can find something usefull. > >>> #0 SYMBOL_NAME (sym=XIL(0x55555f9b3260)) at /usr/src/debug/emacs/emacs-29.4/src/lisp.h:1152 > >> Can you examine the memory it points to so we get a clue, maybe? >> (gdb) x/64gx 0x55555f9b3200 > > So the idea is to use p-0x60, where where p from XIL(p)? It doesn't have to be 0x60 precisely, just enough to get some context :-) In this case, it's enough to let us know that the memory has either been reused for a new block of cons cells, or that we're looking at a cons cell which has been freed by GC. > Here new crash, and x/6gx: > > #0 SYMBOL_NAME (sym=0x555577a7a770) at /usr/src/debug/emacs/emacs-29.4/src/lisp.h:1152 > 1152 return p; > (gdb) print sym > $1 = (Lisp_Object) 0x555577a7a770 > (gdb) xtype > Lisp_Symbol > (gdb) xsymbol > $2 = (struct Lisp_Symbol *) 0xaaaacd8485d0 > Cannot access memory at address 0xaaaacd8485d8 > (gdb) x/64gx 0x555577a7a710 > 0x555577a7a710: 0x0000000000000004 0x0000555577a7a700 > 0x555577a7a720: 0x0000000000000004 0x0000555577a7a710 > 0x555577a7a730: 0x0000000000000004 0x0000555577a7a720 > 0x555577a7a740: 0x0000000000000004 0x0000555577a7a730 > 0x555577a7a750: 0x0000000000000004 0x0000555577a7a740 > 0x555577a7a760: 0x0000000000000004 0x0000555577a7a750 > 0x555577a7a770: 0x0000000000000004 0x0000555577a7a760 > 0x555577a7a780: 0x0000000000000004 0x0000555577a7a770 > 0x555577a7a790: 0x0000000000000004 0x0000555577a7a780 > 0x555577a7a7a0: 0x0000000000000004 0x0000555577a7a790 > 0x555577a7a7b0: 0x0000000000000004 0x0000555577a7a7a0 > 0x555577a7a7c0: 0x0000000000000004 0x0000555577a7a7b0 > 0x555577a7a7d0: 0x0000000000000004 0x0000555577a7a7c0 > 0x555577a7a7e0: 0x0000000000000000 0x0000555577a7a800 That's a cons block, with free cons cells (the car is dead_object(), the cdr is the link to the next free cons cell). Then the mark bits (which are all zero, then the link to the next cons block (immediately afterwards). > 0x555577a7a7f0: 0x5f74736574225b3a 0x0000555577a77c00 This word reads as the string: :["test_ but it's probably just leftover from when this wasn't a cons block. In other words, something may have atttempted to access XCDR (0x555577a7a763) As this is quite strange, please try to produce a live GDB session or a core dump with a "bt full", and then we can walk the cons cells to see what went wrong. >> If you can set a breakpoint on the function >> "wrong_type_argument" (note there may be some false positives) > > "wrong_type_argument" for some reason triggers > on every attempt to open file. Yes, it does trigger a lot. You can restrict the breakpoint to trigger only when value is Qlistp by doing b wrong_type_argument if value == Qlistp then whenever it stops, get a "bt full" and "c" if it doesn't look like the right one. The last bt full before the crash will be the interesting one. > I will try to rebuild emacs with sanitizer. --enable-checking=all might help. The sanitizer might, too, I guess :-) Pip
bug-gnu-emacs <at> gnu.org:bug#76327; Package emacs.
(Mon, 17 Feb 2025 20:32:02 GMT) Full text and rfc822 format available.bug-gnu-emacs <at> gnu.org:bug#76327; Package emacs.
(Tue, 18 Feb 2025 09:56:02 GMT) Full text and rfc822 format available.Message #35 received at submit <at> debbugs.gnu.org (full text, mbox):
From: Evgeniy Dushistov <dushistov <at> mail.ru> To: Pip Cet <pipcet <at> protonmail.com> Cc: bug-gnu-emacs <at> gnu.org, 76327 <at> debbugs.gnu.org, Eli Zaretskii <eliz <at> gnu.org> Subject: Re: bug#76327: 29.4; random segfaults after switch to tree-sitter Date: Tue, 18 Feb 2025 12:55:12 +0300
[Message part 1 (text/plain, inline)]
On Mon, Feb 17, 2025 at 08:31:25PM +0000, Pip Cet wrote:
> Yes, it does trigger a lot. You can restrict the breakpoint to trigger
> only when value is Qlistp by doing
>
> b wrong_type_argument if value == Qlistp
>
I build with enable-checking=all and use b wrong_type_argument if value == Qlistp.
lisp.h:1497: Emacs fatal error: assertion failed: CONSP (a)
Thread 1 "emacs-29.4" hit Breakpoint 2, terminate_due_to_signal (sig=sig <at> entry=6, backtrace_limit=backtrace_limit <at> entry=2147483647) at emacs.c:426
426 {
(gdb) bt
#0 terminate_due_to_signal (sig=sig <at> entry=6, backtrace_limit=backtrace_limit <at> entry=2147483647) at emacs.c:426
#1 0x00005555555d23df in die (msg=msg <at> entry=0x55555590e0f8 "CONSP (a)", file=file <at> entry=0x55555590e048 "lisp.h", line=line <at> entry=1497) at alloc.c:7707
#2 0x00005555555c5ded in XCONS (a=<optimized out>) at /usr/src/debug/emacs/emacs-29.4/src/lisp.h:1497
#3 0x00005555555c5df6 in XCONS (a=<optimized out>) at /usr/src/debug/emacs/emacs-29.4/src/lisp.h:1496
#4 0x000055555576c053 in XCAR (c=<optimized out>) at /usr/src/debug/emacs/emacs-29.4/src/lisp.h:1523
#5 make_lispy_event (event=0x555555f2f660 <kbd_buffer+9216>) at keyboard.c:6375
#6 0x000055555577278f in kbd_buffer_get_event (kbp=<synthetic pointer>, used_mouse_menu=<optimized out>, end_time=<optimized out>) at keyboard.c:4297
#7 read_event_from_main_queue (end_time=end_time <at> entry=0x0, local_getcjmp=local_getcjmp <at> entry=0x7fffffffd300, used_mouse_menu=used_mouse_menu <at> entry=0x7fffffffd64b) at keyboard.c:2279
#8 0x0000555555779293 in read_decoded_event_from_main_queue (end_time=<optimized out>, local_getcjmp=<optimized out>, prev_event=<optimized out>, used_mouse_menu=<optimized out>)
at keyboard.c:2342
#9 read_char (commandflag=1, map=map <at> entry=0x555559490bc3, prev_event=0x0, used_mouse_menu=used_mouse_menu <at> entry=0x7fffffffd64b, end_time=end_time <at> entry=0x0) at keyboard.c:2973
#10 0x000055555577be75 in read_key_sequence
(keybuf=keybuf <at> entry=0x7fffffffd790, prompt=prompt <at> entry=0x0, dont_downcase_last=dont_downcase_last <at> entry=false, can_return_switch_frame=can_return_switch_frame <at> entry=true, fix_current_buffer=fix_current_buffer <at> entry=true, prevent_redisplay=prevent_redisplay <at> entry=false) at keyboard.c:10084
#11 0x000055555577e45f in command_loop_1 () at /usr/src/debug/emacs/emacs-29.4/src/lisp.h:1172
#12 0x0000555555820e46 in internal_condition_case (bfun=bfun <at> entry=0x55555577e210 <command_loop_1>, handlers=handlers <at> entry=0x90, hfun=hfun <at> entry=0x55555576db70 <cmd_error>) at eval.c:1474
#13 0x000055555576222f in command_loop_2 (handlers=handlers <at> entry=0x90) at keyboard.c:1133
#14 0x0000555555820d78 in internal_catch (tag=<optimized out>, func=func <at> entry=0x5555557621f0 <command_loop_2>, arg=arg <at> entry=0x90) at eval.c:1197
#15 0x000055555576283e in command_loop () at keyboard.c:1111
#16 0x000055555576d165 in recursive_edit_1 () at keyboard.c:720
#17 0x000055555576d864 in Frecursive_edit () at keyboard.c:803
#18 0x00005555555c58f9 in main (argc=1, argv=0x7fffffffdc78) at emacs.c:2521
Full gdb log (with "bt full") see in attachment.
> then whenever it stops, get a "bt full" and "c" if it doesn't look like
> the right one. The last bt full before the crash will be the
> interesting one.
>
> > I will try to rebuild emacs with sanitizer.
>
> --enable-checking=all might help. The sanitizer might, too, I guess :-)
>
Sanitizer catch segfault during build of emacs.
May be I need some special configure flags?
I just specify "-fsanitize=address" in CFLAGS and "-lasan" in LDFLAGS,
and also "--with-pdumper=no --with-unexec=no --with-dumping=none" just in case.
Loading loadup.el (source)...
Dump mode: nil
Using load-path (/home/evgeniy/bigdisk1/linux-infra/arch_build/modified-packages/emacs/src/emacs-29.4/lisp /home/evgeniy/bigdisk1/linux-infra/arch_build/modified-packages/emacs/src/emacs-29.4/lisp/emacs-lisp /home/evgeniy/bigdisk1/linux-infra/arch_build/modified-packages/emacs/src/emacs-29.4/lisp/progmodes /home/evgeniy/bigdisk1/linux-infra/arch_build/modified-packages/emacs/src/emacs-29.4/lisp/language /home/evgeniy/bigdisk1/linux-infra/arch_build/modified-packages/emacs/src/emacs-29.4/lisp/international /home/evgeniy/bigdisk1/linux-infra/arch_build/modified-packages/emacs/src/emacs-29.4/lisp/textmodes /home/evgeniy/bigdisk1/linux-infra/arch_build/modified-packages/emacs/src/emacs-29.4/lisp/vc)
Loading emacs-lisp/debug-early...
Loading emacs-lisp/byte-run...
Loading emacs-lisp/backquote...
Loading subr...
Loading keymap...
Fatal error 11: Segmentation fault
Backtrace:
/usr/lib/libasan.so.8(___interceptor_backtrace+0xa4) [0x7e41a82a8834]
../src/emacs(emacs_backtrace+0x10b) [0x57f4196198ad]
../src/emacs(terminate_due_to_signal+0x13d) [0x57f4195c3603]
../src/emacs(+0x401d9e) [0x57f419613d9e]
../src/emacs(+0x401e16) [0x57f419613e16]
../src/emacs(+0x401e6e) [0x57f419613e6e]
/usr/lib/libc.so.6(+0x3dcd0) [0x7e41a5debcd0]
../src/emacs(mark_memory+0x2c) [0x57f4196d2285]
../src/emacs(mark_c_stack+0xd) [0x57f4196d22c3]
../src/emacs(+0x62ed3f) [0x57f419840d3f]
../src/emacs(flush_stack_call_func1+0x47) [0x57f4196cf591]
../src/emacs(mark_threads+0x27) [0x57f419842b93]
../src/emacs(garbage_collect+0x533) [0x57f4196d2820]
../src/emacs(maybe_garbage_collect+0x27) [0x57f4196d36c4]
../src/emacs(eval_sub+0x242) [0x57f419718002]
../src/emacs(+0x576efd) [0x57f419788efd]
../src/emacs(Fload+0x1c16) [0x57f41978acb1]
../src/emacs(eval_sub+0x10f6) [0x57f419718eb6]
../src/emacs(+0x576efd) [0x57f419788efd]
../src/emacs(Fload+0x1c16) [0x57f41978acb1]
../src/emacs(eval_sub+0x10f6) [0x57f419718eb6]
../src/emacs(Feval+0x80) [0x57f41971f2c4]
../src/emacs(+0x3b5d8b) [0x57f4195c7d8b]
../src/emacs(internal_condition_case+0xce) [0x57f41970be4b]
../src/emacs(+0x3b5c56) [0x57f4195c7c56]
../src/emacs(internal_catch+0x3e) [0x57f41970bc8f]
../src/emacs(+0x3b5b72) [0x57f4195c7b72]
../src/emacs(recursive_edit_1+0x144) [0x57f4195d3668]
../src/emacs(Frecursive_edit+0x202) [0x57f4195d3e75]
../src/emacs(main+0x37f7) [0x57f4195c6e91]
--
/Evgeniy
[gdb.txt (text/plain, attachment)]
bug-gnu-emacs <at> gnu.org:bug#76327; Package emacs.
(Tue, 18 Feb 2025 09:56:02 GMT) Full text and rfc822 format available.bug-gnu-emacs <at> gnu.org:bug#76327; Package emacs.
(Tue, 18 Feb 2025 14:56:01 GMT) Full text and rfc822 format available.Message #41 received at 76327 <at> debbugs.gnu.org (full text, mbox):
From: Eli Zaretskii <eliz <at> gnu.org> To: Evgeniy Dushistov <dushistov <at> mail.ru> Cc: pipcet <at> protonmail.com, 76327 <at> debbugs.gnu.org Subject: Re: bug#76327: 29.4; random segfaults after switch to tree-sitter Date: Tue, 18 Feb 2025 16:55:38 +0200
> Date: Tue, 18 Feb 2025 12:55:12 +0300
> From: Evgeniy Dushistov <dushistov <at> mail.ru>
> Cc: bug-gnu-emacs <at> gnu.org, Eli Zaretskii <eliz <at> gnu.org>,
> 76327 <at> debbugs.gnu.org
>
>
> On Mon, Feb 17, 2025 at 08:31:25PM +0000, Pip Cet wrote:
> > Yes, it does trigger a lot. You can restrict the breakpoint to trigger
> > only when value is Qlistp by doing
> >
> > b wrong_type_argument if value == Qlistp
> >
>
> I build with enable-checking=all and use b wrong_type_argument if value == Qlistp.
>
> lisp.h:1497: Emacs fatal error: assertion failed: CONSP (a)
Is this session still inside GDB? I guess not, which is a pity.
The crash is here:
if (CONSP (event->arg))
return list5 (head, position, make_fixnum (double_click_count),
XCAR (event->arg), Fcons (XCAR (XCDR (event->arg)),
XCAR (XCDR (XCDR (event->arg)))));
It's an assertion violation, which probably means XCAR(event->arg) is
not a cons cell. So it would be important to see the exact value of
event->arg at this point. Like this:
(gdb) fr 5
(gdb) pp event->arg
If GDB says it doesn't know about "pp", do this:
(gdb) source /path/to/emacs/stc/.gdbinit
and then repeat the above 2 commands.
If you already let Emacs continue and crash (and exit), then please
wait till the next time it crashes, leave it running under GDB, and
post the backtrace here. We then will try to ask you to display
several values and report the results, so that we could figure out
what could be the problem.
Thanks.
P.S. You could also try building the latest pretest of what will soon
become Emacs 30.1, maybe this problem was already fixed. You can find
the pretest tarballs here:
https://alpha.gnu.org/gnu/emacs/pretest/
bug-gnu-emacs <at> gnu.org:bug#76327; Package emacs.
(Tue, 18 Feb 2025 15:11:01 GMT) Full text and rfc822 format available.Message #44 received at 76327 <at> debbugs.gnu.org (full text, mbox):
From: Evgeniy Dushistov <dushistov <at> mail.ru> To: Eli Zaretskii <eliz <at> gnu.org> Cc: pipcet <at> protonmail.com, 76327 <at> debbugs.gnu.org Subject: Re: bug#76327: 29.4; random segfaults after switch to tree-sitter Date: Tue, 18 Feb 2025 18:09:45 +0300
On Tue, Feb 18, 2025 at 04:55:38PM +0200, Eli Zaretskii wrote: > Is this session still inside GDB? I guess not, which is a pity. > Yes, it still alive. > The crash is here: > > if (CONSP (event->arg)) > return list5 (head, position, make_fixnum (double_click_count), > XCAR (event->arg), Fcons (XCAR (XCDR (event->arg)), > XCAR (XCDR (XCDR (event->arg))))); > > It's an assertion violation, which probably means XCAR(event->arg) is > not a cons cell. So it would be important to see the exact value of > event->arg at this point. Like this: > > (gdb) fr 5 > (gdb) pp event->arg > > If GDB says it doesn't know about "pp", do this: > > (gdb) source /path/to/emacs/stc/.gdbinit > > and then repeat the above 2 commands. > (gdb) fr 5 #5 make_lispy_event (event=0x555555f308e0 <kbd_buffer+13952>) at keyboard.c:6375 warning: Source file is more recent than executable. 6375 return list5 (head, position, make_fixnum (double_click_count), (gdb) pp event->arg (33558466) > If you already let Emacs continue and crash (and exit), then please > wait till the next time it crashes, leave it running under GDB, and > post the backtrace here. We then will try to ask you to display > several values and report the results, so that we could figure out > what could be the problem. > > Thanks. > > P.S. You could also try building the latest pretest of what will soon > become Emacs 30.1, maybe this problem was already fixed. You can find > the pretest tarballs here: > > https://alpha.gnu.org/gnu/emacs/pretest/ I tried https://aur.archlinux.org/cgit/aur.git/tree/PKGBUILD?h=emacs-git , it built emacs from git rev 4cf53c436159ea54dbfe1a1e24515e2e6fbf9a6f, it is crashed after 1 day. And it has annoying issue, then after C-x C-f I press "/" to open file via absolute path it eats "/", so I switched back to 29.4. -- /Evgeniy
bug-gnu-emacs <at> gnu.org:bug#76327; Package emacs.
(Tue, 18 Feb 2025 15:13:02 GMT) Full text and rfc822 format available.Message #47 received at 76327 <at> debbugs.gnu.org (full text, mbox):
From: Pip Cet <pipcet <at> protonmail.com> To: Eli Zaretskii <eliz <at> gnu.org> Cc: 76327 <at> debbugs.gnu.org, Evgeniy Dushistov <dushistov <at> mail.ru> Subject: Re: bug#76327: 29.4; random segfaults after switch to tree-sitter Date: Tue, 18 Feb 2025 15:12:41 +0000
"Eli Zaretskii" <eliz <at> gnu.org> writes: >> Date: Tue, 18 Feb 2025 12:55:12 +0300 >> From: Evgeniy Dushistov <dushistov <at> mail.ru> >> Cc: bug-gnu-emacs <at> gnu.org, Eli Zaretskii <eliz <at> gnu.org>, >> 76327 <at> debbugs.gnu.org >> >> >> On Mon, Feb 17, 2025 at 08:31:25PM +0000, Pip Cet wrote: >> > Yes, it does trigger a lot. You can restrict the breakpoint to trigger >> > only when value is Qlistp by doing >> > >> > b wrong_type_argument if value == Qlistp >> > >> >> I build with enable-checking=all and use b wrong_type_argument if value == Qlistp. >> >> lisp.h:1497: Emacs fatal error: assertion failed: CONSP (a) > > Is this session still inside GDB? I guess not, which is a pity. > > The crash is here: > > if (CONSP (event->arg)) > return list5 (head, position, make_fixnum (double_click_count), > XCAR (event->arg), Fcons (XCAR (XCDR (event->arg)), > XCAR (XCDR (XCDR (event->arg))))); > > It's an assertion violation, which probably means XCAR(event->arg) is > not a cons cell. So it would be important to see the exact value of XCAR (event->arg) probably isn't a cons cell, but XCDR (event->arg) and XCDR (XCDR (event->arg)) should be. The various crashes all look like there's some sort of fundamental GC problem, leading us to free cons cells which are still reachable. Can we find out precisely which compiler is in use? Maybe it would even help to get hold of the emacs binary... > P.S. You could also try building the latest pretest of what will soon > become Emacs 30.1, maybe this problem was already fixed. You can find > the pretest tarballs here: > > https://alpha.gnu.org/gnu/emacs/pretest/ That's also a great idea. My guess it's the unusual compile flags cause some sort of miscompilation here. Pip
bug-gnu-emacs <at> gnu.org:bug#76327; Package emacs.
(Tue, 18 Feb 2025 15:39:02 GMT) Full text and rfc822 format available.Message #50 received at 76327 <at> debbugs.gnu.org (full text, mbox):
From: Pip Cet <pipcet <at> protonmail.com> To: bug-gnu-emacs <at> gnu.org, Eli Zaretskii <eliz <at> gnu.org>, Evgeniy Dushistov <dushistov <at> mail.ru>, 76327 <at> debbugs.gnu.org Subject: Re: bug#76327: 29.4; random segfaults after switch to tree-sitter Date: Tue, 18 Feb 2025 15:38:43 +0000
"Evgeniy Dushistov via \"Bug reports for GNU Emacs, the Swiss army knife of text editors\"" <bug-gnu-emacs <at> gnu.org> writes: > On Tue, Feb 18, 2025 at 04:55:38PM +0200, Eli Zaretskii wrote: >> The crash is here: >> >> if (CONSP (event->arg)) >> return list5 (head, position, make_fixnum (double_click_count), >> XCAR (event->arg), Fcons (XCAR (XCDR (event->arg)), >> XCAR (XCDR (XCDR (event->arg))))); >> >> It's an assertion violation, which probably means XCAR(event->arg) is >> not a cons cell. So it would be important to see the exact value of >> event->arg at this point. Like this: >> >> (gdb) fr 5 >> (gdb) pp event->arg >> >> If GDB says it doesn't know about "pp", do this: >> >> (gdb) source /path/to/emacs/stc/.gdbinit >> >> and then repeat the above 2 commands. >> > > (gdb) fr 5 > #5 make_lispy_event (event=0x555555f308e0 <kbd_buffer+13952>) at keyboard.c:6375 > warning: Source file is more recent than executable. > 6375 return list5 (head, position, make_fixnum (double_click_count), > (gdb) pp event->arg > (33558466) So XCDR (event->arg) is nil, not a cons cell, and its car is also not what it should be. (My reading of xterm.c is that it should be Qnil, and there should be floats in the list following the nil). The car would be XLI(0x8003f0a), but that doesn't ring any immediate bells (it might be a weird character with a shift modifier, but not an ASCII one...) So this still seems like a GC issue. Pip
bug-gnu-emacs <at> gnu.org:bug#76327; Package emacs.
(Tue, 18 Feb 2025 15:40:02 GMT) Full text and rfc822 format available.bug-gnu-emacs <at> gnu.org:bug#76327; Package emacs.
(Tue, 18 Feb 2025 15:47:01 GMT) Full text and rfc822 format available.Message #56 received at 76327 <at> debbugs.gnu.org (full text, mbox):
From: Eli Zaretskii <eliz <at> gnu.org> To: Pip Cet <pipcet <at> protonmail.com> Cc: 76327 <at> debbugs.gnu.org, dushistov <at> mail.ru Subject: Re: bug#76327: 29.4; random segfaults after switch to tree-sitter Date: Tue, 18 Feb 2025 17:46:18 +0200
> Date: Tue, 18 Feb 2025 15:38:43 +0000 > From: Pip Cet <pipcet <at> protonmail.com> > > "Evgeniy Dushistov via \"Bug reports for GNU Emacs, the Swiss army knife of text editors\"" <bug-gnu-emacs <at> gnu.org> writes: > > > (gdb) fr 5 > > #5 make_lispy_event (event=0x555555f308e0 <kbd_buffer+13952>) at keyboard.c:6375 > > warning: Source file is more recent than executable. > > 6375 return list5 (head, position, make_fixnum (double_click_count), > > (gdb) pp event->arg > > (33558466) > > So XCDR (event->arg) is nil, not a cons cell, and its car is also not > what it should be. (My reading of xterm.c is that it should be Qnil, > and there should be floats in the list following the nil). > > The car would be XLI(0x8003f0a), but that doesn't ring any immediate > bells (it might be a weird character with a shift modifier, but not an > ASCII one...) But we are talking about a mouse-wheel event, so it cannot be a character with a modifier, right? > So this still seems like a GC issue. Probably. I just don't understand what could that have to do with tree-sitter.
bug-gnu-emacs <at> gnu.org:bug#76327; Package emacs.
(Tue, 18 Feb 2025 16:15:02 GMT) Full text and rfc822 format available.Message #59 received at 76327 <at> debbugs.gnu.org (full text, mbox):
From: Eli Zaretskii <eliz <at> gnu.org> To: Evgeniy Dushistov <dushistov <at> mail.ru> Cc: pipcet <at> protonmail.com, 76327 <at> debbugs.gnu.org Subject: Re: bug#76327: 29.4; random segfaults after switch to tree-sitter Date: Tue, 18 Feb 2025 18:13:43 +0200
> Date: Tue, 18 Feb 2025 18:09:45 +0300 > From: Evgeniy Dushistov <dushistov <at> mail.ru> > Cc: pipcet <at> protonmail.com, 76327 <at> debbugs.gnu.org > > > P.S. You could also try building the latest pretest of what will soon > > become Emacs 30.1, maybe this problem was already fixed. You can find > > the pretest tarballs here: > > > > https://alpha.gnu.org/gnu/emacs/pretest/ > > I tried https://aur.archlinux.org/cgit/aur.git/tree/PKGBUILD?h=emacs-git , > it built emacs from git rev 4cf53c436159ea54dbfe1a1e24515e2e6fbf9a6f, > it is crashed after 1 day. That's the development version from the master branch, it could be not stable enough. The pretest I mentioned above should be more stable. > And it has annoying issue, then after C-x C-f I press "/" to open > file via absolute path it eats "/", Doesn't happen here, so this is very strange.
bug-gnu-emacs <at> gnu.org:bug#76327; Package emacs.
(Tue, 18 Feb 2025 16:22:01 GMT) Full text and rfc822 format available.Message #62 received at 76327 <at> debbugs.gnu.org (full text, mbox):
From: Evgeniy Dushistov <dushistov <at> mail.ru> To: Pip Cet <pipcet <at> protonmail.com> Cc: Eli Zaretskii <eliz <at> gnu.org>, 76327 <at> debbugs.gnu.org Subject: Re: bug#76327: 29.4; random segfaults after switch to tree-sitter Date: Tue, 18 Feb 2025 19:20:44 +0300
On Tue, Feb 18, 2025 at 03:12:41PM +0000, Pip Cet wrote: > Can we find out precisely which compiler is in use? Maybe it would even > help to get hold of the emacs binary... > The compiler (gcc) and emacs binary from Arch Linux, all the last avaible versions. I rebuild emacs several times during attempts to debug, but all starts from official emacs binary crashes. Here is initial bug report in arch linux issue tracker: https://gitlab.archlinux.org/archlinux/packaging/packages/emacs/-/issues/6 -- /Evgeniy
bug-gnu-emacs <at> gnu.org:bug#76327; Package emacs.
(Tue, 18 Feb 2025 17:25:02 GMT) Full text and rfc822 format available.Message #65 received at 76327 <at> debbugs.gnu.org (full text, mbox):
From: Eli Zaretskii <eliz <at> gnu.org> To: Evgeniy Dushistov <dushistov <at> mail.ru> Cc: pipcet <at> protonmail.com, 76327 <at> debbugs.gnu.org Subject: Re: bug#76327: 29.4; random segfaults after switch to tree-sitter Date: Tue, 18 Feb 2025 19:23:55 +0200
> Date: Tue, 18 Feb 2025 19:20:44 +0300 > From: Evgeniy Dushistov <dushistov <at> mail.ru> > Cc: Eli Zaretskii <eliz <at> gnu.org>, 76327 <at> debbugs.gnu.org > > On Tue, Feb 18, 2025 at 03:12:41PM +0000, Pip Cet wrote: > > Can we find out precisely which compiler is in use? Maybe it would even > > help to get hold of the emacs binary... > > > > The compiler (gcc) and emacs binary from Arch Linux, all the last avaible > versions. > > I rebuild emacs several times during attempts to debug, > but all starts from official emacs binary crashes. > > Here is initial bug report in arch linux issue tracker: > > https://gitlab.archlinux.org/archlinux/packaging/packages/emacs/-/issues/6 This is all very strange. So much so that I'm inclined to suspect some hardware problem on that system. Did you try building and using the same versions on a different box?
bug-gnu-emacs <at> gnu.org:bug#76327; Package emacs.
(Tue, 18 Feb 2025 17:45:02 GMT) Full text and rfc822 format available.Message #68 received at 76327 <at> debbugs.gnu.org (full text, mbox):
From: Pip Cet <pipcet <at> protonmail.com> To: Eli Zaretskii <eliz <at> gnu.org> Cc: 76327 <at> debbugs.gnu.org, Paul Eggert <eggert <at> cs.ucla.edu>, Evgeniy Dushistov <dushistov <at> mail.ru>, Mattias Engdegård <mattiasengdegard <at> gmail.com> Subject: Re: bug#76327: 29.4; random segfaults after switch to tree-sitter Date: Tue, 18 Feb 2025 17:44:15 +0000
"Eli Zaretskii" <eliz <at> gnu.org> writes:
>> Date: Tue, 18 Feb 2025 19:20:44 +0300
>> From: Evgeniy Dushistov <dushistov <at> mail.ru>
>> Cc: Eli Zaretskii <eliz <at> gnu.org>, 76327 <at> debbugs.gnu.org
>>
>> On Tue, Feb 18, 2025 at 03:12:41PM +0000, Pip Cet wrote:
>> > Can we find out precisely which compiler is in use? Maybe it would even
>> > help to get hold of the emacs binary...
>> >
>>
>> The compiler (gcc) and emacs binary from Arch Linux, all the last avaible
>> versions.
>>
>> I rebuild emacs several times during attempts to debug,
>> but all starts from official emacs binary crashes.
>>
>> Here is initial bug report in arch linux issue tracker:
>>
>> https://gitlab.archlinux.org/archlinux/packaging/packages/emacs/-/issues/6
>
> This is all very strange. So much so that I'm inclined to suspect
> some hardware problem on that system. Did you try building and using
> the same versions on a different box?
I'm pretty sure it's a GCC issue. Here's disass mark_threads from the
archlinux binary:
Dump of assembler code for function mark_threads:
0x0000555555857740 <+0>: endbr64
0x0000555555857744 <+4>: push %rbp
0x0000555555857745 <+5>: xor %esi,%esi
0x0000555555857747 <+7>: lea 0xf2(%rip),%rdi # 0x555555857840
0x000055555585774e <+14>: mov %rsp,%rbp
0x0000555555857751 <+17>: push %r15
0x0000555555857753 <+19>: push %r14
0x0000555555857755 <+21>: push %r13
0x0000555555857757 <+23>: push %r12
0x0000555555857759 <+25>: push %rbx
0x000055555585775a <+26>: pop %rbx
0x000055555585775b <+27>: pop %r12
0x000055555585775d <+29>: pop %r13
0x000055555585775f <+31>: pop %r14
0x0000555555857761 <+33>: pop %r15
0x0000555555857763 <+35>: pop %rbp
0x0000555555857764 <+36>: jmp 0x555555791410 <flush_stack_call_func1>
0x0000555555857769 <+41>: nop
Here's what it should look like:
Dump of assembler code for function mark_threads:
0x000000000087c0d0 <+0>: endbr64
0x000000000087c0d4 <+4>: push %rbp
0x000000000087c0d5 <+5>: xor %esi,%esi
0x000000000087c0d7 <+7>: lea -0x28fe(%rip),%rdi # 0x8797e0 <mark_threads_callback>
0x000000000087c0de <+14>: mov %rsp,%rbp
0x000000000087c0e1 <+17>: push %r15
0x000000000087c0e3 <+19>: push %r14
0x000000000087c0e5 <+21>: push %r13
0x000000000087c0e7 <+23>: push %r12
0x000000000087c0e9 <+25>: push %rbx
0x000000000087c0ea <+26>: sub $0x8,%rsp
0x000000000087c0ee <+30>: call 0x691560 <flush_stack_call_func1>
0x000000000087c0f3 <+35>: add $0x8,%rsp
0x000000000087c0f7 <+39>: pop %rbx
0x000000000087c0f8 <+40>: pop %r12
0x000000000087c0fa <+42>: pop %r13
0x000000000087c0fc <+44>: pop %r14
0x000000000087c0fe <+46>: pop %r15
0x000000000087c100 <+48>: pop %rbp
0x000000000087c101 <+49>: ret
End of assembler dump.
The difference is crucial: the broken version pushes the call-saved
registers, then pops them again immediately afterwards, then overwrites
them in flush_stack_call_func1. The correct version keeps the
call-saved registers on the stack while calling flush_stack_call_func1.
We need to find which of the (many) unusual compiler options cause this
miscompilation, and how to avoid it.
As __builtin_unwind_init isn't really documented, I guess it's okay for
GCC to have decided no longer to implement it in the appropriate
fashion.
Paul, Mattias, do you agree with this analysis?
Evgeniy,, could you try replacing the definition of
flush_stack_call_func in lisp.h by this definition, and recompiling?
INLINE void
flush_stack_call_func (void (*func) (void *arg), void *arg)
{
volatile bool repeat = true;
while (repeat)
{
__builtin_unwind_init ();
asm volatile ("" : : : "memory");
flush_stack_call_func1 (func, arg);
repeat = false;
}
}
This attempts to force GCC to make sure the call-saved registers are
still live by the time we call flush_stack_call_func1, by making it
believe that it might have to call __builtin_unwind_init again depending
on the value of a volatile bool variable.
The asm statement is probably unnecessary.
I'll try figuring out which compiler option is to blame now.
Pip
bug-gnu-emacs <at> gnu.org:bug#76327; Package emacs.
(Tue, 18 Feb 2025 17:52:04 GMT) Full text and rfc822 format available.Message #71 received at 76327 <at> debbugs.gnu.org (full text, mbox):
From: Evgeniy Dushistov <dushistov <at> mail.ru> To: Eli Zaretskii <eliz <at> gnu.org> Cc: pipcet <at> protonmail.com, 76327 <at> debbugs.gnu.org Subject: Re: bug#76327: 29.4; random segfaults after switch to tree-sitter Date: Tue, 18 Feb 2025 20:51:20 +0300
On Tue, Feb 18, 2025 at 07:23:55PM +0200, Eli Zaretskii wrote: > This is all very strange. So much so that I'm inclined to suspect > some hardware problem on that system. Did you try building and using > the same versions on a different box? I use the same emacs version on other "box", but it has different OS (macOS) and different compiler (clang I suppose?), plus I don't use emacs that heavily on other "box". It takes from 30 minutes to 48 hours of "editing" to reproduce problem. So emacs does not crash on other machine, but it is too different. Hardward issues is possible, but I doubt about it. This is machine with "ecc" memory, and only emacs crashes according to syslogs. And emacs crashes in the same place every time, it is looks very unbelievable for hardward issue. -- /Evgeniy
bug-gnu-emacs <at> gnu.org:bug#76327; Package emacs.
(Tue, 18 Feb 2025 18:18:02 GMT) Full text and rfc822 format available.Message #74 received at 76327 <at> debbugs.gnu.org (full text, mbox):
From: Pip Cet <pipcet <at> protonmail.com> To: Eli Zaretskii <eliz <at> gnu.org>, Stefan Kangas <stefankangas <at> gmail.com> Cc: 76327 <at> debbugs.gnu.org, Paul Eggert <eggert <at> cs.ucla.edu>, Evgeniy Dushistov <dushistov <at> mail.ru>, Mattias Engdegård <mattiasengdegard <at> gmail.com> Subject: Re: bug#76327: 29.4; random segfaults after switch to tree-sitter Date: Tue, 18 Feb 2025 18:16:58 +0000
Pip Cet <pipcet <at> protonmail.com> writes:
> The asm statement is probably unnecessary.
>
> I'll try figuring out which compiler option is to blame now.
Bug#65727 appears to be the relevant one. Maybe the fix should be
backported?
INLINE void
flush_stack_call_func (void (*func) (void *arg), void *arg)
{
__builtin_unwind_init ();
flush_stack_call_func1 (func, arg);
/* Work around GCC sibling call optimization making
'__builtin_unwind_init' ineffective (bug#65727).
See <https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115132>. */
#if defined __GNUC__ && !defined __clang__ && !defined __OBJC__
asm ("");
#endif
}
Evgeniy, GC bugs like this one are hard to diagnose. Sorry this took so
long.
Eli, Stefan K, what should be done with Emacs 29.4? If more binaries
like the one produced by Arch Linux are out there, people are most
likely to observe unstable Emacs systems, even if they don't end up
reporting bugs here.
Between this, the setjmp "scrambling" issues affecting MPS, and the way
-fanalyze=address breaks conservative GC, it seems like we really should
ask the GCC folks for an option to support conservative GC, and provide
appropriate builtins. Maybe clang would follow suit.
Pip
bug-gnu-emacs <at> gnu.org:bug#76327; Package emacs.
(Tue, 18 Feb 2025 19:41:02 GMT) Full text and rfc822 format available.Message #77 received at 76327 <at> debbugs.gnu.org (full text, mbox):
From: Eli Zaretskii <eliz <at> gnu.org> To: Pip Cet <pipcet <at> protonmail.com> Cc: 76327 <at> debbugs.gnu.org, eggert <at> cs.ucla.edu, dushistov <at> mail.ru, mattiasengdegard <at> gmail.com Subject: Re: bug#76327: 29.4; random segfaults after switch to tree-sitter Date: Tue, 18 Feb 2025 21:40:02 +0200
> Date: Tue, 18 Feb 2025 17:44:15 +0000 > From: Pip Cet <pipcet <at> protonmail.com> > Cc: Evgeniy Dushistov <dushistov <at> mail.ru>, 76327 <at> debbugs.gnu.org, Paul Eggert <eggert <at> cs.ucla.edu>, Mattias Engdegård <mattiasengdegard <at> gmail.com> > > "Eli Zaretskii" <eliz <at> gnu.org> writes: > > > This is all very strange. So much so that I'm inclined to suspect > > some hardware problem on that system. Did you try building and using > > the same versions on a different box? > > I'm pretty sure it's a GCC issue. Yes, that's another possibility. In what version of GCC does this happen?
bug-gnu-emacs <at> gnu.org:bug#76327; Package emacs.
(Tue, 18 Feb 2025 20:07:02 GMT) Full text and rfc822 format available.Message #80 received at 76327 <at> debbugs.gnu.org (full text, mbox):
From: Evgeniy Dushistov <dushistov <at> mail.ru> To: Eli Zaretskii <eliz <at> gnu.org> Cc: Pip Cet <pipcet <at> protonmail.com>, eggert <at> cs.ucla.edu, 76327 <at> debbugs.gnu.org, mattiasengdegard <at> gmail.com Subject: Re: bug#76327: 29.4; random segfaults after switch to tree-sitter Date: Tue, 18 Feb 2025 23:05:58 +0300
On Tue, Feb 18, 2025 at 09:40:02PM +0200, Eli Zaretskii wrote: > > I'm pretty sure it's a GCC issue. > > Yes, that's another possibility. > > In what version of GCC does this happen? gcc (GCC) 14.2.1 20250207 -- /Evgeniy
bug-gnu-emacs <at> gnu.org:bug#76327; Package emacs.
(Tue, 18 Feb 2025 20:19:01 GMT) Full text and rfc822 format available.Message #83 received at 76327 <at> debbugs.gnu.org (full text, mbox):
From: Eli Zaretskii <eliz <at> gnu.org> To: Pip Cet <pipcet <at> protonmail.com> Cc: 76327 <at> debbugs.gnu.org, eggert <at> cs.ucla.edu, dushistov <at> mail.ru, stefankangas <at> gmail.com, mattiasengdegard <at> gmail.com Subject: Re: bug#76327: 29.4; random segfaults after switch to tree-sitter Date: Tue, 18 Feb 2025 22:18:05 +0200
> Date: Tue, 18 Feb 2025 18:16:58 +0000 > From: Pip Cet <pipcet <at> protonmail.com> > Cc: Evgeniy Dushistov <dushistov <at> mail.ru>, 76327 <at> debbugs.gnu.org, Paul Eggert <eggert <at> cs.ucla.edu>, Mattias Engdegård <mattiasengdegard <at> gmail.com> > > Pip Cet <pipcet <at> protonmail.com> writes: > > > The asm statement is probably unnecessary. > > > > I'll try figuring out which compiler option is to blame now. > > Bug#65727 appears to be the relevant one. OK, so this should be definitely fixed in Emacs 30. But Evgeniy says that even the master branch crashes, so what does this tell us? > Maybe the fix should be backported? Backported to Emacs 29? We don't plan on any further releases from the emacs-29 branch. Distros might consider backporting that if they still maintain and support Emacs 29 and older. > Eli, Stefan K, what should be done with Emacs 29.4? See above: we won't make any further Emacs 29.x releases. > Between this, the setjmp "scrambling" issues affecting MPS, and the way > -fanalyze=address breaks conservative GC, it seems like we really should > ask the GCC folks for an option to support conservative GC, and provide > appropriate builtins. Maybe clang would follow suit. Feel free to suggest that to them.
bug-gnu-emacs <at> gnu.org:bug#76327; Package emacs.
(Tue, 18 Feb 2025 23:47:01 GMT) Full text and rfc822 format available.Message #86 received at 76327 <at> debbugs.gnu.org (full text, mbox):
From: Pip Cet <pipcet <at> protonmail.com> To: Eli Zaretskii <eliz <at> gnu.org> Cc: 76327 <at> debbugs.gnu.org, eggert <at> cs.ucla.edu, dushistov <at> mail.ru, stefankangas <at> gmail.com, mattiasengdegard <at> gmail.com Subject: Re: bug#76327: 29.4; random segfaults after switch to tree-sitter Date: Tue, 18 Feb 2025 23:46:08 +0000
"Eli Zaretskii" <eliz <at> gnu.org> writes: >> Date: Tue, 18 Feb 2025 18:16:58 +0000 >> From: Pip Cet <pipcet <at> protonmail.com> >> Cc: Evgeniy Dushistov <dushistov <at> mail.ru>, 76327 <at> debbugs.gnu.org, Paul Eggert <eggert <at> cs.ucla.edu>, Mattias Engdegård <mattiasengdegard <at> gmail.com> >> >> Pip Cet <pipcet <at> protonmail.com> writes: >> >> > The asm statement is probably unnecessary. >> > >> > I'll try figuring out which compiler option is to blame now. >> >> Bug#65727 appears to be the relevant one. > > OK, so this should be definitely fixed in Emacs 30. But Evgeniy says > that even the master branch crashes, so what does this tell us? Different bug? I haven't seen a backtrace or anything for the master branch, just a number of strange GC-related bugs that are all explained by the __builtin_unwind_init thing, plus the -fsanitize=address thing. >> Maybe the fix should be backported? > > Backported to Emacs 29? We don't plan on any further releases from > the emacs-29 branch. Distros might consider backporting that if they > still maintain and support Emacs 29 and older. Okay. Pip
bug-gnu-emacs <at> gnu.org:bug#76327; Package emacs.
(Wed, 19 Feb 2025 11:22:01 GMT) Full text and rfc822 format available.Message #89 received at 76327 <at> debbugs.gnu.org (full text, mbox):
From: Evgeniy Dushistov <dushistov <at> mail.ru> To: Pip Cet <pipcet <at> protonmail.com> Cc: Eli Zaretskii <eliz <at> gnu.org>, Paul Eggert <eggert <at> cs.ucla.edu>, 76327 <at> debbugs.gnu.org, Mattias Engdegård <mattiasengdegard <at> gmail.com> Subject: Re: bug#76327: 29.4; random segfaults after switch to tree-sitter Date: Wed, 19 Feb 2025 14:20:53 +0300
On Tue, Feb 18, 2025 at 05:44:15PM +0000, Pip Cet wrote:
> Evgeniy,, could you try replacing the definition of
> flush_stack_call_func in lisp.h by this definition, and recompiling?
>
> INLINE void
> flush_stack_call_func (void (*func) (void *arg), void *arg)
> {
> volatile bool repeat = true;
> while (repeat)
> {
> __builtin_unwind_init ();
> asm volatile ("" : : : "memory");
> flush_stack_call_func1 (func, arg);
> repeat = false;
> }
> }
>
I tried this fix.
It doesn't help :(
New crash dump looks the same to previous (I rebuilt without --enable-checking=all):
(gdb) bt
#0 __pthread_kill_implementation (threadid=<optimized out>, signo=signo <at> entry=11, no_tid=no_tid <at> entry=0) at pthread_kill.c:44
#1 0x000077717feb96d3 in __pthread_kill_internal (threadid=<optimized out>, signo=11) at pthread_kill.c:89
#2 0x000077717fe5fba0 in __GI_raise (sig=sig <at> entry=11) at ../sysdeps/posix/raise.c:26
#3 0x00005e89a9d6e7ca in terminate_due_to_signal (sig=sig <at> entry=11, backtrace_limit=backtrace_limit <at> entry=40) at emacs.c:464
#4 0x00005e89a9d6f092 in handle_fatal_signal (sig=sig <at> entry=11) at sysdep.c:1783
#5 0x00005e89a9d6f099 in deliver_thread_signal (sig=sig <at> entry=11, handler=0x5e89a9d6f07f <handle_fatal_signal>) at sysdep.c:1775
#6 0x00005e89a9ee0341 in deliver_fatal_thread_signal (sig=11) at sysdep.c:1795
#7 handle_sigsegv (sig=11, siginfo=<optimized out>, arg=<optimized out>) at sysdep.c:1888
#8 0x000077717fe5fcd0 in <signal handler called> () at /usr/lib/libc.so.6
#9 SYMBOL_NAME (sym=0x5e89b479fc10) at /usr/src/debug/emacs/emacs-29.4/src/lisp.h:1152
#10 print_object (obj=0x5e89b479fc10, printcharfun=<optimized out>, escapeflag=true) at print.c:2398
#11 0x00005e89a9f8618d in print (obj=<optimized out>, printcharfun=<optimized out>, escapeflag=<optimized out>) at print.c:1301
#12 0x00005e89a9f862d3 in Fprin1 (object=0x5e89b479fc10, printcharfun=printcharfun <at> entry=0x30, overrides=overrides <at> entry=0x0) at print.c:776
#13 0x00005e89a9f86af9 in print_error_message (data=<optimized out>, data <at> entry=0x5e89c039cbd3, stream=stream <at> entry=0x30, context=<optimized out>, caller=caller <at> entry=0x7fe0) at print.c:1134
#14 0x00005e89a9ec503b in Fcommand_error_default_function (data=0x5e89c039cbd3, context=0x77717bc80284, signal=0x7fe0) at /usr/src/debug/emacs/emacs-29.4/src/lisp.h:1679
#15 0x00005e89a9fabd6c in exec_byte_code (fun=<optimized out>, args_template=<optimized out>, nargs=<optimized out>, args=<optimized out>) at bytecode.c:809
#16 0x00005e89a9f5e0c5 in Ffuncall (nargs=nargs <at> entry=4, args=args <at> entry=0x7ffc97562ab0) at eval.c:2999
#17 0x00005e89a9ec591e in call3 (fn=<optimized out>, arg1=0x5e89c039cbd3, arg2=<optimized out>, arg3=0x7fe0) at /usr/src/debug/emacs/emacs-29.4/src/lisp.h:3262
#18 cmd_error_internal (data=data <at> entry=0x5e89c039cbd3, context=context <at> entry=0x7ffc97562b20 "") at keyboard.c:1013
#19 0x00005e89a9ec5aa2 in cmd_error (data=0x5e89c039cbd3) at keyboard.c:981
#20 0x00005e89a9f58771 in internal_condition_case (bfun=bfun <at> entry=0x5e89a9ed3360 <command_loop_1>, handlers=handlers <at> entry=0x90, hfun=hfun <at> entry=0x5e89a9ec5950 <cmd_error>) at eval.c:1470
#21 0x00005e89a9ebd73f in command_loop_2 (handlers=handlers <at> entry=0x90) at keyboard.c:1133
#22 0x00005e89a9f586d8 in internal_catch (tag=tag <at> entry=0x10080, func=func <at> entry=0x5e89a9ebd700 <command_loop_2>, arg=arg <at> entry=0x90) at eval.c:1197
#23 0x00005e89a9ebd6c5 in command_loop () at keyboard.c:1111
#24 0x00005e89a9ec5461 in recursive_edit_1 () at keyboard.c:720
#25 0x00005e89a9ec583d in Frecursive_edit () at keyboard.c:803
#26 0x00005e89a9d7d0e6 in main (argc=1, argv=0x7ffc97562f38) at emacs.c:2521
(gdb) li 4227
4229 INLINE void
4230 flush_stack_call_func (void (*func) (void *arg), void *arg)
4231 {
4232 volatile bool repeat = true;
4233 while (repeat)
4234 {
4235 __builtin_unwind_init ();
4236 asm volatile ("" : : : "memory");
4237 flush_stack_call_func1 (func, arg);
4238 repeat = false;
4239 }
4240 }
--
/Evgeniy
bug-gnu-emacs <at> gnu.org:bug#76327; Package emacs.
(Wed, 19 Feb 2025 12:37:02 GMT) Full text and rfc822 format available.Message #92 received at submit <at> debbugs.gnu.org (full text, mbox):
From: Pip Cet <pipcet <at> protonmail.com> To: bug-gnu-emacs <at> gnu.org, Evgeniy Dushistov <dushistov <at> mail.ru>, Eli Zaretskii <eliz <at> gnu.org>, Paul Eggert <eggert <at> cs.ucla.edu>, 76327 <at> debbugs.gnu.org, Mattias Engdegård <mattiasengdegard <at> gmail.com> Subject: Re: bug#76327: 29.4; random segfaults after switch to tree-sitter Date: Wed, 19 Feb 2025 12:36:37 +0000
"Evgeniy Dushistov via \"Bug reports for GNU Emacs, the Swiss army knife of text editors\"" <bug-gnu-emacs <at> gnu.org> writes:
> On Tue, Feb 18, 2025 at 05:44:15PM +0000, Pip Cet wrote:
>> Evgeniy,, could you try replacing the definition of
>> flush_stack_call_func in lisp.h by this definition, and recompiling?
>>
>> INLINE void
>> flush_stack_call_func (void (*func) (void *arg), void *arg)
>> {
>> volatile bool repeat = true;
>> while (repeat)
>> {
>> __builtin_unwind_init ();
>> asm volatile ("" : : : "memory");
>> flush_stack_call_func1 (func, arg);
>> repeat = false;
>> }
>> }
>>
>
>
> I tried this fix.
> It doesn't help :(
Oops. Interesting.
> New crash dump looks the same to previous (I rebuilt without --enable-checking=all):
>
> (gdb) bt
Please use "bt full", not "bt", and please keep the sessions alive in
gdb.
Also, please reproduce your precise CFLAGS and compiler version, there's
likely to be a problem there.
> #0 __pthread_kill_implementation (threadid=<optimized out>, signo=signo <at> entry=11, no_tid=no_tid <at> entry=0) at pthread_kill.c:44
> #1 0x000077717feb96d3 in __pthread_kill_internal (threadid=<optimized out>, signo=11) at pthread_kill.c:89
> #2 0x000077717fe5fba0 in __GI_raise (sig=sig <at> entry=11) at ../sysdeps/posix/raise.c:26
> #3 0x00005e89a9d6e7ca in terminate_due_to_signal (sig=sig <at> entry=11, backtrace_limit=backtrace_limit <at> entry=40) at emacs.c:464
> #4 0x00005e89a9d6f092 in handle_fatal_signal (sig=sig <at> entry=11) at sysdep.c:1783
> #5 0x00005e89a9d6f099 in deliver_thread_signal (sig=sig <at> entry=11, handler=0x5e89a9d6f07f <handle_fatal_signal>) at sysdep.c:1775
> #6 0x00005e89a9ee0341 in deliver_fatal_thread_signal (sig=11) at sysdep.c:1795
> #7 handle_sigsegv (sig=11, siginfo=<optimized out>, arg=<optimized out>) at sysdep.c:1888
> #8 0x000077717fe5fcd0 in <signal handler called> () at /usr/lib/libc.so.6
> #9 SYMBOL_NAME (sym=0x5e89b479fc10) at /usr/src/debug/emacs/emacs-29.4/src/lisp.h:1152
> #10 print_object (obj=0x5e89b479fc10, printcharfun=<optimized out>, escapeflag=true) at print.c:2398
> #11 0x00005e89a9f8618d in print (obj=<optimized out>, printcharfun=<optimized out>, escapeflag=<optimized out>) at print.c:1301
> #12 0x00005e89a9f862d3 in Fprin1 (object=0x5e89b479fc10, printcharfun=printcharfun <at> entry=0x30, overrides=overrides <at> entry=0x0) at print.c:776
> #13 0x00005e89a9f86af9 in print_error_message (data=<optimized out>,
> data <at> entry=0x5e89c039cbd3, stream=stream <at> entry=0x30,
> context=<optimized out>, caller=caller <at> entry=0x7fe0) at print.c:1134
> #14 0x00005e89a9ec503b in Fcommand_error_default_function
> (data=0x5e89c039cbd3, context=0x77717bc80284, signal=0x7fe0) at
> /usr/src/debug/emacs/emacs-29.4/src/lisp.h:1679
> #15 0x00005e89a9fabd6c in exec_byte_code (fun=<optimized out>, args_template=<optimized out>, nargs=<optimized out>, args=<optimized out>) at bytecode.c:809
> #16 0x00005e89a9f5e0c5 in Ffuncall (nargs=nargs <at> entry=4, args=args <at> entry=0x7ffc97562ab0) at eval.c:2999
> #17 0x00005e89a9ec591e in call3 (fn=<optimized out>,
> arg1=0x5e89c039cbd3, arg2=<optimized out>, arg3=0x7fe0) at
> /usr/src/debug/emacs/emacs-29.4/src/lisp.h:3262
> #18 cmd_error_internal (data=data <at> entry=0x5e89c039cbd3, context=context <at> entry=0x7ffc97562b20 "") at keyboard.c:1013
> #19 0x00005e89a9ec5aa2 in cmd_error (data=0x5e89c039cbd3) at keyboard.c:981
> #20 0x00005e89a9f58771 in internal_condition_case
> (bfun=bfun <at> entry=0x5e89a9ed3360 <command_loop_1>,
> handlers=handlers <at> entry=0x90, hfun=hfun <at> entry=0x5e89a9ec5950
> <cmd_error>) at eval.c:1470
> #21 0x00005e89a9ebd73f in command_loop_2 (handlers=handlers <at> entry=0x90) at keyboard.c:1133
> #22 0x00005e89a9f586d8 in internal_catch (tag=tag <at> entry=0x10080, func=func <at> entry=0x5e89a9ebd700 <command_loop_2>, arg=arg <at> entry=0x90) at eval.c:1197
> #23 0x00005e89a9ebd6c5 in command_loop () at keyboard.c:1111
> #24 0x00005e89a9ec5461 in recursive_edit_1 () at keyboard.c:720
> #25 0x00005e89a9ec583d in Frecursive_edit () at keyboard.c:803
> #26 0x00005e89a9d7d0e6 in main (argc=1, argv=0x7ffc97562f38) at emacs.c:2521
>
>
> (gdb) li 4227
>
> 4229 INLINE void
> 4230 flush_stack_call_func (void (*func) (void *arg), void *arg)
> 4231 {
> 4232 volatile bool repeat = true;
> 4233 while (repeat)
> 4234 {
> 4235 __builtin_unwind_init ();
> 4236 asm volatile ("" : : : "memory");
> 4237 flush_stack_call_func1 (func, arg);
> 4238 repeat = false;
> 4239 }
> 4240 }
Please disassemble this function by running
disass flush_stack_call_func
Thanks!
Pip
bug-gnu-emacs <at> gnu.org:bug#76327; Package emacs.
(Wed, 19 Feb 2025 12:37:02 GMT) Full text and rfc822 format available.bug-gnu-emacs <at> gnu.org:bug#76327; Package emacs.
(Wed, 19 Feb 2025 16:08:02 GMT) Full text and rfc822 format available.Message #98 received at 76327 <at> debbugs.gnu.org (full text, mbox):
From: Evgeniy Dushistov <dushistov <at> mail.ru> To: Pip Cet <pipcet <at> protonmail.com> Cc: bug-gnu-emacs <at> gnu.org, Paul Eggert <eggert <at> cs.ucla.edu>, 76327 <at> debbugs.gnu.org, Eli Zaretskii <eliz <at> gnu.org>, Mattias Engdegård <mattiasengdegard <at> gmail.com> Subject: Re: bug#76327: 29.4; random segfaults after switch to tree-sitter Date: Wed, 19 Feb 2025 19:07:43 +0300
On Wed, Feb 19, 2025 at 12:36:37PM +0000, Pip Cet wrote:
> Please use "bt full", not "bt", and please keep the sessions alive in
> gdb.
>
I ran it, waiting to crash again.
> Also, please reproduce your precise CFLAGS and compiler version, there's
> likely to be a problem there.
>
As I said earlier I used default compiler from Arch Linux distro:
gcc (GCC) 14.2.1 20250207, I used default PKGBUILD from this distro for emacs package,
Appropriate part of my /etc/makepkg.conf, makepkg utility takes all flags from this file:
CARCH="x86_64"
CHOST="x86_64-pc-linux-gnu"
CFLAGS="-march=nehalem -mtune=znver1 -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 -fno-optimize-sibling-calls"
CXXFLAGS="$CFLAGS -Wp,-D_GLIBCXX_ASSERTIONS"
LDFLAGS="-Wl,-O1 -Wl,--sort-common -Wl,--as-needed -Wl,-z,relro -Wl,-z,now \
-Wl,-z,pack-relative-relocs"
LTOFLAGS="-flto=auto"
MAKEFLAGS="-j33"
DEBUG_CFLAGS="-g"
DEBUG_CXXFLAGS="$DEBUG_CFLAGS"
DEBUG_RUSTFLAGS="-C debuginfo=2"
I tried patched version of emacs (with modified flush_stack_call_func) with
"-fno-optimize-sibling-calls" and without this flag.
Both crashed.
> Please disassemble this function by running
>
> disass flush_stack_call_func
>
It is completely gone after inlining:
(gdb) disassemble flush_stack_call_func
No symbol "flush_stack_call_func" in current context.
(gdb) disassemble flush_stack_call_func1
Dump of assembler code for function flush_stack_call_func1:
0x000000000021d870 <+0>: endbr64
0x000000000021d874 <+4>: mov 0x5d2955(%rip),%rdx # 0x7f01d0 <current_thread>
0x000000000021d87b <+11>: push %rbp
0x000000000021d87c <+12>: mov %rdi,%rax
0x000000000021d87f <+15>: mov %rsi,%rdi
0x000000000021d882 <+18>: mov %rsp,%rbp
0x000000000021d885 <+21>: mov %rbp,0x50(%rdx)
0x000000000021d889 <+25>: call *%rax
0x000000000021d88b <+27>: pop %rbp
0x000000000021d88c <+28>: ret
End of assembler dump.
--
/Evgeniy
bug-gnu-emacs <at> gnu.org:bug#76327; Package emacs.
(Wed, 19 Feb 2025 16:09:02 GMT) Full text and rfc822 format available.bug-gnu-emacs <at> gnu.org:bug#76327; Package emacs.
(Wed, 19 Feb 2025 16:16:02 GMT) Full text and rfc822 format available.Message #104 received at submit <at> debbugs.gnu.org (full text, mbox):
From: Evgeniy Dushistov <dushistov <at> mail.ru> To: Pip Cet <pipcet <at> protonmail.com> Cc: bug-gnu-emacs <at> gnu.org, Paul Eggert <eggert <at> cs.ucla.edu>, 76327 <at> debbugs.gnu.org, Eli Zaretskii <eliz <at> gnu.org>, Mattias Engdegård <mattiasengdegard <at> gmail.com> Subject: Re: bug#76327: 29.4; random segfaults after switch to tree-sitter Date: Wed, 19 Feb 2025 19:14:47 +0300
[Message part 1 (text/plain, inline)]
On Wed, Feb 19, 2025 at 07:07:48PM +0300, Evgeniy Dushistov wrote: > On Wed, Feb 19, 2025 at 12:36:37PM +0000, Pip Cet wrote: > > Please use "bt full", not "bt", and please keep the sessions alive in > > gdb. > > > > I ran it, waiting to crash again. > And here is the crash. See attached gdb.txt with "bt full" -- /Evgeniy
[gdb.txt (text/plain, attachment)]
bug-gnu-emacs <at> gnu.org:bug#76327; Package emacs.
(Wed, 19 Feb 2025 16:16:02 GMT) Full text and rfc822 format available.bug-gnu-emacs <at> gnu.org:bug#76327; Package emacs.
(Wed, 19 Feb 2025 16:33:01 GMT) Full text and rfc822 format available.Message #110 received at 76327 <at> debbugs.gnu.org (full text, mbox):
From: Eli Zaretskii <eliz <at> gnu.org> To: Evgeniy Dushistov <dushistov <at> mail.ru> Cc: pipcet <at> protonmail.com, eggert <at> cs.ucla.edu, 76327 <at> debbugs.gnu.org, mattiasengdegard <at> gmail.com Subject: Re: bug#76327: 29.4; random segfaults after switch to tree-sitter Date: Wed, 19 Feb 2025 18:32:09 +0200
> Date: Wed, 19 Feb 2025 14:20:53 +0300
> From: Evgeniy Dushistov <dushistov <at> mail.ru>
> Cc: Eli Zaretskii <eliz <at> gnu.org>, 76327 <at> debbugs.gnu.org,
> Paul Eggert <eggert <at> cs.ucla.edu>,
> Mattias Engdegård <mattiasengdegard <at> gmail.com>
> "X-PGP-Key: https://sks-keyservers.net/pks/lookup?op=vindex&search=dushistov%40mail.ru"
>
> On Tue, Feb 18, 2025 at 05:44:15PM +0000, Pip Cet wrote:
> > Evgeniy,, could you try replacing the definition of
> > flush_stack_call_func in lisp.h by this definition, and recompiling?
> >
> > INLINE void
> > flush_stack_call_func (void (*func) (void *arg), void *arg)
> > {
> > volatile bool repeat = true;
> > while (repeat)
> > {
> > __builtin_unwind_init ();
> > asm volatile ("" : : : "memory");
> > flush_stack_call_func1 (func, arg);
> > repeat = false;
> > }
> > }
> >
>
>
> I tried this fix.
> It doesn't help :(
>
> New crash dump looks the same to previous (I rebuilt without --enable-checking=all):
Is this still in Emacs 29.4, only with the above patch applied? Or is
this a different version of Emacs?
bug-gnu-emacs <at> gnu.org:bug#76327; Package emacs.
(Wed, 19 Feb 2025 16:44:02 GMT) Full text and rfc822 format available.Message #113 received at 76327 <at> debbugs.gnu.org (full text, mbox):
From: Evgeniy Dushistov <dushistov <at> mail.ru> To: Eli Zaretskii <eliz <at> gnu.org> Cc: pipcet <at> protonmail.com, eggert <at> cs.ucla.edu, 76327 <at> debbugs.gnu.org, mattiasengdegard <at> gmail.com Subject: Re: bug#76327: 29.4; random segfaults after switch to tree-sitter Date: Wed, 19 Feb 2025 19:43:23 +0300
On Wed, Feb 19, 2025 at 06:32:09PM +0200, Eli Zaretskii wrote:
> Is this still in Emacs 29.4, only with the above patch applied? Or is
> this a different version of Emacs?
Yes, it emacs 29.4 with
Index: emacs-29.4/src/lisp.h
===================================================================
--- emacs-29.4.orig/src/lisp.h
+++ emacs-29.4/src/lisp.h
@@ -4229,8 +4229,14 @@ extern void mark_memory (void const *sta
INLINE void
flush_stack_call_func (void (*func) (void *arg), void *arg)
{
- __builtin_unwind_init ();
- flush_stack_call_func1 (func, arg);
+ volatile bool repeat = true;
+ while (repeat)
+ {
+ __builtin_unwind_init ();
+ asm volatile ("" : : : "memory");
+ flush_stack_call_func1 (func, arg);
+ repeat = false;
+ }
}
extern void garbage_collect (void);
--
/Evgeniy
bug-gnu-emacs <at> gnu.org:bug#76327; Package emacs.
(Wed, 19 Feb 2025 20:16:02 GMT) Full text and rfc822 format available.Message #116 received at 76327 <at> debbugs.gnu.org (full text, mbox):
From: Pip Cet <pipcet <at> protonmail.com> To: Evgeniy Dushistov <dushistov <at> mail.ru>, 76327 <at> debbugs.gnu.org, eggert <at> cs.ucla.edu, eliz <at> gnu.org, mattiasengdegard <at> gmail.com Subject: Re: bug#76327: 29.4; random segfaults after switch to tree-sitter Date: Wed, 19 Feb 2025 20:14:53 +0000
"Evgeniy Dushistov via \"Bug reports for GNU Emacs, the Swiss army knife of text editors\"" <bug-gnu-emacs <at> gnu.org> writes: > On Wed, Feb 19, 2025 at 12:36:37PM +0000, Pip Cet wrote: >> Please use "bt full", not "bt", and please keep the sessions alive in >> gdb. >> > > I ran it, waiting to crash again. > >> Also, please reproduce your precise CFLAGS and compiler version, there's >> likely to be a problem there. >> > > As I said earlier I used default compiler from Arch Linux distro: > gcc (GCC) 14.2.1 20250207, I used default PKGBUILD from this distro for emacs package, I tried building Emacs using makepkg and the archlinux docker image. No success so far: I finally managed to get a binory, but no crash so far. > Appropriate part of my /etc/makepkg.conf, makepkg utility takes all flags from this file: > > CARCH="x86_64" > CHOST="x86_64-pc-linux-gnu" > > CFLAGS="-march=nehalem -mtune=znver1 -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 -fno-optimize-sibling-calls" > CXXFLAGS="$CFLAGS -Wp,-D_GLIBCXX_ASSERTIONS" > LDFLAGS="-Wl,-O1 -Wl,--sort-common -Wl,--as-needed -Wl,-z,relro -Wl,-z,now \ > -Wl,-z,pack-relative-relocs" > LTOFLAGS="-flto=auto" > MAKEFLAGS="-j33" > DEBUG_CFLAGS="-g" > DEBUG_CXXFLAGS="$DEBUG_CFLAGS" > DEBUG_RUSTFLAGS="-C debuginfo=2" > > > I tried patched version of emacs (with modified flush_stack_call_func) with > "-fno-optimize-sibling-calls" and without this flag. > Both crashed. Hmm. And those crashes still aren't reproducible, and quite rare? They all look different, but they all look like GC hapened while unwinding through the specpdl or otherwise calling longjmp. And you say they happen with Emacs-30, too? I'm a bit confused that some builds mention LTO flags and some don't... >> Please disassemble this function by running >> >> disass flush_stack_call_func >> > > It is completely gone after inlining: > (gdb) disassemble flush_stack_call_func > No symbol "flush_stack_call_func" in current context. > (gdb) disassemble flush_stack_call_func1 > Dump of assembler code for function flush_stack_call_func1: > 0x000000000021d870 <+0>: endbr64 > 0x000000000021d874 <+4>: mov 0x5d2955(%rip),%rdx # 0x7f01d0 <current_thread> > 0x000000000021d87b <+11>: push %rbp > 0x000000000021d87c <+12>: mov %rdi,%rax > 0x000000000021d87f <+15>: mov %rsi,%rdi > 0x000000000021d882 <+18>: mov %rsp,%rbp > 0x000000000021d885 <+21>: mov %rbp,0x50(%rdx) > 0x000000000021d889 <+25>: call *%rax > 0x000000000021d88b <+27>: pop %rbp > 0x000000000021d88c <+28>: ret > End of assembler dump. Try disassembling mark_threads, though I expect that to be okay now, to be honest. Something else must be the problem. Pip
bug-gnu-emacs <at> gnu.org:bug#76327; Package emacs.
(Thu, 20 Feb 2025 06:13:01 GMT) Full text and rfc822 format available.Message #119 received at 76327 <at> debbugs.gnu.org (full text, mbox):
From: Eli Zaretskii <eliz <at> gnu.org> To: Pip Cet <pipcet <at> protonmail.com> Cc: 76327 <at> debbugs.gnu.org, eggert <at> cs.ucla.edu, dushistov <at> mail.ru, mattiasengdegard <at> gmail.com Subject: Re: bug#76327: 29.4; random segfaults after switch to tree-sitter Date: Thu, 20 Feb 2025 08:12:20 +0200
> Date: Wed, 19 Feb 2025 20:14:53 +0000 > From: Pip Cet <pipcet <at> protonmail.com> > > > It is completely gone after inlining: > > (gdb) disassemble flush_stack_call_func > > No symbol "flush_stack_call_func" in current context. > > (gdb) disassemble flush_stack_call_func1 > > Dump of assembler code for function flush_stack_call_func1: > > 0x000000000021d870 <+0>: endbr64 > > 0x000000000021d874 <+4>: mov 0x5d2955(%rip),%rdx # 0x7f01d0 <current_thread> > > 0x000000000021d87b <+11>: push %rbp > > 0x000000000021d87c <+12>: mov %rdi,%rax > > 0x000000000021d87f <+15>: mov %rsi,%rdi > > 0x000000000021d882 <+18>: mov %rsp,%rbp > > 0x000000000021d885 <+21>: mov %rbp,0x50(%rdx) > > 0x000000000021d889 <+25>: call *%rax > > 0x000000000021d88b <+27>: pop %rbp > > 0x000000000021d88c <+28>: ret > > End of assembler dump. > > Try disassembling mark_threads, though I expect that to be okay now, to > be honest. Something else must be the problem. Based on previous similar problems, removing the -D_FORTIFY_SOURCE=3 flag from the build will avoid the crashes with high probability. I think it is worth our while to see if that's the case with this problem, even if eventually the root cause will be found elsewhere, and _FORTIFY_SOURCE just triggers it somehow.
bug-gnu-emacs <at> gnu.org:bug#76327; Package emacs.
(Thu, 20 Feb 2025 15:25:02 GMT) Full text and rfc822 format available.Message #122 received at 76327 <at> debbugs.gnu.org (full text, mbox):
From: Evgeniy Dushistov <dushistov <at> mail.ru> To: Pip Cet <pipcet <at> protonmail.com> Cc: eliz <at> gnu.org, eggert <at> cs.ucla.edu, 76327 <at> debbugs.gnu.org, mattiasengdegard <at> gmail.com Subject: Re: bug#76327: 29.4; random segfaults after switch to tree-sitter Date: Thu, 20 Feb 2025 18:24:34 +0300
On Wed, Feb 19, 2025 at 08:14:53PM +0000, Pip Cet wrote: > Hmm. And those crashes still aren't reproducible, and quite rare? Yes, just random editing and crash. But not "quite rare", now it is one in hour or two. > They > all look different, but they all look like GC hapened while unwinding > through the specpdl or otherwise calling longjmp. And you say they > happen with Emacs-30, too? > Yes one crash of "/usr/bin/emacs-31.0.50" after ~ 2 days of work. > Try disassembling mark_threads, though I expect that to be okay now, to > be honest. Something else must be the problem. > (gdb) disassemble mark_threads Dump of assembler code for function mark_threads: 0x0000555555827470 <+0>: endbr64 0x0000555555827474 <+4>: push %rbp 0x0000555555827475 <+5>: mov %rsp,%rbp 0x0000555555827478 <+8>: push %r15 0x000055555582747a <+10>: push %r14 0x000055555582747c <+12>: push %r13 0x000055555582747e <+14>: push %r12 0x0000555555827480 <+16>: push %rbx 0x0000555555827481 <+17>: sub $0x18,%rsp 0x0000555555827485 <+21>: movb $0x1,-0x31(%rbp) 0x0000555555827489 <+25>: movzbl -0x31(%rbp),%eax 0x000055555582748d <+29>: test %al,%al 0x000055555582748f <+31>: je 0x5555558274b7 <mark_threads+71> 0x0000555555827491 <+33>: lea -0x1328(%rip),%rbx # 0x555555826170 <mark_threads_callback> 0x0000555555827498 <+40>: nopl 0x0(%rax,%rax,1) 0x00005555558274a0 <+48>: xor %esi,%esi 0x00005555558274a2 <+50>: mov %rbx,%rdi 0x00005555558274a5 <+53>: addr32 call 0x555555770a10 <flush_stack_call_func1> 0x00005555558274ab <+59>: movb $0x0,-0x31(%rbp) 0x00005555558274af <+63>: movzbl -0x31(%rbp),%eax 0x00005555558274b3 <+67>: test %al,%al 0x00005555558274b5 <+69>: jne 0x5555558274a0 <mark_threads+48> 0x00005555558274b7 <+71>: add $0x18,%rsp 0x00005555558274bb <+75>: pop %rbx 0x00005555558274bc <+76>: pop %r12 0x00005555558274be <+78>: pop %r13 0x00005555558274c0 <+80>: pop %r14 0x00005555558274c2 <+82>: pop %r15 0x00005555558274c4 <+84>: pop %rbp 0x00005555558274c5 <+85>: ret End of assembler dump. -- /Evgeniy
bug-gnu-emacs <at> gnu.org:bug#76327; Package emacs.
(Thu, 20 Feb 2025 15:27:02 GMT) Full text and rfc822 format available.Message #125 received at 76327 <at> debbugs.gnu.org (full text, mbox):
From: Evgeniy Dushistov <dushistov <at> mail.ru> To: Eli Zaretskii <eliz <at> gnu.org> Cc: Pip Cet <pipcet <at> protonmail.com>, eggert <at> cs.ucla.edu, 76327 <at> debbugs.gnu.org, mattiasengdegard <at> gmail.com Subject: Re: bug#76327: 29.4; random segfaults after switch to tree-sitter Date: Thu, 20 Feb 2025 18:26:37 +0300
On Thu, Feb 20, 2025 at 08:12:20AM +0200, Eli Zaretskii wrote:
> > Try disassembling mark_threads, though I expect that to be okay now, to
> > be honest. Something else must be the problem.
>
> Based on previous similar problems, removing the -D_FORTIFY_SOURCE=3
> flag from the build will avoid the crashes with high probability. I
> think it is worth our while to see if that's the case with this
> problem, even if eventually the root cause will be found elsewhere,
> and _FORTIFY_SOURCE just triggers it somehow.
I removed mention of _FORTIFY_SOURCE:
CFLAGS="-march=nehalem -mtune=znver1 -O2 -pipe -fno-plt -fexceptions \
-Wformat -Werror=format-security \
-fstack-clash-protection -fcf-protection \
-fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -fno-optimize-sibling-calls"
but it still crashes.
Here is "bt full":
#0 SYMBOL_NAME (sym=0x4000000002002000) at /usr/src/debug/emacs/emacs-29.4/src/lisp.h:1152
#1 print_object (obj=obj <at> entry=0x4000000002002000, printcharfun=printcharfun <at> entry=0x30, escapeflag=escapeflag <at> entry=true) at print.c:2398
len = 140737488343728
i = <optimized out>
name = <optimized out>
size_byte = <optimized out>
p = <optimized out>
signedp = <optimized out>
confusing = <optimized out>
base_depth = <optimized out>
base_sp = <optimized out>
buf = "\320\322\377\377\377\177\000\000\370]xUUU\000\0000\342\210UUU\000\000 \001", '\000' <repeats 15 times>, "\217\2319\343\321\343\026@\323\377\377\377\177"
print_obj = <optimized out>
#2 0x00005555557c70bf in print (obj=obj <at> entry=0x4000000002002000, printcharfun=0x30, escapeflag=escapeflag <at> entry=true) at print.c:1301
#3 0x00005555557c7210 in Fprin1 (object=0x4000000002002000, printcharfun=printcharfun <at> entry=0x30, overrides=overrides <at> entry=0x0) at print.c:776
count = {
bytes = <optimized out>
}
pc = {
printcharfun = 0x30,
old_printcharfun = 0x30,
old_point = -1,
start_point = -1,
old_point_byte = -1,
start_point_byte = -1,
specpdl_count = {
bytes = 224
}
}
#4 0x00005555557c7a39 in print_error_message (data=<optimized out>, data <at> entry=0x55555e5f33c3, stream=stream <at> entry=0x30, context=<optimized out>, caller=caller <at> entry=0x7fe0) at print.c:1134
obj = <optimized out>
li = {
tortoise = <optimized out>,
max = <optimized out>,
n = <optimized out>,
q = <optimized out>
}
sep = 0x55555587b951 ", "
errname = 0x11f70
errmsg = <optimized out>
file_error = <optimized out>
tail = 0x55555e5f3453
#5 0x0000555555704cab in Fcommand_error_default_function (data=0x55555e5f33c3, context=0x7ffff1880284, signal=0x7fe0) at /usr/src/debug/emacs/emacs-29.4/src/lisp.h:1679
sf = 0x5555561aee10
conditions = <optimized out>
is_minibuffer_quit = <optimized out>
#6 0x000055555579d211 in funcall_subr (subr=<optimized out>, numargs=numargs <at> entry=3, args=args <at> entry=0x7ffff0fff050) at eval.c:3042
argbuf = {0x555555ee96e3, 0x0, 0x1000101, 0x0, 0x0, 0x0, 0x1, 0x1f}
a = <optimized out>
fun = <optimized out>
#7 0x00005555557ecd0c in exec_byte_code (fun=<optimized out>, fun <at> entry=0x7ffff1ce5e3d, args_template=<optimized out>, args_template <at> entry=771, nargs=<optimized out>, args=<optimized out>) at bytecode.c:809
call_nargs = 3
call_fun = <optimized out>
count1 = {
bytes = <optimized out>
}
template = <optimized out>
val = <optimized out>
call_args = 0x7ffff0fff050
original_fun = 0x2aaa9bf19470
bytecode = <optimized out>
op = 3
type = <optimized out>
targets = {0x5555555b84c4 <exec_byte_code-2311164>, 0x5555557ed165 <exec_byte_code+2213>, 0x5555557ed15c <exec_byte_code+2204>, 0x5555557ed153 <exec_byte_code+2195>, 0x5555557ecad5 <exec_byte_code+533>, 0x5555557ecad9 <exec_byte_code+537>, 0x5555557ed117 <exec_byte_code+2135>, 0x5555557ed0db <exec_byte_code+2075>, 0x5555557ed9ce <exec_byte_code+4366>, 0x5555557ed9c5 <exec_byte_code+4357>, 0x5555557ed9bc <exec_byte_code+4348>, 0x5555557ed9b3 <exec_byte_code+4339>, 0x5555557ecb11 <exec_byte_code+593>, 0x5555557ecb20 <exec_byte_code+608>, 0x5555557ed9a3 <exec_byte_code+4323>, 0x5555557ed9d7 <exec_byte_code+4375>, 0x5555557eda89 <exec_byte_code+4553>, 0x5555557eda80 <exec_byte_code+4544>, 0x5555557eda77 <exec_byte_code+4535>, 0x5555557eda6e <exec_byte_code+4526>, 0x5555557eca4d <exec_byte_code+397>, 0x5555557eca60 <exec_byte_code+416>, 0x5555557eda4d <exec_byte_code+4493>, 0x5555557eda5d <exec_byte_code+4509>, 0x5555557ed9f1 <exec_byte_code+4401>, 0x5555557ed9e8 <exec_byte_code+4392>, 0x5555557edd3f <exec_byte_code+5247>, 0x5555557edd36 <exec_byte_code+5238>, 0x5555557ecd8c <exec_byte_code+1228>, 0x5555557ecd90 <exec_byte_code+1232>, 0x5555557eda0b <exec_byte_code+4427>, 0x5555557ed9fa <exec_byte_code+4410>, 0x5555557edd0c <exec_byte_code+5196>, 0x5555557edd03 <exec_byte_code+5187>, 0x5555557edcfa <exec_byte_code+5178>, 0x5555557edcf1 <exec_byte_code+5169>, 0x5555557ecb91 <exec_byte_code+721>, 0x5555557ecba0 <exec_byte_code+736>, 0x5555557edd26 <exec_byte_code+5222>, 0x5555557edd15 <exec_byte_code+5205>, 0x5555557edcc7 <exec_byte_code+5127>, 0x5555557edcbe <exec_byte_code+5118>, 0x5555557edcb5 <exec_byte_code+5109>, 0x5555557edcac <exec_byte_code+5100>, 0x5555557ecdd9 <exec_byte_code+1305>, 0x5555557ecde0 <exec_byte_code+1312>, 0x5555557edce1 <exec_byte_code+5153>, 0x5555557edcd0 <exec_byte_code+5136>, 0x5555557edbf8 <exec_byte_code+4920>, 0x5555557edc2b <exec_byte_code+4971>, 0x5555557edca0 <exec_byte_code+5088>, 0x5555555b84c8 <exec_byte_code-2311160>, 0x5555555b84c8 <exec_byte_code-2311160>, 0x5555555b84c8 <exec_byte_code-2311160>, 0x5555555b84c8 <exec_byte_code-2311160>, 0x5555555b84c8 <exec_byte_code-2311160>, 0x5555557ef041 <exec_byte_code+10113>, 0x5555557eefcf <exec_byte_code+9999>, 0x5555557eef89 <exec_byte_code+9929>, 0x5555557eef43 <exec_byte_code+9859>, 0x5555557eeeff <exec_byte_code+9791>, 0x5555557edb0a <exec_byte_code+4682>, 0x5555557edaca <exec_byte_code+4618>, 0x5555557eeece <exec_byte_code+9742>, 0x5555557edbbe <exec_byte_code+4862>, 0x5555557eda92 <exec_byte_code+4562>, 0x5555557eee8e <exec_byte_code+9678>, 0x5555557eee5e <exec_byte_code+9630>, 0x5555557eee1e <exec_byte_code+9566>, 0x5555557eede1 <exec_byte_code+9505>, 0x5555557eeda0 <exec_byte_code+9440>, 0x5555557eed29 <exec_byte_code+9321>, 0x5555557eecb4 <exec_byte_code+9204>, 0x5555557eec38 <exec_byte_code+9080>, 0x5555557eec08 <exec_byte_code+9032>, 0x5555557eebd8 <exec_byte_code+8984>, 0x5555557eeb98 <exec_byte_code+8920>, 0x5555557eeb58 <exec_byte_code+8856>, 0x5555557eeb18 <exec_byte_code+8792>, 0x5555557eead4 <exec_byte_code+8724>, 0x5555557eea9a <exec_byte_code+8666>, 0x5555557eea60 <exec_byte_code+8608>, 0x5555557eea26 <exec_byte_code+8550>, 0x5555557ee984 <exec_byte_code+8388>, 0x5555557ee929 <exec_byte_code+8297>, 0x5555557ee8d8 <exec_byte_code+8216>, 0x5555557ee884 <exec_byte_code+8132>, 0x5555557ee830 <exec_byte_code+8048>, 0x5555557ee7dc <exec_byte_code+7964>, 0x5555557ee788 <exec_byte_code+7880>, 0x5555557ee730 <exec_byte_code+7792>, 0x5555557ee6d4 <exec_byte_code+7700>, 0x5555557ee67c <exec_byte_code+7612>, 0x5555557ee624 <exec_byte_code+7524>, 0x5555557ee5cc <exec_byte_code+7436>, 0x5555557ee573 <exec_byte_code+7347>, 0x5555557ee483 <exec_byte_code+7107>, 0x5555557ece28 <exec_byte_code+1384>, 0x5555557ee453 <exec_byte_code+7059>, 0x5555557ee41e <exec_byte_code+7006>, 0x5555557ee38e <exec_byte_code+6862>, 0x5555557ee345 <exec_byte_code+6789>, 0x5555557ee315 <exec_byte_code+6741>, 0x5555557ee2e3 <exec_byte_code+6691>, 0x5555557ee2b1 <exec_byte_code+6641>, 0x5555557ee277 <exec_byte_code+6583>, 0x5555557ee245 <exec_byte_code+6533>, 0x5555555b84c8 <exec_byte_code-2311160>, 0x5555557ee213 <exec_byte_code+6483>, 0x5555557ee1e1 <exec_byte_code+6433>, 0x5555557ee1af <exec_byte_code+6383>, 0x5555557ee17d <exec_byte_code+6333>, 0x5555557ee14b <exec_byte_code+6283>, 0x5555557ee11b <exec_byte_code+6235>, 0x5555557ece2c <exec_byte_code+1388>, 0x5555555b84c8 <exec_byte_code-2311160>, 0x5555557ee0d8 <exec_byte_code+6168>, 0x5555557ee0a8 <exec_byte_code+6120>, 0x5555557ee078 <exec_byte_code+6072>, 0x5555557ed88a <exec_byte_code+4042>, 0x5555557ed84a <exec_byte_code+3978>, 0x5555557ed81a <exec_byte_code+3930>, 0x5555557ed7ea <exec_byte_code+3882>, 0x5555557ed7aa <exec_byte_code+3818>, 0x5555557ed76a <exec_byte_code+3754>, 0x5555557ed72a <exec_byte_code+3690>, 0x5555557ed6f8 <exec_byte_code+3640>, 0x5555557ed6c8 <exec_byte_code+3592>, 0x5555555b84c8 <exec_byte_code-2311160>, 0x5555557edd48 <exec_byte_code+5256>, 0x5555557edef9 <exec_byte_code+5689>, 0x5555557ed964 <exec_byte_code+4260>, 0x5555557edeba <exec_byte_code+5626>, 0x5555557ede7e <exec_byte_code+5566>, 0x5555557ede42 <exec_byte_code+5506>, 0x5555557edda5 <exec_byte_code+5349>, 0x5555557edd81 <exec_byte_code+5313>, 0x5555557eda1b <exec_byte_code+4443>, 0x5555557ee00c <exec_byte_code+5964>, 0x5555557edfa6 <exec_byte_code+5862>, 0x5555557edf70 <exec_byte_code+5808>, 0x5555557ee031 <exec_byte_code+6001>, 0x5555557ef17a <exec_byte_code+10426>, 0x5555557ef136 <exec_byte_code+10358>, 0x5555557ef0ec <exec_byte_code+10284>, 0x5555557ef08e <exec_byte_code+10190>, 0x5555555b84c8 <exec_byte_code-2311160>, 0x5555557ed684 <exec_byte_code+3524>, 0x5555557ed654 <exec_byte_code+3476>, 0x5555557ed624 <exec_byte_code+3428>, 0x5555557ed5f4 <exec_byte_code+3380>, 0x5555557ed5c4 <exec_byte_code+3332>, 0x5555557ed584 <exec_byte_code+3268>, 0x5555557ed544 <exec_byte_code+3204>, 0x5555557ed504 <exec_byte_code+3140>, 0x5555557ed4c4 <exec_byte_code+3076>, 0x5555557ed470 <exec_byte_code+2992>, 0x5555557ed430 <exec_byte_code+2928>, 0x5555557ed3f0 <exec_byte_code+2864>, 0x5555557ed3c0 <exec_byte_code+2816>, 0x5555557ed35d <exec_byte_code+2717>, 0x5555557ed2fa <exec_byte_code+2618>, 0x5555557ed2be <exec_byte_code+2558>, 0x5555557ed282 <exec_byte_code+2498>, 0x5555557ed248 <exec_byte_code+2440>, 0x5555557ee51b <exec_byte_code+7259>, 0x5555557ee4cc <exec_byte_code+7180>, 0x5555557ed1da <exec_byte_code+2330>, 0x5555557ed16e <exec_byte_code+2222>, 0x5555555b84c8 <exec_byte_code-2311160>, 0x5555555b84c8 <exec_byte_code-2311160>, 0x5555555b84c8 <exec_byte_code-2311160>, 0x5555555b84c8 <exec_byte_code-2311160>, 0x5555555b84c8 <exec_byte_code-2311160>, 0x5555555b84c8 <exec_byte_code-2311160>, 0x5555557eed59 <exec_byte_code+9369>, 0x5555557ee9df <exec_byte_code+8479>, 0x5555557ee3d7 <exec_byte_code+6935>, 0x5555557ed097 <exec_byte_code+2007>, 0x5555557ed053 <exec_byte_code+1939>, 0x5555555b84c8 <exec_byte_code-2311160>, 0x5555555b84c8 <exec_byte_code-2311160>, 0x5555557ed01c <exec_byte_code+1884>, 0x5555557ed902 <exec_byte_code+4162>, 0x5555555b84c8 <exec_byte_code-2311160>, 0x5555555b84c8 <exec_byte_code-2311160>, 0x5555555b84c8 <exec_byte_code-2311160>, 0x5555555b84c8 <exec_byte_code-2311160>, 0x5555555b84c8 <exec_byte_code-2311160>, 0x5555555b84c8 <exec_byte_code-2311160>, 0x5555555b84c8 <exec_byte_code-2311160>, 0x5555555b84c8 <exec_byte_code-2311160>, 0x5555557ed8ca <exec_byte_code+4106> <repeats 64 times>}
quitcounter = <optimized out>
bc = 0x555555d421b0 <main_thread+496>
top = 0x7ffff0fff048
pc = <optimized out>
bytestr = <optimized out>
vector = <optimized out>
maxdepth = <optimized out>
const_length = <optimized out>
bytestr_length = <optimized out>
vectorp = 0x7ffff1ce5e80
max_stack = <optimized out>
frame_base = <optimized out>
fp = <optimized out>
bytestr_data = <optimized out>
rest = <optimized out>
mandatory = <optimized out>
nonrest = <optimized out>
pushedargs = <optimized out>
result = <optimized out>
#8 0x000055555579ee77 in fetch_and_exec_byte_code (fun=0x7ffff1ce5e3d, args_template=771, nargs=93824994062694, args=0x7fffffffd848) at eval.c:3085
#9 funcall_lambda (fun=0x7ffff1ce5e3d, nargs=nargs <at> entry=3, arg_vector=arg_vector <at> entry=0x7fffffffd848) at eval.c:3157
val = <optimized out>
syms_left = <optimized out>
next = <optimized out>
lexenv = <optimized out>
count = {
bytes = <optimized out>
}
i = <optimized out>
optional = <optimized out>
rest = <optimized out>
previous_rest = <optimized out>
#10 0x000055555579f07c in funcall_general (fun=<optimized out>, numargs=numargs <at> entry=3, args=args <at> entry=0x7fffffffd848) at eval.c:2961
funcar = <optimized out>
original_fun = 0x2aaa9bf18fa8
#11 0x000055555579f2b5 in Ffuncall (nargs=nargs <at> entry=4, args=args <at> entry=0x7fffffffd840) at eval.c:2999
count = {
bytes = <optimized out>
}
val = <optimized out>
#12 0x000055555570557e in call3 (fn=<optimized out>, arg1=0x55555e5f33c3, arg2=<optimized out>, arg3=0x7fe0) at /usr/src/debug/emacs/emacs-29.4/src/lisp.h:3262
#13 cmd_error_internal (data=data <at> entry=0x55555e5f33c3, context=context <at> entry=0x7fffffffd8b0 "") at keyboard.c:1013
#14 0x00005555557056f8 in cmd_error (data=0x55555e5f33c3) at keyboard.c:981
old_level = <optimized out>
old_length = <optimized out>
count = {
bytes = <optimized out>
}
conditions = <optimized out>
macroerror = "\000\000\000\000\000\000\000\000\240\230", '\000' <repeats 14 times>, "\rׇ\361\377\177\000\000\000\331\377\377\377\177\000\000\000\217\2319\343\321\343\026\023d"
#15 0x0000555555799931 in internal_condition_case (bfun=bfun <at> entry=0x555555712fa0 <command_loop_1>, handlers=handlers <at> entry=0x90, hfun=hfun <at> entry=0x5555557055b0 <cmd_error>) at eval.c:1470
val = <optimized out>
c = 0x555555ec4c60
#16 0x00005555556fd5bf in command_loop_2 (handlers=handlers <at> entry=0x90) at keyboard.c:1133
val = <optimized out>
#17 0x0000555555799898 in internal_catch (tag=tag <at> entry=0x10080, func=func <at> entry=0x5555556fd580 <command_loop_2>, arg=arg <at> entry=0x90) at eval.c:1197
val = <optimized out>
c = 0x555555ec4b20
#18 0x00005555556fd545 in command_loop () at keyboard.c:1111
#19 0x00005555557050ce in recursive_edit_1 () at keyboard.c:720
count = {
bytes = <optimized out>
}
val = <optimized out>
#20 0x000055555570549d in Frecursive_edit () at keyboard.c:803
count = {
bytes = <optimized out>
}
buffer = <optimized out>
#21 0x00005555555be210 in main (argc=1, argv=0x7fffffffdcc8) at emacs.c:2521
stack_bottom_variable = 0x12f
no_loadup = false
junk = 0x0
dname_arg = 0x0
ch_to_dir = 0x0
original_pwd = <optimized out>
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:
"command-error-default-function" (0xf0fff050)
"help-command-error-confusable-suggestions" (0xffffd848)
Warning: 'set logging off', an alias for the command 'set logging enabled', is deprecated.
Use 'set logging enabled off'.
--
/Evgeniy
bug-gnu-emacs <at> gnu.org:bug#76327; Package emacs.
(Thu, 20 Feb 2025 16:39:02 GMT) Full text and rfc822 format available.Message #128 received at 76327 <at> debbugs.gnu.org (full text, mbox):
From: Pip Cet <pipcet <at> protonmail.com> To: Eli Zaretskii <eliz <at> gnu.org>, Evgeniy Dushistov <dushistov <at> mail.ru>, eggert <at> cs.ucla.edu, 76327 <at> debbugs.gnu.org, mattiasengdegard <at> gmail.com Subject: Re: bug#76327: 29.4; random segfaults after switch to tree-sitter Date: Thu, 20 Feb 2025 16:38:15 +0000
"Evgeniy Dushistov via \"Bug reports for GNU Emacs, the Swiss army knife of text editors\"" <bug-gnu-emacs <at> gnu.org> writes: > On Thu, Feb 20, 2025 at 08:12:20AM +0200, Eli Zaretskii wrote: >> > Try disassembling mark_threads, though I expect that to be okay now, to >> > be honest. Something else must be the problem. >> >> Based on previous similar problems, removing the -D_FORTIFY_SOURCE=3 >> flag from the build will avoid the crashes with high probability. I >> think it is worth our while to see if that's the case with this >> problem, even if eventually the root cause will be found elsewhere, >> and _FORTIFY_SOURCE just triggers it somehow. > > I removed mention of _FORTIFY_SOURCE: > > CFLAGS="-march=nehalem -mtune=znver1 -O2 -pipe -fno-plt -fexceptions \ > -Wformat -Werror=format-security \ > -fstack-clash-protection -fcf-protection \ > -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -fno-optimize-sibling-calls" Can you try setting the CFLAGS to plain "-O2", or even "-O0 -g3 -ggdb", to see whether you get crashes then, too? I don't know how GCC handles -fstack-clash-protection, for example, and "-fno-plt" isn't necessarily harmless either. (All of your crashes seem to happen right after a longjmp, so looking at glibc versions might also be worth it. Maybe it doesn't like being called except through the PLT?) Pip
bug-gnu-emacs <at> gnu.org:bug#76327; Package emacs.
(Thu, 20 Feb 2025 17:11:02 GMT) Full text and rfc822 format available.Message #131 received at 76327 <at> debbugs.gnu.org (full text, mbox):
From: Eli Zaretskii <eliz <at> gnu.org> To: Evgeniy Dushistov <dushistov <at> mail.ru> Cc: pipcet <at> protonmail.com, eggert <at> cs.ucla.edu, 76327 <at> debbugs.gnu.org, mattiasengdegard <at> gmail.com Subject: Re: bug#76327: 29.4; random segfaults after switch to tree-sitter Date: Thu, 20 Feb 2025 19:10:28 +0200
> Date: Thu, 20 Feb 2025 18:26:37 +0300 > From: Evgeniy Dushistov <dushistov <at> mail.ru> > Cc: Pip Cet <pipcet <at> protonmail.com>, 76327 <at> debbugs.gnu.org, > eggert <at> cs.ucla.edu, mattiasengdegard <at> gmail.com > > On Thu, Feb 20, 2025 at 08:12:20AM +0200, Eli Zaretskii wrote: > > > > Based on previous similar problems, removing the -D_FORTIFY_SOURCE=3 > > flag from the build will avoid the crashes with high probability. I > > think it is worth our while to see if that's the case with this > > problem, even if eventually the root cause will be found elsewhere, > > and _FORTIFY_SOURCE just triggers it somehow. > > I removed mention of _FORTIFY_SOURCE: > > CFLAGS="-march=nehalem -mtune=znver1 -O2 -pipe -fno-plt -fexceptions \ > -Wformat -Werror=format-security \ > -fstack-clash-protection -fcf-protection \ > -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -fno-optimize-sibling-calls" > > but it still crashes. Thanks. Another theory eats dust...
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.