GNU logs - #67900, boring messages

Message sent to bug-gnu-emacs@HIDDEN:

Subject: bug#67900: 30.0.50; Emacs Crahes When Executing Command `consult-buffer'
Resent-From: Chang Xiaoduan <drcxd@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Tue, 19 Dec 2023 12:54:01 +0000
Resent-Message-ID: <handler.67900.B.170299042622600 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
To: 67900 <at> debbugs.gnu.org
From: Chang Xiaoduan <drcxd@HIDDEN>
Date: Tue, 19 Dec 2023 15:48:18 +0800
Message-ID: <m3wmtabpkt.fsf@HIDDEN>
MIME-Version: 1.0
Content-Type: text/plain
Received-SPF: pass client-ip=202.108.3.164; envelope-from=drcxd@HIDDEN;
 helo=mail3-164.sinamail.sina.com.cn
X-Spam_score_int: 1
X-Spam_score: 0.1
X-Spam_bar: /
X-Spam_report: (0.1 / 5.0 requ) BAYES_00=-1.9, FREEMAIL_FROM=0.001,
 HK_RANDOM_ENVFROM=0.999, HK_RANDOM_FROM=0.999, RCVD_IN_DNSWL_NONE=-0.0001,
 SPF_HELO_NONE=0.001, SPF_PASS=-0.001,
 T_SCC_BODY_TEXT_LINE=-0.01 autolearn=no autolearn_force=no
X-Spam_action: no action
X-Spam-Score: 2.9 (++)
X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org",
 has NOT identified this incoming email as spam.  The original
 message has been attached to this so you can view it or label
 similar future email.  If you have any questions, see
 the administrator of that system for details.
 Content preview: 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 [...] 
 Content analysis details:   (2.9 points, 10.0 required)
 pts rule name              description
 ---- ---------------------- --------------------------------------------------
 1.0 HK_RANDOM_ENVFROM      Envelope sender username looks random
 1.0 HK_RANDOM_FROM         From username looks random
 -0.0 SPF_HELO_PASS          SPF: HELO matches SPF record
 0.0 FREEMAIL_FROM          Sender email is commonly abused enduser mail
 provider (drcxd[at]sina.com)
 0.9 SPF_FAIL               SPF: sender does not match SPF record (fail)
 [SPF failed: Please see http://www.openspf.org/Why?s=mfrom; id=drcxd%40sina.com;
 ip=2001%3A470%3A142%3A%3A17; r=debbugs.gnu.org]
 -0.0 T_SCC_BODY_TEXT_LINE   No description available.
 0.0 SPOOFED_FREEMAIL       No description available.
X-Mailman-Approved-At: Tue, 19 Dec 2023 07:53:39 -0500
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: 1.9 (+)
X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org",
 has NOT identified this incoming email as spam.  The original
 message has been attached to this so you can view it or label
 similar future email.  If you have any questions, see
 the administrator of that system for details.
 
 Content preview:  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 [...] 
 
 Content analysis details:   (1.9 points, 10.0 required)
 
  pts rule name              description
 ---- ---------------------- --------------------------------------------------
  1.0 HK_RANDOM_ENVFROM      Envelope sender username looks random
  1.0 HK_RANDOM_FROM         From username looks random
 -0.0 SPF_HELO_PASS          SPF: HELO matches SPF record
  0.0 FREEMAIL_FROM          Sender email is commonly abused enduser mail
                             provider (drcxd[at]sina.com)
  0.9 SPF_FAIL               SPF: sender does not match SPF record (fail)
 [SPF failed: Please see http://www.openspf.org/Why?s=mfrom;id=drcxd%40sina.com;ip=2001%3A470%3A142%3A%3A17;r=debbugs.gnu.org]
 -0.0 T_SCC_BODY_TEXT_LINE   No description available.
 -1.0 MAILING_LIST_MULTI     Multiple indicators imply a widely-seen list
                             manager


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))

Message sent:

Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Mailer: MIME-tools 5.505 (Entity 5.505)
Content-Type: text/plain; charset=utf-8
X-Loop: help-debbugs@HIDDEN
From: help-debbugs@HIDDEN (GNU bug Tracking System)
To: Chang Xiaoduan <drcxd@HIDDEN>
Subject: bug#67900: Acknowledgement (30.0.50; Emacs Crahes When Executing
 Command `consult-buffer')
Message-ID: <handler.67900.B.170299042622600.ack <at> debbugs.gnu.org>
References: <m3wmtabpkt.fsf@HIDDEN>
X-Gnu-PR-Message: ack 67900
X-Gnu-PR-Package: emacs
Reply-To: 67900 <at> debbugs.gnu.org
Date: Tue, 19 Dec 2023 12:54:01 +0000

Thank you for filing a new bug report with debbugs.gnu.org.

This is an automatically generated reply to let you know your message
has been received.

Your message is being forwarded to the package maintainers and other
interested parties for their attention; they will reply in due course.

Your message has been sent to the package maintainer(s):
 bug-gnu-emacs@HIDDEN

If you wish to submit further information on this problem, please
send it to 67900 <at> debbugs.gnu.org.

Please do not send mail to help-debbugs@HIDDEN unless you wish
to report a problem with the Bug-tracking system.

--=20
67900: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=3D67900
GNU Bug Tracking System
Contact help-debbugs@HIDDEN with problems

Message sent to bug-gnu-emacs@HIDDEN:

Subject: bug#67900: 30.0.50; Emacs Crahes When Executing Command `consult-buffer'
Resent-From: Eli Zaretskii <eliz@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Tue, 19 Dec 2023 13:18:01 +0000
Resent-Message-ID: <handler.67900.B67900.170299184312565 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
To: Chang Xiaoduan <drcxd@HIDDEN>
Cc: 67900 <at> debbugs.gnu.org
Date: Tue, 19 Dec 2023 15:16:46 +0200
Message-Id: <838r5qib7l.fsf@HIDDEN>
From: Eli Zaretskii <eliz@HIDDEN>
In-Reply-To: <m3wmtabpkt.fsf@HIDDEN> (message from Chang Xiaoduan on Tue, 19
 Dec 2023 15:48:18 +0800)
References: <m3wmtabpkt.fsf@HIDDEN>
Precedence: list
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>

> From: Chang Xiaoduan <drcxd@HIDDEN>
> 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.

Message sent to bug-gnu-emacs@HIDDEN:

Subject: bug#67900: 30.0.50; Emacs Crahes When Executing Command `consult-buffer'
Resent-From: Eli Zaretskii <eliz@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Wed, 20 Dec 2023 13:12:02 +0000
Resent-Message-ID: <handler.67900.B67900.170307787113183 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
To: Chang Xiaoduan <drcxd@HIDDEN>, Andrea Corallo <acorallo@HIDDEN>
Cc: 67900 <at> debbugs.gnu.org
Date: Wed, 20 Dec 2023 15:10:21 +0200
Message-Id: <83plz1ggua.fsf@HIDDEN>
From: Eli Zaretskii <eliz@HIDDEN>
In-Reply-To: <m3msu5751x.fsf@HIDDEN> (message from Chang Xiaoduan on Wed, 20
 Dec 2023 14:37:30 +0800)
References: <m3wmtabpkt.fsf@HIDDEN> <838r5qib7l.fsf@HIDDEN>
 <m3msu5751x.fsf@HIDDEN>
Precedence: list
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>

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

> From: Chang Xiaoduan <drcxd@HIDDEN>
> Date: Wed, 20 Dec 2023 14:37:30 +0800
> 
> Hello Eli,
> 
> Eli Zaretskii <eliz@HIDDEN> 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.

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#67900: 30.0.50; Emacs Crahes When Executing Command `consult-buffer'
Resent-From: Chang Xiaoduan <drcxd@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Thu, 21 Dec 2023 04:52:02 +0000
Resent-Message-ID: <handler.67900.B67900.170313431129974 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 67900
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: Eli Zaretskii <eliz@HIDDEN>
Cc: 67900 <at> debbugs.gnu.org, Andrea Corallo <acorallo@HIDDEN>
Received: via spool by 67900-submit <at> debbugs.gnu.org id=B67900.170313431129974
          (code B ref 67900); Thu, 21 Dec 2023 04:52:02 +0000
Received: (at 67900) by debbugs.gnu.org; 21 Dec 2023 04:51:51 +0000
Received: from localhost ([127.0.0.1]:42210 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1rGB2C-0007nK-Hk
	for submit <at> debbugs.gnu.org; Wed, 20 Dec 2023 23:51:51 -0500
Received: from r3-17.sinamail.sina.com.cn ([202.108.3.17]:42087)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <drcxd@HIDDEN>) id 1rG9he-0006JN-VL
 for 67900 <at> debbugs.gnu.org; Wed, 20 Dec 2023 22:26:35 -0500
X-SMAIL-HELO: PWRD-20210716KV
Received: from unknown (HELO PWRD-20210716KV)([111.207.225.84])
 by sina.com (10.182.253.22) with ESMTP
 id 6583B04D00001BBF; Thu, 21 Dec 2023 11:26:20 +0800 (CST)
X-Sender: drcxd@HIDDEN
X-Auth-ID: drcxd@HIDDEN
Authentication-Results: sina.com; spf=none smtp.mailfrom=drcxd@HIDDEN;
 dkim=none header.i=none;
 dmarc=none action=none header.from=drcxd@HIDDEN
