* Emacs [scratch/igc 6682d0e6c96] crash on Linux 6.6.41 KDE 6.0.5, wayland
@ 2024-09-02 12:24 Eval Exec
2024-09-02 13:06 ` Eli Zaretskii
2024-09-02 16:41 ` Pip Cet
0 siblings, 2 replies; 15+ messages in thread
From: Eval Exec @ 2024-09-02 12:24 UTC (permalink / raw)
To: emacs-devel
Hello,
I'm helping to test scratch/igc branch on my local environment:
```
❯ uname -a
Linux Matrix 6.6.41 #1-NixOS SMP PREEMPT_DYNAMIC Thu Jul 18 11:21:27
UTC 2024 x86_64 GNU/Linux
```
I get the source code of scratch/igc, commit hash: 6682d0e6c96 .
And I append a new commit:
```
diff --git a/src/igc.c b/src/igc.c
index f069a2becc9..4d792da75c8 100644
--- a/src/igc.c
+++ b/src/igc.c
@@ -4459,7 +4459,7 @@ make_arena (struct igc *gc)
MPS_ARGS_END (args);
IGC_CHECK_RES (res);
- mps_gen_param_s gens[] = { { 128000, 0.8 }, { 5 * 128000, 0.4 } };
+ mps_gen_param_s gens[] = { { 128000000, 0.8 }, { 5 * 128000000, 0.4 } };
res = mps_chain_create (&gc->chain, gc->arena, ARRAYELTS (gens), gens);
IGC_CHECK_RES (res);
}
```
Then, I compile it by:
```
make extraclean
./autogen.sh \
&& ./configure \
--prefix=$(realpath ../emacs-build/$(git branch --show-current | sed
's/\//_/g'))\
--with-mps=yes \
--with-imagemagick \
--with-modules --with-x-toolkit=gtk3 --without-compress-install \
--without-toolkit-scroll-bars --with-native-compilation --with-mailutils\
--enable-link-time-optimization \
--with-tree-sitter --with-xinput2 \
--with-dbus --with-native-compilation=aot \
--with-file-notification=inotify\
&& make -j30 install
```
When I launch the emacs, editing rust files, emacs crashed. the backtrace is:
```
(gdb) source /home/exec/Projects/git.savannah.gnu.org/git/emacs/src/.gdbinit
warning: /home/exec/Projects/git.savannah.gnu.org/git/emacs/../lwlib:
No such file or directory
SIGINT is used by the debugger.
Are you sure you want to change it? (y or n) [answered Y; input not
from terminal]
DISPLAY = :0
TERM = tmux-256color
Breakpoint 1 at 0x428ca7: file
/home/exec/Projects/git.savannah.gnu.org/git/emacs/src/emacs.c, line
432.
Breakpoint 2 at 0x52db40: file
/home/exec/Projects/git.savannah.gnu.org/git/emacs/src/xterm.c, line
27126.
(gdb) bt
#0 0x00007f36826a2efc in __pthread_kill_implementation () from
/nix/store/dbcw19dshdwnxdv5q2g6wldj6syyvq7l-glibc-2.39-52/lib/libc.so.6
#1 0x00007f3682652e86 in raise () from
/nix/store/dbcw19dshdwnxdv5q2g6wldj6syyvq7l-glibc-2.39-52/lib/libc.so.6
#2 0x0000000000428d5a in terminate_due_to_signal (sig=11,
backtrace_limit=<optimized out>) at
/home/exec/Projects/git.savannah.gnu.org/git/emacs/src/emacs.c:470
#3 0x0000000000429579 in handle_fatal_signal (sig=<optimized out>) at
/home/exec/Projects/git.savannah.gnu.org/git/emacs/src/sysdep.c:1800
#4 0x00000000006c5a68 in deliver_thread_signal.constprop.0 (sig=11,
handler=<optimized out>) at
/home/exec/Projects/git.savannah.gnu.org/git/emacs/src/sysdep.c:1792
#5 <signal handler called>
#6 0x00007f368265316b in kill () from
/nix/store/dbcw19dshdwnxdv5q2g6wldj6syyvq7l-glibc-2.39-52/lib/libc.so.6
#7 0x00000000007551e9 in sigHandle ()
#8 <signal handler called>
#9 indirect_function (object=XIL(0)) at
/home/exec/Projects/git.savannah.gnu.org/git/emacs/src/lisp.h:1198
#10 0x00007f366e5f5bf4 in
F63616c6c65642d696e7465726163746976656c792d70_called_interactively_p_0
()
from /home/exec/Projects/git.savannah.gnu.org/git/emacs-build/scratch_igc/bin/../lib/emacs/31.0.50/native-lisp/31.0.50-9d7890e6/preloaded/subr-13adf6a6-cdd9cb44.eln
#11 0x00000000005fc7d0 in Ffuncall (nargs=2, args=0x7fff38d032e0) at
/home/exec/Projects/git.savannah.gnu.org/git/emacs/src/eval.c:3114
#12 0x00007f3665406ccf in
F6c73702d6d6f64656c696e652d776f726b73706163652d7374617475732d6d6f6465_lsp_modeline_workspace_status_mode_0
()
from /home/exec/.emacs.d/eln-cache/31.0.50-9d7890e6/lsp-modeline-c0d46924-a9e44c07.eln
#13 0x00000000005fc7d0 in Ffuncall (nargs=1, args=0x7fff38d03480) at
/home/exec/Projects/git.savannah.gnu.org/git/emacs/src/eval.c:3114
#14 0x00000000005fd4c9 in funcall_nil (nargs=<optimized out>,
args=<optimized out>) at
/home/exec/Projects/git.savannah.gnu.org/git/emacs/src/eval.c:2797
#15 0x00000000005f8953 in run_hook_with_args (nargs=1,
args=0x7fff38d03480, funcall=0x5fd4c0 <funcall_nil>) at
/home/exec/Projects/git.savannah.gnu.org/git/emacs/src/eval.c:2967
#16 0x00000000005f8a64 in Frun_hook_with_args (args=0x7fff38d03480,
nargs=1) at /home/exec/Projects/git.savannah.gnu.org/git/emacs/src/eval.c:2826
#17 run_hook (hook=<optimized out>) at
/home/exec/Projects/git.savannah.gnu.org/git/emacs/src/eval.c:2987
#18 Frun_hooks (nargs=1, args=0x7fff38d034c0) at
/home/exec/Projects/git.savannah.gnu.org/git/emacs/src/eval.c:2821
#19 0x00000000005faff2 in eval_sub (form=<optimized out>) at
/home/exec/Projects/git.savannah.gnu.org/git/emacs/src/eval.c:2591
#20 0x00000000005ec449 in Fprogn (body=<optimized out>) at
/home/exec/Projects/git.savannah.gnu.org/git/emacs/src/eval.c:452
#21 Flet (args=XIL(0x7f35cd2f9513)) at
/home/exec/Projects/git.savannah.gnu.org/git/emacs/src/eval.c:1122
#22 0x00000000005fb30f in eval_sub (form=<optimized out>) at
/home/exec/Projects/git.savannah.gnu.org/git/emacs/src/eval.c:2570
#23 0x00000000005fbed1 in Fprogn (body=<optimized out>) at
/home/exec/Projects/git.savannah.gnu.org/git/emacs/src/eval.c:452
#24 funcall_lambda (fun=XIL(0x7f35cd2f71cd), nargs=<optimized out>,
arg_vector=<optimized out>) at
/home/exec/Projects/git.savannah.gnu.org/git/emacs/src/eval.c:3371
#25 0x00000000005fd7b5 in apply_lambda (fun=XIL(0x7f35cd2f71cd),
args=<optimized out>, count=count@entry=...) at
/home/exec/Projects/git.savannah.gnu.org/git/emacs/src/eval.c:3236
#26 0x00000000005fac33 in eval_sub (form=<optimized out>) at
/home/exec/Projects/git.savannah.gnu.org/git/emacs/src/eval.c:2708
#27 0x00000000005eb321 in Fprogn (body=<optimized out>) at
/home/exec/Projects/git.savannah.gnu.org/git/emacs/src/eval.c:452
#28 Fcond (args=<optimized out>) at
/home/exec/Projects/git.savannah.gnu.org/git/emacs/src/eval.c:432
#29 0x00000000005fb30f in eval_sub (form=<optimized out>) at
/home/exec/Projects/git.savannah.gnu.org/git/emacs/src/eval.c:2570
#30 0x00000000005ec449 in Fprogn (body=<optimized out>) at
/home/exec/Projects/git.savannah.gnu.org/git/emacs/src/eval.c:452
#31 Flet (args=XIL(0x7f35cd2ec093)) at
/home/exec/Projects/git.savannah.gnu.org/git/emacs/src/eval.c:1122
#32 0x00000000005fb30f in eval_sub (form=<optimized out>) at
/home/exec/Projects/git.savannah.gnu.org/git/emacs/src/eval.c:2570
#33 0x00000000005fbed1 in Fprogn (body=<optimized out>) at
/home/exec/Projects/git.savannah.gnu.org/git/emacs/src/eval.c:452
#34 funcall_lambda (fun=XIL(0x7f35cd2e83e5), nargs=<optimized out>,
arg_vector=<optimized out>) at
/home/exec/Projects/git.savannah.gnu.org/git/emacs/src/eval.c:3371
#35 0x00000000005fd7b5 in apply_lambda (fun=XIL(0x7f35cd2e83e5),
args=<optimized out>, count=count@entry=...) at
/home/exec/Projects/git.savannah.gnu.org/git/emacs/src/eval.c:3236
#36 0x00000000005fac33 in eval_sub (form=<optimized out>) at
/home/exec/Projects/git.savannah.gnu.org/git/emacs/src/eval.c:2708
#37 0x00000000005fbed1 in Fprogn (body=<optimized out>) at
/home/exec/Projects/git.savannah.gnu.org/git/emacs/src/eval.c:452
#38 funcall_lambda (fun=XIL(0x7f35dbc28f05), nargs=<optimized out>,
arg_vector=<optimized out>) at
/home/exec/Projects/git.savannah.gnu.org/git/emacs/src/eval.c:3371
#39 0x00000000005fd7b5 in apply_lambda (fun=XIL(0x7f35dbc28f05),
args=<optimized out>, count=count@entry=...) at
/home/exec/Projects/git.savannah.gnu.org/git/emacs/src/eval.c:3236
#40 0x00000000005fac33 in eval_sub (form=<optimized out>) at
/home/exec/Projects/git.savannah.gnu.org/git/emacs/src/eval.c:2708
#41 0x00000000005ec449 in Fprogn (body=<optimized out>) at
/home/exec/Projects/git.savannah.gnu.org/git/emacs/src/eval.c:452
#42 Flet (args=XIL(0x7f35dbc25bb3)) at
/home/exec/Projects/git.savannah.gnu.org/git/emacs/src/eval.c:1122
#43 0x00000000005fb30f in eval_sub (form=<optimized out>) at
/home/exec/Projects/git.savannah.gnu.org/git/emacs/src/eval.c:2570
#44 0x00000000005eadd1 in Fprogn (body=<optimized out>) at
/home/exec/Projects/git.savannah.gnu.org/git/emacs/src/eval.c:452
#45 0x00000000005fb30f in eval_sub (form=<optimized out>) at
/home/exec/Projects/git.savannah.gnu.org/git/emacs/src/eval.c:2570
#46 0x00000000005fb30f in eval_sub (form=<optimized out>) at
/home/exec/Projects/git.savannah.gnu.org/git/emacs/src/eval.c:2570
#47 0x00000000005fbed1 in Fprogn (body=<optimized out>) at
/home/exec/Projects/git.savannah.gnu.org/git/emacs/src/eval.c:452
#48 funcall_lambda (fun=XIL(0x7f35dbc1e8d5), nargs=<optimized out>,
arg_vector=<optimized out>) at
/home/exec/Projects/git.savannah.gnu.org/git/emacs/src/eval.c:3371
#49 0x00000000005fd7b5 in apply_lambda (fun=XIL(0x7f35dbc1e8d5),
args=<optimized out>, count=count@entry=...) at
/home/exec/Projects/git.savannah.gnu.org/git/emacs/src/eval.c:3236
#50 0x00000000005fac33 in eval_sub (form=<optimized out>) at
/home/exec/Projects/git.savannah.gnu.org/git/emacs/src/eval.c:2708
#51 0x00000000005eadd1 in Fprogn (body=<optimized out>) at
/home/exec/Projects/git.savannah.gnu.org/git/emacs/src/eval.c:452
#52 0x00000000005fb30f in eval_sub (form=<optimized out>) at
/home/exec/Projects/git.savannah.gnu.org/git/emacs/src/eval.c:2570
#53 0x00000000005fb30f in eval_sub (form=<optimized out>) at
/home/exec/Projects/git.savannah.gnu.org/git/emacs/src/eval.c:2570
#54 0x00000000005ebea1 in Fprogn (body=<optimized out>) at
/home/exec/Projects/git.savannah.gnu.org/git/emacs/src/eval.c:452
#55 FletX (args=<optimized out>) at
/home/exec/Projects/git.savannah.gnu.org/git/emacs/src/eval.c:1055
--Type <RET> for more, q to quit, c to continue without paging--c
#56 0x00000000005fb30f in eval_sub (form=<optimized out>) at
/home/exec/Projects/git.savannah.gnu.org/git/emacs/src/eval.c:2570
#57 0x00000000005fbed1 in Fprogn (body=<optimized out>) at
/home/exec/Projects/git.savannah.gnu.org/git/emacs/src/eval.c:452
#58 funcall_lambda (fun=XIL(0x7f35dd31ce05), nargs=<optimized out>,
arg_vector=<optimized out>) at
/home/exec/Projects/git.savannah.gnu.org/git/emacs/src/eval.c:3371
#59 0x00000000005fd7b5 in apply_lambda (fun=XIL(0x7f35dd31ce05),
args=<optimized out>, count=count@entry=...) at
/home/exec/Projects/git.savannah.gnu.org/git/emacs/src/eval.c:3236
#60 0x00000000005fac33 in eval_sub (form=<optimized out>) at
/home/exec/Projects/git.savannah.gnu.org/git/emacs/src/eval.c:2708
#61 0x00000000005eae11 in For (args=<optimized out>) at
/home/exec/Projects/git.savannah.gnu.org/git/emacs/src/eval.c:365
#62 0x00000000005fb30f in eval_sub (form=<optimized out>) at
/home/exec/Projects/git.savannah.gnu.org/git/emacs/src/eval.c:2570
#63 0x00000000005fbed1 in Fprogn (body=<optimized out>) at
/home/exec/Projects/git.savannah.gnu.org/git/emacs/src/eval.c:452
#64 funcall_lambda (fun=XIL(0x7f363f8c814d), nargs=<optimized out>,
arg_vector=<optimized out>) at
/home/exec/Projects/git.savannah.gnu.org/git/emacs/src/eval.c:3371
#65 0x00000000005fc7d0 in Ffuncall (nargs=2, args=0x7fff38d048a0) at
/home/exec/Projects/git.savannah.gnu.org/git/emacs/src/eval.c:3114
#66 0x00000000005ff3f7 in mapcar1 (leni=leni@entry=1,
vals=vals@entry=0x7fff38d04900, fn=fn@entry=XIL(0x7f363f8c814d),
seq=seq@entry=XIL(0x7f363f8c32db))
at /home/exec/Projects/git.savannah.gnu.org/git/emacs/src/fns.c:3369
#67 0x00000000005ff729 in Fmapcar (function=XIL(0x7f363f8c814d),
sequence=XIL(0x7f363f8c32db)) at
/home/exec/Projects/git.savannah.gnu.org/git/emacs/src/fns.c:3489
#68 0x00000000005fb4b0 in eval_sub (form=<optimized out>) at
/home/exec/Projects/git.savannah.gnu.org/git/emacs/src/eval.c:2622
#69 0x00000000005fbed1 in Fprogn (body=<optimized out>) at
/home/exec/Projects/git.savannah.gnu.org/git/emacs/src/eval.c:452
#70 funcall_lambda (fun=XIL(0x7f35dd31c3f5), nargs=<optimized out>,
arg_vector=<optimized out>) at
/home/exec/Projects/git.savannah.gnu.org/git/emacs/src/eval.c:3371
#71 0x00000000005fd7b5 in apply_lambda (fun=XIL(0x7f35dd31c3f5),
args=<optimized out>, count=count@entry=...) at
/home/exec/Projects/git.savannah.gnu.org/git/emacs/src/eval.c:3236
#72 0x00000000005fac33 in eval_sub (form=<optimized out>) at
/home/exec/Projects/git.savannah.gnu.org/git/emacs/src/eval.c:2708
#73 0x00000000005eadd1 in Fprogn (body=<optimized out>) at
/home/exec/Projects/git.savannah.gnu.org/git/emacs/src/eval.c:452
#74 0x00000000005fb30f in eval_sub (form=<optimized out>) at
/home/exec/Projects/git.savannah.gnu.org/git/emacs/src/eval.c:2570
#75 0x00000000005fb30f in eval_sub (form=<optimized out>) at
/home/exec/Projects/git.savannah.gnu.org/git/emacs/src/eval.c:2570
#76 0x00000000005ec449 in Fprogn (body=<optimized out>) at
/home/exec/Projects/git.savannah.gnu.org/git/emacs/src/eval.c:452
#77 Flet (args=XIL(0x7f35dd32715b)) at
/home/exec/Projects/git.savannah.gnu.org/git/emacs/src/eval.c:1122
#78 0x00000000005fb30f in eval_sub (form=<optimized out>) at
/home/exec/Projects/git.savannah.gnu.org/git/emacs/src/eval.c:2570
#79 0x00000000005fb30f in eval_sub (form=<optimized out>) at
/home/exec/Projects/git.savannah.gnu.org/git/emacs/src/eval.c:2570
#80 0x00000000005ec449 in Fprogn (body=<optimized out>) at
/home/exec/Projects/git.savannah.gnu.org/git/emacs/src/eval.c:452
#81 Flet (args=XIL(0x7f35dd324633)) at
/home/exec/Projects/git.savannah.gnu.org/git/emacs/src/eval.c:1122
#82 0x00000000005fb30f in eval_sub (form=<optimized out>) at
/home/exec/Projects/git.savannah.gnu.org/git/emacs/src/eval.c:2570
#83 0x00000000005ebea1 in Fprogn (body=<optimized out>) at
/home/exec/Projects/git.savannah.gnu.org/git/emacs/src/eval.c:452
#84 FletX (args=<optimized out>) at
/home/exec/Projects/git.savannah.gnu.org/git/emacs/src/eval.c:1055
#85 0x00000000005fb30f in eval_sub (form=<optimized out>) at
/home/exec/Projects/git.savannah.gnu.org/git/emacs/src/eval.c:2570
#86 0x00000000005ec449 in Fprogn (body=<optimized out>) at
/home/exec/Projects/git.savannah.gnu.org/git/emacs/src/eval.c:452
#87 Flet (args=XIL(0x7f35dd3228d3)) at
/home/exec/Projects/git.savannah.gnu.org/git/emacs/src/eval.c:1122
#88 0x00000000005fb30f in eval_sub (form=<optimized out>) at
/home/exec/Projects/git.savannah.gnu.org/git/emacs/src/eval.c:2570
#89 0x00000000005fbed1 in Fprogn (body=<optimized out>) at
/home/exec/Projects/git.savannah.gnu.org/git/emacs/src/eval.c:452
#90 funcall_lambda (fun=XIL(0x7f35dd321bd5), nargs=<optimized out>,
arg_vector=<optimized out>) at
/home/exec/Projects/git.savannah.gnu.org/git/emacs/src/eval.c:3371
#91 0x00000000005fd7b5 in apply_lambda (fun=XIL(0x7f35dd321bd5),
args=<optimized out>, count=count@entry=...) at
/home/exec/Projects/git.savannah.gnu.org/git/emacs/src/eval.c:3236
#92 0x00000000005fac33 in eval_sub (form=<optimized out>) at
/home/exec/Projects/git.savannah.gnu.org/git/emacs/src/eval.c:2708
#93 0x00000000005eae11 in For (args=<optimized out>) at
/home/exec/Projects/git.savannah.gnu.org/git/emacs/src/eval.c:365
#94 0x00000000005fb30f in eval_sub (form=<optimized out>) at
/home/exec/Projects/git.savannah.gnu.org/git/emacs/src/eval.c:2570
#95 0x00000000005eb853 in Fsetq (args=<optimized out>) at
/home/exec/Projects/git.savannah.gnu.org/git/emacs/src/eval.c:499
#96 0x00000000005fb30f in eval_sub (form=<optimized out>) at
/home/exec/Projects/git.savannah.gnu.org/git/emacs/src/eval.c:2570
#97 0x00000000005eb1f2 in Fif (args=XIL(0x7f364c7cc39b)) at
/home/exec/Projects/git.savannah.gnu.org/git/emacs/src/eval.c:404
#98 0x00000000005fb30f in eval_sub (form=<optimized out>) at
/home/exec/Projects/git.savannah.gnu.org/git/emacs/src/eval.c:2570
#99 0x00000000005eb321 in Fprogn (body=<optimized out>) at
/home/exec/Projects/git.savannah.gnu.org/git/emacs/src/eval.c:452
#100 Fcond (args=<optimized out>) at
/home/exec/Projects/git.savannah.gnu.org/git/emacs/src/eval.c:432
#101 0x00000000005fb30f in eval_sub (form=<optimized out>) at
/home/exec/Projects/git.savannah.gnu.org/git/emacs/src/eval.c:2570
#102 0x00000000005ec449 in Fprogn (body=<optimized out>) at
/home/exec/Projects/git.savannah.gnu.org/git/emacs/src/eval.c:452
#103 Flet (args=XIL(0x7f364c7cc12b)) at
/home/exec/Projects/git.savannah.gnu.org/git/emacs/src/eval.c:1122
#104 0x00000000005fb30f in eval_sub (form=<optimized out>) at
/home/exec/Projects/git.savannah.gnu.org/git/emacs/src/eval.c:2570
#105 0x00000000005eadd1 in Fprogn (body=<optimized out>) at
/home/exec/Projects/git.savannah.gnu.org/git/emacs/src/eval.c:452
#106 0x00000000005fb30f in eval_sub (form=<optimized out>) at
/home/exec/Projects/git.savannah.gnu.org/git/emacs/src/eval.c:2570
#107 0x00000000005fb30f in eval_sub (form=<optimized out>) at
/home/exec/Projects/git.savannah.gnu.org/git/emacs/src/eval.c:2570
#108 0x00000000005fbed1 in Fprogn (body=<optimized out>) at
/home/exec/Projects/git.savannah.gnu.org/git/emacs/src/eval.c:452
#109 funcall_lambda (fun=XIL(0x7f364c7ca405), nargs=<optimized out>,
arg_vector=<optimized out>) at
/home/exec/Projects/git.savannah.gnu.org/git/emacs/src/eval.c:3371
#110 0x00000000005fc7d0 in Ffuncall (nargs=nargs@entry=1,
args=args@entry=0x7fff38d05c90) at
/home/exec/Projects/git.savannah.gnu.org/git/emacs/src/eval.c:3114
#111 0x00000000005fd0d8 in Fapply (nargs=2, args=0x7fff38d05c90) at
/home/exec/Projects/git.savannah.gnu.org/git/emacs/src/eval.c:2739
#112 0x00007f364fb3c552 in
F6c7370406d616769742d66696e642d66696c65_lspmagit_find_file_0 () from
/home/exec/.emacs.d/eln-cache/31.0.50-9d7890e6/magit-files-f4ea0232-65a60fcb.eln
#113 0x00000000005fc7d0 in Ffuncall (nargs=nargs@entry=2,
args=args@entry=0x7f366d5ff0c8) at
/home/exec/Projects/git.savannah.gnu.org/git/emacs/src/eval.c:3114
#114 0x00000000005fd0d8 in Fapply (nargs=3, args=0x7f366d5ff0c8) at
/home/exec/Projects/git.savannah.gnu.org/git/emacs/src/eval.c:2739
#115 0x0000000000649930 in exec_byte_code (fun=<optimized out>,
args_template=<optimized out>, nargs=<optimized out>, args=<optimized
out>) at /home/exec/Projects/git.savannah.gnu.org/git/emacs/src/lisp.h:2322
#116 0x00000000005fd7b5 in apply_lambda (fun=XIL(0x7f364c7c58ed),
args=<optimized out>, count=count@entry=...) at
/home/exec/Projects/git.savannah.gnu.org/git/emacs/src/eval.c:3236
#117 0x00000000005fac33 in eval_sub (form=<optimized out>) at
/home/exec/Projects/git.savannah.gnu.org/git/emacs/src/eval.c:2708
#118 0x00000000005fb30f in eval_sub (form=<optimized out>) at
/home/exec/Projects/git.savannah.gnu.org/git/emacs/src/eval.c:2570
#119 0x00000000005eadd1 in Fprogn (body=<optimized out>) at
/home/exec/Projects/git.savannah.gnu.org/git/emacs/src/eval.c:452
#120 0x00000000005fb30f in eval_sub (form=<optimized out>) at
/home/exec/Projects/git.savannah.gnu.org/git/emacs/src/eval.c:2570
#121 0x00000000005fb30f in eval_sub (form=<optimized out>) at
/home/exec/Projects/git.savannah.gnu.org/git/emacs/src/eval.c:2570
#122 0x00000000005fbed1 in Fprogn (body=<optimized out>) at
/home/exec/Projects/git.savannah.gnu.org/git/emacs/src/eval.c:452
#123 funcall_lambda (fun=XIL(0x7f35cd2a9fdd), nargs=<optimized out>,
arg_vector=<optimized out>) at
/home/exec/Projects/git.savannah.gnu.org/git/emacs/src/eval.c:3371
#124 0x00000000005fd7b5 in apply_lambda (fun=XIL(0x7f35cd2a9fdd),
args=<optimized out>, count=count@entry=...) at
/home/exec/Projects/git.savannah.gnu.org/git/emacs/src/eval.c:3236
#125 0x00000000005fac33 in eval_sub (form=<optimized out>) at
/home/exec/Projects/git.savannah.gnu.org/git/emacs/src/eval.c:2708
#126 0x00000000005e1fd1 in Fprogn (body=<optimized out>) at
/home/exec/Projects/git.savannah.gnu.org/git/emacs/src/eval.c:452
#127 Fsave_current_buffer (args=<optimized out>) at
/home/exec/Projects/git.savannah.gnu.org/git/emacs/src/editfns.c:852
#128 0x00000000005fb30f in eval_sub (form=<optimized out>) at
/home/exec/Projects/git.savannah.gnu.org/git/emacs/src/eval.c:2570
#129 0x00000000005eadd1 in Fprogn (body=<optimized out>) at
/home/exec/Projects/git.savannah.gnu.org/git/emacs/src/eval.c:452
#130 0x00000000005fb30f in eval_sub (form=<optimized out>) at
/home/exec/Projects/git.savannah.gnu.org/git/emacs/src/eval.c:2570
#131 0x00000000005fb30f in eval_sub (form=<optimized out>) at
/home/exec/Projects/git.savannah.gnu.org/git/emacs/src/eval.c:2570
#132 0x00000000005ec449 in Fprogn (body=<optimized out>) at
/home/exec/Projects/git.savannah.gnu.org/git/emacs/src/eval.c:452
#133 Flet (args=XIL(0x7f358e57770b)) at
/home/exec/Projects/git.savannah.gnu.org/git/emacs/src/eval.c:1122
#134 0x00000000005fb30f in eval_sub (form=<optimized out>) at
/home/exec/Projects/git.savannah.gnu.org/git/emacs/src/eval.c:2570
#135 0x00000000005eb6c1 in Fprogn (body=<optimized out>) at
/home/exec/Projects/git.savannah.gnu.org/git/emacs/src/eval.c:452
#136 prog_ignore (body=<optimized out>) at
/home/exec/Projects/git.savannah.gnu.org/git/emacs/src/eval.c:463
#137 Fwhile (args=<optimized out>) at
/home/exec/Projects/git.savannah.gnu.org/git/emacs/src/eval.c:1143
#138 0x00000000005fb30f in eval_sub (form=<optimized out>) at
/home/exec/Projects/git.savannah.gnu.org/git/emacs/src/eval.c:2570
#139 0x00000000005ec449 in Fprogn (body=<optimized out>) at
/home/exec/Projects/git.savannah.gnu.org/git/emacs/src/eval.c:452
#140 Flet (args=XIL(0x7f358e577673)) at
/home/exec/Projects/git.savannah.gnu.org/git/emacs/src/eval.c:1122
#141 0x00000000005fb30f in eval_sub (form=<optimized out>) at
/home/exec/Projects/git.savannah.gnu.org/git/emacs/src/eval.c:2570
#142 0x00000000005ebea1 in Fprogn (body=<optimized out>) at
/home/exec/Projects/git.savannah.gnu.org/git/emacs/src/eval.c:452
#143 FletX (args=<optimized out>) at
/home/exec/Projects/git.savannah.gnu.org/git/emacs/src/eval.c:1055
#144 0x00000000005fb30f in eval_sub (form=<optimized out>) at
/home/exec/Projects/git.savannah.gnu.org/git/emacs/src/eval.c:2570
#145 0x00000000005fbed1 in Fprogn (body=<optimized out>) at
/home/exec/Projects/git.savannah.gnu.org/git/emacs/src/eval.c:452
#146 funcall_lambda (fun=XIL(0x7f358e5774fd), nargs=<optimized out>,
arg_vector=<optimized out>) at
/home/exec/Projects/git.savannah.gnu.org/git/emacs/src/eval.c:3371
#147 0x00000000005fc7d0 in Ffuncall (nargs=1, args=0x7fff38d06db8) at
/home/exec/Projects/git.savannah.gnu.org/git/emacs/src/eval.c:3114
#148 0x00000000005eb61e in Ffuncall_interactively (nargs=1,
args=0x7fff38d06db8) at
/home/exec/Projects/git.savannah.gnu.org/git/emacs/src/callint.c:250
#149 0x00000000005fc7d0 in Ffuncall (nargs=nargs@entry=2,
args=args@entry=0x7fff38d06db0) at
/home/exec/Projects/git.savannah.gnu.org/git/emacs/src/eval.c:3114
#150 0x00000000005fd0d8 in Fapply (nargs=3, args=0x7fff38d06db0) at
/home/exec/Projects/git.savannah.gnu.org/git/emacs/src/eval.c:2739
#151 0x00000000005f4814 in Fcall_interactively
(function=XIL(0x7f3607c59850), record_flag=XIL(0x12670),
keys=XIL(0x7f35e6269b95)) at
/home/exec/Projects/git.savannah.gnu.org/git/emacs/src/callint.c:342
#152 0x00007f366e40d885 in F636f6d6d616e642d65786563757465_command_execute_0 ()
from /home/exec/Projects/git.savannah.gnu.org/git/emacs-build/scratch_igc/bin/../lib/emacs/31.0.50/native-lisp/31.0.50-9d7890e6/preloaded/simple-fab5b0cf-6cd62745.eln
#153 0x00000000005fc7d0 in Ffuncall (nargs=3, args=0x7fff38d06fb0) at
/home/exec/Projects/git.savannah.gnu.org/git/emacs/src/eval.c:3114
#154 0x00007f366e40c6e9 in
F657865637574652d657874656e6465642d636f6d6d616e64_execute_extended_command_0
()
from /home/exec/Projects/git.savannah.gnu.org/git/emacs-build/scratch_igc/bin/../lib/emacs/31.0.50/native-lisp/31.0.50-9d7890e6/preloaded/simple-fab5b0cf-6cd62745.eln
#155 0x0000000000649930 in exec_byte_code (fun=<optimized out>,
args_template=<optimized out>, nargs=<optimized out>, args=<optimized
out>) at /home/exec/Projects/git.savannah.gnu.org/git/emacs/src/lisp.h:2322
#156 0x00000000005fc336 in funcall_lambda (fun=XIL(0x7f35ee62a6f5),
nargs=<optimized out>, arg_vector=<optimized out>) at
/home/exec/Projects/git.savannah.gnu.org/git/emacs/src/eval.c:3373
#157 0x00000000005fc7d0 in Ffuncall (nargs=nargs@entry=5,
args=0x7fff38d072d0) at
/home/exec/Projects/git.savannah.gnu.org/git/emacs/src/eval.c:3114
#158 0x00000000005fcef4 in Fapply (nargs=3, args=0x7f366d5ff040) at
/home/exec/Projects/git.savannah.gnu.org/git/emacs/src/eval.c:2786
#159 0x0000000000649930 in exec_byte_code (fun=<optimized out>,
args_template=<optimized out>, nargs=<optimized out>, args=<optimized
out>) at /home/exec/Projects/git.savannah.gnu.org/git/emacs/src/lisp.h:2322
#160 0x00000000005fc7d0 in Ffuncall (nargs=4, args=0x7fff38d075b8) at
/home/exec/Projects/git.savannah.gnu.org/git/emacs/src/eval.c:3114
#161 0x00000000005eb61e in Ffuncall_interactively (nargs=4,
args=0x7fff38d075b8) at
/home/exec/Projects/git.savannah.gnu.org/git/emacs/src/callint.c:250
#162 0x00000000005fc7d0 in Ffuncall (nargs=nargs@entry=5,
args=0x7fff38d075b0) at
/home/exec/Projects/git.savannah.gnu.org/git/emacs/src/eval.c:3114
#163 0x00000000005fcef4 in Fapply (nargs=3, args=0x7fff38d07740) at
/home/exec/Projects/git.savannah.gnu.org/git/emacs/src/eval.c:2786
#164 0x00000000005f4814 in Fcall_interactively
(function=XIL(0x7f360d412818), record_flag=XIL(0),
keys=XIL(0x7f35e49b2ef5)) at
/home/exec/Projects/git.savannah.gnu.org/git/emacs/src/callint.c:342
#165 0x00007f366e40d885 in F636f6d6d616e642d65786563757465_command_execute_0 ()
from /home/exec/Projects/git.savannah.gnu.org/git/emacs-build/scratch_igc/bin/../lib/emacs/31.0.50/native-lisp/31.0.50-9d7890e6/preloaded/simple-fab5b0cf-6cd62745.eln
#166 0x00000000005fc7d0 in Ffuncall (nargs=2, args=0x7fff38d07950) at
/home/exec/Projects/git.savannah.gnu.org/git/emacs/src/eval.c:3114
#167 0x0000000000561ccd in command_loop_1 () at
/home/exec/Projects/git.savannah.gnu.org/git/emacs/src/keyboard.c:1561
#168 0x00000000005f6ed7 in internal_condition_case (bfun=0x561870
<command_loop_1>, handlers=<optimized out>, hfun=0x5601e0 <cmd_error>)
at /home/exec/Projects/git.savannah.gnu.org/git/emacs/src/eval.c:1633
#169 0x000000000055e196 in command_loop_2
(handlers=handlers@entry=XIL(0xa8)) at
/home/exec/Projects/git.savannah.gnu.org/git/emacs/src/keyboard.c:1179
#170 0x00000000005f6e31 in internal_catch (tag=<optimized out>,
func=0x55e170 <command_loop_2>, arg=XIL(0xa8)) at
/home/exec/Projects/git.savannah.gnu.org/git/emacs/src/eval.c:1312
#171 0x0000000000561831 in command_loop () at
/home/exec/Projects/git.savannah.gnu.org/git/emacs/src/keyboard.c:1157
#172 0x00000000006d9646 in recursive_edit_1.isra.0 () at
/home/exec/Projects/git.savannah.gnu.org/git/emacs/src/keyboard.c:765
#173 0x00000000005661a0 in Frecursive_edit () at
/home/exec/Projects/git.savannah.gnu.org/git/emacs/src/keyboard.c:848
#174 0x0000000000433189 in main (argc=<optimized out>,
argv=0x7fff38d07e88) at
/home/exec/Projects/git.savannah.gnu.org/git/emacs/src/emacs.c:2646
You can't do that without a process to debug.
(gdb)
```
What information should I provide to help investigating this crash?
Thank you
^ permalink raw reply related [flat|nested] 15+ messages in thread
* Re: Emacs [scratch/igc 6682d0e6c96] crash on Linux 6.6.41 KDE 6.0.5, wayland
2024-09-02 12:24 Emacs [scratch/igc 6682d0e6c96] crash on Linux 6.6.41 KDE 6.0.5, wayland Eval Exec
@ 2024-09-02 13:06 ` Eli Zaretskii
2024-09-02 13:08 ` Eval EXEC
2024-09-02 16:41 ` Pip Cet
1 sibling, 1 reply; 15+ messages in thread
From: Eli Zaretskii @ 2024-09-02 13:06 UTC (permalink / raw)
To: Eval Exec; +Cc: emacs-devel
> From: Eval Exec <execvy@gmail.com>
> Date: Mon, 2 Sep 2024 20:24:25 +0800
>
> Hello,
> I'm helping to test scratch/igc branch on my local environment:
> ```
> ❯ uname -a
> Linux Matrix 6.6.41 #1-NixOS SMP PREEMPT_DYNAMIC Thu Jul 18 11:21:27
> UTC 2024 x86_64 GNU/Linux
> ```
>
> I get the source code of scratch/igc, commit hash: 6682d0e6c96 .
> And I append a new commit:
> ```
> diff --git a/src/igc.c b/src/igc.c
> index f069a2becc9..4d792da75c8 100644
> --- a/src/igc.c
> +++ b/src/igc.c
> @@ -4459,7 +4459,7 @@ make_arena (struct igc *gc)
> MPS_ARGS_END (args);
> IGC_CHECK_RES (res);
>
> - mps_gen_param_s gens[] = { { 128000, 0.8 }, { 5 * 128000, 0.4 } };
> + mps_gen_param_s gens[] = { { 128000000, 0.8 }, { 5 * 128000000, 0.4 } };
> res = mps_chain_create (&gc->chain, gc->arena, ARRAYELTS (gens), gens);
> IGC_CHECK_RES (res);
> }
AFAIU, the above requests MPS to create a generation chain whose
capacity is 128GB. How much memory do you have on that system?
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Emacs [scratch/igc 6682d0e6c96] crash on Linux 6.6.41 KDE 6.0.5, wayland
2024-09-02 13:06 ` Eli Zaretskii
@ 2024-09-02 13:08 ` Eval EXEC
0 siblings, 0 replies; 15+ messages in thread
From: Eval EXEC @ 2024-09-02 13:08 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: emacs-devel
[-- Attachment #1: Type: text/plain, Size: 1485 bytes --]
My total memory is 48GB*2 memory:
```
❯ free -h
total used free shared buff/cache
available
Mem: 93Gi 6.8Gi 75Gi 2.8Gi 12Gi 83Gi
Swap: 95Gi 1.5Gi 94Gi
```
Thank you, I should decrease `mps_gen_param_s` to use less memory.
On 9/2/24 21:06, Eli Zaretskii wrote:
>> From: Eval Exec<execvy@gmail.com>
>> Date: Mon, 2 Sep 2024 20:24:25 +0800
>>
>> Hello,
>> I'm helping to test scratch/igc branch on my local environment:
>> ```
>> ❯ uname -a
>> Linux Matrix 6.6.41 #1-NixOS SMP PREEMPT_DYNAMIC Thu Jul 18 11:21:27
>> UTC 2024 x86_64 GNU/Linux
>> ```
>>
>> I get the source code of scratch/igc, commit hash: 6682d0e6c96 .
>> And I append a new commit:
>> ```
>> diff --git a/src/igc.c b/src/igc.c
>> index f069a2becc9..4d792da75c8 100644
>> --- a/src/igc.c
>> +++ b/src/igc.c
>> @@ -4459,7 +4459,7 @@ make_arena (struct igc *gc)
>> MPS_ARGS_END (args);
>> IGC_CHECK_RES (res);
>>
>> - mps_gen_param_s gens[] = { { 128000, 0.8 }, { 5 * 128000, 0.4 } };
>> + mps_gen_param_s gens[] = { { 128000000, 0.8 }, { 5 * 128000000, 0.4 } };
>> res = mps_chain_create (&gc->chain, gc->arena, ARRAYELTS (gens), gens);
>> IGC_CHECK_RES (res);
>> }
> AFAIU, the above requests MPS to create a generation chain whose
> capacity is 128GB. How much memory do you have on that system?
[-- Attachment #2: Type: text/html, Size: 2093 bytes --]
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Emacs [scratch/igc 6682d0e6c96] crash on Linux 6.6.41 KDE 6.0.5, wayland
2024-09-02 12:24 Emacs [scratch/igc 6682d0e6c96] crash on Linux 6.6.41 KDE 6.0.5, wayland Eval Exec
2024-09-02 13:06 ` Eli Zaretskii
@ 2024-09-02 16:41 ` Pip Cet
2024-09-03 1:10 ` execvy
1 sibling, 1 reply; 15+ messages in thread
From: Pip Cet @ 2024-09-02 16:41 UTC (permalink / raw)
To: Eval Exec; +Cc: emacs-devel
"Eval Exec" <execvy@gmail.com> writes:
> Hello,
> I'm helping to test scratch/igc branch on my local environment:
Thank you!
> ```
> ❯ uname -a
> Linux Matrix 6.6.41 #1-NixOS SMP PREEMPT_DYNAMIC Thu Jul 18 11:21:27
> UTC 2024 x86_64 GNU/Linux
> ```
>
> I get the source code of scratch/igc, commit hash: 6682d0e6c96 .
> And I append a new commit:
> ```
> diff --git a/src/igc.c b/src/igc.c
> index f069a2becc9..4d792da75c8 100644
> --- a/src/igc.c
> +++ b/src/igc.c
> @@ -4459,7 +4459,7 @@ make_arena (struct igc *gc)
> MPS_ARGS_END (args);
> IGC_CHECK_RES (res);
>
> - mps_gen_param_s gens[] = { { 128000, 0.8 }, { 5 * 128000, 0.4 } };
> + mps_gen_param_s gens[] = { { 128000000, 0.8 }, { 5 * 128000000, 0.4 } };
> res = mps_chain_create (&gc->chain, gc->arena, ARRAYELTS (gens), gens);
> IGC_CHECK_RES (res);
> }
> ```
Those numbers are in kilobytes, so that requests 640 gigabytes of memory
before it'll even start collecting in earnest. In theory, that should
work given enough RAM or swap, but I doubt anyone's tested MPS with such
extreme settings.
> Then, I compile it by:
> ```
> make extraclean
> ./autogen.sh \
> && ./configure \
> --prefix=$(realpath ../emacs-build/$(git branch --show-current | sed
> 's/\//_/g'))\
> --with-mps=yes \
> --with-imagemagick \
> --with-modules --with-x-toolkit=gtk3 --without-compress-install \
> --without-toolkit-scroll-bars --with-native-compilation --with-mailutils\
> --enable-link-time-optimization \
> --with-tree-sitter --with-xinput2 \
> --with-dbus --with-native-compilation=aot \
> --with-file-notification=inotify\
> && make -j30 install
> ```
>
> When I launch the emacs, editing rust files, emacs crashed. the
> backtrace is:
How much memory was it using at the time? To me it looks conceivable
the crash happened because we failed to get enough memory for a new
stack frame, but if it's reproducible or happens again after reducing
the generation sizes, we need to investigate it further.
> ```
> (gdb) source /home/exec/Projects/git.savannah.gnu.org/git/emacs/src/.gdbinit
> warning: /home/exec/Projects/git.savannah.gnu.org/git/emacs/../lwlib:
> No such file or directory
> SIGINT is used by the debugger.
> Are you sure you want to change it? (y or n) [answered Y; input not
> from terminal]
> DISPLAY = :0
> TERM = tmux-256color
> Breakpoint 1 at 0x428ca7: file
> /home/exec/Projects/git.savannah.gnu.org/git/emacs/src/emacs.c, line
> 432.
> Breakpoint 2 at 0x52db40: file
> /home/exec/Projects/git.savannah.gnu.org/git/emacs/src/xterm.c, line
> 27126.
> (gdb) bt
> #0 0x00007f36826a2efc in __pthread_kill_implementation () from
> /nix/store/dbcw19dshdwnxdv5q2g6wldj6syyvq7l-glibc-2.39-52/lib/libc.so.6
> #1 0x00007f3682652e86 in raise () from
> /nix/store/dbcw19dshdwnxdv5q2g6wldj6syyvq7l-glibc-2.39-52/lib/libc.so.6
> #2 0x0000000000428d5a in terminate_due_to_signal (sig=11,
> backtrace_limit=<optimized out>) at
> /home/exec/Projects/git.savannah.gnu.org/git/emacs/src/emacs.c:470
> #3 0x0000000000429579 in handle_fatal_signal (sig=<optimized out>) at
> /home/exec/Projects/git.savannah.gnu.org/git/emacs/src/sysdep.c:1800
> #4 0x00000000006c5a68 in deliver_thread_signal.constprop.0 (sig=11,
> handler=<optimized out>) at
> /home/exec/Projects/git.savannah.gnu.org/git/emacs/src/sysdep.c:1792
> #5 <signal handler called>
> #6 0x00007f368265316b in kill () from
> /nix/store/dbcw19dshdwnxdv5q2g6wldj6syyvq7l-glibc-2.39-52/lib/libc.so.6
> #7 0x00000000007551e9 in sigHandle ()
> #8 <signal handler called>
> #9 indirect_function (object=XIL(0)) at
> /home/exec/Projects/git.savannah.gnu.org/git/emacs/src/lisp.h:1198
It would be good to know whether 'object' is actually nil in this case
(in which case lisp.h:1198 is wrong) or whether the nil is wrong (and
the lisp.h:1198, possibly, correct), but I suspect the best bet is to
reduce the generation chain sizes and try again.
> What information should I provide to help investigating this crash?
Trying again with a more moderate generation size would be ideal, but
you might want to run Emacs in GDB and keep it connected after a crash
so we can investigate further.
Thanks again
Pip
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Emacs [scratch/igc 6682d0e6c96] crash on Linux 6.6.41 KDE 6.0.5, wayland
2024-09-02 16:41 ` Pip Cet
@ 2024-09-03 1:10 ` execvy
2024-09-03 3:33 ` Eval EXEC
2024-09-03 10:57 ` Pip Cet
0 siblings, 2 replies; 15+ messages in thread
From: execvy @ 2024-09-03 1:10 UTC (permalink / raw)
To: Pip Cet, emacs-devel
Hello
After I change `mps_gen_param_s gens[] = { { 128000, 0.8 }, { 5 * 128000, 0.4 } };`
to `mps_gen_param_s gens[] = { { 12800000, 0.8 }, { 5 * 12800000, 0.4 } };`, the Emacs never crash again.
And it's RES mem is 2661M, I think it's good, I'm editing 2000 rust files in Emacs with rust-analyzer lsp server. 99% of time I don't feel GC's lag.
But, When I hit `Ctrl + right click`, I feel a very long GC lag ( > 10 seconds). It's reproducible.
So I profiler-start, then `Ctrl + right click`, then `profiler-stop`, got:
```
14726 58% Automatic GC
10528 41% - help-command-error-confusable-suggestions
10528 41% - debug
10528 41% - recursive-edit
391 1% - substitute-command-keys
134 0% - #<byte-code-function 6991>
134 0% - kill-buffer
102 0% tabspaces--local-buffer-p
6 0% - replace-buffer-in-windows
3 0% - unrecord-window-buffer
1 0% window-normalize-window
1 0% window-normalize-buffer
19 0% generate-new-buffer
16 0% text-quoting-style
332 1% - redisplay_internal (C function)
18 0% - eval
11 0% - mode--line-format-right-align
6 0% string-pixel-width
1 0% - eval
1 0% - minions--prominent-modes
1 0% - cl-remove-if-not
1 0% cl-remove
5 0% - breadcrumb--header-line
4 0% - funcall
2 0% - breadcrumb-imenu-crumbs
2 0% - let
2 0% - which-function
2 0% - add-log-current-defun
2 0% - treesit-add-log-current-defun
1 0% - treesit-defun-at-point
1 0% - treesit-thing-at-point
1 0% treesit-thing-at
1 0% - treesit-defun-name
1 0% rust-ts-mode--defun-name
2 0% - breadcrumb-project-crumbs
2 0% - breadcrumb--project-crumbs-1
1 0% - file-relative-name
1 0% - apply
1 0% - #<interpreted-function 782>
1 0% - my-cacheable-file-relative-name
1 0% let
1 0% breadcrumb--format-project-node
1 0% - minions--prominent-modes
1 0% - cl-remove-if-not
1 0% - cl-remove
1 0% #<native-comp-function F616e6f6e796d6f75732d6c616d626461_anonymous_lambda_8>
1 0% - if
1 0% frame-parameter
2 0% - tab-bar-make-keymap
2 0% - tab-bar-make-keymap-1
2 0% - tab-bar-format-list
2 0% - #<byte-code-function 18B>
1 0% - tab-bar-format-tabs
1 0% - #<byte-code-function 11D>
1 0% tab-bar--format-tab
1 0% - tab-bar-format-align-right
1 0% - tab-bar-format-list
1 0% - #<byte-code-function 118B>
1 0% - keycast-tab-bar
1 0% - keycast--format
1 0% format-spec
1 0% - redisplay--pre-redisplay-functions
1 0% - run-hook-with-args
1 0% - redisplay--update-region-highlight
1 0% #<advice 250>
84 0% keymap-canonicalize
69 0% - #<byte-code-function 9CC>
68 0% - easy-menu-filter-return
68 0% - easy-menu-create-menu
67 0% easy-menu-convert-item
1 0% - recentf-make-menu-items
1 0% - mapcar
1 0% recentf-make-default-menu-element
16 0% - timer-event-handler
14 0% - apply
8 0% - #<native-comp-function F616e6f6e796d6f75732d6c616d626461_anonymous_lambda_9>
8 0% jit-lock-context-fontify
3 0% - diff-hl-flydiff-update
1 0% - diff-hl-update
1 0% - diff-hl--update
1 0% diff-hl-remove-overlays
2 0% - which-key--update
2 0% - which-key--create-buffer-and-show
1 0% - apply
1 0% - message
1 0% - apply
1 0% - ad-Advice-message
1 0% - apply
1 0% #<primitive-function message>
1 0% - which-key--get-bindings
1 0% - which-key--get-current-bindings
1 0% - which-key--get-keymap-bindings
1 0% - which-key--get-keymap-bindings-1
1 0% - #<byte-code-function 515>
1 0% string-match
1 0% - activities-save-all
1 0% - activities--persist
1 0% persist-save
2 0% - timer-inc-time
2 0% timer-relative-time
6 0% - #<interpreted-function 1D9>
6 0% - let
6 0% - while
6 0% - if
6 0% - let*
6 0% - if
6 0% - progn
5 0% - funcall
4 0% - #<interpreted-function 202>
4 0% - funcall
4 0% - #<interpreted-function F7F>
4 0% - if
4 0% - progn
4 0% - funcall
4 0% - #<interpreted-function CCB>
4 0% - save-current-buffer
4 0% - apply
4 0% - #<interpreted-function 4AE>
4 0% - let
3 0% - while
3 0% - let
3 0% - let*
1 0% plist-get
1 0% - lsp--position-to-point
1 0% - let*
1 0% lsp--line-character-to-point
1 0% - lsp--label-from-inlay-hints-response
1 0% - cond
1 0% - string-join
1 0% - mapcar
1 0% - function
1 0% - cconv-make-interpreted-closure
1 0% - macroexpand-all
1 0% - macroexp--expand-all
1 0% - macroexp--all-forms
1 0% macroexp--expand-all
1 0% - let
1 0% - if
1 0% - let
1 0% - let*
1 0% - -filter
1 0% - #<byte-code-function D73>
1 0% - apply
1 0% - lsp--workspace-method-supported?
1 0% - let
1 0% - if
1 0% - or
1 0% - if
1 0% - progn
1 0% - lsp--capability
1 0% if
1 0% - #<interpreted-function 867>
1 0% - funcall
1 0% - #<interpreted-function F0B>
1 0% - if
1 0% - progn
1 0% - funcall
1 0% - #<interpreted-function E7E>
1 0% - save-current-buffer
1 0% - apply
1 0% - #<interpreted-function 4AE>
1 0% - lsp--remove-overlays
1 0% - save-restriction
1 0% remove-overlays
1 0% - condition-case
1 0% - let
1 0% - save-current-buffer
1 0% - unwind-protect
1 0% - and
1 0% - kill-buffer
1 0% - replace-buffer-in-windows
1 0% unrecord-window-buffer
1 0% - or
1 0% - and
1 0% - or
1 0% - not
1 0% verify-visited-file-modtime
1 0% - frame-monitor-workarea
1 0% - frame-monitor-attribute
1 0% display-monitor-attributes-list
1 0% display-line-numbers-update-width
1 0% - winner-save-old-configurations
1 0% winner-remember
1 0% - #:evil-activate-visual-state
1 0% - apply
1 0% - #<native-comp-function F616e6f6e796d6f75732d6c616d626461_anonymous_lambda_10>
1 0% - evil-visual-state
1 0% - evil-normalize-keymaps
1 0% - evil-state-keymaps
1 0% - evil-state-keymaps
1 0% - evil-state-intercept-keymaps
1 0% evil-intercept-keymap-p
0 0% ...
```
Automatic GC take too much times, do you think this is expected?
On 9/3/24 12:41 AM, Pip Cet <pipcet@protonmail.com> wrote:
> "Eval Exec" <execvy@gmail.com> writes:
>
> > Hello,
> > I'm helping to test scratch/igc branch on my local environment:
>
> Thank you!
>
> > ```
> > ❯ uname -a
> > Linux Matrix 6.6.41 #1-NixOS SMP PREEMPT_DYNAMIC Thu Jul 18 11:21:27
> > UTC 2024 x86_64 GNU/Linux
> > ```
> >
> > I get the source code of scratch/igc, commit hash: 6682d0e6c96 .
> > And I append a new commit:
> > ```
> > diff --git a/src/igc.c b/src/igc.c
> > index f069a2becc9..4d792da75c8 100644
> > --- a/src/igc.c
> > +++ b/src/igc.c
> > @@ -4459,7 +4459,7 @@ make_arena (struct igc *gc)
> > MPS_ARGS_END (args);
> > IGC_CHECK_RES (res);
> >
> > - mps_gen_param_s gens[] = { { 128000, 0.8 }, { 5 * 128000, 0.4 } };
> > + mps_gen_param_s gens[] = { { 128000000, 0.8 }, { 5 * 128000000, 0.4 } };
> > res = mps_chain_create (&gc->chain, gc->arena, ARRAYELTS (gens), gens);
> > IGC_CHECK_RES (res);
> > }
> > ```
>
> Those numbers are in kilobytes, so that requests 640 gigabytes of memory
> before it'll even start collecting in earnest. In theory, that should
> work given enough RAM or swap, but I doubt anyone's tested MPS with such
> extreme settings.
>
> > Then, I compile it by:
> > ```
> > make extraclean
> > ./autogen.sh \
> > && ./configure \
> > --prefix=$(realpath ../emacs-build/$(git branch --show-current | sed
> > 's/\//_/g'))\
> > --with-mps=yes \
> > --with-imagemagick \
> > --with-modules --with-x-toolkit=gtk3 --without-compress-install \
> > --without-toolkit-scroll-bars --with-native-compilation --with-mailutils\
> > --enable-link-time-optimization \
> > --with-tree-sitter --with-xinput2 \
> > --with-dbus --with-native-compilation=aot \
> > --with-file-notification=inotify\
> > && make -j30 install
> > ```
> >
> > When I launch the emacs, editing rust files, emacs crashed. the
> > backtrace is:
>
> How much memory was it using at the time? To me it looks conceivable
> the crash happened because we failed to get enough memory for a new
> stack frame, but if it's reproducible or happens again after reducing
> the generation sizes, we need to investigate it further.
>
> > ```
> > (gdb) source /home/exec/Projects/git.savannah.gnu.org/git/emacs/src/.gdbinit
> > warning: /home/exec/Projects/git.savannah.gnu.org/git/emacs/../lwlib:
> > No such file or directory
> > SIGINT is used by the debugger.
> > Are you sure you want to change it? (y or n) [answered Y; input not
> > from terminal]
> > DISPLAY = :0
> > TERM = tmux-256color
> > Breakpoint 1 at 0x428ca7: file
> > /home/exec/Projects/git.savannah.gnu.org/git/emacs/src/emacs.c, line
> > 432.
> > Breakpoint 2 at 0x52db40: file
> > /home/exec/Projects/git.savannah.gnu.org/git/emacs/src/xterm.c, line
> > 27126.
> > (gdb) bt
> > #0 0x00007f36826a2efc in __pthread_kill_implementation () from
> > /nix/store/dbcw19dshdwnxdv5q2g6wldj6syyvq7l-glibc-2.39-52/lib/libc.so.6
> > #1 0x00007f3682652e86 in raise () from
> > /nix/store/dbcw19dshdwnxdv5q2g6wldj6syyvq7l-glibc-2.39-52/lib/libc.so.6
> > #2 0x0000000000428d5a in terminate_due_to_signal (sig=11,
> > backtrace_limit=<optimized out>) at
> > /home/exec/Projects/git.savannah.gnu.org/git/emacs/src/emacs.c:470
> > #3 0x0000000000429579 in handle_fatal_signal (sig=<optimized out>) at
> > /home/exec/Projects/git.savannah.gnu.org/git/emacs/src/sysdep.c:1800
> > #4 0x00000000006c5a68 in deliver_thread_signal.constprop.0 (sig=11,
> > handler=<optimized out>) at
> > /home/exec/Projects/git.savannah.gnu.org/git/emacs/src/sysdep.c:1792
> > #5 <signal handler called>
> > #6 0x00007f368265316b in kill () from
> > /nix/store/dbcw19dshdwnxdv5q2g6wldj6syyvq7l-glibc-2.39-52/lib/libc.so.6
> > #7 0x00000000007551e9 in sigHandle ()
> > #8 <signal handler called>
> > #9 indirect_function (object=XIL(0)) at
> > /home/exec/Projects/git.savannah.gnu.org/git/emacs/src/lisp.h:1198
>
> It would be good to know whether 'object' is actually nil in this case
> (in which case lisp.h:1198 is wrong) or whether the nil is wrong (and
> the lisp.h:1198, possibly, correct), but I suspect the best bet is to
> reduce the generation chain sizes and try again.
>
> > What information should I provide to help investigating this crash?
>
> Trying again with a more moderate generation size would be ideal, but
> you might want to run Emacs in GDB and keep it connected after a crash
> so we can investigate further.
>
> Thanks again
> Pip
>
>
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Emacs [scratch/igc 6682d0e6c96] crash on Linux 6.6.41 KDE 6.0.5, wayland
2024-09-03 1:10 ` execvy
@ 2024-09-03 3:33 ` Eval EXEC
2024-09-03 12:58 ` Eli Zaretskii
2024-09-03 10:57 ` Pip Cet
1 sibling, 1 reply; 15+ messages in thread
From: Eval EXEC @ 2024-09-03 3:33 UTC (permalink / raw)
To: Pip Cet, emacs-devel
When I M-x `menu-bar-mode` to enable menu-bar, the long gc lag (> 10
seconds) happened too.
Then I try `Ctrl + right clock`, then there is no long gc lag (> 10
seconds).
On 9/3/24 09:10, execvy@gmail.com wrote:
> Hello
>
> After I change `mps_gen_param_s gens[] = { { 128000, 0.8 }, { 5 *
> 128000, 0.4 } };`
> to `mps_gen_param_s gens[] = { { 12800000, 0.8 }, { 5 * 12800000, 0.4
> } };`, the Emacs never crash again. And it's RES mem is 2661M, I think
> it's good, I'm editing 2000 rust files in Emacs with rust-analyzer lsp
> server. 99% of time I don't feel GC's lag.
> But, When I hit `Ctrl + right click`, I feel a very long GC lag ( > 10
> seconds). It's reproducible.
> So I profiler-start, then `Ctrl + right click`, then `profiler-stop`,
> got:
> ```
> 14726 58% Automatic GC
> 10528 41% - help-command-error-confusable-suggestions
> 10528 41% - debug
> 10528 41% - recursive-edit
> 391 1% - substitute-command-keys
> 134 0% - #<byte-code-function 6991>
> 134 0% - kill-buffer
> 102 0% tabspaces--local-buffer-p
> 6 0% - replace-buffer-in-windows
> 3 0% - unrecord-window-buffer
> 1 0% window-normalize-window
> 1 0% window-normalize-buffer
> 19 0% generate-new-buffer
> 16 0% text-quoting-style
> 332 1% - redisplay_internal (C function)
> 18 0% - eval
> 11 0% - mode--line-format-right-align
> 6 0% string-pixel-width
> 1 0% - eval
> 1 0% - minions--prominent-modes
> 1 0% - cl-remove-if-not
> 1 0% cl-remove
> 5 0% - breadcrumb--header-line
> 4 0% - funcall
> 2 0% - breadcrumb-imenu-crumbs
> 2 0% - let
> 2 0% - which-function
> 2 0% - add-log-current-defun
> 2 0% - treesit-add-log-current-defun
> 1 0% - treesit-defun-at-point
> 1 0% - treesit-thing-at-point
> 1 0% treesit-thing-at
> 1 0% - treesit-defun-name
> 1 0% rust-ts-mode--defun-name
> 2 0% - breadcrumb-project-crumbs
> 2 0% - breadcrumb--project-crumbs-1
> 1 0% - file-relative-name
> 1 0% - apply
> 1 0% - #<interpreted-function 782>
> 1 0% - my-cacheable-file-relative-name
> 1 0% let
> 1 0% breadcrumb--format-project-node
> 1 0% - minions--prominent-modes
> 1 0% - cl-remove-if-not
> 1 0% - cl-remove
> 1 0% #<native-comp-function
> F616e6f6e796d6f75732d6c616d626461_anonymous_lambda_8>
> 1 0% - if
> 1 0% frame-parameter
> 2 0% - tab-bar-make-keymap
> 2 0% - tab-bar-make-keymap-1
> 2 0% - tab-bar-format-list
> 2 0% - #<byte-code-function 18B>
> 1 0% - tab-bar-format-tabs
> 1 0% - #<byte-code-function 11D>
> 1 0% tab-bar--format-tab
> 1 0% - tab-bar-format-align-right
> 1 0% - tab-bar-format-list
> 1 0% - #<byte-code-function 118B>
> 1 0% - keycast-tab-bar
> 1 0% - keycast--format
> 1 0% format-spec
> 1 0% - redisplay--pre-redisplay-functions
> 1 0% - run-hook-with-args
> 1 0% - redisplay--update-region-highlight
> 1 0% #<advice 250>
> 84 0% keymap-canonicalize
> 69 0% - #<byte-code-function 9CC>
> 68 0% - easy-menu-filter-return
> 68 0% - easy-menu-create-menu
> 67 0% easy-menu-convert-item
> 1 0% - recentf-make-menu-items
> 1 0% - mapcar
> 1 0% recentf-make-default-menu-element
> 16 0% - timer-event-handler
> 14 0% - apply
> 8 0% - #<native-comp-function
> F616e6f6e796d6f75732d6c616d626461_anonymous_lambda_9>
> 8 0% jit-lock-context-fontify
> 3 0% - diff-hl-flydiff-update
> 1 0% - diff-hl-update
> 1 0% - diff-hl--update
> 1 0% diff-hl-remove-overlays
> 2 0% - which-key--update
> 2 0% - which-key--create-buffer-and-show
> 1 0% - apply
> 1 0% - message
> 1 0% - apply
> 1 0% - ad-Advice-message
> 1 0% - apply
> 1 0% #<primitive-function message>
> 1 0% - which-key--get-bindings
> 1 0% - which-key--get-current-bindings
> 1 0% - which-key--get-keymap-bindings
> 1 0% - which-key--get-keymap-bindings-1
> 1 0% - #<byte-code-function 515>
> 1 0% string-match
> 1 0% - activities-save-all
> 1 0% - activities--persist
> 1 0% persist-save
> 2 0% - timer-inc-time
> 2 0% timer-relative-time
> 6 0% - #<interpreted-function 1D9>
> 6 0% - let
> 6 0% - while
> 6 0% - if
> 6 0% - let*
> 6 0% - if
> 6 0% - progn
> 5 0% - funcall
> 4 0% - #<interpreted-function 202>
> 4 0% - funcall
> 4 0% - #<interpreted-function F7F>
> 4 0% - if
> 4 0% - progn
> 4 0% - funcall
> 4 0% - #<interpreted-function CCB>
> 4 0% - save-current-buffer
> 4 0% - apply
> 4 0% - #<interpreted-function 4AE>
> 4 0% - let
> 3 0% - while
> 3 0% - let
> 3 0% - let*
> 1 0% plist-get
> 1 0% - lsp--position-to-point
> 1 0% - let*
> 1 0% lsp--line-character-to-point
> 1 0% -
> lsp--label-from-inlay-hints-response
> 1 0% - cond
> 1 0% - string-join
> 1 0% - mapcar
> 1 0% - function
> 1 0% -
> cconv-make-interpreted-closure
> 1 0% - macroexpand-all
> 1 0% - macroexp--expand-all
> 1 0% - macroexp--all-forms
> 1 0% macroexp--expand-all
> 1 0% - let
> 1 0% - if
> 1 0% - let
> 1 0% - let*
> 1 0% - -filter
> 1 0% - #<byte-code-function D73>
> 1 0% - apply
> 1 0% -
> lsp--workspace-method-supported?
> 1 0% - let
> 1 0% - if
> 1 0% - or
> 1 0% - if
> 1 0% - progn
> 1 0% - lsp--capability
> 1 0% if
> 1 0% - #<interpreted-function 867>
> 1 0% - funcall
> 1 0% - #<interpreted-function F0B>
> 1 0% - if
> 1 0% - progn
> 1 0% - funcall
> 1 0% - #<interpreted-function E7E>
> 1 0% - save-current-buffer
> 1 0% - apply
> 1 0% - #<interpreted-function 4AE>
> 1 0% - lsp--remove-overlays
> 1 0% - save-restriction
> 1 0% remove-overlays
> 1 0% - condition-case
> 1 0% - let
> 1 0% - save-current-buffer
> 1 0% - unwind-protect
> 1 0% - and
> 1 0% - kill-buffer
> 1 0% - replace-buffer-in-windows
> 1 0% unrecord-window-buffer
> 1 0% - or
> 1 0% - and
> 1 0% - or
> 1 0% - not
> 1 0% verify-visited-file-modtime
> 1 0% - frame-monitor-workarea
> 1 0% - frame-monitor-attribute
> 1 0% display-monitor-attributes-list
> 1 0% display-line-numbers-update-width
> 1 0% - winner-save-old-configurations
> 1 0% winner-remember
> 1 0% - #:evil-activate-visual-state
> 1 0% - apply
> 1 0% - #<native-comp-function
> F616e6f6e796d6f75732d6c616d626461_anonymous_lambda_10>
> 1 0% - evil-visual-state
> 1 0% - evil-normalize-keymaps
> 1 0% - evil-state-keymaps
> 1 0% - evil-state-keymaps
> 1 0% - evil-state-intercept-keymaps
> 1 0% evil-intercept-keymap-p
> 0 0% ...
>
> ```
> Automatic GC take too much times, do you think this is expected?
>
> On 9/3/24 12:41 AM, Pip Cet <pipcet@protonmail.com> wrote:
>> "Eval Exec" <execvy@gmail.com> writes:
>>
>> > Hello,
>> > I'm helping to test scratch/igc branch on my local environment:
>>
>> Thank you!
>>
>> > ```
>> > ❯ uname -a
>> > Linux Matrix 6.6.41 #1-NixOS SMP PREEMPT_DYNAMIC Thu Jul 18 11:21:27
>> > UTC 2024 x86_64 GNU/Linux
>> > ```
>> >
>> > I get the source code of scratch/igc, commit hash: 6682d0e6c96 .
>> > And I append a new commit:
>> > ```
>> > diff --git a/src/igc.c b/src/igc.c
>> > index f069a2becc9..4d792da75c8 100644
>> > --- a/src/igc.c
>> > +++ b/src/igc.c
>> > @@ -4459,7 +4459,7 @@ make_arena (struct igc *gc)
>> > MPS_ARGS_END (args);
>> > IGC_CHECK_RES (res);
>> >
>> > - mps_gen_param_s gens[] = { { 128000, 0.8 }, { 5 * 128000, 0.4 } };
>> > + mps_gen_param_s gens[] = { { 128000000, 0.8 }, { 5 * 128000000,
>> 0.4 } };
>> > res = mps_chain_create (&gc->chain, gc->arena, ARRAYELTS
>> (gens), gens);
>> > IGC_CHECK_RES (res);
>> > }
>> > ```
>>
>> Those numbers are in kilobytes, so that requests 640 gigabytes of memory
>> before it'll even start collecting in earnest. In theory, that should
>> work given enough RAM or swap, but I doubt anyone's tested MPS with such
>> extreme settings.
>>
>> > Then, I compile it by:
>> > ```
>> > make extraclean
>> > ./autogen.sh \
>> > && ./configure \
>> > --prefix=$(realpath ../emacs-build/$(git branch --show-current |
>> sed
>> > 's/\//_/g'))\
>> > --with-mps=yes \
>> > --with-imagemagick \
>> > --with-modules --with-x-toolkit=gtk3 --without-compress-install \
>> > --without-toolkit-scroll-bars --with-native-compilation
>> --with-mailutils\
>> > --enable-link-time-optimization \
>> > --with-tree-sitter --with-xinput2 \
>> > --with-dbus --with-native-compilation=aot \
>> > --with-file-notification=inotify\
>> > && make -j30 install
>> > ```
>> >
>> > When I launch the emacs, editing rust files, emacs crashed. the
>> > backtrace is:
>>
>> How much memory was it using at the time? To me it looks conceivable
>> the crash happened because we failed to get enough memory for a new
>> stack frame, but if it's reproducible or happens again after reducing
>> the generation sizes, we need to investigate it further.
>>
>> > ```
>> > (gdb) source
>> /home/exec/Projects/git.savannah.gnu.org/git/emacs/src/.gdbinit
>> > warning: /home/exec/Projects/git.savannah.gnu.org/git/emacs/../lwlib:
>> > No such file or directory
>> > SIGINT is used by the debugger.
>> > Are you sure you want to change it? (y or n) [answered Y; input not
>> > from terminal]
>> > DISPLAY = :0
>> > TERM = tmux-256color
>> > Breakpoint 1 at 0x428ca7: file
>> > /home/exec/Projects/git.savannah.gnu.org/git/emacs/src/emacs.c, line
>> > 432.
>> > Breakpoint 2 at 0x52db40: file
>> > /home/exec/Projects/git.savannah.gnu.org/git/emacs/src/xterm.c, line
>> > 27126.
>> > (gdb) bt
>> > #0 0x00007f36826a2efc in __pthread_kill_implementation () from
>> >
>> /nix/store/dbcw19dshdwnxdv5q2g6wldj6syyvq7l-glibc-2.39-52/lib/libc.so.6
>> > #1 0x00007f3682652e86 in raise () from
>> >
>> /nix/store/dbcw19dshdwnxdv5q2g6wldj6syyvq7l-glibc-2.39-52/lib/libc.so.6
>> > #2 0x0000000000428d5a in terminate_due_to_signal (sig=11,
>> > backtrace_limit=<optimized out>) at
>> > /home/exec/Projects/git.savannah.gnu.org/git/emacs/src/emacs.c:470
>> > #3 0x0000000000429579 in handle_fatal_signal (sig=<optimized out>) at
>> > /home/exec/Projects/git.savannah.gnu.org/git/emacs/src/sysdep.c:1800
>> > #4 0x00000000006c5a68 in deliver_thread_signal.constprop.0 (sig=11,
>> > handler=<optimized out>) at
>> > /home/exec/Projects/git.savannah.gnu.org/git/emacs/src/sysdep.c:1792
>> > #5 <signal handler called>
>> > #6 0x00007f368265316b in kill () from
>> >
>> /nix/store/dbcw19dshdwnxdv5q2g6wldj6syyvq7l-glibc-2.39-52/lib/libc.so.6
>> > #7 0x00000000007551e9 in sigHandle ()
>> > #8 <signal handler called>
>> > #9 indirect_function (object=XIL(0)) at
>> > /home/exec/Projects/git.savannah.gnu.org/git/emacs/src/lisp.h:1198
>>
>> It would be good to know whether 'object' is actually nil in this case
>> (in which case lisp.h:1198 is wrong) or whether the nil is wrong (and
>> the lisp.h:1198, possibly, correct), but I suspect the best bet is to
>> reduce the generation chain sizes and try again.
>>
>> > What information should I provide to help investigating this crash?
>>
>> Trying again with a more moderate generation size would be ideal, but
>> you might want to run Emacs in GDB and keep it connected after a crash
>> so we can investigate further.
>>
>> Thanks again
>> Pip
>>
>>
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Emacs [scratch/igc 6682d0e6c96] crash on Linux 6.6.41 KDE 6.0.5, wayland
2024-09-03 1:10 ` execvy
2024-09-03 3:33 ` Eval EXEC
@ 2024-09-03 10:57 ` Pip Cet
2024-09-03 11:20 ` execvy
1 sibling, 1 reply; 15+ messages in thread
From: Pip Cet @ 2024-09-03 10:57 UTC (permalink / raw)
To: execvy; +Cc: emacs-devel
<execvy@gmail.com> writes:
> After I change `mps_gen_param_s gens[] = { { 128000, 0.8 }, { 5 * 128000, 0.4 } };`
> to `mps_gen_param_s gens[] = { { 12800000, 0.8 }, { 5 * 12800000, 0.4 } };`, the Emacs never crash again.
That's still a very large size for the initial generation, in
particular. May I ask why you decided to do that? I think for
interactive use, you want to keep the initial generation reasonably
small.
> And it's RES mem is 2661M, I think it's good, I'm editing 2000 rust files in Emacs with rust-analyzer lsp server. 99% of time I don't feel GC's lag.
> But, When I hit `Ctrl + right click`, I feel a very long GC lag ( > 10 seconds). It's reproducible.
Are we sure that it's GC causing this? I assume control + right click
shows a buffer menu, so it builds a list of all buffers, and you have a
lot of them...
I've played around a little creating 10,000 buffers and showing the
buffer menu, and there does appear to be some lag, but this is true both
with and without MPS. I also tried a build with --with-x-toolkit=no,
and that seemed to have less lag.
> So I profiler-start, then `Ctrl + right click`, then `profiler-stop`, got:
> ```
> 14726 58% Automatic GC
> 10528 41% - help-command-error-confusable-suggestions
> 10528 41% - debug
> 10528 41% - recursive-edit
> 391 1% - substitute-command-keys
I cannot tell from this whether MPS was called once and took a very long
time to run, or was called many times and the problem lies elsewhere.
Does the problem happen with the default generation sizes?
Pip
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Emacs [scratch/igc 6682d0e6c96] crash on Linux 6.6.41 KDE 6.0.5, wayland
2024-09-03 10:57 ` Pip Cet
@ 2024-09-03 11:20 ` execvy
0 siblings, 0 replies; 15+ messages in thread
From: execvy @ 2024-09-03 11:20 UTC (permalink / raw)
To: Pip Cet, emacs-devel
> That's still a very large size for the initial generation, in
particular. May I ask why you decided to do that?
When I living in Emacs, I like long press `j` (evil-next-line) and `k` (evil-previous-line) to move around the code.
In master build, long press `j` and `k` are very smooth.
But in mps build, long press `j` and `k` can feel frequent brief pauses.
So I tested whether increasing the number in `mps_gen_param_s` would make long-pressing `j` and `k` smoother. After the test, it did help, but I still feel pauses when long-pressing `j` and `k`.
> Are we sure that it's GC causing this? I assume control + right click
shows a buffer menu, so it builds a list of all buffers, and you have a
lot of them...
No, I think the ctrl + right click is not related to GC.
On 9/3/24 6:57 PM, Pip Cet <pipcet@protonmail.com> wrote:
> <execvy@gmail.com> writes:
>
> > After I change `mps_gen_param_s gens[] = { { 128000, 0.8 }, { 5 * 128000, 0.4 } };`
> > to `mps_gen_param_s gens[] = { { 12800000, 0.8 }, { 5 * 12800000, 0.4 } };`, the Emacs never crash again.
>
> That's still a very large size for the initial generation, in
> particular. May I ask why you decided to do that? I think for
> interactive use, you want to keep the initial generation reasonably
> small.
>
> > And it's RES mem is 2661M, I think it's good, I'm editing 2000 rust files in Emacs with rust-analyzer lsp server. 99% of time I don't feel GC's lag.
> > But, When I hit `Ctrl + right click`, I feel a very long GC lag ( > 10 seconds). It's reproducible.
>
> Are we sure that it's GC causing this? I assume control + right click
> shows a buffer menu, so it builds a list of all buffers, and you have a
> lot of them...
>
> I've played around a little creating 10,000 buffers and showing the
> buffer menu, and there does appear to be some lag, but this is true both
> with and without MPS. I also tried a build with --with-x-toolkit=no,
> and that seemed to have less lag.
>
> > So I profiler-start, then `Ctrl + right click`, then `profiler-stop`, got:
> > ```
> > 14726 58% Automatic GC
> > 10528 41% - help-command-error-confusable-suggestions
> > 10528 41% - debug
> > 10528 41% - recursive-edit
> > 391 1% - substitute-command-keys
>
> I cannot tell from this whether MPS was called once and took a very long
> time to run, or was called many times and the problem lies elsewhere.
>
> Does the problem happen with the default generation sizes?
>
> Pip
>
>
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Emacs [scratch/igc 6682d0e6c96] crash on Linux 6.6.41 KDE 6.0.5, wayland
2024-09-03 3:33 ` Eval EXEC
@ 2024-09-03 12:58 ` Eli Zaretskii
2024-09-03 14:58 ` execvy
0 siblings, 1 reply; 15+ messages in thread
From: Eli Zaretskii @ 2024-09-03 12:58 UTC (permalink / raw)
To: Eval EXEC; +Cc: pipcet, emacs-devel
> Date: Tue, 3 Sep 2024 11:33:14 +0800
> From: Eval EXEC <execvy@gmail.com>
>
> When I M-x `menu-bar-mode` to enable menu-bar, the long gc lag (> 10
> seconds) happened too.
>
> Then I try `Ctrl + right clock`, then there is no long gc lag (> 10
> seconds).
What file are you visiting when this happened?
I see no lag whatsoever here, FWIW (but then I didn't change the MPS
arena parameters to such large values).
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Emacs [scratch/igc 6682d0e6c96] crash on Linux 6.6.41 KDE 6.0.5, wayland
2024-09-03 12:58 ` Eli Zaretskii
@ 2024-09-03 14:58 ` execvy
2024-09-03 15:34 ` Eli Zaretskii
0 siblings, 1 reply; 15+ messages in thread
From: execvy @ 2024-09-03 14:58 UTC (permalink / raw)
To: Eli Zaretskii, pipcet, emacs-devel
What file are you visiting when this happened?
A /home/exec/Projects/git.savannah.gnu.org/git/emacs-build/scratch_igc/share/emacs/31.0.50/lisp/files.el file.
Another information: my KDE plasma setting has a keyboard config.
I config keyboard long press repeat rate as: 100 repeats/s
If I decrease 100 repeats/s to 10 repeats/s, then I feel no gc pause on scratch/igc.
But, in master branch, even I set 100 repeats/s for long press key config. I feel no pause.
On 9/3/24 8:58 PM, Eli Zaretskii <eliz@gnu.org> wrote:
> > Date: Tue, 3 Sep 2024 11:33:14 +0800
> > From: Eval EXEC <execvy@gmail.com>
> >
> > When I M-x `menu-bar-mode` to enable menu-bar, the long gc lag (> 10
> > seconds) happened too.
> >
> > Then I try `Ctrl + right clock`, then there is no long gc lag (> 10
> > seconds).
>
> What file are you visiting when this happened?
>
> I see no lag whatsoever here, FWIW (but then I didn't change the MPS
> arena parameters to such large values).
>
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Emacs [scratch/igc 6682d0e6c96] crash on Linux 6.6.41 KDE 6.0.5, wayland
2024-09-03 14:58 ` execvy
@ 2024-09-03 15:34 ` Eli Zaretskii
2024-09-03 15:57 ` Pip Cet
0 siblings, 1 reply; 15+ messages in thread
From: Eli Zaretskii @ 2024-09-03 15:34 UTC (permalink / raw)
To: execvy; +Cc: pipcet, emacs-devel
> Date: Tue, 3 Sep 2024 22:58:04 +0800
> From: execvy@gmail.com
>
> What file are you visiting when this happened?
> A /home/exec/Projects/git.savannah.gnu.org/git/emacs-build/scratch_igc/share/emacs/31.0.50/lisp/files.el file.
>
> Another information: my KDE plasma setting has a keyboard config.
> I config keyboard long press repeat rate as: 100 repeats/s
> If I decrease 100 repeats/s to 10 repeats/s, then I feel no gc pause on scratch/igc.
>
> But, in master branch, even I set 100 repeats/s for long press key config. I feel no pause.
And I don't feel any pauses with the igc branch, either.
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Emacs [scratch/igc 6682d0e6c96] crash on Linux 6.6.41 KDE 6.0.5, wayland
2024-09-03 15:34 ` Eli Zaretskii
@ 2024-09-03 15:57 ` Pip Cet
2024-09-03 16:06 ` Eli Zaretskii
0 siblings, 1 reply; 15+ messages in thread
From: Pip Cet @ 2024-09-03 15:57 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: execvy, emacs-devel
"Eli Zaretskii" <eliz@gnu.org> writes:
>> Date: Tue, 3 Sep 2024 22:58:04 +0800
>> From: execvy@gmail.com
>>
>> What file are you visiting when this happened?
>> A /home/exec/Projects/git.savannah.gnu.org/git/emacs-build/scratch_igc/share/emacs/31.0.50/lisp/files.el file.
>>
>> Another information: my KDE plasma setting has a keyboard config.
>> I config keyboard long press repeat rate as: 100 repeats/s
>> If I decrease 100 repeats/s to 10 repeats/s, then I feel no gc pause on scratch/igc.
>>
>> But, in master branch, even I set 100 repeats/s for long press key config. I feel no pause.
>
> And I don't feel any pauses with the igc branch, either.
I'm not sure key repeat is a particularly good test of GC
responsiveness; it appears to be heavily influenced by non-GC factors,
and when holding C-n, redisplay stops at some point and only catches up
when the key is released.
If I set the keyboard repeat rate to 255 using 'xset', which appears to
be the maximum supported, an MPS Emacs running my production session
(some 200 buffers) ends up exhibiting this behavior when holding C-n, so
only the first, non-repeated command is displayed properly. A
newly-launched MPS Emacs does fine with xdisp.c in fundamental mode, but
in C mode it ends up scrolling for a bit, presumably until font-lock
does its work, then not scrolling until 'n' is released again.
It would be nice to change this behavior to force some redisplay even
when Emacs can't keep up with keypresses, but I don't think this is an
MPS issue at this point.
Is it true that we only redisplay once all key presses have been
handled?
Pip
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Emacs [scratch/igc 6682d0e6c96] crash on Linux 6.6.41 KDE 6.0.5, wayland
2024-09-03 15:57 ` Pip Cet
@ 2024-09-03 16:06 ` Eli Zaretskii
2024-09-03 16:22 ` Eval EXEC
0 siblings, 1 reply; 15+ messages in thread
From: Eli Zaretskii @ 2024-09-03 16:06 UTC (permalink / raw)
To: Pip Cet; +Cc: execvy, emacs-devel
> Date: Tue, 03 Sep 2024 15:57:05 +0000
> From: Pip Cet <pipcet@protonmail.com>
> Cc: execvy@gmail.com, emacs-devel@gnu.org
>
> "Eli Zaretskii" <eliz@gnu.org> writes:
>
> > And I don't feel any pauses with the igc branch, either.
>
> I'm not sure key repeat is a particularly good test of GC
> responsiveness; it appears to be heavily influenced by non-GC factors,
> and when holding C-n, redisplay stops at some point and only catches up
> when the key is released.
>
> If I set the keyboard repeat rate to 255 using 'xset', which appears to
> be the maximum supported, an MPS Emacs running my production session
> (some 200 buffers) ends up exhibiting this behavior when holding C-n, so
> only the first, non-repeated command is displayed properly. A
> newly-launched MPS Emacs does fine with xdisp.c in fundamental mode, but
> in C mode it ends up scrolling for a bit, presumably until font-lock
> does its work, then not scrolling until 'n' is released again.
I see none of this, but my auto-repeat rate is about 30/sec.
> It would be nice to change this behavior to force some redisplay even
> when Emacs can't keep up with keypresses, but I don't think this is an
> MPS issue at this point.
For me, the MPS build is much snappier scrolling through xdisp.c (in C
mode) than the "normal" build.
> Is it true that we only redisplay once all key presses have been
> handled?
We redisplay when we get back to the main loop and there's no input
pending. Depending on the input rate and the time it takes to process
each key, it could go either way.
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Emacs [scratch/igc 6682d0e6c96] crash on Linux 6.6.41 KDE 6.0.5, wayland
2024-09-03 16:06 ` Eli Zaretskii
@ 2024-09-03 16:22 ` Eval EXEC
2024-09-03 17:36 ` Eli Zaretskii
0 siblings, 1 reply; 15+ messages in thread
From: Eval EXEC @ 2024-09-03 16:22 UTC (permalink / raw)
To: Eli Zaretskii, Pip Cet; +Cc: emacs-devel
[-- Attachment #1: Type: text/plain, Size: 1894 bytes --]
> We redisplay when we get back to the main loop and there's no input
> pending.
Where is the main loop? Could you please tell me the source code file and line number related to "getting back to the main loop"? I'm interested in the Emacs source code. Thank you.
On 9/4/24 00:06, Eli Zaretskii wrote:
>> Date: Tue, 03 Sep 2024 15:57:05 +0000
>> From: Pip Cet<pipcet@protonmail.com>
>> Cc:execvy@gmail.com,emacs-devel@gnu.org
>>
>> "Eli Zaretskii"<eliz@gnu.org> writes:
>>
>>> And I don't feel any pauses with the igc branch, either.
>> I'm not sure key repeat is a particularly good test of GC
>> responsiveness; it appears to be heavily influenced by non-GC factors,
>> and when holding C-n, redisplay stops at some point and only catches up
>> when the key is released.
>>
>> If I set the keyboard repeat rate to 255 using 'xset', which appears to
>> be the maximum supported, an MPS Emacs running my production session
>> (some 200 buffers) ends up exhibiting this behavior when holding C-n, so
>> only the first, non-repeated command is displayed properly. A
>> newly-launched MPS Emacs does fine with xdisp.c in fundamental mode, but
>> in C mode it ends up scrolling for a bit, presumably until font-lock
>> does its work, then not scrolling until 'n' is released again.
> I see none of this, but my auto-repeat rate is about 30/sec.
>
>> It would be nice to change this behavior to force some redisplay even
>> when Emacs can't keep up with keypresses, but I don't think this is an
>> MPS issue at this point.
> For me, the MPS build is much snappier scrolling through xdisp.c (in C
> mode) than the "normal" build.
>
>> Is it true that we only redisplay once all key presses have been
>> handled?
> We redisplay when we get back to the main loop and there's no input
> pending. Depending on the input rate and the time it takes to process
> each key, it could go either way.
>
[-- Attachment #2: Type: text/html, Size: 3109 bytes --]
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Emacs [scratch/igc 6682d0e6c96] crash on Linux 6.6.41 KDE 6.0.5, wayland
2024-09-03 16:22 ` Eval EXEC
@ 2024-09-03 17:36 ` Eli Zaretskii
0 siblings, 0 replies; 15+ messages in thread
From: Eli Zaretskii @ 2024-09-03 17:36 UTC (permalink / raw)
To: Eval EXEC; +Cc: pipcet, emacs-devel
> Date: Wed, 4 Sep 2024 00:22:44 +0800
> Cc: emacs-devel@gnu.org
> From: Eval EXEC <execvy@gmail.com>
>
> > We redisplay when we get back to the main loop and there's no input
> > pending.
>
> Where is the main loop? Could you please tell me the source code file and line number related to "getting back to the main loop"? I'm interested in the Emacs source code. Thank you.
The main loop is in keyboard.c, in the function command_loop_1.
^ permalink raw reply [flat|nested] 15+ messages in thread
end of thread, other threads:[~2024-09-03 17:36 UTC | newest]
Thread overview: 15+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2024-09-02 12:24 Emacs [scratch/igc 6682d0e6c96] crash on Linux 6.6.41 KDE 6.0.5, wayland Eval Exec
2024-09-02 13:06 ` Eli Zaretskii
2024-09-02 13:08 ` Eval EXEC
2024-09-02 16:41 ` Pip Cet
2024-09-03 1:10 ` execvy
2024-09-03 3:33 ` Eval EXEC
2024-09-03 12:58 ` Eli Zaretskii
2024-09-03 14:58 ` execvy
2024-09-03 15:34 ` Eli Zaretskii
2024-09-03 15:57 ` Pip Cet
2024-09-03 16:06 ` Eli Zaretskii
2024-09-03 16:22 ` Eval EXEC
2024-09-03 17:36 ` Eli Zaretskii
2024-09-03 10:57 ` Pip Cet
2024-09-03 11:20 ` execvy
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).