bug#67900: 30.0.50; Emacs Crahes When Executing Command `consult-buffer'

bug#67900: 30.0.50; Emacs Crahes When Executing Command `consult-buffer'

[Chang Xiaoduan]

Recently I frequently expericence Emacs crashes when executing the
command `consult-buffer'. Though it is a command provided by a
third-party package, I assume Emacs should report an lisp error rather
than crashing? So I consider report this issue to GNU rather than author
of some emacs-lisp package. As you can see I am using Emacs on Windows
and I copmiled it from source using MinGW-w64. However, the same crash
happens with a pre-built 29.1 Emacs downloaded from a mirror site.


The backtrace is listed as follows:

(gdb) bt
#0  0x00007ffb3afbb3b3 in KERNELBASE!DebugBreak () from C:\Windows\System32\KernelBase.dll
#1  0x00007ff6230f8778 in emacs_abort () at ../../src/w32fns.c:11177
#2  0x00007ff622fc2119 in terminate_due_to_signal (sig=11, backtrace_limit=<optimized out>)
    at ../../src/emacs.c:484
#3  0x00007ff622fe4519 in deliver_fatal_thread_signal () at ../../src/sysdep.c:1811
#4  0x00007ff62315d972 in _gnu_exception_handler (exception_data=0xcf46df7500)
    at C:/M/B/src/mingw-w64/mingw-w64-crt/crt/crt_handler.c:213
#5  0x00007ffb3ccf7ff8 in msvcrt!__C_specific_handler () from C:\Windows\System32\msvcrt.dll
#6  0x00007ffb3d4923df in ntdll!.chkstk () from C:\Windows\SYSTEM32\ntdll.dll
#7  0x00007ffb3d4414a4 in ntdll!RtlRaiseException () from C:\Windows\SYSTEM32\ntdll.dll
#8  0x00007ffb3d490f0e in ntdll!KiUserExceptionDispatcher () from C:\Windows\SYSTEM32\ntdll.dll
#9  0x00007ff622ff85be in XSTRING (a=0x4) at ../../src/lisp.h:1622
#10 SCHARS (string=0x4) at ../../src/lisp.h:1701
#11 Fall_completions (string=0x1ff4343e96c, collection=<optimized out>, predicate=0x1ff4877b3e5,

    hide_spaces=0x0) at ../../src/minibuf.c:1936
#12 0x00007ff623053952 in Ffuncall (nargs=4, args=0xcf46df8bb0) at ../../src/eval.c:3016
#13 0x00007ffb24a81b60 in F636f6d706c6574652d776974682d616374696f6e_complete_with_action_0 ()
   from d:\emacs_home\workplace\emacs\build-debug\native-lisp\30.0.50-0d7a8ace\preloaded\minibuf
fer-1b0f548b-ffe4640c.eln
#14 0x00007ff6230a0d97 in exec_byte_code (fun=<optimized out>, args_template=<optimized out>,
    nargs=<optimized out>, nargs@entry=2195952233080, args=<optimized out>,
    args@entry=0x10000cf46df8da8) at ../../src/lisp.h:2210
#15 0x00007ff623058dab in fetch_and_exec_byte_code (args=0x10000cf46df8da8, nargs=2195952233080,

    args_template=<optimized out>, fun=<optimized out>) at ../../src/eval.c:3102
#16 0x00007ff623058fa6 in funcall_general (fun=<optimized out>, numargs=numargs@entry=3,
    args=args@entry=0xcf46df8da8) at ../../src/eval.c:2978
--Type <RET> for more, q to quit, c to continue without paging--
#17 0x00007ff623053952 in Ffuncall (nargs=nargs@entry=4, args=args@entry=0xcf46df8da0)
    at ../../src/eval.c:3016
#18 0x00007ff622ff84db in call3 (arg3=0x30, arg2=0x1ff4877b3e5, arg1=0x1ff4343e96c,
    fn=0x1ff48fad8a5) at ../../src/lisp.h:3262
#19 Fall_completions (string=0x1ff4343e96c, collection=0x1ff48fad8a5, predicate=0x1ff4877b3e5,
    hide_spaces=0x0) at ../../src/minibuf.c:1869
#20 0x00007ffb1e5b30c6 in F6f726465726c6573732d66696c746572_orderless_filter_0 ()
   from d:\emacs_home\.emacs.d\eln-cache\30.0.50-0d7a8ace\orderless-6e1acb3c-3f58e36d.eln
#21 0x00007ff623053952 in Ffuncall (nargs=4, args=0xcf46df8fc0) at ../../src/eval.c:3016
#22 0x00007ffb1e5b31c6 in F6f726465726c6573732d616c6c2d636f6d706c6574696f6e73_orderless_all_comp
letions_0 () from d:\emacs_home\.emacs.d\eln-cache\30.0.50-0d7a8ace\orderless-6e1acb3c-3f58e36d.
eln
#23 0x00007ff6230a0d97 in exec_byte_code (fun=<optimized out>, args_template=<optimized out>,
    nargs=<optimized out>, nargs@entry=2195952287256, args=<optimized out>,
    args@entry=0x10000cf46df91a8) at ../../src/lisp.h:2210
#24 0x00007ff623058dab in fetch_and_exec_byte_code (args=0x10000cf46df91a8, nargs=2195952287256,

    args_template=<optimized out>, fun=<optimized out>) at ../../src/eval.c:3102
#25 0x00007ff623058fa6 in funcall_general (fun=<optimized out>, numargs=numargs@entry=1,
    args=args@entry=0xcf46df91a8) at ../../src/eval.c:2978
#26 0x00007ff623053952 in Ffuncall (nargs=nargs@entry=2, args=args@entry=0xcf46df91a0)
    at ../../src/eval.c:3016
#27 0x00007ff623062077 in call1 (arg1=<optimized out>, fn=0xffff82092148bfb0)
    at ../../src/lisp.h:3248
#28 mapcar1 (leni=2, vals=vals@entry=0x0, fn=0xffff82092148bfb0, fn@entry=0x1ff48f5f035,
    seq=seq@entry=0x1ff485ad0c3) at ../../src/fns.c:3044
#29 0x00007ff62306475c in Fmapc (function=0x1ff48f5f035, sequence=0x1ff485ad0c3)
    at ../../src/fns.c:3181
--Type <RET> for more, q to quit, c to continue without paging--
#30 0x00007ff6230a0d97 in exec_byte_code (fun=<optimized out>, args_template=<optimized out>,
    nargs=<optimized out>, nargs@entry=2195847683064, args=<optimized out>,
    args@entry=0x10000cf46df93f8) at ../../src/lisp.h:2210
#31 0x00007ff623058dab in fetch_and_exec_byte_code (args=0x10000cf46df93f8, nargs=2195847683064,

    args_template=<optimized out>, fun=<optimized out>) at ../../src/eval.c:3102
#32 0x00007ff623058fa6 in funcall_general (fun=<optimized out>, numargs=numargs@entry=2,
    args=args@entry=0xcf46df93f8) at ../../src/eval.c:2978
#33 0x00007ff623053952 in Ffuncall (nargs=3, args=0xcf46df93f0) at ../../src/eval.c:3016
#34 0x00007ffb24a865e2 in F636f6d706c6574696f6e2d2d6e74682d636f6d706c6574696f6e_completion__nth_
completion_0 ()
   from d:\emacs_home\workplace\emacs\build-debug\native-lisp\30.0.50-0d7a8ace\preloaded\minibuf
fer-1b0f548b-ffe4640c.eln
#35 0x00007ff62305713f in funcall_subr (subr=<optimized out>, numargs=numargs@entry=6,
    args=args@entry=0xcf46df9648) at ../../src/eval.c:3065
#36 0x00007ff623058f20 in funcall_general (fun=<optimized out>, numargs=numargs@entry=6,
    args=args@entry=0xcf46df9648) at ../../src/eval.c:2962
#37 0x00007ff623053952 in Ffuncall (nargs=7, args=0xcf46df9640) at ../../src/eval.c:3016
#38 0x00007ffb24a869b9 in F636f6d706c6574696f6e2d616c6c2d636f6d706c6574696f6e73_completion_all_c
ompletions_0 ()
   from d:\emacs_home\workplace\emacs\build-debug\native-lisp\30.0.50-0d7a8ace\preloaded\minibuf
fer-1b0f548b-ffe4640c.eln
#39 0x00007ff623057166 in funcall_subr (subr=<optimized out>, numargs=numargs@entry=5,
    args=args@entry=0xcf46df97e8) at ../../src/eval.c:3063
#40 0x00007ff623058f20 in funcall_general (fun=<optimized out>, numargs=numargs@entry=5,
    args=args@entry=0xcf46df97e8) at ../../src/eval.c:2962
#41 0x00007ff623053952 in Ffuncall (nargs=nargs@entry=6, args=0xcf46df97e0)
--Type <RET> for more, q to quit, c to continue without paging--
    at ../../src/eval.c:3016
#42 0x00007ff623053ca0 in Fapply (nargs=2, args=0x1ff44087130) at ../../src/eval.c:2687
#43 0x00007ff6230a0d97 in exec_byte_code (fun=<optimized out>, args_template=<optimized out>,
    nargs=<optimized out>, nargs@entry=2195886223352, args=<optimized out>,
    args@entry=0x10000cf46df99d8) at ../../src/lisp.h:2210
#44 0x00007ff623058dab in fetch_and_exec_byte_code (args=0x10000cf46df99d8, nargs=2195886223352,

    args_template=<optimized out>, fun=<optimized out>) at ../../src/eval.c:3102
#45 0x00007ff623058fa6 in funcall_general (fun=<optimized out>, numargs=numargs@entry=5,
    args=args@entry=0xcf46df99d8) at ../../src/eval.c:2978
#46 0x00007ff623053952 in Ffuncall (nargs=nargs@entry=6, args=0xcf46df99d0)
    at ../../src/eval.c:3016
#47 0x00007ff623053ca0 in Fapply (nargs=2, args=0xcf46df9ac0) at ../../src/eval.c:2687
#48 0x00007ff6230579a9 in eval_sub (form=<optimized out>) at ../../src/eval.c:2491
#49 0x00007ff623057caa in eval_sub (form=<optimized out>) at ../../src/eval.c:2507
#50 0x00007ff623057b97 in eval_sub (form=<optimized out>) at ../../src/eval.c:2470
#51 0x00007ff623057ed1 in Fprogn (body=<optimized out>) at ../../src/eval.c:436
#52 0x00007ff623057b97 in eval_sub (form=<optimized out>) at ../../src/eval.c:2470
#53 0x00007ff623059ca6 in Funwind_protect (args=0x1ff44ed0f23) at ../../src/lisp.h:1524
#54 0x00007ff623057b97 in eval_sub (form=<optimized out>) at ../../src/eval.c:2470
#55 0x00007ff623059b01 in Fprogn (body=<optimized out>) at ../../src/eval.c:436
#56 FletX (args=<optimized out>) at ../../src/eval.c:970
#57 0x00007ff623057b97 in eval_sub (form=<optimized out>) at ../../src/eval.c:2470
#58 0x00007ff6230596c9 in Fprogn (body=<optimized out>) at ../../src/eval.c:436
#59 Flet (args=0x7ff6235fab80 <Slet>) at ../../src/eval.c:1038
#60 0x00007ff623057b97 in eval_sub (form=<optimized out>) at ../../src/eval.c:2470
#61 0x00007ff6230596c9 in Fprogn (body=<optimized out>) at ../../src/eval.c:436
--Type <RET> for more, q to quit, c to continue without paging--
#62 Flet (args=0x7ff6235fab80 <Slet>) at ../../src/eval.c:1038
#63 0x00007ff623057b97 in eval_sub (form=<optimized out>) at ../../src/eval.c:2470
#64 0x00007ff623058cf1 in Fprogn (body=<optimized out>) at ../../src/eval.c:436
#65 funcall_lambda (fun=0x1ff44ed0d53, fun@entry=0x7ff621687820, nargs=nargs@entry=5,
    arg_vector=arg_vector@entry=0xcf46dfa570) at ../../src/eval.c:3254
#66 0x00007ff6230592ae in apply_lambda (fun=0x7ff621687820, fun@entry=0x1ff44ed0d43,
    args=<optimized out>, count=..., count@entry=...) at ../../src/eval.c:3124
#67 0x00007ff623057544 in eval_sub (form=<optimized out>) at ../../src/eval.c:2609
#68 0x00007ff62305992c in FletX (args=0x1ff48615be3) at ../../src/eval.c:946
#69 0x00007ff623057b97 in eval_sub (form=<optimized out>) at ../../src/eval.c:2470
#70 0x00007ff623058cf1 in Fprogn (body=<optimized out>) at ../../src/eval.c:436
#71 funcall_lambda (fun=0x1ff48615af3, fun@entry=0x21687b90, nargs=nargs@entry=2,
    arg_vector=arg_vector@entry=0xcf46dfa950) at ../../src/eval.c:3254
#72 0x00007ff6230592ae in apply_lambda (fun=0x21687b90, fun@entry=0x1ff48615ae3,
    args=<optimized out>, count=..., count@entry=...) at ../../src/eval.c:3124
#73 0x00007ff623057544 in eval_sub (form=<optimized out>) at ../../src/eval.c:2609
#74 0x00007ff623057ed1 in Fprogn (body=<optimized out>) at ../../src/eval.c:436
#75 0x00007ff623057b97 in eval_sub (form=<optimized out>) at ../../src/eval.c:2470
#76 0x00007ff623057e41 in For (args=<optimized out>) at ../../src/eval.c:349
#77 0x00007ff623057b97 in eval_sub (form=<optimized out>) at ../../src/eval.c:2470
#78 0x00007ff623057f84 in Fsetq (args=<optimized out>) at ../../src/eval.c:483
#79 0x00007ff623057b97 in eval_sub (form=<optimized out>) at ../../src/eval.c:2470
#80 0x00007ff6230596c9 in Fprogn (body=<optimized out>) at ../../src/eval.c:436
#81 Flet (args=0x7ff6235fab80 <Slet>) at ../../src/eval.c:1038
#82 0x00007ff623057b97 in eval_sub (form=<optimized out>) at ../../src/eval.c:2470
#83 0x00007ff623057ed1 in Fprogn (body=<optimized out>) at ../../src/eval.c:436
--Type <RET> for more, q to quit, c to continue without paging--
#84 0x00007ff623051edb in internal_catch (tag=<optimized out>, func=0x7ff623057ea0 <Fprogn>,
    arg=0x1ff4860c233) at ../../src/eval.c:1209
#85 0x00007ff623057b97 in eval_sub (form=<optimized out>) at ../../src/eval.c:2470
#86 0x00007ff6230596c9 in Fprogn (body=<optimized out>) at ../../src/eval.c:436
#87 Flet (args=0x7ff6235fab80 <Slet>) at ../../src/eval.c:1038
#88 0x00007ff623057b97 in eval_sub (form=form@entry=0x1ff4860c203) at ../../src/eval.c:2470
#89 0x00007ff62305a081 in internal_lisp_condition_case (var=0x0, bodyform=0x1ff4860c203,
    handlers=<optimized out>) at ../../src/eval.c:1440
#90 0x00007ff623057b97 in eval_sub (form=<optimized out>) at ../../src/eval.c:2470
#91 0x00007ff6230596c9 in Fprogn (body=<optimized out>) at ../../src/eval.c:436
#92 Flet (args=0x7ff6235fab80 <Slet>) at ../../src/eval.c:1038
#93 0x00007ff623057b97 in eval_sub (form=<optimized out>) at ../../src/eval.c:2470
#94 0x00007ff623058731 in Fprogn (body=<optimized out>) at ../../src/eval.c:436
#95 Fif (args=<optimized out>) at ../../src/eval.c:392
#96 0x00007ff623057b97 in eval_sub (form=<optimized out>) at ../../src/eval.c:2470
#97 0x00007ff6230596c9 in Fprogn (body=<optimized out>) at ../../src/eval.c:436
#98 Flet (args=0x7ff6235fab80 <Slet>) at ../../src/eval.c:1038
#99 0x00007ff623057b97 in eval_sub (form=<optimized out>) at ../../src/eval.c:2470
#100 0x00007ff62305992c in FletX (args=0x1ff4860b203) at ../../src/eval.c:946
#101 0x00007ff623057b97 in eval_sub (form=<optimized out>) at ../../src/eval.c:2470
#102 0x00007ff623058731 in Fprogn (body=<optimized out>) at ../../src/eval.c:436
#103 Fif (args=<optimized out>) at ../../src/eval.c:392
#104 0x00007ff623057b97 in eval_sub (form=<optimized out>) at ../../src/eval.c:2470
#105 0x00007ff623059b01 in Fprogn (body=<optimized out>) at ../../src/eval.c:436
#106 FletX (args=<optimized out>) at ../../src/eval.c:970
#107 0x00007ff623057b97 in eval_sub (form=<optimized out>) at ../../src/eval.c:2470
--Type <RET> for more, q to quit, c to continue without paging--
#108 0x00007ff623058cf1 in Fprogn (body=<optimized out>) at ../../src/eval.c:436
#109 funcall_lambda (fun=0x1ff4860b0b3, fun@entry=0x1ff21689aa0, nargs=nargs@entry=1,
    arg_vector=arg_vector@entry=0xcf46dfbe30) at ../../src/eval.c:3254
#110 0x00007ff6230592ae in apply_lambda (fun=0x1ff21689aa0, fun@entry=0x1ff4860b0a3,
    args=<optimized out>, count=..., count@entry=...) at ../../src/eval.c:3124
#111 0x00007ff623057544 in eval_sub (form=<optimized out>) at ../../src/eval.c:2609
#112 0x00007ff6230596c9 in Fprogn (body=<optimized out>) at ../../src/eval.c:436
#113 Flet (args=0x7ff6235fab80 <Slet>) at ../../src/eval.c:1038
#114 0x00007ff623057b97 in eval_sub (form=<optimized out>) at ../../src/eval.c:2470
#115 0x00007ff623058cf1 in Fprogn (body=<optimized out>) at ../../src/eval.c:436
#116 funcall_lambda (fun=0x1ff485fa253, nargs=nargs@entry=0,
    arg_vector=arg_vector@entry=0xcf46dfc2b0) at ../../src/eval.c:3254
#117 0x00007ff623058fa6 in funcall_general (fun=<optimized out>, numargs=numargs@entry=0,
    args=args@entry=0xcf46dfc2b0) at ../../src/eval.c:2978
#118 0x00007ff623053952 in Ffuncall (nargs=1, args=0xcf46dfc2a8) at ../../src/eval.c:3016
#119 0x00007ff62305221f in internal_condition_case_n (
    bfun=bfun@entry=0x7ff622fc2a60 <safe_run_hooks_1>, nargs=nargs@entry=2,
    args=args@entry=0xcf46dfc2a0, handlers=handlers@entry=0x30,
    hfun=hfun@entry=0x7ff622fc56f0 <safe_run_hooks_error>) at ../../src/eval.c:1570
#120 0x00007ff622fc3e64 in safe_run_hook_funcall (nargs=2, args=0xcf46dfc390)
    at ../../src/keyboard.c:1923
#121 0x00007ff6230527fb in run_hook_with_args (nargs=2, args=0xcf46dfc390,
    funcall=0x7ff622fc3dc0 <safe_run_hook_funcall>) at ../../src/eval.c:2875
#122 0x00007ff622fc3728 in safe_run_hooks_maybe_narrowed (hook=hook@entry=0xde60,
    w=<optimized out>) at ../../src/keyboard.c:1961
#123 0x00007ff622fd9261 in command_loop_1 () at ../../src/keyboard.c:1322
--Type <RET> for more, q to quit, c to continue without paging--
#124 0x00007ff623051f6d in internal_condition_case (
    bfun=bfun@entry=0x7ff622fd8460 <command_loop_1>, handlers=handlers@entry=0x90,
    hfun=hfun@entry=0x7ff622fcc060 <cmd_error>) at ../../src/eval.c:1486
#125 0x00007ff622fc29ee in command_loop_2 (handlers=0x90) at ../../src/keyboard.c:1157
#126 0x00007ff623051edb in internal_catch (tag=tag@entry=0x6c90,
    func=func@entry=0x7ff622fc29c0 <command_loop_2>, arg=arg@entry=0x90) at ../../src/eval.c:120
9
#127 0x00007ff622fc28cf in command_loop () at ../../src/keyboard.c:1127
#128 0x0000000000000000 in ?? ()

In GNU Emacs 30.0.50 (build 2, x86_64-w64-mingw32) of 2023-12-16 built
 on PWRD-20210716KV
Repository revision: 746507dc3b9f555ff6e8e6282ff03ac211752325
Repository branch: master
Windowing system distributor 'Microsoft Corp.', version 10.0.19042
System Description: Microsoft Windows 10 Enterprise (v10.0.2009.19042.2965)

Configured using:
 'configure --prefix=/d/emacs_home/program/emacs --with-json'

Configured features:
ACL DBUS GIF GMP GNUTLS HARFBUZZ JPEG JSON LCMS2 LIBXML2 MODULES
NATIVE_COMP NOTIFY W32NOTIFY PDUMPER PNG RSVG SOUND SQLITE3 THREADS TIFF
TOOLKIT_SCROLL_BARS TREE_SITTER WEBP XPM ZLIB

Important settings:
  value of $LANG: ENU
  locale-coding-system: cp936

Major mode: Lisp Interaction

Minor modes in effect:
  consult-org-roam-mode: t
  org-roam-db-autosync-mode: t
  yas-minor-mode: t
  hl-line-mode: t
  electric-pair-mode: t
  display-fill-column-indicator-mode: t
  hl-todo-mode: t
  which-key-mode: t
  meow-global-mode: t
  meow-mode: t
  meow-normal-mode: t
  meow-esc-mode: t
  marginalia-mode: t
  vertico-mode: t
  global-corfu-mode: t
  corfu-mode: t
  global-display-line-numbers-mode: t
  display-line-numbers-mode: t
  recentf-mode: t
  global-auto-revert-mode: t
  display-time-mode: t
  global-ligature-mode: t
  ligature-mode: t
  override-global-mode: t
  tooltip-mode: t
  global-eldoc-mode: t
  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
  minibuffer-regexp-mode: t
  column-number-mode: t
  line-number-mode: t
  transient-mark-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  auto-save-visited-mode: t
  hs-minor-mode: t

Load-path shadows:
d:/emacs_home/.emacs.d/elpa/transient-20231205.1848/transient hides d:/emacs_home/program/emacs/share/emacs/30.0.50/lisp/transient
d:/emacs_home/.emacs.d/elpa/standard-themes-2.0.0/theme-loaddefs hides d:/emacs_home/program/emacs/share/emacs/30.0.50/lisp/theme-loaddefs

Features:
(shadow sort mail-extr emacsbug tramp-cmds org-habit ol-eww eww
url-queue mm-url ol-rmail ol-mhe ol-irc ol-info ol-gnus nnselect
gnus-art mm-uu mml2015 mm-view mml-smime smime gnutls dig gnus-sum
gnus-group gnus-undo gnus-start gnus-dbus gnus-cloud nnimap nnmail
mail-source utf7 nnoo gnus-spec gnus-int gnus-range message sendmail
yank-media rfc822 mml mml-sec epa derived epg rfc6068 epg-config
mm-decode mm-bodies mm-encode mailabbrev gmm-utils mailheader gnus-win
gnus nnheader gnus-util mail-utils range ol-docview doc-view jka-compr
image-mode exif dired-x dired dired-loaddefs ol-bibtex bibtex ol-bbdb
ol-w3m ol-doi org-link-doi consult-org-roam consult-org-roam-buffer
emacsql-sqlite-builtin sqlite org-roam-migrate org-roam-log
org-roam-mode org-roam-capture org-roam-id org-roam-node org-roam-db
org-roam-utils org-roam-compat org-roam org-capture org-attach
emacsql-sqlite emacsql-sqlite-common emacsql emacsql-compiler
magit-section cursor-sensor dash textsec uni-scripts mail-parse rfc2231
rfc2047 rfc2045 mm-util ietf-drums mail-prsvr idna-mapping ucs-normalize
uni-confusable textsec-check tramp-archive tramp-gvfs dbus tramp
trampver tramp-integration files-x tramp-message tramp-compat shell
parse-time iso8601 tramp-loaddefs nov imenu shr pixel-fill kinsoku
url-file puny svg xml esxml-query dom mule-util project vc-git diff-mode
vc-dispatcher zoom ace-window avy cal-iso face-remap org-agenda
org-element org-persist xdg org-id avl-tree generator org-refile ob-C
cc-mode cc-fonts cc-guess cc-menus cc-cmds cc-styles cc-align cc-engine
cc-vars cc-defs ob-scheme geiser-impl help-fns radix-tree geiser-custom
geiser-base geiser ob-dot org ob ob-tangle ob-ref ob-lob ob-table ob-exp
org-macro org-src ob-comint org-pcomplete pcomplete org-list
org-footnote org-faces org-entities time-date noutline outline
ob-emacs-lisp ob-core ob-eval org-cycle org-table org-keys oc
org-loaddefs find-func cal-menu calendar cal-loaddefs ol org-fold
org-fold-core org-compat org-version org-macs format-spec yasnippet
hl-line hideshow elec-pair display-fill-column-indicator hl-todo
git-gutter modus-operandi-theme modus-themes which-key meow meow-tutor
meow-cheatsheet meow-cheatsheet-layout meow-core meow-shims delsel
meow-esc meow-command array meow-beacon meow-thing meow-visual
meow-keypad meow-helpers meow-util color meow-keymap meow-face meow-var
consult bookmark pp marginalia orderless vertico graphviz-dot-mode
thingatpt compile text-property-search comint ansi-osc ansi-color ring
cape corfu compat display-line-numbers recentf tree-widget wid-edit
autorevert filenotify edmacro kmacro time ligature persistent-soft
list-utils pcache eieio-base cl font-utils unicode-fonts ibuf-macs
diminish benchmark-init comp comp-cstr warnings icons comp-run
comp-common rx advice cl-extra help-mode use-package use-package-ensure
use-package-delight use-package-diminish use-package-bind-key bind-key
easy-mmode use-package-core ace-window-autoloads alert-toast-autoloads
avy-autoloads benchmark-init-autoloads calibre-autoloads cape-autoloads
citar-embark-autoloads citar-org-roam-autoloads citar-autoloads
citeproc-autoloads clang-format-autoloads company-autoloads
consult-lsp-autoloads consult-org-roam-autoloads corfu-autoloads
diminish-autoloads ef-themes-autoloads embark-consult-autoloads
consult-autoloads embark-autoloads evil-nerd-commenter-autoloads
flycheck-autoloads format-all-autoloads geiser-chez-autoloads
geiser-autoloads git-gutter-autoloads graphviz-dot-mode-autoloads
hl-todo-autoloads htmlize-autoloads inheritenv-autoloads
language-id-autoloads ligature-autoloads logos-autoloads
lsp-ui-autoloads lsp-mode-autoloads ht-autoloads f-autoloads
lua-mode-autoloads lv-autoloads magit-autoloads pcase
git-commit-autoloads marginalia-autoloads markdown-mode-autoloads
meow-autoloads modus-themes-autoloads nov-autoloads esxml-autoloads
kv-autoloads olivetti-autoloads orderless-autoloads org-modern-autoloads
org-roam-ui-autoloads org-roam-autoloads magit-section-autoloads
emacsql-autoloads parsebib-autoloads pkg-info-autoloads epl-autoloads
pomidor-autoloads dash-autoloads alert-autoloads log4e-autoloads
gntp-autoloads powershell-autoloads projectile-autoloads queue-autoloads
request-autoloads ripgrep-autoloads s-autoloads scratch-autoloads
simple-httpd-autoloads spinner-autoloads standard-themes-autoloads
string-inflection-autoloads symbol-overlay-autoloads tempel-autoloads
tmr-autoloads transient-autoloads unicode-fonts-autoloads
ucs-utils-autoloads font-utils-autoloads persistent-soft-autoloads
list-utils-autoloads pcache-autoloads vertico-autoloads
websocket-autoloads wgrep-autoloads which-key-autoloads
with-editor-autoloads info compat-autoloads yasnippet-autoloads
zoom-autoloads package browse-url url url-proxy url-privacy url-expand
url-methods url-history url-cookie generate-lisp-file url-domsuf
url-util mailcap url-handlers url-parse auth-source cl-seq eieio
eieio-core cl-macs password-cache json subr-x map byte-opt gv bytecomp
byte-compile url-vars cl-loaddefs cl-lib rmc iso-transl tooltip cconv
eldoc paren electric uniquify ediff-hook vc-hooks lisp-float-type
elisp-mode mwheel dos-w32 ls-lisp disp-table term/w32-win w32-win
w32-vars term/common-win 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 w32notify dbusbind w32 lcms2 multi-tty move-toolbar
make-network-process native-compile emacs)

Memory information:
((conses 16 715206 78869) (symbols 48 38308 0)
 (strings 32 153274 6004) (string-bytes 1 4799744) (vectors 16 85912)
 (vector-slots 8 1597188 41816) (floats 8 776 492)
 (intervals 56 783 0) (buffers 992 15))

bug#67900: 30.0.50; Emacs Crahes When Executing Command `consult-buffer'