X-SMAIL-MID: 6009166816196
X-SMAIL-UIID: EB8AF9C6F2D845E2A7B3E381FACC6852-20231221-112620-1
From: Chang Xiaoduan <drcxd@HIDDEN>
In-Reply-To: <83plz1ggua.fsf@HIDDEN> (Eli Zaretskii's message of "Wed, 20 Dec
 2023 15:10:21 +0200")
References: <m3wmtabpkt.fsf@HIDDEN> <838r5qib7l.fsf@HIDDEN>
 <m3msu5751x.fsf@HIDDEN> <83plz1ggua.fsf@HIDDEN>
Date: Thu, 21 Dec 2023 11:26:05 +0800
Message-ID: <m35y0snsmq.fsf@HIDDEN>
User-Agent: Gnus/5.13 (Gnus v5.13)
MIME-Version: 1.0
Content-Type: text/plain
X-Spam-Score: 1.3 (+)
X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org",
 has NOT identified this incoming email as spam.  The original
 message has been attached to this so you can view it or label
 similar future email.  If you have any questions, see
 the administrator of that system for details.
 Content preview:  Eli Zaretskii writes: > [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
 total [...] 
 Content analysis details:   (1.3 points, 10.0 required)
 pts rule name              description
 ---- ---------------------- --------------------------------------------------
 1.0 HK_RANDOM_ENVFROM      Envelope sender username looks random
 1.0 HK_RANDOM_FROM         From username looks random
 0.0 FREEMAIL_FROM          Sender email is commonly abused enduser mail
 provider (drcxd[at]sina.com)
 0.0 SPF_HELO_NONE          SPF: HELO does not publish an SPF Record
 -0.0 SPF_PASS               SPF: sender matches SPF record
 -0.7 RCVD_IN_DNSWL_LOW      RBL: Sender listed at https://www.dnswl.org/,
 low trust [202.108.3.17 listed in list.dnswl.org]
 -0.0 T_SCC_BODY_TEXT_LINE   No description available.
X-Mailman-Approved-At: Wed, 20 Dec 2023 23:51:45 -0500
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: 0.3 (/)

Eli Zaretskii <eliz@HIDDEN> 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?

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#67900: 30.0.50; Emacs Crahes When Executing Command `consult-buffer'
Resent-From: Eli Zaretskii <eliz@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Thu, 21 Dec 2023 08:04:01 +0000
Resent-Message-ID: <handler.67900.B67900.170314579717935 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 67900
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: Chang Xiaoduan <drcxd@HIDDEN>
Cc: 67900 <at> debbugs.gnu.org, acorallo@HIDDEN
Received: via spool by 67900-submit <at> debbugs.gnu.org id=B67900.170314579717935
          (code B ref 67900); Thu, 21 Dec 2023 08:04:01 +0000
Received: (at 67900) by debbugs.gnu.org; 21 Dec 2023 08:03:17 +0000
Received: from localhost ([127.0.0.1]:42330 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1rGE1V-0004fC-5I
	for submit <at> debbugs.gnu.org; Thu, 21 Dec 2023 03:03:17 -0500
Received: from eggs.gnu.org ([2001:470:142:3::10]:58870)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <eliz@HIDDEN>) id 1rGE1Q-0004ex-GF
 for 67900 <at> debbugs.gnu.org; Thu, 21 Dec 2023 03:03:16 -0500
Received: from fencepost.gnu.org ([2001:470:142:3::e])
 by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
 (Exim 4.90_1) (envelope-from <eliz@HIDDEN>)
 id 1rGE1D-0002rk-3R; Thu, 21 Dec 2023 03:02:59 -0500
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org;
 s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date:
 mime-version; bh=Am7LE6qhmiDE+aR/ut8q3Fc+5bzrrPKXxUNo5SBhRWY=; b=pnDyoU43CIzs
 d6LUZ++5/HuwxPwQcTspAVvG0VNXykgQ/6T98mJXTDzvBIgwk1vvgZnaKLSGip6I9JrhKCz4A1bex
 cMwPh2byp9fESRmcdElkT6pkjZoa98zcmCMr/874vneXr7RUiWs7CRspgoYrtgrnwigQtU3ukx7vz
 VGhJrNmQTLDjuFzr1Vl261I5KH6CFj/FRY/fW8Q046gS1oVq/pRYx+SPytAKZyjCV5OK2PJn1KcqV
 6ibTTJmB2mOBB7RiVoI+oBTHy0lmdbpFLwwowyQHsQ+vMzGvsT580JghlCtCTGPzDrHsVxIS0AIYS
 6Mkf5CFJkjugOhI22Ypgng==;
Date: Thu, 21 Dec 2023 10:02:42 +0200
Message-Id: <8334vwgezh.fsf@HIDDEN>
From: Eli Zaretskii <eliz@HIDDEN>
In-Reply-To: <m35y0snsmq.fsf@HIDDEN> (message from Chang Xiaoduan on Thu, 21
 Dec 2023 11:26:05 +0800)
References: <m3wmtabpkt.fsf@HIDDEN> <838r5qib7l.fsf@HIDDEN>
 <m3msu5751x.fsf@HIDDEN> <83plz1ggua.fsf@HIDDEN> <m35y0snsmq.fsf@HIDDEN>
X-Spam-Score: -2.3 (--)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)

> From: Chang Xiaoduan <drcxd@HIDDEN>
> Cc: Andrea Corallo <acorallo@HIDDEN>,  67900 <at> debbugs.gnu.org
> Date: Thu, 21 Dec 2023 11:26:05 +0800
> 
> Eli Zaretskii <eliz@HIDDEN> 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.

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#67900: 30.0.50; Emacs Crahes When Executing Command `consult-buffer'
Resent-From: Andrea Corallo <acorallo@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Thu, 21 Dec 2023 12:41:02 +0000
Resent-Message-ID: <handler.67900.B67900.170316245232081 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 67900
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: Eli Zaretskii <eliz@HIDDEN>
Cc: 67900 <at> debbugs.gnu.org, Chang Xiaoduan <drcxd@HIDDEN>
Received: via spool by 67900-submit <at> debbugs.gnu.org id=B67900.170316245232081
          (code B ref 67900); Thu, 21 Dec 2023 12:41:02 +0000
Received: (at 67900) by debbugs.gnu.org; 21 Dec 2023 12:40:52 +0000
Received: from localhost ([127.0.0.1]:42597 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1rGIM7-0008LN-Of
	for submit <at> debbugs.gnu.org; Thu, 21 Dec 2023 07:40:52 -0500
Received: from eggs.gnu.org ([2001:470:142:3::10]:51494)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <acorallo@HIDDEN>) id 1rGIM4-0008L9-Jm
 for 67900 <at> debbugs.gnu.org; Thu, 21 Dec 2023 07:40:49 -0500
Received: from fencepost.gnu.org ([2001:470:142:3::e])
 by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
 (Exim 4.90_1) (envelope-from <acorallo@HIDDEN>)
 id 1rGILr-0002Zb-JG; Thu, 21 Dec 2023 07:40:35 -0500
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org;
 s=fencepost-gnu-org; h=MIME-Version:Date:References:In-Reply-To:Subject:To:
 From; bh=9T7SdGiCyjrZzaAX8Ol/VEJeuCvg19sLASYSm6ccEG4=; b=p8MqF4uyenXe8deJt9df
 avjp7nICAzdm+pbAhRRzfB2kYGNOg8Ut1vLTUwf13apt9pKHAkm5xS8AcOti+FbTIQrwm4zYb81EB
 ClMqQrHCvdhZkg9mW9GjPAm6lLyKAUf0ZMWGvmyWCDpeeO7q7JavJOAd4uPzgww66vdskYCkSRZM5
 zP4jQHMs6GXz539ESQxGcQPGZogUt2GQbra0QfZUAOxBe0heJ0xKLum/OKgGlmFc/GhKBXn1GIGS/
 zHWaDFZl270a5/NdIF4F1p33lkUwQzhYFl1f5NUP8Orb+Jlq2snL44hCYnWCjmiHi7sCydviQY1I/
 fcjuNssGCuE9rw==;
Received: from acorallo by fencepost.gnu.org with local (Exim 4.90_1)
 (envelope-from <acorallo@HIDDEN>)
 id 1rGILn-0003ZJ-4w; Thu, 21 Dec 2023 07:40:34 -0500
From: Andrea Corallo <acorallo@HIDDEN>
In-Reply-To: <8334vwgezh.fsf@HIDDEN> (Eli Zaretskii's message of "Thu, 21 Dec
 2023 10:02:42 +0200")
References: <m3wmtabpkt.fsf@HIDDEN> <838r5qib7l.fsf@HIDDEN>
 <m3msu5751x.fsf@HIDDEN> <83plz1ggua.fsf@HIDDEN>
 <m35y0snsmq.fsf@HIDDEN> <8334vwgezh.fsf@HIDDEN>
Date: Thu, 21 Dec 2023 07:40:16 -0500
Message-ID: <yp1msu3zq33.fsf@HIDDEN>
User-Agent: Gnus/5.13 (Gnus v5.13)
MIME-Version: 1.0
Content-Type: text/plain
X-Spam-Score: -2.3 (--)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)

Eli Zaretskii <eliz@HIDDEN> writes:

>> From: Chang Xiaoduan <drcxd@HIDDEN>
>> Cc: Andrea Corallo <acorallo@HIDDEN>,  67900 <at> debbugs.gnu.org
>> Date: Thu, 21 Dec 2023 11:26:05 +0800
>> 
>> Eli Zaretskii <eliz@HIDDEN> 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

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#67900: 30.0.50; Emacs Crahes When Executing Command `consult-buffer'
Resent-From: Chang Xiaoduan <drcxd@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Fri, 22 Dec 2023 03:46:02 +0000
Resent-Message-ID: <handler.67900.B67900.170321672015650 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 67900
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: Andrea Corallo <acorallo@HIDDEN>
Cc: 67900 <at> debbugs.gnu.org, Eli Zaretskii <eliz@HIDDEN>
Received: via spool by 67900-submit <at> debbugs.gnu.org id=B67900.170321672015650
          (code B ref 67900); Fri, 22 Dec 2023 03:46:02 +0000
Received: (at 67900) by debbugs.gnu.org; 22 Dec 2023 03:45:20 +0000
Received: from localhost ([127.0.0.1]:45771 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1rGWTQ-00042B-3U
	for submit <at> debbugs.gnu.org; Thu, 21 Dec 2023 22:45:20 -0500
Received: from mail115-171.sinamail.sina.com.cn ([218.30.115.171]:32844)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <drcxd@HIDDEN>) id 1rGWTM-0003di-Ok
 for 67900 <at> debbugs.gnu.org; Thu, 21 Dec 2023 22:45:18 -0500
X-SMAIL-HELO: PWRD-20210716KV
Received: from unknown (HELO PWRD-20210716KV)([111.207.225.84])
 by sina.com (172.16.235.25) with ESMTP
 id 6585063900003851; Fri, 22 Dec 2023 11:45:04 +0800 (CST)
X-Sender: drcxd@HIDDEN
X-Auth-ID: drcxd@HIDDEN
Authentication-Results: sina.com; spf=none smtp.mailfrom=drcxd@HIDDEN;
 dkim=none header.i=none;
 dmarc=none action=none header.from=drcxd@HIDDEN
X-SMAIL-MID: 70756834209886
X-SMAIL-UIID: 6A7C0E26362442E7AA53687CEF490FF4-20231222-114504-1
From: Chang Xiaoduan <drcxd@HIDDEN>
In-Reply-To: <yp1msu3zq33.fsf@HIDDEN> (Andrea Corallo's message of
 "Thu, 21 Dec 2023 07:40:16 -0500")
References: <m3wmtabpkt.fsf@HIDDEN> <838r5qib7l.fsf@HIDDEN>
 <m3msu5751x.fsf@HIDDEN> <83plz1ggua.fsf@HIDDEN>
 <m35y0snsmq.fsf@HIDDEN> <8334vwgezh.fsf@HIDDEN>
 <yp1msu3zq33.fsf@HIDDEN>
Date: Fri, 22 Dec 2023 11:44:57 +0800
Message-ID: <m3ttoaaojq.fsf@HIDDEN>
User-Agent: Gnus/5.13 (Gnus v5.13)
MIME-Version: 1.0
Content-Type: text/plain
X-Spam-Score: 1.3 (+)
X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org",
 has NOT identified this incoming email as spam.  The original
 message has been attached to this so you can view it or label
 similar future email.  If you have any questions, see
 the administrator of that system for details.
 Content preview:  Andrea Corallo writes: > Eli Zaretskii writes: > >>> From:
 Chang Xiaoduan >>> Cc: Andrea Corallo , 67900 <at> debbugs.gnu.org >>> Date: Thu,
 21 Dec 2023 11:26:05 +0800 >>> >>> Eli Zaretskii writes: >>> >>> > [Please
 use R [...] 
 Content analysis details:   (1.3 points, 10.0 required)
 pts rule name              description
 ---- ---------------------- --------------------------------------------------
 1.0 HK_RANDOM_ENVFROM      Envelope sender username looks random
 1.0 HK_RANDOM_FROM         From username looks random
 -0.7 RCVD_IN_DNSWL_LOW      RBL: Sender listed at https://www.dnswl.org/,
 low trust [218.30.115.171 listed in list.dnswl.org]
 0.0 FREEMAIL_FROM          Sender email is commonly abused enduser mail
 provider (drcxd[at]sina.com)
 0.0 SPF_HELO_NONE          SPF: HELO does not publish an SPF Record
 -0.0 SPF_PASS               SPF: sender matches SPF record
 -0.0 T_SCC_BODY_TEXT_LINE   No description available.
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: 0.3 (/)

Andrea Corallo <acorallo@HIDDEN> writes:

> Eli Zaretskii <eliz@HIDDEN> writes:
>
>>> From: Chang Xiaoduan <drcxd@HIDDEN>
>>> Cc: Andrea Corallo <acorallo@HIDDEN>,  67900 <at> debbugs.gnu.org
>>> Date: Thu, 21 Dec 2023 11:26:05 +0800
>>> 
>>> Eli Zaretskii <eliz@HIDDEN> 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

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#67900: 30.0.50; Emacs Crahes When Executing Command `consult-buffer'
Resent-From: Eli Zaretskii <eliz@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Fri, 22 Dec 2023 07:42:01 +0000
Resent-Message-ID: <handler.67900.B67900.17032309143212 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 67900
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: Chang Xiaoduan <drcxd@HIDDEN>
Cc: 67900 <at> debbugs.gnu.org, acorallo@HIDDEN
Received: via spool by 67900-submit <at> debbugs.gnu.org id=B67900.17032309143212
          (code B ref 67900); Fri, 22 Dec 2023 07:42:01 +0000
Received: (at 67900) by debbugs.gnu.org; 22 Dec 2023 07:41:54 +0000
Received: from localhost ([127.0.0.1]:46004 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1rGaAL-0000pk-Ei
	for submit <at> debbugs.gnu.org; Fri, 22 Dec 2023 02:41:53 -0500
Received: from eggs.gnu.org ([2001:470:142:3::10]:41098)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <eliz@HIDDEN>) id 1rGaAJ-0000pW-66
 for 67900 <at> debbugs.gnu.org; Fri, 22 Dec 2023 02:41:51 -0500
Received: from fencepost.gnu.org ([2001:470:142:3::e])
 by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
 (Exim 4.90_1) (envelope-from <eliz@HIDDEN>)
 id 1rGaA7-0004Z4-CN; Fri, 22 Dec 2023 02:41:40 -0500
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org;
 s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date:
 mime-version; bh=gq/sHw7xR71dP/dv+HUDrKJCFeQ3flKj/c+jU1gDOPg=; b=hKITBnqp50g1
 dNDoh8pdUrD51tkPzbaZ79CnMLZtKTJDNVpE2vF5TozDXFIvtafX0iox3Ph48spSbezppRkHBp0M3
 LwEdIcUpEh8NJ+srsriE8SlEdUyz001Zt1S3AGCP1RaqWgcx14pIus7/py47Ta1YQDVaIWM4lcZU6
 HaMSgTTvFejinrlXiYfwZlhz3eStTto9J8ONshgIPCm/0GrmFUGF+YWV0cXJsdzXJG5lhVm7o2RYe
 74g1HSctigd6H7g+7/F6v7JqNhWDLmMnBnGzWypMLFg7idCQqvtRzwN5gOEqU9e/HE84KZasXl0K9
 75v8w0U7BNnvhlsvUqhP/g==;
Date: Fri, 22 Dec 2023 09:41:27 +0200
Message-Id: <83msu2fzvc.fsf@HIDDEN>
From: Eli Zaretskii <eliz@HIDDEN>
In-Reply-To: <m3ttoaaojq.fsf@HIDDEN> (message from Chang Xiaoduan on Fri, 22
 Dec 2023 11:44:57 +0800)
References: <m3wmtabpkt.fsf@HIDDEN> <838r5qib7l.fsf@HIDDEN>
 <m3msu5751x.fsf@HIDDEN> <83plz1ggua.fsf@HIDDEN>
 <m35y0snsmq.fsf@HIDDEN> <8334vwgezh.fsf@HIDDEN>
 <yp1msu3zq33.fsf@HIDDEN> <m3ttoaaojq.fsf@HIDDEN>
X-Spam-Score: -2.3 (--)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)

> From: Chang Xiaoduan <drcxd@HIDDEN>
> Cc: Eli Zaretskii <eliz@HIDDEN>,  67900 <at> debbugs.gnu.org
> Date: Fri, 22 Dec 2023 11:44:57 +0800
> 
> Andrea Corallo <acorallo@HIDDEN> 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.

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#67900: 30.0.50; Emacs Crahes When Executing Command `consult-buffer'
Resent-From: Andrea Corallo <acorallo@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Fri, 22 Dec 2023 09:39:02 +0000
Resent-Message-ID: <handler.67900.B67900.170323793029612 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 67900
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: Eli Zaretskii <eliz@HIDDEN>
Cc: 67900 <at> debbugs.gnu.org, Chang Xiaoduan <drcxd@HIDDEN>
Received: via spool by 67900-submit <at> debbugs.gnu.org id=B67900.170323793029612
          (code B ref 67900); Fri, 22 Dec 2023 09:39:02 +0000
Received: (at 67900) by debbugs.gnu.org; 22 Dec 2023 09:38:50 +0000
Received: from localhost ([127.0.0.1]:46070 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1rGbzW-0007hX-6S
	for submit <at> debbugs.gnu.org; Fri, 22 Dec 2023 04:38:50 -0500
Received: from eggs.gnu.org ([2001:470:142:3::10]:43526)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <acorallo@HIDDEN>) id 1rGbzU-0007hK-7L
 for 67900 <at> debbugs.gnu.org; Fri, 22 Dec 2023 04:38:48 -0500
Received: from fencepost.gnu.org ([2001:470:142:3::e])
 by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
 (Exim 4.90_1) (envelope-from <acorallo@HIDDEN>)
 id 1rGbzG-0007AD-AN; Fri, 22 Dec 2023 04:38:34 -0500
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org;
 s=fencepost-gnu-org; h=MIME-Version:Date:References:In-Reply-To:Subject:To:
 From; bh=YowyK4H7JMkUfBy+Bn+bWhKiaKgSZ8+fWr/Njcry0Qs=; b=KdB9fxt3Z5lGQPvd/bza
 HtXeU6SP0LrELCPSS7ZUOK9E5p5C9AaTUl6rpOTiYLUPzOTFcGCJA3u74IbBVoGE4pRoWAA3dX+dv
 i1u9SondgaCp0XTmCAz8xM1fVTJsj+cUWkk1d7yHPjK4rwd/iHq2mzkqqYdV9kxg+pBapSovtAsAS
 eRphPjB9pvgR1BYjGXZ1zc0Rsi8QpkXjLNrRKzbsuUCNfin9q13d1G45/pEVLL0PP1IQ0MrKELEn2
 LsTl6QV1RqHubwjjKT33EcT+g0bj36dXV99uUHZTIcPo7OIkhIW6v08eQLKJVvXhg1tVK9bhptNJ8
 gBYqhygR5Tmczw==;
Received: from acorallo by fencepost.gnu.org with local (Exim 4.90_1)
 (envelope-from <acorallo@HIDDEN>)
 id 1rGbyv-0003Ez-7p; Fri, 22 Dec 2023 04:38:23 -0500
From: Andrea Corallo <acorallo@HIDDEN>
In-Reply-To: <83msu2fzvc.fsf@HIDDEN> (Eli Zaretskii's message of "Fri, 22 Dec
 2023 09:41:27 +0200")
References: <m3wmtabpkt.fsf@HIDDEN> <838r5qib7l.fsf@HIDDEN>
 <m3msu5751x.fsf@HIDDEN> <83plz1ggua.fsf@HIDDEN>
 <m35y0snsmq.fsf@HIDDEN> <8334vwgezh.fsf@HIDDEN>
 <yp1msu3zq33.fsf@HIDDEN> <m3ttoaaojq.fsf@HIDDEN>
 <83msu2fzvc.fsf@HIDDEN>
Date: Fri, 22 Dec 2023 04:38:11 -0500
Message-ID: <yp1il4qzif0.fsf@HIDDEN>
User-Agent: Gnus/5.13 (Gnus v5.13)
MIME-Version: 1.0
Content-Type: text/plain
X-Spam-Score: -2.3 (--)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)

Eli Zaretskii <eliz@HIDDEN> writes:

>> From: Chang Xiaoduan <drcxd@HIDDEN>
>> Cc: Eli Zaretskii <eliz@HIDDEN>,  67900 <at> debbugs.gnu.org
>> Date: Fri, 22 Dec 2023 11:44:57 +0800
>> 
>> Andrea Corallo <acorallo@HIDDEN> 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

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#67900: 30.0.50; Emacs Crahes When Executing Command `consult-buffer'
Resent-From: Chang Xiaoduan <drcxd@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Sat, 23 Dec 2023 02:31:02 +0000
Resent-Message-ID: <handler.67900.B67900.17032986404137 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 67900
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: Eli Zaretskii <eliz@HIDDEN>
Cc: 67900 <at> debbugs.gnu.org, acorallo@HIDDEN
Received: via spool by 67900-submit <at> debbugs.gnu.org id=B67900.17032986404137
          (code B ref 67900); Sat, 23 Dec 2023 02:31:02 +0000
Received: (at 67900) by debbugs.gnu.org; 23 Dec 2023 02:30:40 +0000
Received: from localhost ([127.0.0.1]:48127 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1rGrmh-00012q-BH
	for submit <at> debbugs.gnu.org; Fri, 22 Dec 2023 21:30:40 -0500
Received: from mail115-80.sinamail.sina.com.cn ([218.30.115.80]:36408)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <drcxd@HIDDEN>) id 1rGrma-0000fj-Nk
 for 67900 <at> debbugs.gnu.org; Fri, 22 Dec 2023 21:30:37 -0500
X-SMAIL-HELO: PWRD-20210716KV
Received: from unknown (HELO PWRD-20210716KV)([111.207.225.84])
 by sina.com (10.75.12.45) with ESMTP
 id 6586463500003889; Sat, 23 Dec 2023 10:30:21 +0800 (CST)
X-Sender: drcxd@HIDDEN
X-Auth-ID: drcxd@HIDDEN
Authentication-Results: sina.com; spf=none smtp.mailfrom=drcxd@HIDDEN;
 dkim=none header.i=none;
 dmarc=none action=none header.from=drcxd@HIDDEN
X-SMAIL-MID: 87857331457761
X-SMAIL-UIID: 5C982603FF554F1A90CF0B2FC7A41D41-20231223-103021-1
From: Chang Xiaoduan <drcxd@HIDDEN>
In-Reply-To: <83msu2fzvc.fsf@HIDDEN> (Eli Zaretskii's message of "Fri, 22 Dec
 2023 09:41:27 +0200")
References: <m3wmtabpkt.fsf@HIDDEN> <838r5qib7l.fsf@HIDDEN>
 <m3msu5751x.fsf@HIDDEN> <83plz1ggua.fsf@HIDDEN>
 <m35y0snsmq.fsf@HIDDEN> <8334vwgezh.fsf@HIDDEN>
 <yp1msu3zq33.fsf@HIDDEN> <m3ttoaaojq.fsf@HIDDEN>
 <83msu2fzvc.fsf@HIDDEN>
Date: Sat, 23 Dec 2023 10:30:14 +0800
Message-ID: <m37cl5d51l.fsf@HIDDEN>
User-Agent: Gnus/5.13 (Gnus v5.13)
MIME-Version: 1.0
Content-Type: text/plain
X-Spam-Score: 1.3 (+)
X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org",
 has NOT identified this incoming email as spam.  The original
 message has been attached to this so you can view it or label
 similar future email.  If you have any questions, see
 the administrator of that system for details.
 Content preview:  Eli Zaretskii writes: > 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 [...] 
 Content analysis details:   (1.3 points, 10.0 required)
 pts rule name              description
 ---- ---------------------- --------------------------------------------------
 1.0 HK_RANDOM_ENVFROM      Envelope sender username looks random
 1.0 HK_RANDOM_FROM         From username looks random
 0.0 FREEMAIL_FROM          Sender email is commonly abused enduser mail
 provider (drcxd[at]sina.com)
 0.0 SPF_HELO_NONE          SPF: HELO does not publish an SPF Record
 -0.0 SPF_PASS               SPF: sender matches SPF record
 -0.7 RCVD_IN_DNSWL_LOW      RBL: Sender listed at https://www.dnswl.org/,
 low trust [218.30.115.80 listed in list.dnswl.org]
 -0.0 T_SCC_BODY_TEXT_LINE   No description available.
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: 0.3 (/)

Eli Zaretskii <eliz@HIDDEN> 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

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#67900: 30.0.50; Emacs Crahes When Executing Command `consult-buffer'
Resent-From: Eli Zaretskii <eliz@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Sat, 23 Dec 2023 07:36:01 +0000
Resent-Message-ID: <handler.67900.B67900.170331692815107 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 67900
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: Chang Xiaoduan <drcxd@HIDDEN>
Cc: 67900 <at> debbugs.gnu.org, acorallo@HIDDEN
Received: via spool by 67900-submit <at> debbugs.gnu.org id=B67900.170331692815107
          (code B ref 67900); Sat, 23 Dec 2023 07:36:01 +0000
Received: (at 67900) by debbugs.gnu.org; 23 Dec 2023 07:35:28 +0000
Received: from localhost ([127.0.0.1]:48444 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1rGwXf-0003va-Sw
	for submit <at> debbugs.gnu.org; Sat, 23 Dec 2023 02:35:28 -0500
Received: from eggs.gnu.org ([2001:470:142:3::10]:35212)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <eliz@HIDDEN>) id 1rGwXd-0003vJ-Ip
 for 67900 <at> debbugs.gnu.org; Sat, 23 Dec 2023 02:35:26 -0500
Received: from fencepost.gnu.org ([2001:470:142:3::e])
 by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
 (Exim 4.90_1) (envelope-from <eliz@HIDDEN>)
 id 1rGwXO-0001As-Oj; Sat, 23 Dec 2023 02:35:10 -0500
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org;
 s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date:
 mime-version; bh=sErrAsopotu0Fa61ZtdeiOAyfLXjB5rqchARoza/in0=; b=HoPDVQheaE88
 mU9Hadf1QXl89PdIOKoUMv5InrZnqWJ4elQANRIRNhzEIjHu9psyTyLt99mTDRtOfvra9JG6qLHpE
 1xkcC2rWnVyiH1I8gYsCrCWZByH1qKafcMO1DqwWEbeCunGChMTzv2Mp6Rhc/OIm/y+M4eMWK125F
 rBONF4O+8JreT996lRYk3i/X0XdTWRu+ZahmF/MF2bEB58zbkGPc4UDvVcCzfHy6TiwFP9Qw9lA4o
 HhX3ynTU4rR7BKPD5mvBF3V/vyP6C5bomYkM0UwwCX3wg2Kxxpgs2BWdhDHNBso7R6NbMCN5qzWNx
 pfmpZCyqxYipKvf7TfD3pw==;
Date: Sat, 23 Dec 2023 09:35:00 +0200
Message-Id: <834jg9fk2j.fsf@HIDDEN>
From: Eli Zaretskii <eliz@HIDDEN>
In-Reply-To: <m37cl5d51l.fsf@HIDDEN> (message from Chang Xiaoduan on Sat, 23
 Dec 2023 10:30:14 +0800)
References: <m3wmtabpkt.fsf@HIDDEN> <838r5qib7l.fsf@HIDDEN>
 <m3msu5751x.fsf@HIDDEN> <83plz1ggua.fsf@HIDDEN>
 <m35y0snsmq.fsf@HIDDEN> <8334vwgezh.fsf@HIDDEN>
 <yp1msu3zq33.fsf@HIDDEN> <m3ttoaaojq.fsf@HIDDEN>
 <83msu2fzvc.fsf@HIDDEN> <m37cl5d51l.fsf@HIDDEN>
X-Spam-Score: -2.3 (--)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)

> From: Chang Xiaoduan <drcxd@HIDDEN>
> Cc: acorallo@HIDDEN,  67900 <at> 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.

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#67900: 30.0.50; Emacs Crahes When Executing Command `consult-buffer'
Resent-From: Andrea Corallo <acorallo@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Tue, 26 Dec 2023 08:33:02 +0000
Resent-Message-ID: <handler.67900.B67900.17035795511505 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 67900
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: Eli Zaretskii <eliz@HIDDEN>
Cc: 67900 <at> debbugs.gnu.org, Chang Xiaoduan <drcxd@HIDDEN>
Received: via spool by 67900-submit <at> debbugs.gnu.org id=B67900.17035795511505
          (code B ref 67900); Tue, 26 Dec 2023 08:33:02 +0000
Received: (at 67900) by debbugs.gnu.org; 26 Dec 2023 08:32:31 +0000
Received: from localhost ([127.0.0.1]:55809 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1rI2rX-0000OA-7G
	for submit <at> debbugs.gnu.org; Tue, 26 Dec 2023 03:32:31 -0500
Received: from eggs.gnu.org ([2001:470:142:3::10]:57980)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <acorallo@HIDDEN>) id 1rI2rU-0000Nm-Ju
 for 67900 <at> debbugs.gnu.org; Tue, 26 Dec 2023 03:32:29 -0500
Received: from fencepost.gnu.org ([2001:470:142:3::e])
 by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
 (Exim 4.90_1) (envelope-from <acorallo@HIDDEN>)
 id 1rI2rE-0008Qd-W2; Tue, 26 Dec 2023 03:32:13 -0500
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org;
 s=fencepost-gnu-org; h=MIME-Version:Date:References:In-Reply-To:Subject:To:
 From; bh=UTijiMo7HQ0VTc5+vQznkvxhTrJD1GdWi7NFXJkm+HA=; b=UaBoJjyvWXFscdccu9We
 +o0PdF45MLhDI18LInUoyRQCv5nrQ4yP+6oEp/zHB59uks3nKYNJGkpF82nmMNPzp8Dmm9RQ2T5E8
 WuS8N5U+SyY9b10/n0+uPo6nPJCcgkOM6WUQCPxuTb1X2w1vaBZqGYzpfmoQhuC6U+YPyszlDaUjv
 vMEwwwr/Q/fhZmuM5fKV7Q4AXgFRmcG5vSqwxgdbrRWpg4kHDNrtZCziTtYoe2MCsasxVTFI07ef2
 srY5ZfgZc/pW9bde+vnC3NUuGJonWCPwO4c2fq4Xa1Q/onxDes8kgfgW4rVkWf24w3GAHrBeojtA+
 z8tVpvZOsM46xQ==;
Received: from acorallo by fencepost.gnu.org with local (Exim 4.90_1)
 (envelope-from <acorallo@HIDDEN>)
 id 1rI2rD-0003WX-EH; Tue, 26 Dec 2023 03:32:11 -0500
From: Andrea Corallo <acorallo@HIDDEN>
In-Reply-To: <834jg9fk2j.fsf@HIDDEN> (Eli Zaretskii's message of "Sat, 23 Dec
 2023 09:35:00 +0200")
References: <m3wmtabpkt.fsf@HIDDEN> <838r5qib7l.fsf@HIDDEN>
 <m3msu5751x.fsf@HIDDEN> <83plz1ggua.fsf@HIDDEN>
 <m35y0snsmq.fsf@HIDDEN> <8334vwgezh.fsf@HIDDEN>
 <yp1msu3zq33.fsf@HIDDEN> <m3ttoaaojq.fsf@HIDDEN>
 <83msu2fzvc.fsf@HIDDEN> <m37cl5d51l.fsf@HIDDEN>
 <834jg9fk2j.fsf@HIDDEN>
Date: Tue, 26 Dec 2023 03:32:11 -0500
Message-ID: <yp1a5pxz7n8.fsf@HIDDEN>
User-Agent: Gnus/5.13 (Gnus v5.13)
MIME-Version: 1.0
Content-Type: text/plain
X-Spam-Score: -2.3 (--)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)

Eli Zaretskii <eliz@HIDDEN> writes:

>> From: Chang Xiaoduan <drcxd@HIDDEN>
>> Cc: acorallo@HIDDEN,  67900 <at> 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

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#67900: 30.0.50; Emacs Crahes When Executing Command `consult-buffer'
Resent-From: Chang Xiaoduan <drcxd@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Thu, 28 Dec 2023 11:46:02 +0000
Resent-Message-ID: <handler.67900.B67900.170376390318977 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 67900
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: Andrea Corallo <acorallo@HIDDEN>
Cc: 67900 <at> debbugs.gnu.org, Eli Zaretskii <eliz@HIDDEN>
Received: via spool by 67900-submit <at> debbugs.gnu.org id=B67900.170376390318977
          (code B ref 67900); Thu, 28 Dec 2023 11:46:02 +0000
Received: (at 67900) by debbugs.gnu.org; 28 Dec 2023 11:45:03 +0000
Received: from localhost ([127.0.0.1]:38641 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1rIoow-0004ui-F6
	for submit <at> debbugs.gnu.org; Thu, 28 Dec 2023 06:45:02 -0500
Received: from mail3-162.sinamail.sina.com.cn ([202.108.3.162]:36193)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <drcxd@HIDDEN>) id 1rIooq-0004ti-KY
 for 67900 <at> debbugs.gnu.org; Thu, 28 Dec 2023 06:44:57 -0500
X-SMAIL-HELO: PWRD-20210716KV
Received: from unknown (HELO PWRD-20210716KV)([111.207.225.84])
 by sina.com (10.182.253.22) with ESMTP
 id 658D5FA80000380C; Thu, 28 Dec 2023 19:44:49 +0800 (CST)
X-Sender: drcxd@HIDDEN
X-Auth-ID: drcxd@HIDDEN
Authentication-Results: sina.com; spf=none smtp.mailfrom=drcxd@HIDDEN;
 dkim=none header.i=none;
 dmarc=none action=none header.from=drcxd@HIDDEN
X-SMAIL-MID: 9483766816240
X-SMAIL-UIID: BD51520548774BBE8DBF5C03C1DDBFCA-20231228-194449-1
From: Chang Xiaoduan <drcxd@HIDDEN>
In-Reply-To: <yp1a5pxz7n8.fsf@HIDDEN> (Andrea Corallo's message of
 "Tue, 26 Dec 2023 03:32:11 -0500")
References: <m3wmtabpkt.fsf@HIDDEN> <838r5qib7l.fsf@HIDDEN>
 <m3msu5751x.fsf@HIDDEN> <83plz1ggua.fsf@HIDDEN>
 <m35y0snsmq.fsf@HIDDEN> <8334vwgezh.fsf@HIDDEN>
 <yp1msu3zq33.fsf@HIDDEN> <m3ttoaaojq.fsf@HIDDEN>
 <83msu2fzvc.fsf@HIDDEN> <m37cl5d51l.fsf@HIDDEN>
 <834jg9fk2j.fsf@HIDDEN> <yp1a5pxz7n8.fsf@HIDDEN>
Date: Thu, 28 Dec 2023 19:44:40 +0800
Message-ID: <m3sf3mmtzr.fsf@HIDDEN>
User-Agent: Gnus/5.13 (Gnus v5.13)
MIME-Version: 1.0
Content-Type: text/plain
X-Spam-Score: 2.0 (++)
X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org",
 has NOT identified this incoming email as spam.  The original
 message has been attached to this so you can view it or label
 similar future email.  If you have any questions, see
 the administrator of that system for details.
 Content preview: Andrea Corallo writes: > Eli Zaretskii 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 [...] 
 Content analysis details:   (2.0 points, 10.0 required)
 pts rule name              description
 ---- ---------------------- --------------------------------------------------
 1.0 HK_RANDOM_ENVFROM      Envelope sender username looks random
 1.0 HK_RANDOM_FROM         From username looks random
 -0.0 SPF_PASS               SPF: sender matches SPF record
 0.0 FREEMAIL_FROM          Sender email is commonly abused enduser mail
 provider (drcxd[at]sina.com)
 0.0 RCVD_IN_MSPIKE_H3      RBL: Good reputation (+3)
 [202.108.3.162 listed in wl.mailspike.net]
 -0.0 RCVD_IN_DNSWL_NONE     RBL: Sender listed at https://www.dnswl.org/,
 no trust [202.108.3.162 listed in list.dnswl.org]
 0.0 SPF_HELO_NONE          SPF: HELO does not publish an SPF Record
 0.0 RCVD_IN_MSPIKE_WL      Mailspike good senders
 -0.0 T_SCC_BODY_TEXT_LINE   No description available.
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: 1.0 (+)

Andrea Corallo <acorallo@HIDDEN> writes:

> Eli Zaretskii <eliz@HIDDEN> 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

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#67900: 30.0.50; Emacs Crahes When Executing Command `consult-buffer'
Resent-From: Andrea Corallo <acorallo@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Fri, 29 Dec 2023 18:38:01 +0000
Resent-Message-ID: <handler.67900.B67900.170387505627660 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 67900
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: Chang Xiaoduan <drcxd@HIDDEN>
Cc: 67900 <at> debbugs.gnu.org, Eli Zaretskii <eliz@HIDDEN>
Received: via spool by 67900-submit <at> debbugs.gnu.org id=B67900.170387505627660
          (code B ref 67900); Fri, 29 Dec 2023 18:38:01 +0000
Received: (at 67900) by debbugs.gnu.org; 29 Dec 2023 18:37:36 +0000
Received: from localhost ([127.0.0.1]:42214 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1rJHjk-0007C4-7b
	for submit <at> debbugs.gnu.org; Fri, 29 Dec 2023 13:37:36 -0500
Received: from eggs.gnu.org ([2001:470:142:3::10]:42532)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <acorallo@HIDDEN>) id 1rJHjh-0007Bm-5i
 for 67900 <at> debbugs.gnu.org; Fri, 29 Dec 2023 13:37:34 -0500
Received: from fencepost.gnu.org ([2001:470:142:3::e])
 by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
 (Exim 4.90_1) (envelope-from <acorallo@HIDDEN>)
 id 1rJHjX-0001z1-VK; Fri, 29 Dec 2023 13:37:23 -0500
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org;
 s=fencepost-gnu-org; h=MIME-Version:Date:References:In-Reply-To:Subject:To:
 From; bh=eemGfl+krr7gVVqzVvNhQw6BKvgE4Lf2ng4Ze6V8w2Q=; b=Uwf6FjOIu+bNR+zMUeur
 T5M6wIJUgrrWIBeYkXgi+E8a8f67C8Dd2PZhAmy6+ja1Khz1IEko7g5oiBe3+20uynnElX5bOFuzl
 jwhXMAbdmjWo3bn9NuE4KVzW2wV0X2AgV3T1Oa9ChKONysciyTYpZ2jge/dNg564KUrA6IWZuv5Wn
 GNNiS7aQTse2PWlgypCU2x5gXMWHCf99NPHriO9PLZ9eWcDo/kGec94vIYApnoxJNZty1mhoBxETv
 OeiancDWIoexwuCndTUojFxoA0kUZQ0UFcqwHIff2FV+UCC0F6daOVmU3E7OiQ1FUDymPMs1zZBbg
 KYFVx0M+couohw==;
Received: from acorallo by fencepost.gnu.org with local (Exim 4.90_1)
 (envelope-from <acorallo@HIDDEN>)
 id 1rJHjX-0002b2-6p; Fri, 29 Dec 2023 13:37:23 -0500
From: Andrea Corallo <acorallo@HIDDEN>
In-Reply-To: <m3sf3mmtzr.fsf@HIDDEN> (Chang Xiaoduan's message of "Thu, 28
 Dec 2023 19:44:40 +0800")
References: <m3wmtabpkt.fsf@HIDDEN> <838r5qib7l.fsf@HIDDEN>
 <m3msu5751x.fsf@HIDDEN> <83plz1ggua.fsf@HIDDEN>
 <m35y0snsmq.fsf@HIDDEN> <8334vwgezh.fsf@HIDDEN>
 <yp1msu3zq33.fsf@HIDDEN> <m3ttoaaojq.fsf@HIDDEN>
 <83msu2fzvc.fsf@HIDDEN> <m37cl5d51l.fsf@HIDDEN>
 <834jg9fk2j.fsf@HIDDEN> <yp1a5pxz7n8.fsf@HIDDEN>
 <m3sf3mmtzr.fsf@HIDDEN>
Date: Fri, 29 Dec 2023 13:37:23 -0500
Message-ID: <yp15y0gzwgs.fsf@HIDDEN>
User-Agent: Gnus/5.13 (Gnus v5.13)
MIME-Version: 1.0
Content-Type: text/plain
X-Spam-Score: -2.3 (--)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)

Chang Xiaoduan <drcxd@HIDDEN> writes:

> Andrea Corallo <acorallo@HIDDEN> writes:
>
>> Eli Zaretskii <eliz@HIDDEN> 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

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#67900: 30.0.50; Emacs Crahes When Executing Command `consult-buffer'
Resent-From: Chang Xiaoduan <drcxd@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Tue, 02 Jan 2024 07:26:02 +0000
Resent-Message-ID: <handler.67900.B67900.170418031124993 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 67900
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: Andrea Corallo <acorallo@HIDDEN>
Cc: 67900 <at> debbugs.gnu.org, Eli Zaretskii <eliz@HIDDEN>
Received: via spool by 67900-submit <at> debbugs.gnu.org id=B67900.170418031124993
          (code B ref 67900); Tue, 02 Jan 2024 07:26:02 +0000
Received: (at 67900) by debbugs.gnu.org; 2 Jan 2024 07:25:11 +0000
Received: from localhost ([127.0.0.1]:49251 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1rKZ9D-0006V3-7i
	for submit <at> debbugs.gnu.org; Tue, 02 Jan 2024 02:25:11 -0500
Received: from r3-20.sinamail.sina.com.cn ([202.108.3.20]:45926)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <drcxd@HIDDEN>) id 1rKZ9A-0006Um-S2
 for 67900 <at> debbugs.gnu.org; Tue, 02 Jan 2024 02:25:09 -0500
X-SMAIL-HELO: PWRD-20210716KV
Received: from unknown (HELO PWRD-20210716KV)([111.207.225.84])
 by sina.com (10.182.253.24) with ESMTP
 id 6593BA43000038F2; Tue, 2 Jan 2024 15:24:59 +0800 (CST)
X-Sender: drcxd@HIDDEN
X-Auth-ID: drcxd@HIDDEN
Authentication-Results: sina.com; spf=none smtp.mailfrom=drcxd@HIDDEN;
 dkim=none header.i=none;
 dmarc=none action=none header.from=drcxd@HIDDEN
X-SMAIL-MID: 4490851048685
X-SMAIL-UIID: D3F5298604334FB7B58E9BD9A2306739-20240102-152459-1
From: Chang Xiaoduan <drcxd@HIDDEN>
In-Reply-To: <yp15y0gzwgs.fsf@HIDDEN> (Andrea Corallo's message of
 "Fri, 29 Dec 2023 13:37:23 -0500")
References: <m3wmtabpkt.fsf@HIDDEN> <838r5qib7l.fsf@HIDDEN>
 <m3msu5751x.fsf@HIDDEN> <83plz1ggua.fsf@HIDDEN>
 <m35y0snsmq.fsf@HIDDEN> <8334vwgezh.fsf@HIDDEN>
 <yp1msu3zq33.fsf@HIDDEN> <m3ttoaaojq.fsf@HIDDEN>
 <83msu2fzvc.fsf@HIDDEN> <m37cl5d51l.fsf@HIDDEN>
 <834jg9fk2j.fsf@HIDDEN> <yp1a5pxz7n8.fsf@HIDDEN>
 <m3sf3mmtzr.fsf@HIDDEN> <yp15y0gzwgs.fsf@HIDDEN>
Date: Tue, 02 Jan 2024 15:24:52 +0800
Message-ID: <m31qb0nqnv.fsf@HIDDEN>
User-Agent: Gnus/5.13 (Gnus v5.13)
MIME-Version: 1.0
Content-Type: text/plain
X-Spam-Score: 2.0 (++)
X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org",
 has NOT identified this incoming email as spam.  The original
 message has been attached to this so you can view it or label
 similar future email.  If you have any questions, see
 the administrator of that system for details.
 Content preview: Andrea Corallo 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 func [...] 
 Content analysis details:   (2.0 points, 10.0 required)
 pts rule name              description
 ---- ---------------------- --------------------------------------------------
 1.0 HK_RANDOM_ENVFROM      Envelope sender username looks random
 1.0 HK_RANDOM_FROM         From username looks random
 -0.0 SPF_PASS               SPF: sender matches SPF record
 0.0 FREEMAIL_FROM          Sender email is commonly abused enduser mail
 provider (drcxd[at]sina.com)
 0.0 SPF_HELO_NONE          SPF: HELO does not publish an SPF Record
 -0.0 T_SCC_BODY_TEXT_LINE   No description available.
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: 1.0 (+)

Andrea Corallo <acorallo@HIDDEN> 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

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#67900: 30.0.50; Emacs Crahes When Executing Command `consult-buffer'
Resent-From: Chang Xiaoduan <drcxd@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Tue, 02 Jan 2024 08:21:02 +0000
Resent-Message-ID: <handler.67900.B67900.17041836495965 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 67900
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: Andrea Corallo <acorallo@HIDDEN>
Cc: 67900 <at> debbugs.gnu.org, Eli Zaretskii <eliz@HIDDEN>
Received: via spool by 67900-submit <at> debbugs.gnu.org id=B67900.17041836495965
          (code B ref 67900); Tue, 02 Jan 2024 08:21:02 +0000
Received: (at 67900) by debbugs.gnu.org; 2 Jan 2024 08:20:49 +0000
Received: from localhost ([127.0.0.1]:49374 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1rKa13-0001Y8-Bj
	for submit <at> debbugs.gnu.org; Tue, 02 Jan 2024 03:20:49 -0500
Received: from r3-19.sinamail.sina.com.cn ([202.108.3.19]:34215)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <drcxd@HIDDEN>) id 1rKa10-0001Xm-Mg
 for 67900 <at> debbugs.gnu.org; Tue, 02 Jan 2024 03:20:48 -0500
X-SMAIL-HELO: PWRD-20210716KV
Received: from unknown (HELO PWRD-20210716KV)([111.207.225.84])
 by sina.com (10.182.253.24) with ESMTP
 id 6593C7480000045D; Tue, 2 Jan 2024 16:20:33 +0800 (CST)
X-Sender: drcxd@HIDDEN
X-Auth-ID: drcxd@HIDDEN
Authentication-Results: sina.com; spf=none smtp.mailfrom=drcxd@HIDDEN;
 dkim=none header.i=none;
 dmarc=none action=none header.from=drcxd@HIDDEN
X-SMAIL-MID: 4738761049264
X-SMAIL-UIID: E3845025CBE7471C9D3F530EF2064C64-20240102-162033-1
From: Chang Xiaoduan <drcxd@HIDDEN>
In-Reply-To: <yp15y0gzwgs.fsf@HIDDEN> (Andrea Corallo's message of
 "Fri, 29 Dec 2023 13:37:23 -0500")
References: <m3wmtabpkt.fsf@HIDDEN> <838r5qib7l.fsf@HIDDEN>
 <m3msu5751x.fsf@HIDDEN> <83plz1ggua.fsf@HIDDEN>
 <m35y0snsmq.fsf@HIDDEN> <8334vwgezh.fsf@HIDDEN>
 <yp1msu3zq33.fsf@HIDDEN> <m3ttoaaojq.fsf@HIDDEN>
 <83msu2fzvc.fsf@HIDDEN> <m37cl5d51l.fsf@HIDDEN>
 <834jg9fk2j.fsf@HIDDEN> <yp1a5pxz7n8.fsf@HIDDEN>
 <m3sf3mmtzr.fsf@HIDDEN> <yp15y0gzwgs.fsf@HIDDEN>
Date: Tue, 02 Jan 2024 16:20:24 +0800
Message-ID: <m3jzosgn93.fsf@HIDDEN>
User-Agent: Gnus/5.13 (Gnus v5.13)
MIME-Version: 1.0
Content-Type: text/plain
X-Spam-Score: 1.3 (+)
X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org",
 has NOT identified this incoming email as spam.  The original
 message has been attached to this so you can view it or label
 similar future email.  If you have any questions, see
 the administrator of that system for details.
 Content preview:  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'. Th [...]
 Content analysis details:   (1.3 points, 10.0 required)
 pts rule name              description
 ---- ---------------------- --------------------------------------------------
 1.0 HK_RANDOM_ENVFROM      Envelope sender username looks random
 1.0 HK_RANDOM_FROM         From username looks random
 -0.0 SPF_PASS               SPF: sender matches SPF record
 0.0 FREEMAIL_FROM          Sender email is commonly abused enduser mail
 provider (drcxd[at]sina.com)
 0.0 RCVD_IN_MSPIKE_H3      RBL: Good reputation (+3)
 [202.108.3.19 listed in wl.mailspike.net]
 0.0 SPF_HELO_NONE          SPF: HELO does not publish an SPF Record
 -0.7 RCVD_IN_DNSWL_LOW      RBL: Sender listed at https://www.dnswl.org/,
 low trust [202.108.3.19 listed in list.dnswl.org]
 0.0 RCVD_IN_MSPIKE_WL      Mailspike good senders
 -0.0 T_SCC_BODY_TEXT_LINE   No description available.
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: 0.3 (/)


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

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#67900: 30.0.50; Emacs Crahes When Executing Command `consult-buffer'
Resent-From: Andrea Corallo <acorallo@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Thu, 04 Jan 2024 09:52:02 +0000
Resent-Message-ID: <handler.67900.B67900.170436190820115 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 67900
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: Chang Xiaoduan <drcxd@HIDDEN>
Cc: 67900 <at> debbugs.gnu.org, Eli Zaretskii <eliz@HIDDEN>
Received: via spool by 67900-submit <at> debbugs.gnu.org id=B67900.170436190820115
          (code B ref 67900); Thu, 04 Jan 2024 09:52:02 +0000
Received: (at 67900) by debbugs.gnu.org; 4 Jan 2024 09:51:48 +0000
Received: from localhost ([127.0.0.1]:53590 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1rLKOA-0005EL-AR
	for submit <at> debbugs.gnu.org; Thu, 04 Jan 2024 04:51:48 -0500
Received: from eggs.gnu.org ([2001:470:142:3::10]:33542)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <acorallo@HIDDEN>) id 1rLKO5-0005E2-8v
 for 67900 <at> debbugs.gnu.org; Thu, 04 Jan 2024 04:51:45 -0500
Received: from fencepost.gnu.org ([2001:470:142:3::e])
 by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
 (Exim 4.90_1) (envelope-from <acorallo@HIDDEN>)
 id 1rLKNs-0003Vh-8X; Thu, 04 Jan 2024 04:51:28 -0500
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org;
 s=fencepost-gnu-org; h=MIME-Version:Date:References:In-Reply-To:Subject:To:
 From; bh=9QDHsn6KVFIQV4ATOFFLyK6myqI78MSO93kuFBnu6+A=; b=UKy4IaL7rOye4+XRJz0J
 rmYjZkqjP3sUSJEzuUB/FbRabWxb2tHZaZ7eiyEuaksVkCbhcjRHXgJQpRRN4sL6efwOn81pAR9/R
 Pu+cFwtPAjAjsqzubVVaRN3AwetOJLLF7z7yJf4dSrjvQ88+EcB1CggxmIH0exn2N+5miRlz81ksk
 TFNYWM/b1jjJiFwScZDvEI54IMW1FipHNy36jepiiqmlK36D89fuLQtg2e9XgcHWNSvEUPUNtlQTa
 gOwALlr+aL3kUYUi/Io+byx1QALTAf6bRnCj2medRxgALmO+qqp7pM7SNyZKVyTB9M0m9X+7+BaQv
 yPmYfiJ/uohH3Q==;
Received: from acorallo by fencepost.gnu.org with local (Exim 4.90_1)
 (envelope-from <acorallo@HIDDEN>)
 id 1rLKNq-0000sr-6c; Thu, 04 Jan 2024 04:51:27 -0500
From: Andrea Corallo <acorallo@HIDDEN>
In-Reply-To: <m31qb0nqnv.fsf@HIDDEN> (Chang Xiaoduan's message of "Tue, 02
 Jan 2024 15:24:52 +0800")
References: <m3wmtabpkt.fsf@HIDDEN> <838r5qib7l.fsf@HIDDEN>
 <m3msu5751x.fsf@HIDDEN> <83plz1ggua.fsf@HIDDEN>
 <m35y0snsmq.fsf@HIDDEN> <8334vwgezh.fsf@HIDDEN>
 <yp1msu3zq33.fsf@HIDDEN> <m3ttoaaojq.fsf@HIDDEN>
 <83msu2fzvc.fsf@HIDDEN> <m37cl5d51l.fsf@HIDDEN>
 <834jg9fk2j.fsf@HIDDEN> <yp1a5pxz7n8.fsf@HIDDEN>
 <m3sf3mmtzr.fsf@HIDDEN> <yp15y0gzwgs.fsf@HIDDEN>
 <m31qb0nqnv.fsf@HIDDEN>
Date: Thu, 04 Jan 2024 04:51:26 -0500
Message-ID: <yp18r55xw81.fsf@HIDDEN>
User-Agent: Gnus/5.13 (Gnus v5.13)
MIME-Version: 1.0
Content-Type: text/plain
X-Spam-Score: -2.3 (--)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)

Chang Xiaoduan <drcxd@HIDDEN> writes:

> Andrea Corallo <acorallo@HIDDEN> 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

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#67900: 30.0.50; Emacs Crahes When Executing Command `consult-buffer'
Resent-From: Andrea Corallo <acorallo@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Thu, 04 Jan 2024 09:59:01 +0000
Resent-Message-ID: <handler.67900.B67900.170436232820806 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 67900
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: Chang Xiaoduan <drcxd@HIDDEN>
Cc: 67900 <at> debbugs.gnu.org, Eli Zaretskii <eliz@HIDDEN>
Received: via spool by 67900-submit <at> debbugs.gnu.org id=B67900.170436232820806
          (code B ref 67900); Thu, 04 Jan 2024 09:59:01 +0000
Received: (at 67900) by debbugs.gnu.org; 4 Jan 2024 09:58:48 +0000
Received: from localhost ([127.0.0.1]:53595 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1rLKUx-0005PV-NS
	for submit <at> debbugs.gnu.org; Thu, 04 Jan 2024 04:58:48 -0500
Received: from eggs.gnu.org ([2001:470:142:3::10]:43796)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <acorallo@HIDDEN>) id 1rLKUv-0005PH-Nx
 for 67900 <at> debbugs.gnu.org; Thu, 04 Jan 2024 04:58:46 -0500
Received: from fencepost.gnu.org ([2001:470:142:3::e])
 by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
 (Exim 4.90_1) (envelope-from <acorallo@HIDDEN>)
 id 1rLKUj-0004SP-2b; Thu, 04 Jan 2024 04:58:33 -0500
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org;
 s=fencepost-gnu-org; h=MIME-Version:Date:References:In-Reply-To:Subject:To:
 From; bh=xpof+oaXI/26TVR9amqjWSfXKGmnyurWM+Ez/JwKOH8=; b=haJUpRG3shKi0vxNvWZs
 G0NTVBRPHIkDFNA1t7EXSPsvgl8kHLKTAD8pX+UZ/H2VqDr1xiQGEJRog9mSf/KqNLBNTT4RQ5soT
 +C4HEet0AIAy9x5rHgI1Sw0pQqGSrI47DSeJCMqbWz8ooWyAmAKtl4g44IlVxf6C7Q3bUf+b9rkEF
 b2URBfTcHgw72tamgkV2SjT+Z3YVfPT8TRHLHcR1YnFjIOxoVL/VMwxUwDY2HAaDBwMl/XV3zm60W
 3UOOdY0DXnqUReNxqRdbQQGu4O9/EpOxAEssrwFk0AoAhlEZZHDU5mC6pn6Snt46GcDDjERyv1HKO
 TFn40cQc2TI4Rg==;
Received: from acorallo by fencepost.gnu.org with local (Exim 4.90_1)
 (envelope-from <acorallo@HIDDEN>)
 id 1rLKUg-0004qL-KN; Thu, 04 Jan 2024 04:58:30 -0500
From: Andrea Corallo <acorallo@HIDDEN>
In-Reply-To: <m3jzosgn93.fsf@HIDDEN> (Chang Xiaoduan's message of "Tue, 02
 Jan 2024 16:20:24 +0800")
References: <m3wmtabpkt.fsf@HIDDEN> <838r5qib7l.fsf@HIDDEN>
 <m3msu5751x.fsf@HIDDEN> <83plz1ggua.fsf@HIDDEN>
 <m35y0snsmq.fsf@HIDDEN> <8334vwgezh.fsf@HIDDEN>
 <yp1msu3zq33.fsf@HIDDEN> <m3ttoaaojq.fsf@HIDDEN>
 <83msu2fzvc.fsf@HIDDEN> <m37cl5d51l.fsf@HIDDEN>
 <834jg9fk2j.fsf@HIDDEN> <yp1a5pxz7n8.fsf@HIDDEN>
 <m3sf3mmtzr.fsf@HIDDEN> <yp15y0gzwgs.fsf@HIDDEN>
 <m3jzosgn93.fsf@HIDDEN>
Date: Thu, 04 Jan 2024 04:58:30 -0500
Message-ID: <yp14jftxvw9.fsf@HIDDEN>
User-Agent: Gnus/5.13 (Gnus v5.13)
MIME-Version: 1.0
Content-Type: text/plain
X-Spam-Score: -2.3 (--)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)

Chang Xiaoduan <drcxd@HIDDEN> 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

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#67900: 30.0.50; Emacs Crahes When Executing Command `consult-buffer'
Resent-From: Richard Stallman <rms@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Fri, 05 Jan 2024 04:23:02 +0000
Resent-Message-ID: <handler.67900.B67900.170442855331548 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 67900
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: Chang Xiaoduan <drcxd@HIDDEN>
Cc: 67900 <at> debbugs.gnu.org, eliz@HIDDEN, acorallo@HIDDEN
Reply-To: rms@HIDDEN
Received: via spool by 67900-submit <at> debbugs.gnu.org id=B67900.170442855331548
          (code B ref 67900); Fri, 05 Jan 2024 04:23:02 +0000
Received: (at 67900) by debbugs.gnu.org; 5 Jan 2024 04:22:33 +0000
Received: from localhost ([127.0.0.1]:56128 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1rLbj6-0008Cl-Tq
	for submit <at> debbugs.gnu.org; Thu, 04 Jan 2024 23:22:33 -0500
Received: from eggs.gnu.org ([2001:470:142:3::10]:54730)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <rms@HIDDEN>) id 1rLbj3-0008CV-2Y
 for 67900 <at> debbugs.gnu.org; Thu, 04 Jan 2024 23:22:31 -0500
Received: from fencepost.gnu.org ([2001:470:142:3::e])
 by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
 (Exim 4.90_1) (envelope-from <rms@HIDDEN>)
 id 1rLbip-0005QT-2c; Thu, 04 Jan 2024 23:22:16 -0500
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org;
 s=fencepost-gnu-org; h=Date:References:Subject:In-Reply-To:To:From:
 mime-version; bh=WX2mIIn5+Hm16YWku8gzKN8okFfIwCKXlxsOGA/QTeI=; b=TScOLmmjD0vB
 t8dlxAQzNDUiPb0mM0lMaB0VR5NZoNKd4fqPPse8zMYjrjEMGuOON4gWzPTa0LNAAlS0/6y4KO/nl
 GmV12shEPG3qCLA/sMxCejIUNtVk1VmKSCq5PtZyTr+LMtGM7by48K6Zjlm6RggpMRt+a1qyZMe6Q
 GfXDLLVxl6cjQZgSPB2PQ/UK/RM8LKHKqn68ZFUAgmq3KQMfvq2fioSiOi5y9nK5IMVghOjJXGa9k
 YndQCgkjg8tp/0ZjDqxsIzwp5dRgbReJJdPUeIAJAIzygbKBtUXJJkYMifrh5Df6UpfHrOKBPQKVb
 qjRlqH6BmfasQ4khKdV7xw==;
Received: from rms by fencepost.gnu.org with local (Exim 4.90_1)
 (envelope-from <rms@HIDDEN>)
 id 1rLbio-0008MS-PN; Thu, 04 Jan 2024 23:22:14 -0500
Content-Type: text/plain; charset=Utf-8
From: Richard Stallman <rms@HIDDEN>
In-Reply-To: <m3jzosgn93.fsf@HIDDEN> (message from Chang Xiaoduan on Tue, 02
 Jan 2024 16:20:24 +0800)
References: <m3wmtabpkt.fsf@HIDDEN> <838r5qib7l.fsf@HIDDEN>
 <m3msu5751x.fsf@HIDDEN> <83plz1ggua.fsf@HIDDEN>
 <m35y0snsmq.fsf@HIDDEN> <8334vwgezh.fsf@HIDDEN>
 <yp1msu3zq33.fsf@HIDDEN> <m3ttoaaojq.fsf@HIDDEN>
 <83msu2fzvc.fsf@HIDDEN> <m37cl5d51l.fsf@HIDDEN>
 <834jg9fk2j.fsf@HIDDEN> <yp1a5pxz7n8.fsf@HIDDEN>
 <m3sf3mmtzr.fsf@HIDDEN> <yp15y0gzwgs.fsf@HIDDEN>
 <m3jzosgn93.fsf@HIDDEN>
Message-Id: <E1rLbio-0008MS-PN@HIDDEN>
Date: Thu, 04 Jan 2024 23:22:14 -0500
X-Spam-Score: -2.3 (--)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)

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

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)

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#67900: 30.0.50; Emacs Crahes When Executing Command `consult-buffer'
Resent-From: Chang Xiaoduan <drcxd@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Fri, 05 Jan 2024 07:05:01 +0000
Resent-Message-ID: <handler.67900.B67900.170443829529286 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 67900
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: Andrea Corallo <acorallo@HIDDEN>
Cc: 67900 <at> debbugs.gnu.org, Eli Zaretskii <eliz@HIDDEN>
Received: via spool by 67900-submit <at> debbugs.gnu.org id=B67900.170443829529286
          (code B ref 67900); Fri, 05 Jan 2024 07:05:01 +0000
