|
| From: | execvy |
| Subject: | Re: Emacs [scratch/igc 6682d0e6c96] crash on Linux 6.6.41 KDE 6.0.5, wayland |
| Date: | Tue, 3 Sep 2024 09:10:50 +0800 |
| User-agent: | Mozilla Thunderbird |
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
| [Prev in Thread] | Current Thread | [Next in Thread] |