[Eli Zaretskii]

> From: Chang Xiaoduan <drcxd@sina.com>
> Date: Tue, 19 Dec 2023 15:48:18 +0800
> 
> 
> Recently I frequently expericence Emacs crashes when executing the
> command `consult-buffer'. Though it is a command provided by a
> third-party package, I assume Emacs should report an lisp error rather
> than crashing? So I consider report this issue to GNU rather than author
> of some emacs-lisp package. As you can see I am using Emacs on Windows
> and I copmiled it from source using MinGW-w64. However, the same crash
> happens with a pre-built 29.1 Emacs downloaded from a mirror site.

The backtrace says that all-completions was called in a way that
either its first or its second argument are/include an invalid data,
whch doesn't produce a valid string.  How this could happen is
anybody's guess, because the backtrace you show is quite deep and
includes 3rd-party code.

We need a reproducible recipe, starting from "emacs -Q", to reproduce
the problem, so we could debug it here and find the reason(s).  Can
you please provide such a recipe?  It is okay to include in the recipe
commands that load add-on packages, as long as you clearly tell where
to get those packages and how to load them.

Thanks.

bug#67900: 30.0.50; Emacs Crahes When Executing Command `consult-buffer'

[Eli Zaretskii]

[Please use Reply All to reply, to keep the bug tracker CC'ed.]

> From: Chang Xiaoduan <drcxd@sina.com>
> Date: Wed, 20 Dec 2023 14:37:30 +0800
> 
> Hello Eli,
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > We need a reproducible recipe, starting from "emacs -Q", to reproduce
> > the problem, so we could debug it here and find the reason(s).  Can
> > you please provide such a recipe?  It is okay to include in the recipe
> > commands that load add-on packages, as long as you clearly tell where
> > to get those packages and how to load them.
> >
> > Thanks.
> 
> I have tried my best but what I found at best is an unreliable
> reproducible recipe.
> 
> Start Emacs with `emacs -Q` then evaluate the following expressions one
> by one:
> 
> ```
> (require 'package)
> (setq package-archives
>       '(
>         ("gnu" . "https://elpa.gnu.org/packages/")
>         ("melpa" . "https://melpa.org/packages/")
>         ("nongnu" . "https://elpa.nongnu.org/nongnu/")))
> (unless (package-installed-p 'use-package)
>   (package-install 'use-package))
> (require 'use-package)
> (setq use-package-always-ensure t)
> 
> (use-package consult)
> ```
> 
> After you have evaluated `(use-package consult)`, you may experience a
> crash when Emacs is compiling its code. The backtrace for this crash:
> 
> ```
> (gdb) bt
> #0  0x00007ff80ad7b3b3 in KERNELBASE!DebugBreak () from C:\Windows\System32\KernelBase.dll
> #1  0x00007ff6b2f58778 in emacs_abort () at ../../src/w32fns.c:11177
> #2  0x00007ff6b2e22119 in terminate_due_to_signal (sig=11, backtrace_limit=<optimized out>) at ../../src/emacs.c:484
> #3  0x00007ff6b2e44519 in deliver_fatal_thread_signal () at ../../src/sysdep.c:1811
> #4  0x00007ff6b2fbd972 in _gnu_exception_handler (exception_data=0x694ddfbd40) at C:/M/B/src/mingw-w64/mingw-w64-crt/crt/crt_handler.c:213
> #5  0x00007ff80c507ff8 in msvcrt!__C_specific_handler () from C:\Windows\System32\msvcrt.dll
> #6  0x00007ff80d6523df in ntdll!.chkstk () from C:\Windows\SYSTEM32\ntdll.dll
> #7  0x00007ff80d6014a4 in ntdll!RtlRaiseException () from C:\Windows\SYSTEM32\ntdll.dll
> #8  0x00007ff80d650f0e in ntdll!KiUserExceptionDispatcher () from C:\Windows\SYSTEM32\ntdll.dll
> #9  0x00007ff6b2edc652 in XBARE_SYMBOL (a=<optimized out>) at ../../src/lisp.h:1152
> #10 XSYMBOL (a=<optimized out>) at ../../src/lisp.h:1161
> #11 SYMBOL_NAME (sym=<optimized out>) at ../../src/lisp.h:2335
> #12 print_object (obj=<optimized out>, obj@entry=0x193c854e520, printcharfun=0x0, escapeflag=true) at ../../src/print.c:2413
> #13 0x00007ff6b2edec06 in print (obj=obj@entry=0x193c854e520, printcharfun=<optimized out>, escapeflag=escapeflag@entry=true)
>     at ../../src/print.c:1301
> #14 0x00007ff6b2eded28 in Fprin1 (object=0x193c854e520, printcharfun=printcharfun@entry=0x193c3a6b8bd, overrides=overrides@entry=0x0)
>     at ../../src/print.c:776
> #15 0x00007ff6b2edf36b in print_error_message (data=<optimized out>, stream=0x193c3a6b8bd, context=context@entry=0x0, caller=caller@entry=0x0)
>     at ../../src/print.c:1134
> #16 0x00007ff6b2edf5a2 in Ferror_message_string (obj=<optimized out>) at ../../src/print.c:1038
> #17 0x00007fff9fc37d61 in F627974652d636f6d70696c652d7265706f72742d6572726f72_byte_compile_report_error_0 ()
>    from d:\emacs_home\program\emacs\lib\emacs\30.0.50\native-lisp\30.0.50-580ae89a\bytecomp-12882072-25b12c81.eln
> #18 0x00007ff6b2eb3952 in Ffuncall (nargs=2, args=0x694ddfd818) at ../../src/eval.c:3016
> #19 0x00007fff9fc3f56a in F627974652d636f6d70696c652d66726f6d2d627566666572_byte_compile_from_buffer_0 ()
>    from d:\emacs_home\program\emacs\lib\emacs\30.0.50\native-lisp\30.0.50-580ae89a\bytecomp-12882072-25b12c81.eln
> #20 0x00007ff6b2eb3952 in Ffuncall (nargs=2, args=0x694ddfd980) at ../../src/eval.c:3016
> #21 0x00007fff9fc3d784 in F627974652d636f6d70696c652d66696c65_byte_compile_file_0 ()
>    from d:\emacs_home\program\emacs\lib\emacs\30.0.50\native-lisp\30.0.50-580ae89a\bytecomp-12882072-25b12c81.eln
> #22 0x00007ff6b2eb3952 in Ffuncall (nargs=2, args=0x694ddfdaa0) at ../../src/eval.c:3016
> #23 0x00007fff9fc3c60b in F627974652d7265636f6d70696c652d66696c65_byte_recompile_file_0 ()
>    from d:\emacs_home\program\emacs\lib\emacs\30.0.50\native-lisp\30.0.50-580ae89a\bytecomp-12882072-25b12c81.eln
> #24 0x00007ff6b2f00d97 in exec_byte_code (fun=<optimized out>, args_template=<optimized out>, nargs=<optimized out>, nargs@entry=1734276455720,
>     args=<optimized out>, args@entry=0xa0000694ddfdd08) at ../../src/lisp.h:2210
> #25 0x00007ff6b2eb8dab in fetch_and_exec_byte_code (args=0xa0000694ddfdd08, nargs=1734276455720, args_template=<optimized out>, fun=<optimized out>)
>     at ../../src/eval.c:3102
> #26 0x00007ff6b2eb8fa6 in funcall_general (fun=<optimized out>, numargs=numargs@entry=0, args=args@entry=0x694ddfdd08) at ../../src/eval.c:2978
> #27 0x00007ff6b2eb3952 in Ffuncall (nargs=1, args=0x694ddfdd00) at ../../src/eval.c:3016
> #28 0x00007fff9fc3c513 in F627974652d7265636f6d70696c652d6469726563746f7279_byte_recompile_directory_0 ()
>    from d:\emacs_home\program\emacs\lib\emacs\30.0.50\native-lisp\30.0.50-580ae89a\bytecomp-12882072-25b12c81.eln
> #29 0x00007ff6b2f00d97 in exec_byte_code (fun=<optimized out>, args_template=<optimized out>, nargs=<optimized out>, nargs@entry=1734174478760,
>     args=<optimized out>, args@entry=0x610000694ddfdec8) at ../../src/lisp.h:2210
> #30 0x00007ff6b2eb8dab in fetch_and_exec_byte_code (args=0x610000694ddfdec8, nargs=1734174478760, args_template=<optimized out>, fun=<optimized out>)
>     at ../../src/eval.c:3102
> #31 0x00007ff6b2eb8fa6 in funcall_general (fun=<optimized out>, numargs=numargs@entry=1, args=args@entry=0x694ddfdec8) at ../../src/eval.c:2978
> #32 0x00007ff6b2eb3952 in Ffuncall (nargs=nargs@entry=2, args=args@entry=0x694ddfdec0) at ../../src/eval.c:3016
> #33 0x00007ff6b2ec2077 in call1 (arg1=<optimized out>, fn=0xffff819d10e34f20) at ../../src/lisp.h:3248
> #34 mapcar1 (leni=2, vals=vals@entry=0x0, fn=fn@entry=0xffff819d10e34f20, seq=seq@entry=0x193c872b613) at ../../src/fns.c:3044
> #35 0x00007ff6b2ec475c in Fmapc (function=0xffff819d10e34f20, sequence=0x193c872b613) at ../../src/fns.c:3181
> #36 0x00007ff6b2f00d97 in exec_byte_code (fun=<optimized out>, fun@entry=0x11aa1220, args_template=<optimized out>, nargs=<optimized out>,
>     nargs@entry=1734174522728, args=<optimized out>, args@entry=0xfc0000694ddfe040) at ../../src/lisp.h:2210
> #37 0x00007ff6b2eb8dab in fetch_and_exec_byte_code (args=0xfc0000694ddfe040, nargs=1734174522728, args_template=<optimized out>, fun=0x11aa1220)
>     at ../../src/eval.c:3102
> #38 0x00007ff6b2eb92ae in apply_lambda (fun=0x11aa1220, fun@entry=0x193c4d59e65, args=<optimized out>, count=..., count@entry=...)
>     at ../../src/eval.c:3124
> #39 0x00007ff6b2eb7544 in eval_sub (form=<optimized out>) at ../../src/eval.c:2609
> #40 0x00007ff6b2ee08d5 in readevalloop_eager_expand_eval (val=<optimized out>, macroexpand=macroexpand@entry=0xffff819d10183120)
>     at ../../src/lread.c:2411
> #41 0x00007ff6b2ee07dc in readevalloop_eager_expand_eval (val=0x0, val@entry=0x193c4f123e3, macroexpand=macroexpand@entry=0xffff819d10183120)
>     at ../../src/lisp.h:1498
> #42 0x00007ff6b2ee8fde in readevalloop (readcharfun=readcharfun@entry=0x193c4e3e335, infile0=infile0@entry=0x0,
>     sourcename=sourcename@entry=0x193c430c534, printflag=printflag@entry=false, unibyte=unibyte@entry=0x0, readfun=readfun@entry=0x0,
>     start=start@entry=0x0, end=<optimized out>, end@entry=0x0) at ../../src/lread.c:2595
> #43 0x00007ff6b2eea37f in Feval_buffer (buffer=<optimized out>, printflag=0x0, filename=0x193c430c534, unibyte=0x0, do_allow_print=0x30)
>     at ../../src/lread.c:2668
> #44 0x00007fffee1727ed in F6c6f61642d776974682d636f64652d636f6e76657273696f6e_load_with_code_conversion_0 ()
>    from d:\emacs_home\program\emacs\lib\emacs\30.0.50\native-lisp\30.0.50-580ae89a\preloaded\mule-3352613d-5a32cafd.eln
> #45 0x00007ff6b2eb7166 in funcall_subr (subr=<optimized out>, numargs=numargs@entry=4, args=args@entry=0x694ddfe918) at ../../src/eval.c:3063
> #46 0x00007ff6b2eb8f20 in funcall_general (fun=<optimized out>, numargs=numargs@entry=4, args=args@entry=0x694ddfe918) at ../../src/eval.c:2962
> #47 0x00007ff6b2eb3952 in Ffuncall (nargs=nargs@entry=5, args=args@entry=0x694ddfe910) at ../../src/eval.c:3016
> #48 0x00007ff6b2ee971c in call4 (arg4=0x30, arg3=0x30, arg2=0x193c430c534, arg1=<optimized out>, fn=<optimized out>) at ../../src/lisp.h:3270
> #49 Fload (file=0x193c430c6b4, noerror=<optimized out>, nomessage=0xffff819d0ff38f08, nosuffix=<optimized out>, must_suffix=<optimized out>)
>     at ../../src/lread.c:1680
> #50 0x00007ff6b2eb7166 in funcall_subr (subr=<optimized out>, numargs=numargs@entry=3, args=args@entry=0x694ddfed50) at ../../src/eval.c:3063
> #51 0x00007ff6b2eb8f20 in funcall_general (fun=<optimized out>, numargs=numargs@entry=3, args=args@entry=0x694ddfed50) at ../../src/eval.c:2962
> #52 0x00007ff6b2eb3952 in Ffuncall (nargs=4, args=0x694ddfed48) at ../../src/eval.c:3016
> #53 0x00007fffee1b528c in F737461727475702d2d6c6f61642d757365722d696e69742d66696c65_startup__load_user_init_file_0 ()
>    from d:\emacs_home\program\emacs\lib\emacs\30.0.50\native-lisp\30.0.50-580ae89a\preloaded\startup-bbc6ea72-acd89ebf.eln
> #54 0x00007ff6b2eb3952 in Ffuncall (nargs=4, args=0x694ddfee80) at ../../src/eval.c:3016
> #55 0x00007fffee1b72f9 in F636f6d6d616e642d6c696e65_command_line_0 ()
>    from d:\emacs_home\program\emacs\lib\emacs\30.0.50\native-lisp\30.0.50-580ae89a\preloaded\startup-bbc6ea72-acd89ebf.eln
> #56 0x00007ff6b2eb3952 in Ffuncall (nargs=1, args=0x694ddfefa8) at ../../src/eval.c:3016
> #57 0x00007fffee1b34e0 in F6e6f726d616c2d746f702d6c6576656c_normal_top_level_0 ()
>    from d:\emacs_home\program\emacs\lib\emacs\30.0.50\native-lisp\30.0.50-580ae89a\preloaded\startup-bbc6ea72-acd89ebf.eln
> #58 0x00007ff6b2eb7b89 in eval_sub (form=form@entry=0x193c38d4903) at ../../src/eval.c:2516
> #59 0x00007ff6b2eba2c2 in Feval (form=0x193c38d4903, lexical=<optimized out>) at ../../src/eval.c:2383
> #60 0x00007ff6b2eb1f6d in internal_condition_case (bfun=bfun@entry=0x7ff6b2e22a30 <top_level_2>, handlers=handlers@entry=0x90,
>     hfun=hfun@entry=0x7ff6b2e2c060 <cmd_error>) at ../../src/eval.c:1486
> #61 0x00007ff6b2e2353d in top_level_1 (ignore=<optimized out>) at ../../src/keyboard.c:1174
> #62 0x00007ff6b2eb1edb in internal_catch (tag=tag@entry=0x10fb0, func=func@entry=0x7ff6b2e23510 <top_level_1>, arg=arg@entry=0x0)
>     at ../../src/eval.c:1209
> #63 0x00007ff6b2e22965 in command_loop () at ../../src/keyboard.c:1134
> #64 0x0000000000000000 in ?? ()
> ```
> 
> This crash does not occur every time the consult package is installed,
> you may have to try multiple times to reproduce it. Remember to delete
> all isntalled packages and eln-caches before you try again.
> 
> After the consult package is installed, `M-x consult-buffer` may trigger
> the crash I mentioned in the last E-mail. However, this one is also not
> reproducible every time the command is executed. You may restart Emacs
> and try again. If you have restarted several times and the crash still
> not present itself, then you may have to reinstall the pacakge.
> 
> Another thing worth noting is that, when I expericen such a crash, if I
> delete the eln-cache for the consult package. Then the next time I start
> Emacs and execute `conult-buffer`, Emacs never crashes. However, it
> generates the eln-cache for that package. If I restart Emacs after that,
> it is likely to crash when I execute `consult-buffer`. I think the crash
> is related with the eln-cache, which also explains why there is no elisp
> error but a crash. I hope this information could be helpful, but you may
> have alredy figured it out.
> 
> If you still can't reprocude the crash, please tell me if there is
> anything else I can do to help.

The above seems to indicate the problems are somehow related to native
compilation.  Can you build Emacs without native-compilation, and try
reproducing this in such an Emacs?  If the problem doesn't happen in
Emacs without native-compilation, I suspect this is a MinGW GCC bug,
not an Emacs bug: the native code in *.eln files is somehow invalid.

Which version of GCC do you have installed, and is libgccjit you have
is from the same GCC version?

Or maybe we have a bug in native compilation.  Andrea, can you try
reproducing this on GNU/Linux?

Another idea is to modify comp.el to have native-comp-speed default to
1 instead of 2, then rebuild Emacs ("make bootstrap") with CFLAGS='-O1',
and see if the problem goes away.  If it does, that again points
toward GCC/libgccjit and the compiler optimizations.

bug#67900: 30.0.50; Emacs Crahes When Executing Command `consult-buffer'

[Chang Xiaoduan]

Eli Zaretskii <eliz@gnu.org> writes:

> [Please use Reply All to reply, to keep the bug tracker CC'ed.]
>

This is the first time I report an Emacs bug using E-mails and I am not
familiar with this kind of workflow for reporting a bug and
communication. I have raised some issues on GitHub but that is totally
different and more intuitive. Would you mind introducing me how such a
workflow came into being and why you stick with it? Any links to wiki or
articles are welcomed.

>
> The above seems to indicate the problems are somehow related to native
> compilation.  Can you build Emacs without native-compilation, and try
> reproducing this in such an Emacs?  If the problem doesn't happen in
> Emacs without native-compilation, I suspect this is a MinGW GCC bug,
> not an Emacs bug: the native code in *.eln files is somehow invalid.

I can not reproduce the crash using Emacs without native-compilation.

>
> Which version of GCC do you have installed, and is libgccjit you have
> is from the same GCC version?

I am using gcc 13.2.0 and mingw-w64-x86_64-libgccjit 13.2.0-3.

>
> Or maybe we have a bug in native compilation.  Andrea, can you try
> reproducing this on GNU/Linux?
>
> Another idea is to modify comp.el to have native-comp-speed default to
> 1 instead of 2, then rebuild Emacs ("make bootstrap") with CFLAGS='-O1',
> and see if the problem goes away.  If it does, that again points
> toward GCC/libgccjit and the compiler optimizations.

I have modified the `native-comp-speed` to 1, but not specified
`CFLAGS='-O1'`. Though, the resulting Emacs binary does not reproduce
the same crash.

After all, it looks like Eli's assumption is likely to be true. If you
are familiar with reporting a compiler bug, could you tell me how could
I verify it is indeed a MinGW GCC bug and report this to MinGW?

bug#67900: 30.0.50; Emacs Crahes When Executing Command `consult-buffer'

[Eli Zaretskii]

> From: Chang Xiaoduan <drcxd@sina.com>
> Cc: Andrea Corallo <acorallo@gnu.org>,  67900@debbugs.gnu.org
> Date: Thu, 21 Dec 2023 11:26:05 +0800
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > [Please use Reply All to reply, to keep the bug tracker CC'ed.]
> >
> 
> This is the first time I report an Emacs bug using E-mails and I am not
> familiar with this kind of workflow for reporting a bug and
> communication. I have raised some issues on GitHub but that is totally
> different and more intuitive. Would you mind introducing me how such a
> workflow came into being and why you stick with it? Any links to wiki or
> articles are welcomed.

It's a long story.  In a nutshell, we use email because doing that,
together with some features of the debbugs issue tracker, makes it
very easy to do everything from Emacs: review patches and send
feedback for patches, apply patches that are approved, manage issues
(open, close, and reopen them, add and remove tags to issues, etc.),
and do other jobs.

We are looking into switching to a different issue tracker, which
would allow also PR-based workflows and a browser UI to do some of
these jobs, but so far every tracker we've examined needed additions
and improvements to satisfy our needs, and so we haven't switched yet.

> > The above seems to indicate the problems are somehow related to native
> > compilation.  Can you build Emacs without native-compilation, and try
> > reproducing this in such an Emacs?  If the problem doesn't happen in
> > Emacs without native-compilation, I suspect this is a MinGW GCC bug,
> > not an Emacs bug: the native code in *.eln files is somehow invalid.
> 
> I can not reproduce the crash using Emacs without native-compilation.
> 
> >
> > Which version of GCC do you have installed, and is libgccjit you have
> > is from the same GCC version?
> 
> I am using gcc 13.2.0 and mingw-w64-x86_64-libgccjit 13.2.0-3.
> 
> >
> > Or maybe we have a bug in native compilation.  Andrea, can you try
> > reproducing this on GNU/Linux?
> >
> > Another idea is to modify comp.el to have native-comp-speed default to
> > 1 instead of 2, then rebuild Emacs ("make bootstrap") with CFLAGS='-O1',
> > and see if the problem goes away.  If it does, that again points
> > toward GCC/libgccjit and the compiler optimizations.
> 
> I have modified the `native-comp-speed` to 1, but not specified
> `CFLAGS='-O1'`. Though, the resulting Emacs binary does not reproduce
> the same crash.
> 
> After all, it looks like Eli's assumption is likely to be true. If you
> are familiar with reporting a compiler bug, could you tell me how could
> I verify it is indeed a MinGW GCC bug and report this to MinGW?

Andrea, can you please help Chang Xiaoduan to create a reproducer in
this case, and examine it by comparing with what you see when you
native-compile consult-buffer on your system?  Maybe we could somehow
work around this in Emacs, since IME the libgccjit folks are not very
responsive to MinGW-specific bugs.

Another idea would be to build Emacs with native-compilation as usual,
with native-comp-speed set to 2, but then compile only consult.el with
native-comp-speed set to 1.  If that also solves the problem, we will
know that something in consult.el triggers the problem, and could
perhaps try narrowing down the problem to some very specific code in
consult.el.

Thanks.

bug#67900: 30.0.50; Emacs Crahes When Executing Command `consult-buffer'

[Andrea Corallo]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Chang Xiaoduan <drcxd@sina.com>
>> Cc: Andrea Corallo <acorallo@gnu.org>,  67900@debbugs.gnu.org
>> Date: Thu, 21 Dec 2023 11:26:05 +0800
>> 
>> Eli Zaretskii <eliz@gnu.org> writes:
>> 
>> > [Please use Reply All to reply, to keep the bug tracker CC'ed.]
>> >
>> 
>> This is the first time I report an Emacs bug using E-mails and I am not
>> familiar with this kind of workflow for reporting a bug and
>> communication. I have raised some issues on GitHub but that is totally
>> different and more intuitive. Would you mind introducing me how such a
>> workflow came into being and why you stick with it? Any links to wiki or
>> articles are welcomed.
>
> It's a long story.  In a nutshell, we use email because doing that,
> together with some features of the debbugs issue tracker, makes it
> very easy to do everything from Emacs: review patches and send
> feedback for patches, apply patches that are approved, manage issues
> (open, close, and reopen them, add and remove tags to issues, etc.),
> and do other jobs.
>
> We are looking into switching to a different issue tracker, which
> would allow also PR-based workflows and a browser UI to do some of
> these jobs, but so far every tracker we've examined needed additions
> and improvements to satisfy our needs, and so we haven't switched yet.
>
>> > The above seems to indicate the problems are somehow related to native
>> > compilation.  Can you build Emacs without native-compilation, and try
>> > reproducing this in such an Emacs?  If the problem doesn't happen in
>> > Emacs without native-compilation, I suspect this is a MinGW GCC bug,
>> > not an Emacs bug: the native code in *.eln files is somehow invalid.
>> 
>> I can not reproduce the crash using Emacs without native-compilation.
>> 
>> >
>> > Which version of GCC do you have installed, and is libgccjit you have
>> > is from the same GCC version?
>> 
>> I am using gcc 13.2.0 and mingw-w64-x86_64-libgccjit 13.2.0-3.
>> 
>> >
>> > Or maybe we have a bug in native compilation.  Andrea, can you try
>> > reproducing this on GNU/Linux?
>> >
>> > Another idea is to modify comp.el to have native-comp-speed default to
>> > 1 instead of 2, then rebuild Emacs ("make bootstrap") with CFLAGS='-O1',
>> > and see if the problem goes away.  If it does, that again points
>> > toward GCC/libgccjit and the compiler optimizations.
>> 
>> I have modified the `native-comp-speed` to 1, but not specified
>> `CFLAGS='-O1'`. Though, the resulting Emacs binary does not reproduce
>> the same crash.
>> 
>> After all, it looks like Eli's assumption is likely to be true. If you
>> are familiar with reporting a compiler bug, could you tell me how could
>> I verify it is indeed a MinGW GCC bug and report this to MinGW?
>
> Andrea, can you please help Chang Xiaoduan to create a reproducer in
> this case, and examine it by comparing with what you see when you
> native-compile consult-buffer on your system?  Maybe we could somehow
> work around this in Emacs, since IME the libgccjit folks are not very
> responsive to MinGW-specific bugs.

I tried to reproduce on my system (GNU Emacs 30.0.50 (build 1,
x86_64-pc-linux-gnu) of 2023-12-21) with no success.

I think a starting point would be to identify which one is the
compilation unit that gets misscompiled, the second will be to indentify
the function.

I'd proceed bisecting the compilations unit in Emacs core and in the
packages involved adding the "no-native-compile: t" cookie to the file.

But before starting with a blind bisect I think we should try if any of
the .eln present in the back trace is the responsible, AFAICS those are:
bytecomp.el, mule.el, startup.el (with the first being the suspect nr1).

Thanks

  Andrea

bug#67900: 30.0.50; Emacs Crahes When Executing Command `consult-buffer'

[Chang Xiaoduan]

Andrea Corallo <acorallo@gnu.org> writes:

> Eli Zaretskii <eliz@gnu.org> writes:
>
>>> From: Chang Xiaoduan <drcxd@sina.com>
>>> Cc: Andrea Corallo <acorallo@gnu.org>,  67900@debbugs.gnu.org
>>> Date: Thu, 21 Dec 2023 11:26:05 +0800
>>> 
>>> Eli Zaretskii <eliz@gnu.org> writes:
>>> 
>>> > [Please use Reply All to reply, to keep the bug tracker CC'ed.]
>>> >
>>> 
>>> This is the first time I report an Emacs bug using E-mails and I am not
>>> familiar with this kind of workflow for reporting a bug and
>>> communication. I have raised some issues on GitHub but that is totally
>>> different and more intuitive. Would you mind introducing me how such a
>>> workflow came into being and why you stick with it? Any links to wiki or
>>> articles are welcomed.
>>
>> It's a long story.  In a nutshell, we use email because doing that,
>> together with some features of the debbugs issue tracker, makes it
>> very easy to do everything from Emacs: review patches and send
>> feedback for patches, apply patches that are approved, manage issues
>> (open, close, and reopen them, add and remove tags to issues, etc.),
>> and do other jobs.
>>
>> We are looking into switching to a different issue tracker, which
>> would allow also PR-based workflows and a browser UI to do some of
>> these jobs, but so far every tracker we've examined needed additions
>> and improvements to satisfy our needs, and so we haven't switched yet.
>>
>>> > The above seems to indicate the problems are somehow related to native
>>> > compilation.  Can you build Emacs without native-compilation, and try
>>> > reproducing this in such an Emacs?  If the problem doesn't happen in
>>> > Emacs without native-compilation, I suspect this is a MinGW GCC bug,
>>> > not an Emacs bug: the native code in *.eln files is somehow invalid.
>>> 
>>> I can not reproduce the crash using Emacs without native-compilation.
>>> 
>>> >
>>> > Which version of GCC do you have installed, and is libgccjit you have
>>> > is from the same GCC version?
>>> 
>>> I am using gcc 13.2.0 and mingw-w64-x86_64-libgccjit 13.2.0-3.
>>> 
>>> >
>>> > Or maybe we have a bug in native compilation.  Andrea, can you try
>>> > reproducing this on GNU/Linux?
>>> >
>>> > Another idea is to modify comp.el to have native-comp-speed default to
>>> > 1 instead of 2, then rebuild Emacs ("make bootstrap") with CFLAGS='-O1',
>>> > and see if the problem goes away.  If it does, that again points
>>> > toward GCC/libgccjit and the compiler optimizations.
>>> 
>>> I have modified the `native-comp-speed` to 1, but not specified
>>> `CFLAGS='-O1'`. Though, the resulting Emacs binary does not reproduce
>>> the same crash.
>>> 
>>> After all, it looks like Eli's assumption is likely to be true. If you
>>> are familiar with reporting a compiler bug, could you tell me how could
>>> I verify it is indeed a MinGW GCC bug and report this to MinGW?
>>
>> Andrea, can you please help Chang Xiaoduan to create a reproducer in
>> this case, and examine it by comparing with what you see when you
>> native-compile consult-buffer on your system?  Maybe we could somehow
>> work around this in Emacs, since IME the libgccjit folks are not very
>> responsive to MinGW-specific bugs.
>
> I tried to reproduce on my system (GNU Emacs 30.0.50 (build 1,
> x86_64-pc-linux-gnu) of 2023-12-21) with no success.
>
> I think a starting point would be to identify which one is the
> compilation unit that gets misscompiled, the second will be to indentify
> the function.
>
> I'd proceed bisecting the compilations unit in Emacs core and in the
> packages involved adding the "no-native-compile: t" cookie to the file.
>
> But before starting with a blind bisect I think we should try if any of
> the .eln present in the back trace is the responsible, AFAICS those are:
> bytecomp.el, mule.el, startup.el (with the first being the suspect nr1).
>
> Thanks
>
>   Andrea

I also use Emacs with the same configuration on a Linux system and it
has never crashed while I have been experiencing frequent crashes on
Windows. I think it is not reproducible on Linux.

I have tried to build Emacs with native-compilation on and added a
file-local prop-line in consult.el setting `native-comp-speed` to 1. The
eln cache produced does not trigger the crash. After setting the
file-local property `native-comp-spped` back to 2, I easily reproduced
the crash. Does this indicate that the miscompiled code is inside
consult.el?

I try to find out the minimal code that can reproduce the issue by
starting an Emacs instance with the -Q option. Then I copy the
definition of `consult-buffer` into this instance and evaluate it. If
there is an error, such as missing definition, I try to fix the error by
copying more code and evaluating them. Finally I reached a point that
`consult-buffer` can be executed with no error reported. However, when I
save all copied code to an el file and load it with a clean Emacs (with
-Q option) then I evaluate the buffer and execute `consult-buffer` there
is an error! I have tried this process twice: copying any required code
and execute them piece by piece until `consult-buffer` can be executed
correctly, saving the whole code as an el file then trying to evaluate
it with another clean Emacs instance, it always fails to execute
`consult-buffer` after I evaluate the whole buffer all at once. I have
no idead why this happens since I know not much about emacs lisp.  If
you want I can send you the file. Do you post the content of the file in
E-mail directly or send it as an attachment? Also, when the history of
this communication becomes longer, do I have to keep the content of the
original mails when I reply?

Let me know if there is anything else I can do to help.

Thank you

bug#67900: 30.0.50; Emacs Crahes When Executing Command `consult-buffer'

[Eli Zaretskii]

> From: Chang Xiaoduan <drcxd@sina.com>
> Cc: Eli Zaretskii <eliz@gnu.org>,  67900@debbugs.gnu.org
> Date: Fri, 22 Dec 2023 11:44:57 +0800
> 
> Andrea Corallo <acorallo@gnu.org> writes:
> 
> > But before starting with a blind bisect I think we should try if any of
> > the .eln present in the back trace is the responsible, AFAICS those are:
> > bytecomp.el, mule.el, startup.el (with the first being the suspect nr1).
> 
> I also use Emacs with the same configuration on a Linux system and it
> has never crashed while I have been experiencing frequent crashes on
> Windows. I think it is not reproducible on Linux.
> 
> I have tried to build Emacs with native-compilation on and added a
> file-local prop-line in consult.el setting `native-comp-speed` to 1. The
> eln cache produced does not trigger the crash. After setting the
> file-local property `native-comp-spped` back to 2, I easily reproduced
> the crash. Does this indicate that the miscompiled code is inside
> consult.el?

It could, but see what Andrea wrote above: it could also be the fault
of a few other packages involved in this.

So please build Emacs with those 3 packages (bytecomp.el, mule.el,
startup.el) natively-compiled with native-comp-speed = 1, then
native-compile consult.el with native-comp-speed = 2, and see if you
still see the crashes.  If yes, then consult.el is probably the one
that triggers the bug.  If compiling those 3 other packages with
native-comp-speed = 1 eliminates the crashes, then we need to look for
the one of those 3 which triggers the crash, and continue narrowing
this down from there.

> I try to find out the minimal code that can reproduce the issue by
> starting an Emacs instance with the -Q option. Then I copy the
> definition of `consult-buffer` into this instance and evaluate it. If
> there is an error, such as missing definition, I try to fix the error by
> copying more code and evaluating them. Finally I reached a point that
> `consult-buffer` can be executed with no error reported. However, when I
> save all copied code to an el file and load it with a clean Emacs (with
> -Q option) then I evaluate the buffer and execute `consult-buffer` there
> is an error! I have tried this process twice: copying any required code
> and execute them piece by piece until `consult-buffer` can be executed
> correctly, saving the whole code as an el file then trying to evaluate
> it with another clean Emacs instance, it always fails to execute
> `consult-buffer` after I evaluate the whole buffer all at once. I have
> no idead why this happens since I know not much about emacs lisp.

What is the error you see after you evaluate the whole code?  It might
be that the order of the code in the el file matters, and you need to
reorder the functions and variables there.

But I think finding the minimal Lisp code which, when native-compiled
with native-comp-speed = 2, triggers the crashes is more important.

Thanks.

bug#67900: 30.0.50; Emacs Crahes When Executing Command `consult-buffer'

[Andrea Corallo]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Chang Xiaoduan <drcxd@sina.com>
>> Cc: Eli Zaretskii <eliz@gnu.org>,  67900@debbugs.gnu.org
>> Date: Fri, 22 Dec 2023 11:44:57 +0800
>> 
>> Andrea Corallo <acorallo@gnu.org> writes:
>> 
>> > But before starting with a blind bisect I think we should try if any of
>> > the .eln present in the back trace is the responsible, AFAICS those are:
>> > bytecomp.el, mule.el, startup.el (with the first being the suspect nr1).
>> 
>> I also use Emacs with the same configuration on a Linux system and it
>> has never crashed while I have been experiencing frequent crashes on
>> Windows. I think it is not reproducible on Linux.
>> 
>> I have tried to build Emacs with native-compilation on and added a
>> file-local prop-line in consult.el setting `native-comp-speed` to 1. The
>> eln cache produced does not trigger the crash. After setting the
>> file-local property `native-comp-spped` back to 2, I easily reproduced
>> the crash. Does this indicate that the miscompiled code is inside
>> consult.el?
>
> It could, but see what Andrea wrote above: it could also be the fault
> of a few other packages involved in this.
>
> So please build Emacs with those 3 packages (bytecomp.el, mule.el,
> startup.el) natively-compiled with native-comp-speed = 1, then
> native-compile consult.el with native-comp-speed = 2, and see if you
> still see the crashes.  If yes, then consult.el is probably the one
> that triggers the bug.  If compiling those 3 other packages with
> native-comp-speed = 1 eliminates the crashes, then we need to look for
> the one of those 3 which triggers the crash, and continue narrowing
> this down from there.

I agree, that's a good advice, let's investigate this bit first.

Thanks

  Andrea

bug#67900: 30.0.50; Emacs Crahes When Executing Command `consult-buffer'

[Chang Xiaoduan]

Eli Zaretskii <eliz@gnu.org> writes:

> So please build Emacs with those 3 packages (bytecomp.el, mule.el,
> startup.el) natively-compiled with native-comp-speed = 1, then
> native-compile consult.el with native-comp-speed = 2, and see if you
> still see the crashes.  If yes, then consult.el is probably the one
> that triggers the bug.  If compiling those 3 other packages with
> native-comp-speed = 1 eliminates the crashes, then we need to look for
> the one of those 3 which triggers the crash, and continue narrowing
> this down from there.

I have added a file-local prop-line to each of bytecomp.el, mule.el and
startup.el, which sets the `native-comp-speed` to 1. Then I rebuilt
Emacs and test with a cosnult.el with `native-comp-speed` as 2. Is this
the correct setup to test? The result: Emacs still crashes when
executing `consult-buffer`.

Further more, I have another test with `native-comp-speed` in comp.el
set to 1. That is, the default optimizaiton level for all
native-compiled lisp code is 1. Then, I add a file-local prop-line in
consult.el and set the `native-comp-speed` to 2. The result: Emacs still
crashes when executing `consult-buffer`.

I guess this is enough to confirm that the miscompiled code is in
consult.el. What should I do next?

Thanks

bug#67900: 30.0.50; Emacs Crahes When Executing Command `consult-buffer'

[Eli Zaretskii]

> From: Chang Xiaoduan <drcxd@sina.com>
> Cc: acorallo@gnu.org,  67900@debbugs.gnu.org
> Date: Sat, 23 Dec 2023 10:30:14 +0800
> 
> I have added a file-local prop-line to each of bytecomp.el, mule.el and
> startup.el, which sets the `native-comp-speed` to 1. Then I rebuilt
> Emacs and test with a cosnult.el with `native-comp-speed` as 2. Is this
> the correct setup to test? The result: Emacs still crashes when
> executing `consult-buffer`.
> 
> Further more, I have another test with `native-comp-speed` in comp.el
> set to 1. That is, the default optimizaiton level for all
> native-compiled lisp code is 1. Then, I add a file-local prop-line in
> consult.el and set the `native-comp-speed` to 2. The result: Emacs still
> crashes when executing `consult-buffer`.
> 
> I guess this is enough to confirm that the miscompiled code is in
> consult.el.

I think so, yes.  Andrea, do you agree?

> What should I do next?

If Andrea agrees, I hope he will be able to propose a way of narrowing
this down, tailored specifically to the code in consult.el.

bug#67900: 30.0.50; Emacs Crahes When Executing Command `consult-buffer'

[Andrea Corallo]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Chang Xiaoduan <drcxd@sina.com>
>> Cc: acorallo@gnu.org,  67900@debbugs.gnu.org
>> Date: Sat, 23 Dec 2023 10:30:14 +0800
>>
>> I have added a file-local prop-line to each of bytecomp.el, mule.el and
>> startup.el, which sets the `native-comp-speed` to 1. Then I rebuilt
>> Emacs and test with a cosnult.el with `native-comp-speed` as 2. Is this
>> the correct setup to test? The result: Emacs still crashes when
>> executing `consult-buffer`.

Yes if consult.el was recompiled in this setup.

>> Further more, I have another test with `native-comp-speed` in comp.el
>> set to 1. That is, the default optimizaiton level for all
>> native-compiled lisp code is 1. Then, I add a file-local prop-line in
>> consult.el and set the `native-comp-speed` to 2. The result: Emacs still
>> crashes when executing `consult-buffer`.
>>
>> I guess this is enough to confirm that the miscompiled code is in
>> consult.el.
>
> I think so, yes.  Andrea, do you agree?

Yes I think so.

>> What should I do next?
>
> If Andrea agrees, I hope he will be able to propose a way of narrowing
> this down, tailored specifically to the code in consult.el.

I think the next step is to narrow down the miss-compiled function.  For
that we can tweak speed on function basis like:

(defun foo (x y)
  (declare (speed 1))
  (+ x y))

As usual I'd start probing the suspect function `consult-buffer` and if
we find is not the coolprint I'd probably bisect all the functions in
the compilation unit.

Thanks

  Andrea

bug#67900: 30.0.50; Emacs Crahes When Executing Command `consult-buffer'

[Chang Xiaoduan]

Andrea Corallo <acorallo@gnu.org> writes:

> Eli Zaretskii <eliz@gnu.org> writes:
> I think the next step is to narrow down the miss-compiled function.  For
> that we can tweak speed on function basis like:
>
> (defun foo (x y)
>   (declare (speed 1))
>   (+ x y))
>
> As usual I'd start probing the suspect function `consult-buffer` and if
> we find is not the coolprint I'd probably bisect all the functions in
> the compilation unit.
>
> Thanks
>
>   Andrea

I have done this differently: I use an Emacs compiled with
`native-comp-speed` set to 1. Then I add the `declare` form to all the
`defun`, `cl-defun`, `defmacro` and `defsubst`, for example:

```
(defun consult--customize-put (cmds prop form)
  "Set property PROP to FORM of commands CMDS."
  (declare (speed 2))
  (dolist (cmd cmds)
    (cond
     ((and (boundp cmd) (consp (symbol-value cmd)))
      (setf (plist-get (symbol-value cmd) prop) (eval form 'lexical)))
     ((functionp cmd)
      (setf (plist-get (alist-get cmd consult--customize-alist) prop) form))
     (t (user-error "%s is neither a Command command nor a source" cmd))))
  nil)
```

With this setup I can not reproduce the crash. Is the method wrong? How?
Can you explain this to me?

Thank you

bug#67900: 30.0.50; Emacs Crahes When Executing Command `consult-buffer'

[Andrea Corallo]

Chang Xiaoduan <drcxd@sina.com> writes:

> Andrea Corallo <acorallo@gnu.org> writes:
>
>> Eli Zaretskii <eliz@gnu.org> writes:
>> I think the next step is to narrow down the miss-compiled function.  For
>> that we can tweak speed on function basis like:
>>
>> (defun foo (x y)
>>   (declare (speed 1))
>>   (+ x y))
>>
>> As usual I'd start probing the suspect function `consult-buffer` and if
>> we find is not the coolprint I'd probably bisect all the functions in
>> the compilation unit.
>>
>> Thanks
>>
>>   Andrea
>
> I have done this differently: I use an Emacs compiled with
> `native-comp-speed` set to 1. Then I add the `declare` form to all the
> `defun`, `cl-defun`, `defmacro` and `defsubst`, for example:
>
> ```
> (defun consult--customize-put (cmds prop form)
>   "Set property PROP to FORM of commands CMDS."
>   (declare (speed 2))
>   (dolist (cmd cmds)
>     (cond
>      ((and (boundp cmd) (consp (symbol-value cmd)))
>       (setf (plist-get (symbol-value cmd) prop) (eval form 'lexical)))
>      ((functionp cmd)
>       (setf (plist-get (alist-get cmd consult--customize-alist) prop) form))
>      (t (user-error "%s is neither a Command command nor a source" cmd))))
>   nil)
> ```
>
> With this setup I can not reproduce the crash. Is the method wrong? How?
> Can you explain this to me?
>
> Thank you

There could be some function generated by macros without the speed
declaration?  Dunno...

Anyway please try the opposite strategy (CU at speed 2 and functions at
speed 1) to narrow the function and let us know if it's more successful.

Thanks

  Andrea

bug#67900: 30.0.50; Emacs Crahes When Executing Command `consult-buffer'

[Chang Xiaoduan]

Andrea Corallo <acorallo@gnu.org> writes:

>
> There could be some function generated by macros without the speed
> declaration?  Dunno...
>
> Anyway please try the opposite strategy (CU at speed 2 and functions at
> speed 1) to narrow the function and let us know if it's more successful.
>
> Thanks
>
>   Andrea

Hello,

I just confirmed that when Emacs is built with `native-comp-speed' set
to 2 and only `consult-buffer' has the form `(declare (speed 1))`, I can
still reproduce the crash. However, when all `defun', `defmacro',
`cl-defun' and `defsubst' get the form `(declare (speed 1))`, then the
crash can not be reproduced. Before I investigate further, I am
wondering that is that only one function responsible to the crash? Is it
possible that when 2 or more certain functions get compiled with
`native-comp-speed' set to 2 that the crash can be reproduced? If this
is ture, then I think mannually add declare forms to functions is some
how impossible to find the combination of such functions.

Thanks

bug#67900: 30.0.50; Emacs Crahes When Executing Command `consult-buffer'

[Chang Xiaoduan]

Hello,

There is another thing that I would like you to know. When I am trying
to locate which function may contain the miscompiled code, I edit some
code then execute `emacs-lisp-native-compile-and-load'. This also causes
a crash sometimes, though not every time. Maybe we should investigate
this crash first?

Thanks

bug#67900: 30.0.50; Emacs Crahes When Executing Command `consult-buffer'

[Andrea Corallo]

Chang Xiaoduan <drcxd@sina.com> writes:

> Andrea Corallo <acorallo@gnu.org> writes:
>
>>
>> There could be some function generated by macros without the speed
>> declaration?  Dunno...
>>
>> Anyway please try the opposite strategy (CU at speed 2 and functions at
>> speed 1) to narrow the function and let us know if it's more successful.
>>
>> Thanks
>>
>>   Andrea
>
> Hello,
>
> I just confirmed that when Emacs is built with `native-comp-speed' set
> to 2 and only `consult-buffer' has the form `(declare (speed 1))`, I can
> still reproduce the crash.

Okay then `consult-buffer' is not the misscompiled culprit.

> However, when all `defun', `defmacro',
> `cl-defun' and `defsubst' get the form `(declare (speed 1))`, then the
> crash can not be reproduced.

That's in line with the fact that you observed that compiling the whole
file at speed 1 does not trigger the bug.

> Before I investigate further, I am
> wondering that is that only one function responsible to the crash?

From what you observed `consult-buffer' is not the problematic one.

> Is it
> possible that when 2 or more certain functions get compiled with
> `native-comp-speed' set to 2 that the crash can be reproduced?

It should not be the case, the only interactions we might observe is
between defmacro/defsubst and functions.

> If this
> is ture, then I think mannually add declare forms to functions is some
> how impossible to find the combination of such functions.

See previous point, but anyway I think adding declarations only defun is
a good start.

Thanks

  Andrea

bug#67900: 30.0.50; Emacs Crahes When Executing Command `consult-buffer'

[Andrea Corallo]

Chang Xiaoduan <drcxd@sina.com> writes:

> Hello,
>
> There is another thing that I would like you to know. When I am trying
> to locate which function may contain the miscompiled code, I edit some
> code then execute `emacs-lisp-native-compile-and-load'. This also causes
> a crash sometimes, though not every time. Maybe we should investigate
> this crash first?

Interesting I've never experienced this on GNU/Linux, yes I think we
should investigate this but I would treat it as a different bug (even
tho they might be potentially the same one).

Thanks

  Andrea

bug#67900: 30.0.50; Emacs Crahes When Executing Command `consult-buffer'

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

I'd like to see what `consult-buffer' does, but the function seems not
to exist in master from Jan 1.  Can you tell me anything about it?
Where is it defined?


-- 
Dr Richard Stallman (https://stallman.org)
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

bug#67900: 30.0.50; Emacs Crahes When Executing Command `consult-buffer'

[Chang Xiaoduan]

Hello Andrea,

I still doubt the method you suggest to locate the mis-compiled code
here.

Assume we have n functions all compiled with optimization level
2. Executing one of them, which may call the others, triggers a
crash. Now if we make one of the function compiled with optimization
level 1, and the crash can still be reproduced, then can we conclude
that the function is not involved in the crash? I do not think so. Maybe
that function and some other function both trigger the crash.

Now assume we have n functions all compiled with optimization level 1
and no crash. Making one function compiled with optimization level 2 and
the program crashes. I think now it is safe to conclude that this
function is involved in the crash.

The following is what I have done:

1. I mark all `defun' in consult.el with `(declare (speed 1))'. I can
still reproduce the crash.

2. In addition to step 1, I mark all `cl-defun' in consult.el with
`(declare (speed 1))'. I can still reproduce the crash.

3. In addition to step 2, I mark all `defmacro' in consult.el with
`(declare (speed 1))'. I do not know if this works with `defmacro' or
not, I do it anyway. I can still reproduce the crash. However, I notice
one of the `defmacro' is somehow special:

#+begin_src eamcs-lisp
(defmacro consult--define-state (type)
  "Define state function for TYPE."
  (declare (speed 1))
  `(defun ,(intern (format "consult--%s-state" type)) ()
     ,(format "State function for %ss with preview.
The result can be passed as :state argument to `consult--read'." type)
     (consult--state-with-return (,(intern (format "consult--%s-preview" type)))
                                 #',(intern (format "consult--%s-action" type)))))
#+end_src

From what I know about "macro" in C, this will expand to a function
definition. I assume this is also true in Emacs Lisp, so:

4. In addition to step 3, I add the `declare' form in the macro
definition, and now the code is:

#+begin_src emacs-lisp
(defmacro consult--define-state (type)
  "Define state function for TYPE."
  (declare (speed 1))
  `(defun ,(intern (format "consult--%s-state" type)) ()
     ,(format "State function for %ss with preview.
The result can be passed as :state argument to `consult--read'." type)
     (declare (speed 1))
     (consult--state-with-return (,(intern (format "consult--%s-preview" type)))
                                 #',(intern (format "consult--%s-action" type)))))
#+end_src

Only after step 4, I can not reproduce the crash. If I regress to step
3, then the crash is reproducible. Thus, I think *at least* the function
generated using this macro is involved in the crash. What do you think
about it?

Thank you

bug#67900: 30.0.50; Emacs Crahes When Executing Command `consult-buffer'

[Chang Xiaoduan]

Richard Stallman <rms@gnu.org> writes:

> [[[ To any NSA and FBI agents reading my email: please consider    ]]]
> [[[ whether defending the US Constitution against all enemies,     ]]]
> [[[ foreign or domestic, requires you to follow Snowden's example. ]]]
>
> I'd like to see what `consult-buffer' does, but the function seems not
> to exist in master from Jan 1.  Can you tell me anything about it?
> Where is it defined?

Hello Richard,

Please note that `consult-buffer' is a function defined in a third-party
package consult.el (https://github.com/minad/consult). Also this issue
seems a Windows platform-specific one. It is only reproducible on
Windows with native compilation turned on.

Thank you

bug#67900: 30.0.50; Emacs Crahes When Executing Command `consult-buffer'

[Andrea Corallo]

Chang Xiaoduan <drcxd@sina.com> writes:

> Hello Andrea,
>
> I still doubt the method you suggest to locate the mis-compiled code
> here.
>
> Assume we have n functions all compiled with optimization level
> 2. Executing one of them, which may call the others, triggers a
> crash. Now if we make one of the function compiled with optimization
> level 1, and the crash can still be reproduced, then can we conclude
> that the function is not involved in the crash? I do not think so. Maybe
> that function and some other function both trigger the crash.
>
> Now assume we have n functions all compiled with optimization level 1
> and no crash. Making one function compiled with optimization level 2 and
> the program crashes. I think now it is safe to conclude that this
> function is involved in the crash.
>
> The following is what I have done:
>
> 1. I mark all `defun' in consult.el with `(declare (speed 1))'. I can
> still reproduce the crash.
>
> 2. In addition to step 1, I mark all `cl-defun' in consult.el with
> `(declare (speed 1))'. I can still reproduce the crash.
>
> 3. In addition to step 2, I mark all `defmacro' in consult.el with
> `(declare (speed 1))'. I do not know if this works with `defmacro' or
> not, I do it anyway. I can still reproduce the crash. However, I notice
> one of the `defmacro' is somehow special:
>
> #+begin_src eamcs-lisp
> (defmacro consult--define-state (type)
>   "Define state function for TYPE."
>   (declare (speed 1))
>   `(defun ,(intern (format "consult--%s-state" type)) ()
>      ,(format "State function for %ss with preview.
> The result can be passed as :state argument to `consult--read'." type)
>      (consult--state-with-return (,(intern (format "consult--%s-preview" type)))
>                                  #',(intern (format "consult--%s-action" type)))))
> #+end_src
>
>
>>From what I know about "macro" in C, this will expand to a function
> definition. I assume this is also true in Emacs Lisp, so:
>
> 4. In addition to step 3, I add the `declare' form in the macro
> definition, and now the code is:
>
> #+begin_src emacs-lisp
> (defmacro consult--define-state (type)
>   "Define state function for TYPE."
>   (declare (speed 1))
>   `(defun ,(intern (format "consult--%s-state" type)) ()
>      ,(format "State function for %ss with preview.
> The result can be passed as :state argument to `consult--read'." type)
>      (declare (speed 1))
>      (consult--state-with-return (,(intern (format "consult--%s-preview" type)))
>                                  #',(intern (format "consult--%s-action" type)))))
> #+end_src
>
> Only after step 4, I can not reproduce the crash. If I regress to step
> 3, then the crash is reproducible. Thus, I think *at least* the function
> generated using this macro is involved in the crash. What do you think
> about it?

I think you did what I suggested, adding declares to narrow down the
issue to defuns.  The fact that some defun is macro generated and that
one of these could have been the misscompiled one was as well suggested
by me in this thread.

I think the best now is to macro expand all those function and keep on
using the suggested declare method to narrow down exactly which of the
generated functions is the problematic one.

Thanks

  Andrea

bug#67900: 30.0.50; Emacs Crahes When Executing Command `consult-buffer'

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

Thanks for clearing that up.

It tends to happen with me that, after various messages went by in a
thread and I did not focus on it, something seems potentially to have
general importance -- which means I should pay attention.  But at that
point the messages don't say what it is about.

-- 
Dr Richard Stallman (https://stallman.org)
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

bug#67900: 30.0.50; Emacs Crahes When Executing Command `consult-buffer'

[Chang Xiaoduan]

Hello Andrea,

After some further test, I have found that the crash is reproducible
when the declare form is absent from the function definition inside the
macro definition.

#+begin_src emacs-lisp
(defmacro consult--define-state (type)
  "Define state function for TYPE."
  (declare (speed 1))
  `(defun ,(intern (format "consult--%s-state" type)) ()
     ,(format "State function for %ss with preview.
The result can be passed as :state argument to `consult--read'." type)
     (declare (speed 1)) ;; If absent, crash is reproducible
     (consult--state-with-return (,(intern (format "consult--%s-preview" type)))
                                 #',(intern (format "consult--%s-action" type)))))
#+end_src

Even if I use `emacs-lisp-macroexpand' to expand all instances of this
macro, and add declare form to these functions, missing the declare form
in the function definition inside the macro definition still triggers
the crash. In fact, if the functions generated from the macro expansion
contains the declare form seems has nothing to do with the crash. Do you
have any idea why this is happening and how it may be fixed?

Thanks

bug#67900: 30.0.50; Emacs Crahes When Executing Command `consult-buffer'

[Andrea Corallo]

Chang Xiaoduan <drcxd@sina.com> writes:

> Hello Andrea,
>
> After some further test, I have found that the crash is reproducible
> when the declare form is absent from the function definition inside the
> macro definition.

You mean with the whole compilation unit is compiled at speed 2?

> #+begin_src emacs-lisp
> (defmacro consult--define-state (type)
>   "Define state function for TYPE."
>   (declare (speed 1))
>   `(defun ,(intern (format "consult--%s-state" type)) ()
>      ,(format "State function for %ss with preview.
> The result can be passed as :state argument to `consult--read'." type)
>      (declare (speed 1)) ;; If absent, crash is reproducible
>      (consult--state-with-return (,(intern (format "consult--%s-preview" type)))
>                                  #',(intern (format "consult--%s-action" type)))))
> #+end_src
>
> Even if I use `emacs-lisp-macroexpand' to expand all instances of this
> macro, and add declare form to these functions, missing the declare form
> in the function definition inside the macro definition still triggers
> the crash.

Mmmh not sure I understand, if you macro expanded all the instances of
this macro how can the macro matter given it's never called?

> In fact, if the functions generated from the macro expansion
> contains the declare form seems has nothing to do with the crash. Do you
> have any idea why this is happening and how it may be fixed?

I think we have to really understand what's happening here and if what
you've observed is reproducible cause it does not make much sense to me
ATM.

Thanks for your investigation

  Andrea

bug#67900: 30.0.50; Emacs Crahes When Executing Command `consult-buffer'

[Chang Xiaoduan]

Hello Andrea,

Andrea Corallo <acorallo@gnu.org> writes:

> You mean with the whole compilation unit is compiled at speed 2?

No, all the `defun', `cl-defun', and `defmacro' are declared with
`(speed 1)`.

> Mmmh not sure I understand, if you macro expanded all the instances of
> this macro how can the macro matter given it's never called?

I am very curious about this point as well. At first, I expand the macro
without the declare form in the function definition in the macro
definition. Then I add the declare form to the functions generated by
the macro expansion. To my surprise, the crash still occurs.

In another test, I add the declare form to the function definition in
the macro definition, and expanded the macros. The crash can not be
reproduced. I remove all the declare form in the generated functions,
and the crash still can not be reproduced.

Thus I come to the conclusion that the declare form in the function
definition in the macro definition is what triggers the crash.

I do not know Emacs lisp much so I convinced myself that maybe macros in
Emacs lisp is different from macros in C++ and even if there is no
instance of using the macro it still get compiled in the native
compilation. Thus, I just reported what I have observed to you.

>
> I think we have to really understand what's happening here and if what
> you've observed is reproducible cause it does not make much sense to me
> ATM.
>
> Thanks for your investigation
>
>   Andrea

I guess you do not use Windows? Maybe I can setup a Windows VM so that I
can sent the VM to you and you can see the crash by yourselves. I also
wonder is there any way that we can check the C source code generated
from the Emacs lisp code before it is sent to the C compiler?

Thank you

bug#67900: 30.0.50; Emacs Crahes When Executing Command `consult-buffer'

[Andrea Corallo]

Chang Xiaoduan <drcxd@sina.com> writes:

> Hello Andrea,
>
> Andrea Corallo <acorallo@gnu.org> writes:
>
>> You mean with the whole compilation unit is compiled at speed 2?
>
> No, all the `defun', `cl-defun', and `defmacro' are declared with
> `(speed 1)`.
>
>> Mmmh not sure I understand, if you macro expanded all the instances of
>> this macro how can the macro matter given it's never called?
>
> I am very curious about this point as well. At first, I expand the macro
> without the declare form in the function definition in the macro
> definition. Then I add the declare form to the functions generated by
> the macro expansion. To my surprise, the crash still occurs.
>
> In another test, I add the declare form to the function definition in
> the macro definition, and expanded the macros. The crash can not be
> reproduced. I remove all the declare form in the generated functions,
> and the crash still can not be reproduced.
>
> Thus I come to the conclusion that the declare form in the function
> definition in the macro definition is what triggers the crash.
>
> I do not know Emacs lisp much so I convinced myself that maybe macros in
> Emacs lisp is different from macros in C++ and even if there is no
> instance of using the macro it still get compiled in the native
> compilation. Thus, I just reported what I have observed to you.
>
>>
>> I think we have to really understand what's happening here and if what
>> you've observed is reproducible cause it does not make much sense to me
>> ATM.
>>
>> Thanks for your investigation
>>
>>   Andrea
>
> I guess you do not use Windows?

I don't, not usually at least.

> Maybe I can setup a Windows VM so that I
> can sent the VM to you and you can see the crash by yourselves.

Yes I could have a look.

> I also
> wonder is there any way that we can check the C source code generated
> from the Emacs lisp code before it is sent to the C compiler?

Yep, see `native-comp-debug'.

Thanks

  Andrea