Received: (at 67900) by debbugs.gnu.org; 5 Jan 2024 07:04:55 +0000
Received: from localhost ([127.0.0.1]:56205 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1rLeGE-0007cI-PV
	for submit <at> debbugs.gnu.org; Fri, 05 Jan 2024 02:04:55 -0500
Received: from mail3-162.sinamail.sina.com.cn ([202.108.3.162]:45746)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <drcxd@HIDDEN>) id 1rLeG9-0007bx-69
 for 67900 <at> debbugs.gnu.org; Fri, 05 Jan 2024 02:04:53 -0500
X-SMAIL-HELO: PWRD-20210716KV
Received: from unknown (HELO PWRD-20210716KV)([111.207.225.84])
 by sina.com (10.182.253.22) with ESMTP
 id 6597A9FA00003DA1; Fri, 5 Jan 2024 15:04:36 +0800 (CST)
X-Sender: drcxd@HIDDEN
X-Auth-ID: drcxd@HIDDEN
Authentication-Results: sina.com; spf=none smtp.mailfrom=drcxd@HIDDEN;
 dkim=none header.i=none;
 dmarc=none action=none header.from=drcxd@HIDDEN
X-SMAIL-MID: 3183776816529
X-SMAIL-UIID: 87DC651FC8DB4D4D971BAB81E23A1E84-20240105-150436-1
From: Chang Xiaoduan <drcxd@HIDDEN>
In-Reply-To: <yp18r55xw81.fsf@HIDDEN> (Andrea Corallo's message of
 "Thu, 04 Jan 2024 04:51:26 -0500")
