Package: emacs;
Reported by: Aaron Zeng <azeng <at> janestreet.com>
Date: Thu, 29 May 2025 20:58:02 UTC
Severity: normal
Found in version 30.1.90
View this message in rfc822 format
From: Eli Zaretskii <eliz <at> gnu.org> To: Stefan Monnier <monnier <at> iro.umontreal.ca> Cc: 78637 <at> debbugs.gnu.org, app-emacs-dev <at> janestreet.com, azeng <at> janestreet.com Subject: bug#78637: 30.1.90; Calling setopt during init loads cus-start over and over Date: Sat, 31 May 2025 20:23:39 +0300
> Cc: 78637 <at> debbugs.gnu.org, app-emacs-dev <at> janestreet.com
> Date: Sat, 31 May 2025 11:17:04 -0400
> From: Stefan Monnier via "Bug reports for GNU Emacs,
> the Swiss army knife of text editors" <bug-gnu-emacs <at> gnu.org>
>
> > While trying to improve Emacs startup time at my site, I noticed that
> > cus-start was being loaded repeatedly, each time setopt was called.
>
> I don't see this, but I do see `cus-start` being (re)loaded when the
> first `setopt` is executed.
>
> This comes from the weird conditional below:
>
> (unless dump-mode
> (provide 'cus-start))
>
> This dates back to
>
> commit 4883633e7b4416a0da1a63bc7fd0c4081bdc7837
> Author: Richard M. Stallman <rms <at> gnu.org>
> Date: Sat May 31 00:54:10 1997 +0000
>
> Arrange to load it once during dumping,
> and again if needed by cus-edit.el.
> (custom-start-quote): Don't define as separate function.
> (load-path): Improve the :type.
> (delete-exited-processes): Fix group to processes-basics.
>
> I have no idea why, but it's not a new problem.
>
> Maybe the repeated-loading you're seeing is due to `dump-mode` being
> non-nil in your Emacs build? If that's the case, do you have any idea
> why that would be the case (it's rather unusual).
No dump-mode is nil at this stage.
I think I'm beginning to understand why this happens: somehow loading
cus-start signals an error, so we never get to the provide part.
E.g., if I change the init file to say this:
(setq force-load-messages t)
(require 'cus-start)
(dotimes (_ 25)
(setopt make-backup-files nil))
then starting "emacs" shows the *Warnings* buffer with this text:
Wrong type argument: listp, t
To ensure normal operation, you should investigate and remove the
cause of the error in your initialization file. Start Emacs with
the ‘--debug-init’ option to view a complete error backtrace.
I also see that wrong-type-argument error signaled if I run the recipe
under GDB with a breakpoint on Fsignal. The backtrace is below, if it
helps. It seems Emacs is trying to do the equivalent of
(member transient-mark-mode t)
But I cannot figure out which part of cus-start causes this. Any
ideas?
Here's the backtrace from the error Emacs signals and some additional
data from snooping around:
(gdb) bt
#0 Fsignal (error_symbol=85536, data=-4611686018187727616) at eval.c:1820
#1 0x00955a95 in xsignal (error_symbol=85536, data=-4611686018187727616)
at lisp.h:4845
#2 0x0095bb1a in xsignal2 (error_symbol=85536, arg1=49488, arg2=48)
at eval.c:1988
#3 0x0092e545 in wrong_type_argument (predicate=49488, value=48) at data.c:135
#4 0x00967a07 in CHECK_LIST_END (x=48, y=48) at lisp.h:3368
#5 0x0096eef5 in Fmemq (elt=138077904, list=48) at fns.c:1923
#6 0x0096ebeb in Fmember (elt=138077904, list=48) at fns.c:1905
#7 0x009d14c6 in exec_byte_code (fun=-6917529027483966176,
args_template=1026, nargs=3, args=0xa020440) at bytecode.c:1604
#8 0x009cc8d7 in Fbyte_code (bytestr=-9223372036650939888,
vector=-6917529027437457712, maxdepth=4611686018427387933)
at bytecode.c:329
#9 0x0095dff5 in eval_sub (form=-4611686018187654016) at eval.c:2604
#10 0x009afade in readevalloop (readcharfun=37056, infile0=0x628cb04,
sourcename=-9223372036650939824, printflag=false, unibyte=0, readfun=0,
start=0, end=0) at lread.c:2543
#11 0x009acdba in Fload (file=-9223372036698239704, noerror=0, nomessage=48,
nosuffix=0, must_suffix=48) at lread.c:1731
#12 0x009ad1c0 in save_match_data_load (file=-9223372036698239704, noerror=0,
nomessage=48, nosuffix=0, must_suffix=48) at lread.c:1783
#13 0x0095d0c9 in load_with_autoload_queue (file=-9223372036698239704,
noerror=0, nomessage=48, nosuffix=0, must_suffix=48) at eval.c:2382
#14 0x00977eb5 in Frequire (feature=138111896, filename=0, noerror=0)
at fns.c:3771
#15 0x009600d3 in funcall_subr (subr=0x105bc40 <Srequire>, numargs=1,
args=0xa020320) at eval.c:3165
#16 0x009cd90d in exec_byte_code (fun=-6917529027484546136, args_template=257,
nargs=1, args=0xa0202e0) at bytecode.c:812
#17 0x0096094f in funcall_lambda (fun=-6917529027438039424, nargs=2,
arg_vector=0x628d470) at eval.c:3252
#18 0x0096076a in apply_lambda (fun=-6917529027438039424,
args=-4611686018298105856, count=1280) at eval.c:3215
#19 0x0095e517 in eval_sub (form=-4611686018298105872) at eval.c:2645
#20 0x00956ba6 in Fprogn (body=0) at eval.c:439
#21 0x00959483 in Flet (args=-4611686018298106016) at eval.c:1109
#22 0x0095dbc3 in eval_sub (form=-4611686018298106032) at eval.c:2549
#23 0x00956ba6 in Fprogn (body=-4611686018298006720) at eval.c:439
#24 0x00956bf2 in prog_ignore (body=-4611686018298106080) at eval.c:450
#25 0x0095951a in Fwhile (args=-4611686018298106064) at eval.c:1130
#26 0x0095dbc3 in eval_sub (form=-4611686018298106048) at eval.c:2549
#27 0x00956ba6 in Fprogn (body=0) at eval.c:439
#28 0x00959483 in Flet (args=-4611686018298106288) at eval.c:1109
#29 0x0095dbc3 in eval_sub (form=-4611686018298106304) at eval.c:2549
#30 0x009aee16 in readevalloop_eager_expand_eval (val=-4611686018298006624,
macroexpand=44400) at lread.c:2359
#31 0x009afac4 in readevalloop (readcharfun=-6917529027437162840, infile0=0x0,
sourcename=-9223372036650853472, printflag=false, unibyte=0, readfun=0,
start=0, end=0) at lread.c:2541
#32 0x009affc2 in Feval_buffer (buffer=-6917529027437162840, printflag=0,
filename=-9223372036650853472, unibyte=0, do_allow_print=48)
at lread.c:2616
#33 0x009601c0 in funcall_subr (subr=0x105d040 <Seval_buffer>, numargs=5,
args=0xa020280) at eval.c:3169
#34 0x009cd90d in exec_byte_code (fun=-6917529027484017368, args_template=257,
nargs=1, args=0xa020288) at bytecode.c:812
#35 0x0096094f in funcall_lambda (fun=-6917529027483359632, nargs=4,
arg_vector=0x628eb88) at eval.c:3252
#36 0x0095fa15 in funcall_general (fun=-6917529027483359632, numargs=4,
args=0x628eb88) at eval.c:3044
#37 0x0095fd3e in Ffuncall (nargs=5, args=0x628eb80) at eval.c:3093
#38 0x009ac862 in Fload (file=-9223372036698322936, noerror=138689728,
nomessage=138689664, nosuffix=0, must_suffix=0) at lread.c:1619
#39 0x009601c0 in funcall_subr (subr=0x105cfc0 <Sload>, numargs=3,
args=0xa0201d8) at eval.c:3169
#40 0x009cd90d in exec_byte_code (fun=-6917529027484481064, args_template=513,
nargs=1, args=0xa020238) at bytecode.c:812
#41 0x0096094f in funcall_lambda (fun=-6917529027478952400, nargs=0,
arg_vector=0x628f5a0) at eval.c:3252
#42 0x0096076a in apply_lambda (fun=-6917529027478952400, args=0, count=128)
at eval.c:3215
#43 0x0095e517 in eval_sub (form=-4611686018263554520) at eval.c:2645
#44 0x0095d5f0 in Feval (form=-4611686018263554520, lexical=48) at eval.c:2462
#45 0x008646d7 in top_level_2 () at keyboard.c:1184
#46 0x0095aa2d in internal_condition_case (bfun=0x86464e <top_level_2>,
handlers=144, hfun=0x863c02 <cmd_error>) at eval.c:1613
#47 0x0086476a in top_level_1 (ignore=0) at keyboard.c:1196
#48 0x00959ab2 in internal_catch (tag=75552, func=0x8646f6 <top_level_1>,
arg=0) at eval.c:1292
#49 0x00864541 in command_loop () at keyboard.c:1145
#50 0x00863662 in recursive_edit_1 () at keyboard.c:754
#51 0x00863900 in Frecursive_edit () at keyboard.c:837
#52 0x0085ea23 in main (argc=1, argv=0x7bf25c0) at emacs.c:2646
Lisp Backtrace:
"add-to-list" (0xa020428)
"byte-code" (0x628c270)
"require" (0xa020320)
"custom-load-symbol" (0xa0202d8)
"setopt--set" (0x628d470)
"let" (0x628d840)
"while" (0x628da80)
"let" (0x628dd10)
"eval-buffer" (0xa020280)
"load-with-code-conversion" (0x628eb88)
"load" (0xa0201d8)
0xc2418f8 PVEC_CLOSURE
"startup--load-user-init-file" (0xa0200c8)
"command-line" (0xa020048)
"normal-top-level" (0x628f5a0)
(gdb) fr 7
#7 0x009d14c6 in exec_byte_code (fun=-6917529027483966176,
args_template=1026, nargs=3, args=0xa020440) at bytecode.c:1604
1604 TOP = Fmember (TOP, v1);
(gdb) pp TOP
transient-mark-mode
(gdb) pp v1
t
(gdb) fr 9
#9 0x0095dff5 in eval_sub (form=-4611686018187654016) at eval.c:2604
2604 val = (XSUBR (fun)->function.a3
(gdb) p form
$12 = -4611686018187654016
(gdb) xcar
$13 = 0x83ad218
(gdb) xtype
Lisp_Symbol
(gdb) xsymbol
$14 = (struct Lisp_Symbol *) 0x953f378
"byte-code"
(gdb) p form
$15 = -4611686018187654016
(gdb) xcdr
$16 = 0xc00000000e4a0c70
(gdb) xcar
$17 = 0x800000000c264a10
(gdb) xtype
Lisp_String
(gdb) xprintbytestr $17->u.s
Bytecode: Non-integral right operand for "@" operator.
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.