References: <m3wmtabpkt.fsf@HIDDEN> <838r5qib7l.fsf@HIDDEN>
 <m3msu5751x.fsf@HIDDEN> <83plz1ggua.fsf@HIDDEN>
 <m35y0snsmq.fsf@HIDDEN> <8334vwgezh.fsf@HIDDEN>
 <yp1msu3zq33.fsf@HIDDEN> <m3ttoaaojq.fsf@HIDDEN>
 <83msu2fzvc.fsf@HIDDEN> <m37cl5d51l.fsf@HIDDEN>
 <834jg9fk2j.fsf@HIDDEN> <yp1a5pxz7n8.fsf@HIDDEN>
 <m3sf3mmtzr.fsf@HIDDEN> <yp15y0gzwgs.fsf@HIDDEN>
 <m31qb0nqnv.fsf@HIDDEN> <yp18r55xw81.fsf@HIDDEN>
Date: Fri, 05 Jan 2024 15:04:26 +0800
Message-ID: <m3cyugclc5.fsf@HIDDEN>
User-Agent: Gnus/5.13 (Gnus v5.13)
MIME-Version: 1.0
Content-Type: text/plain
X-Spam-Score: 2.0 (++)
X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org",
 has NOT identified this incoming email as spam.  The original
 message has been attached to this so you can view it or label
 similar future email.  If you have any questions, see
 the administrator of that system for details.
 Content preview:  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 lev
 [...] Content analysis details:   (2.0 points, 10.0 required)
 pts rule name              description
 ---- ---------------------- --------------------------------------------------
 1.0 HK_RANDOM_ENVFROM      Envelope sender username looks random
 1.0 HK_RANDOM_FROM         From username looks random
 -0.0 SPF_PASS               SPF: sender matches SPF record
 0.0 FREEMAIL_FROM          Sender email is commonly abused enduser mail
 provider (drcxd[at]sina.com)
 0.0 SPF_HELO_NONE          SPF: HELO does not publish an SPF Record
 -0.0 RCVD_IN_DNSWL_NONE     RBL: Sender listed at https://www.dnswl.org/,
 no trust [202.108.3.162 listed in list.dnswl.org]
 0.0 RCVD_IN_MSPIKE_H3      RBL: Good reputation (+3)
 [202.108.3.162 listed in wl.mailspike.net]
 0.0 RCVD_IN_MSPIKE_WL      Mailspike good senders
 -0.0 T_SCC_BODY_TEXT_LINE   No description available.
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: 1.0 (+)

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

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#67900: 30.0.50; Emacs Crahes When Executing Command `consult-buffer'
Resent-From: Chang Xiaoduan <drcxd@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Fri, 05 Jan 2024 07:10:02 +0000
Resent-Message-ID: <handler.67900.B67900.170443856429758 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 67900
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: Richard Stallman <rms@HIDDEN>
Cc: 67900 <at> debbugs.gnu.org, eliz@HIDDEN, acorallo@HIDDEN
Received: via spool by 67900-submit <at> debbugs.gnu.org id=B67900.170443856429758
          (code B ref 67900); Fri, 05 Jan 2024 07:10:02 +0000
Received: (at 67900) by debbugs.gnu.org; 5 Jan 2024 07:09:24 +0000
Received: from localhost ([127.0.0.1]:56215 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1rLeKZ-0007ju-Hb
	for submit <at> debbugs.gnu.org; Fri, 05 Jan 2024 02:09:23 -0500
Received: from r3-23.sinamail.sina.com.cn ([202.108.3.23]:37909)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <drcxd@HIDDEN>) id 1rLeKX-0007jf-9R
 for 67900 <at> debbugs.gnu.org; Fri, 05 Jan 2024 02:09:22 -0500
X-SMAIL-HELO: PWRD-20210716KV
Received: from unknown (HELO PWRD-20210716KV)([111.207.225.84])
 by sina.com (10.182.253.25) with ESMTP
 id 6597AB1300006904; Fri, 5 Jan 2024 15:09:09 +0800 (CST)
X-Sender: drcxd@HIDDEN
X-Auth-ID: drcxd@HIDDEN
Authentication-Results: sina.com; spf=none smtp.mailfrom=drcxd@HIDDEN;
 dkim=none header.i=none;
 dmarc=none action=none header.from=drcxd@HIDDEN
X-SMAIL-MID: 52189812059271
X-SMAIL-UIID: CEF0CA9340DE4DEB8C18A33A4CD8E0A7-20240105-150909-1
From: Chang Xiaoduan <drcxd@HIDDEN>
In-Reply-To: <E1rLbio-0008MS-PN@HIDDEN> (Richard Stallman's message
 of "Thu, 04 Jan 2024 23:22:14 -0500")
References: <m3wmtabpkt.fsf@HIDDEN> <838r5qib7l.fsf@HIDDEN>
 <m3msu5751x.fsf@HIDDEN> <83plz1ggua.fsf@HIDDEN>
 <m35y0snsmq.fsf@HIDDEN> <8334vwgezh.fsf@HIDDEN>
 <yp1msu3zq33.fsf@HIDDEN> <m3ttoaaojq.fsf@HIDDEN>
 <83msu2fzvc.fsf@HIDDEN> <m37cl5d51l.fsf@HIDDEN>
 <834jg9fk2j.fsf@HIDDEN> <yp1a5pxz7n8.fsf@HIDDEN>
 <m3sf3mmtzr.fsf@HIDDEN> <yp15y0gzwgs.fsf@HIDDEN>
 <m3jzosgn93.fsf@HIDDEN> <E1rLbio-0008MS-PN@HIDDEN>
Date: Fri, 05 Jan 2024 15:09:07 +0800
Message-ID: <m31qawcl4c.fsf@HIDDEN>
User-Agent: Gnus/5.13 (Gnus v5.13)
MIME-Version: 1.0
Content-Type: text/plain
X-Spam-Score: 1.3 (+)
X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org",
 has NOT identified this incoming email as spam.  The original
 message has been attached to this so you can view it or label
 similar future email.  If you have any questions, see
 the administrator of that system for details.
 Content preview: Richard Stallman 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 e [...] 
 Content analysis details:   (1.3 points, 10.0 required)
 pts rule name              description
 ---- ---------------------- --------------------------------------------------
 1.0 HK_RANDOM_ENVFROM      Envelope sender username looks random
 1.0 HK_RANDOM_FROM         From username looks random
 -0.0 SPF_PASS               SPF: sender matches SPF record
 0.0 FREEMAIL_FROM          Sender email is commonly abused enduser mail
 provider (drcxd[at]sina.com)
 -0.7 RCVD_IN_DNSWL_LOW      RBL: Sender listed at https://www.dnswl.org/,
 low trust [202.108.3.23 listed in list.dnswl.org]
 0.0 SPF_HELO_NONE          SPF: HELO does not publish an SPF Record
 -0.0 T_SCC_BODY_TEXT_LINE   No description available.
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: 0.3 (/)

Richard Stallman <rms@HIDDEN> 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

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#67900: 30.0.50; Emacs Crahes When Executing Command `consult-buffer'
Resent-From: Andrea Corallo <acorallo@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Fri, 05 Jan 2024 21:48:02 +0000
Resent-Message-ID: <handler.67900.B67900.170449123528064 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 67900
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: Chang Xiaoduan <drcxd@HIDDEN>
Cc: 67900 <at> debbugs.gnu.org, Eli Zaretskii <eliz@HIDDEN>
Received: via spool by 67900-submit <at> debbugs.gnu.org id=B67900.170449123528064
          (code B ref 67900); Fri, 05 Jan 2024 21:48:02 +0000
Received: (at 67900) by debbugs.gnu.org; 5 Jan 2024 21:47:15 +0000
Received: from localhost ([127.0.0.1]:58088 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1rLs26-0007IZ-V2
	for submit <at> debbugs.gnu.org; Fri, 05 Jan 2024 16:47:15 -0500
Received: from eggs.gnu.org ([2001:470:142:3::10]:60000)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <acorallo@HIDDEN>) id 1rLs24-0007IL-C8
 for 67900 <at> debbugs.gnu.org; Fri, 05 Jan 2024 16:47:13 -0500
Received: from fencepost.gnu.org ([2001:470:142:3::e])
 by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
 (Exim 4.90_1) (envelope-from <acorallo@HIDDEN>)
 id 1rLs1r-0007fl-7C; Fri, 05 Jan 2024 16:46:59 -0500
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org;
 s=fencepost-gnu-org; h=MIME-Version:Date:References:In-Reply-To:Subject:To:
 From; bh=Wl0Xk8fFOC3OULxMgIsi8M2i8g3gn1zzKbDcnOhNMrk=; b=hi1vjXMdk5AN4YnpqNbO
 E0imIDuPniMnJFLpOhwHapDEaRldfonv2Bd+StXeW8YOdR3n1wVA3cvYhqnbc0hjF2yQqor+9zW7R
 MEFsf0K97p96WwQo1iZDPenwPDBdK3I2yx/kMD4M8FePtRZyN2aiwipIVSdkCBaWBPP0q8D1h+2Cl
 O3NOpILN1uvrFxP33J0S2lFE02vEJPmmvE803IqLWmvLVuiwDJ4nVBsBZbATcZz5grgruqp9V3NB6
 Pnyr01ko1SJ2B4udvx1j1lhJcgiD2czZ942mDqDt1+JrNMmE4/YHu9R9+sVBZ8b2UZahKGH/IV6Yj
 5o08jTVUNiJOfA==;
Received: from acorallo by fencepost.gnu.org with local (Exim 4.90_1)
 (envelope-from <acorallo@HIDDEN>)
 id 1rLs1e-0001zX-H8; Fri, 05 Jan 2024 16:46:57 -0500
From: Andrea Corallo <acorallo@HIDDEN>
In-Reply-To: <m3cyugclc5.fsf@HIDDEN> (Chang Xiaoduan's message of "Fri, 05
 Jan 2024 15:04:26 +0800")
References: <m3wmtabpkt.fsf@HIDDEN> <838r5qib7l.fsf@HIDDEN>
 <m3msu5751x.fsf@HIDDEN> <83plz1ggua.fsf@HIDDEN>
 <m35y0snsmq.fsf@HIDDEN> <8334vwgezh.fsf@HIDDEN>
 <yp1msu3zq33.fsf@HIDDEN> <m3ttoaaojq.fsf@HIDDEN>
 <83msu2fzvc.fsf@HIDDEN> <m37cl5d51l.fsf@HIDDEN>
 <834jg9fk2j.fsf@HIDDEN> <yp1a5pxz7n8.fsf@HIDDEN>
 <m3sf3mmtzr.fsf@HIDDEN> <yp15y0gzwgs.fsf@HIDDEN>
 <m31qb0nqnv.fsf@HIDDEN> <yp18r55xw81.fsf@HIDDEN>
 <m3cyugclc5.fsf@HIDDEN>
Date: Fri, 05 Jan 2024 16:46:46 -0500
Message-ID: <yp1r0ivwj09.fsf@HIDDEN>
User-Agent: Gnus/5.13 (Gnus v5.13)
MIME-Version: 1.0
Content-Type: text/plain
X-Spam-Score: -2.3 (--)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)

Chang Xiaoduan <drcxd@HIDDEN> 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

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#67900: 30.0.50; Emacs Crahes When Executing Command `consult-buffer'
Resent-From: Richard Stallman <rms@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Sun, 07 Jan 2024 04:31:02 +0000
Resent-Message-ID: <handler.67900.B67900.17046018049159 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 67900
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: Chang Xiaoduan <drcxd@HIDDEN>
Cc: 67900 <at> debbugs.gnu.org
Reply-To: rms@HIDDEN
Received: via spool by 67900-submit <at> debbugs.gnu.org id=B67900.17046018049159
          (code B ref 67900); Sun, 07 Jan 2024 04:31:02 +0000
Received: (at 67900) by debbugs.gnu.org; 7 Jan 2024 04:30:04 +0000
Received: from localhost ([127.0.0.1]:60539 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1rMKnT-0002Mt-HT
	for submit <at> debbugs.gnu.org; Sat, 06 Jan 2024 23:30:04 -0500
Received: from eggs.gnu.org ([2001:470:142:3::10]:50398)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <rms@HIDDEN>) id 1rMKnQ-0002JU-KI
 for 67900 <at> debbugs.gnu.org; Sat, 06 Jan 2024 23:30:01 -0500
Received: from fencepost.gnu.org ([2001:470:142:3::e])
 by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
 (Exim 4.90_1) (envelope-from <rms@HIDDEN>)
 id 1rMKnC-0005Zx-If; Sat, 06 Jan 2024 23:29:46 -0500
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org;
 s=fencepost-gnu-org; h=Date:References:Subject:In-Reply-To:To:From:
 mime-version; bh=Vkou/pnUnNT6RGlraQmW2QL6lW4Impzi6lPw7EZTPjI=; b=ZdQfEvL4QBm+
 pb1WUhADhcAk4+RgG87g5q4tAjD6nVJJi86oFpstggJmr4LUIi+q8/TzukXo/+wSeWROCFhdwM91N
 f7JshD4wj4zxWGOl2D43W+5Zds0i6PCg+gGLkguolLKs3/4M7WDQyAaxNbT5PeVxtrTcmC6HezCPs
 IXtsrhk8H5k9DY+xAiL4I/0qormpYGHCjHZOcoHy1dmmDjMlT9LQ5zz0gZJck+ia2bu2xH1LEKNed
 A/y1/sNrZtDYscghRP/GS00+c2T0Xxl2Q7Cnbeilw1CtmVF/bvgY05bTyEw0W/60ar0C0mggyvoUU
 +2eLY1291QEUt0bDJAZ4Hw==;
Received: from rms by fencepost.gnu.org with local (Exim 4.90_1)
 (envelope-from <rms@HIDDEN>)
 id 1rMKnB-000447-Ao; Sat, 06 Jan 2024 23:29:45 -0500
Content-Type: text/plain; charset=Utf-8
From: Richard Stallman <rms@HIDDEN>
In-Reply-To: <m31qawcl4c.fsf@HIDDEN> (message from Chang Xiaoduan on Fri, 05
 Jan 2024 15:09:07 +0800)
References: <m3wmtabpkt.fsf@HIDDEN> <838r5qib7l.fsf@HIDDEN>
 <m3msu5751x.fsf@HIDDEN> <83plz1ggua.fsf@HIDDEN>
 <m35y0snsmq.fsf@HIDDEN> <8334vwgezh.fsf@HIDDEN>
 <yp1msu3zq33.fsf@HIDDEN> <m3ttoaaojq.fsf@HIDDEN>
 <83msu2fzvc.fsf@HIDDEN> <m37cl5d51l.fsf@HIDDEN>
 <834jg9fk2j.fsf@HIDDEN> <yp1a5pxz7n8.fsf@HIDDEN>
 <m3sf3mmtzr.fsf@HIDDEN> <yp15y0gzwgs.fsf@HIDDEN>
 <m3jzosgn93.fsf@HIDDEN> <E1rLbio-0008MS-PN@HIDDEN>
 <m31qawcl4c.fsf@HIDDEN>
Message-Id: <E1rMKnB-000447-Ao@HIDDEN>
Date: Sat, 06 Jan 2024 23:29:45 -0500
X-Spam-Score: -2.3 (--)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)

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

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)

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#67900: 30.0.50; Emacs Crahes When Executing Command `consult-buffer'
Resent-From: Chang Xiaoduan <drcxd@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Mon, 08 Jan 2024 03:29:01 +0000
Resent-Message-ID: <handler.67900.B67900.17046845226150 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 67900
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: Andrea Corallo <acorallo@HIDDEN>
Cc: 67900 <at> debbugs.gnu.org, Eli Zaretskii <eliz@HIDDEN>
Received: via spool by 67900-submit <at> debbugs.gnu.org id=B67900.17046845226150
          (code B ref 67900); Mon, 08 Jan 2024 03:29:01 +0000
Received: (at 67900) by debbugs.gnu.org; 8 Jan 2024 03:28:42 +0000
Received: from localhost ([127.0.0.1]:34798 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1rMgJe-0001b8-HN
	for submit <at> debbugs.gnu.org; Sun, 07 Jan 2024 22:28:42 -0500
Received: from r3-22.sinamail.sina.com.cn ([202.108.3.22]:40515)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <drcxd@HIDDEN>) id 1rMgJd-0001au-0U
 for 67900 <at> debbugs.gnu.org; Sun, 07 Jan 2024 22:28:41 -0500
X-SMAIL-HELO: PWRD-20210716KV
Received: from unknown (HELO PWRD-20210716KV)([111.207.225.84])
 by sina.com (10.182.253.23) with ESMTP
 id 659B6BD4000035CC; Mon, 8 Jan 2024 11:28:26 +0800 (CST)
X-Sender: drcxd@HIDDEN
X-Auth-ID: drcxd@HIDDEN
Authentication-Results: sina.com; spf=none smtp.mailfrom=drcxd@HIDDEN;
 dkim=none header.i=none;
 dmarc=none action=none header.from=drcxd@HIDDEN
X-SMAIL-MID: 8282607864943
X-SMAIL-UIID: 27A248201AD447A59055186C9A52D6CC-20240108-112826-1
From: Chang Xiaoduan <drcxd@HIDDEN>
In-Reply-To: <yp1r0ivwj09.fsf@HIDDEN> (Andrea Corallo's message of
 "Fri, 05 Jan 2024 16:46:46 -0500")
References: <m3wmtabpkt.fsf@HIDDEN> <838r5qib7l.fsf@HIDDEN>
 <m3msu5751x.fsf@HIDDEN> <83plz1ggua.fsf@HIDDEN>
 <m35y0snsmq.fsf@HIDDEN> <8334vwgezh.fsf@HIDDEN>
 <yp1msu3zq33.fsf@HIDDEN> <m3ttoaaojq.fsf@HIDDEN>
 <83msu2fzvc.fsf@HIDDEN> <m37cl5d51l.fsf@HIDDEN>
 <834jg9fk2j.fsf@HIDDEN> <yp1a5pxz7n8.fsf@HIDDEN>
 <m3sf3mmtzr.fsf@HIDDEN> <yp15y0gzwgs.fsf@HIDDEN>
 <m31qb0nqnv.fsf@HIDDEN> <yp18r55xw81.fsf@HIDDEN>
 <m3cyugclc5.fsf@HIDDEN> <yp1r0ivwj09.fsf@HIDDEN>
Date: Mon, 08 Jan 2024 11:28:26 +0800
Message-ID: <m3a5pgec6d.fsf@HIDDEN>
User-Agent: Gnus/5.13 (Gnus v5.13)
MIME-Version: 1.0
Content-Type: text/plain
X-Spam-Score: 1.3 (+)
X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org",
 has NOT identified this incoming email as spam.  The original
 message has been attached to this so you can view it or label
 similar future email.  If you have any questions, see
 the administrator of that system for details.
 Content preview:  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 [...] 
 Content analysis details:   (1.3 points, 10.0 required)
 pts rule name              description
 ---- ---------------------- --------------------------------------------------
 1.0 HK_RANDOM_ENVFROM      Envelope sender username looks random
 1.0 HK_RANDOM_FROM         From username looks random
 -0.0 SPF_PASS               SPF: sender matches SPF record
 0.0 FREEMAIL_FROM          Sender email is commonly abused enduser mail
 provider (drcxd[at]sina.com)
 0.0 RCVD_IN_MSPIKE_H3      RBL: Good reputation (+3)
 [202.108.3.22 listed in wl.mailspike.net]
 0.0 SPF_HELO_NONE          SPF: HELO does not publish an SPF Record
 -0.7 RCVD_IN_DNSWL_LOW      RBL: Sender listed at https://www.dnswl.org/,
 low trust [202.108.3.22 listed in list.dnswl.org]
 0.0 RCVD_IN_MSPIKE_WL      Mailspike good senders
 -0.0 T_SCC_BODY_TEXT_LINE   No description available.
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: 0.3 (/)

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

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#67900: 30.0.50; Emacs Crahes When Executing Command `consult-buffer'
Resent-From: Andrea Corallo <acorallo@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Mon, 08 Jan 2024 10:36:02 +0000
Resent-Message-ID: <handler.67900.B67900.170471013516590 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 67900
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: Chang Xiaoduan <drcxd@HIDDEN>
Cc: 67900 <at> debbugs.gnu.org, Eli Zaretskii <eliz@HIDDEN>
Received: via spool by 67900-submit <at> debbugs.gnu.org id=B67900.170471013516590
          (code B ref 67900); Mon, 08 Jan 2024 10:36:02 +0000
Received: (at 67900) by debbugs.gnu.org; 8 Jan 2024 10:35:35 +0000
Received: from localhost ([127.0.0.1]:35285 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1rMmyl-0004JW-Ge
	for submit <at> debbugs.gnu.org; Mon, 08 Jan 2024 05:35:35 -0500
Received: from eggs.gnu.org ([2001:470:142:3::10]:55030)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <acorallo@HIDDEN>) id 1rMmyj-0004JI-FH
 for 67900 <at> debbugs.gnu.org; Mon, 08 Jan 2024 05:35:34 -0500
Received: from fencepost.gnu.org ([2001:470:142:3::e])
 by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
 (Exim 4.90_1) (envelope-from <acorallo@HIDDEN>)
 id 1rMmyU-0003wB-AJ; Mon, 08 Jan 2024 05:35:18 -0500
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org;
 s=fencepost-gnu-org; h=MIME-Version:Date:References:In-Reply-To:Subject:To:
 From; bh=FX1+JU7RUeV0ABNaChLHVci3hpGG5AwLipnNToETtCg=; b=feCBpS2pTjMieRQr3yEN
 Qmer++smP//RVjMtQoOdqR7JcZL82xVip6jDo7nHXSlO1sA8zPmvKh2OKuDDNkFEvlxf1TcCNVFZ/
 +6qQPbp9k9ZC2weOpHYd9NOKqzb7zSW03dIEWGP8ar0bHEoSeZZzXnSS38jIaCnnzY7ea0kQ9WW8J
 FZUyn7st5nSMSBdnWuqn4oBZpjpcZZPYIfjt4K1L5Mx5TvSL6L7KkI6tiQDpOoG3bQS1DNABG1LC5
 +38HQcdLLLIlk0Hk/62mh6s9Uy+1oY0cGHQjWm8A3aKjEfK9GN/2SC6PDssZgDSk4QtlF8L/G2W4Z
 5buBOApSSmNEdA==;
Received: from acorallo by fencepost.gnu.org with local (Exim 4.90_1)
 (envelope-from <acorallo@HIDDEN>)
 id 1rMmyS-0000vZ-Hk; Mon, 08 Jan 2024 05:35:16 -0500
From: Andrea Corallo <acorallo@HIDDEN>
In-Reply-To: <m3a5pgec6d.fsf@HIDDEN> (Chang Xiaoduan's message of "Mon, 08
 Jan 2024 11:28:26 +0800")
References: <m3wmtabpkt.fsf@HIDDEN> <838r5qib7l.fsf@HIDDEN>
 <m3msu5751x.fsf@HIDDEN> <83plz1ggua.fsf@HIDDEN>
 <m35y0snsmq.fsf@HIDDEN> <8334vwgezh.fsf@HIDDEN>
 <yp1msu3zq33.fsf@HIDDEN> <m3ttoaaojq.fsf@HIDDEN>
 <83msu2fzvc.fsf@HIDDEN> <m37cl5d51l.fsf@HIDDEN>
 <834jg9fk2j.fsf@HIDDEN> <yp1a5pxz7n8.fsf@HIDDEN>
 <m3sf3mmtzr.fsf@HIDDEN> <yp15y0gzwgs.fsf@HIDDEN>
 <m31qb0nqnv.fsf@HIDDEN> <yp18r55xw81.fsf@HIDDEN>
 <m3cyugclc5.fsf@HIDDEN> <yp1r0ivwj09.fsf@HIDDEN>
 <m3a5pgec6d.fsf@HIDDEN>
Date: Mon, 08 Jan 2024 05:35:16 -0500
Message-ID: <yp1mstgw1sr.fsf@HIDDEN>
User-Agent: Gnus/5.13 (Gnus v5.13)
MIME-Version: 1.0
Content-Type: text/plain
X-Spam-Score: -2.3 (--)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)

Chang Xiaoduan <drcxd@HIDDEN> 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

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#67900: 30.0.50; Emacs Crahes When Executing Command `consult-buffer'
Resent-From: Chang Xiaoduan <drcxd@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Mon, 08 Jan 2024 11:41:01 +0000
Resent-Message-ID: <handler.67900.B67900.170471405831468 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 67900
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: Andrea Corallo <acorallo@HIDDEN>
Cc: 67900 <at> debbugs.gnu.org, Eli Zaretskii <eliz@HIDDEN>
Received: via spool by 67900-submit <at> debbugs.gnu.org id=B67900.170471405831468
          (code B ref 67900); Mon, 08 Jan 2024 11:41:01 +0000
Received: (at 67900) by debbugs.gnu.org; 8 Jan 2024 11:40:58 +0000
Received: from localhost ([127.0.0.1]:35351 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1rMo01-0008BT-Qc
	for submit <at> debbugs.gnu.org; Mon, 08 Jan 2024 06:40:58 -0500
Received: from mail115-63.sinamail.sina.com.cn ([218.30.115.63]:33459)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <drcxd@HIDDEN>) id 1rMnzx-0008BC-ST
 for 67900 <at> debbugs.gnu.org; Mon, 08 Jan 2024 06:40:56 -0500
X-SMAIL-HELO: PWRD-20210716KV
Received: from unknown (HELO PWRD-20210716KV)([111.207.225.84])
 by sina.com (10.75.12.45) with ESMTP
 id 659BDF3300007CCD; Mon, 8 Jan 2024 19:40:41 +0800 (CST)
X-Sender: drcxd@HIDDEN
X-Auth-ID: drcxd@HIDDEN
Authentication-Results: sina.com; spf=none smtp.mailfrom=drcxd@HIDDEN;
 dkim=none header.i=none;
 dmarc=none action=none header.from=drcxd@HIDDEN
X-SMAIL-MID: 53274031457897
X-SMAIL-UIID: E96CFA3523214CD78862CF803BBC2EE3-20240108-194041-1
From: Chang Xiaoduan <drcxd@HIDDEN>
In-Reply-To: <yp1mstgw1sr.fsf@HIDDEN> (Andrea Corallo's message of
 "Mon, 08 Jan 2024 05:35:16 -0500")
References: <m3wmtabpkt.fsf@HIDDEN> <838r5qib7l.fsf@HIDDEN>
 <m3msu5751x.fsf@HIDDEN> <83plz1ggua.fsf@HIDDEN>
 <m35y0snsmq.fsf@HIDDEN> <8334vwgezh.fsf@HIDDEN>
 <yp1msu3zq33.fsf@HIDDEN> <m3ttoaaojq.fsf@HIDDEN>
 <83msu2fzvc.fsf@HIDDEN> <m37cl5d51l.fsf@HIDDEN>
 <834jg9fk2j.fsf@HIDDEN> <yp1a5pxz7n8.fsf@HIDDEN>
 <m3sf3mmtzr.fsf@HIDDEN> <yp15y0gzwgs.fsf@HIDDEN>
 <m31qb0nqnv.fsf@HIDDEN> <yp18r55xw81.fsf@HIDDEN>
 <m3cyugclc5.fsf@HIDDEN> <yp1r0ivwj09.fsf@HIDDEN>
 <m3a5pgec6d.fsf@HIDDEN> <yp1mstgw1sr.fsf@HIDDEN>
Date: Mon, 08 Jan 2024 19:40:36 +0800
Message-ID: <m3jzoknjd7.fsf@HIDDEN>
User-Agent: Gnus/5.13 (Gnus v5.13)
MIME-Version: 1.0
Content-Type: text/plain
X-Spam-Score: 1.3 (+)
X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org",
 has NOT identified this incoming email as spam.  The original
 message has been attached to this so you can view it or label
 similar future email.  If you have any questions, see
 the administrator of that system for details.
 Content preview:  Hello Andrea,
 Andrea Corallo writes: > You mean with the whole
 compilation unit is compiled at speed 2? 
 Content analysis details:   (1.3 points, 10.0 required)
 pts rule name              description
 ---- ---------------------- --------------------------------------------------
 1.0 HK_RANDOM_ENVFROM      Envelope sender username looks random
 1.0 HK_RANDOM_FROM         From username looks random
 -0.7 RCVD_IN_DNSWL_LOW      RBL: Sender listed at https://www.dnswl.org/,
 low trust [218.30.115.63 listed in list.dnswl.org]
 -0.0 RCVD_IN_MSPIKE_H2      RBL: Average reputation (+2)
 [218.30.115.63 listed in wl.mailspike.net]
 -0.0 SPF_PASS               SPF: sender matches SPF record
 0.0 FREEMAIL_FROM          Sender email is commonly abused enduser mail
 provider (drcxd[at]sina.com)
 0.0 SPF_HELO_NONE          SPF: HELO does not publish an SPF Record
 -0.0 T_SCC_BODY_TEXT_LINE   No description available.
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: 0.3 (/)

Hello Andrea,

Andrea Corallo <acorallo@HIDDEN> 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

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#67900: 30.0.50; Emacs Crahes When Executing Command `consult-buffer'
Resent-From: Andrea Corallo <acorallo@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Tue, 09 Jan 2024 09:59:01 +0000
Resent-Message-ID: <handler.67900.B67900.170479430025255 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 67900
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: Chang Xiaoduan <drcxd@HIDDEN>
Cc: 67900 <at> debbugs.gnu.org, Eli Zaretskii <eliz@HIDDEN>
Received: via spool by 67900-submit <at> debbugs.gnu.org id=B67900.170479430025255
          (code B ref 67900); Tue, 09 Jan 2024 09:59:01 +0000
Received: (at 67900) by debbugs.gnu.org; 9 Jan 2024 09:58:20 +0000
Received: from localhost ([127.0.0.1]:38424 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1rN8sF-0006ZH-Sw
	for submit <at> debbugs.gnu.org; Tue, 09 Jan 2024 04:58:20 -0500
Received: from eggs.gnu.org ([2001:470:142:3::10]:39610)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <acorallo@HIDDEN>) id 1rN8sE-0006Z2-9J
 for 67900 <at> debbugs.gnu.org; Tue, 09 Jan 2024 04:58:19 -0500
Received: from fencepost.gnu.org ([2001:470:142:3::e])
 by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
 (Exim 4.90_1) (envelope-from <acorallo@HIDDEN>)
 id 1rN8ry-0004XE-PO; Tue, 09 Jan 2024 04:58:02 -0500
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org;
 s=fencepost-gnu-org; h=MIME-Version:Date:References:In-Reply-To:Subject:To:
 From; bh=5rw/KQn9Xf3p5nAaHjQJDBoRn85FBaVmtobpYArhN7U=; b=Kwvz+jfRKMaOZoYrzRHW
 pXNGyuAKwnKMrenBdZlqzYjyVMLeY50g/WyHVmbji24eDWeA4pcDo1dDnMsUydQYdKn+RxajffB3G
 CCJE9oQMVJuGHDFod3vzdbzW3yStbPLemt8d1GVjGAHpK3IcFUuyPtVTOQuVoNfXE8GPPeZTzHKeK
 5z0I5XDICRwfuaMpClQUtMtziaeXbjEzHN2rgtZmGaYFzpwaS1RYmMNsQG+xgMhBy7RzgR4PN2zMs
 oiI9TSPohKgMZQY8NBvVXrgJIxVdk+iCaVIvERWHh7U5EHHiZ3ovlwYzDyO4PuXMKtK1aMdNivCYv
 H9POYpaTJf6ypQ==;
Received: from acorallo by fencepost.gnu.org with local (Exim 4.90_1)
 (envelope-from <acorallo@HIDDEN>)
 id 1rN8rw-0001Xg-Nr; Tue, 09 Jan 2024 04:58:01 -0500
From: Andrea Corallo <acorallo@HIDDEN>
In-Reply-To: <m3jzoknjd7.fsf@HIDDEN> (Chang Xiaoduan's message of "Mon, 08
 Jan 2024 19:40:36 +0800")
References: <m3wmtabpkt.fsf@HIDDEN> <838r5qib7l.fsf@HIDDEN>
 <m3msu5751x.fsf@HIDDEN> <83plz1ggua.fsf@HIDDEN>
 <m35y0snsmq.fsf@HIDDEN> <8334vwgezh.fsf@HIDDEN>
 <yp1msu3zq33.fsf@HIDDEN> <m3ttoaaojq.fsf@HIDDEN>
 <83msu2fzvc.fsf@HIDDEN> <m37cl5d51l.fsf@HIDDEN>
 <834jg9fk2j.fsf@HIDDEN> <yp1a5pxz7n8.fsf@HIDDEN>
 <m3sf3mmtzr.fsf@HIDDEN> <yp15y0gzwgs.fsf@HIDDEN>
 <m31qb0nqnv.fsf@HIDDEN> <yp18r55xw81.fsf@HIDDEN>
 <m3cyugclc5.fsf@HIDDEN> <yp1r0ivwj09.fsf@HIDDEN>
 <m3a5pgec6d.fsf@HIDDEN> <yp1mstgw1sr.fsf@HIDDEN>
 <m3jzoknjd7.fsf@HIDDEN>
Date: Tue, 09 Jan 2024 04:58:00 -0500
Message-ID: <yp1il42x1zr.fsf@HIDDEN>
User-Agent: Gnus/5.13 (Gnus v5.13)
MIME-Version: 1.0
Content-Type: text/plain
X-Spam-Score: -2.3 (--)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)

Chang Xiaoduan <drcxd@HIDDEN> writes:

> Hello Andrea,
>
> Andrea Corallo <acorallo@HIDDEN> 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

Last modified: Sat, 20 Jan 2024 12:30:02 UTC

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997 nCipher Corporation Ltd, 1994-97 Ian Jackson.