From: execvy@gmail.com
To: Pip Cet <pipcet@protonmail.com>, emacs-devel@gnu.org
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 [thread overview]
Message-ID: <2dbfa6b7-19c4-40e1-a094-2995261097ac@gmail.com> (raw)
In-Reply-To: <87ikve2el4.fsf@protonmail.com>
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
>
>
next prev parent reply other threads:[~2024-09-03 1:10 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
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 [this message]
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
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=2dbfa6b7-19c4-40e1-a094-2995261097ac@gmail.com \
--to=execvy@gmail.com \
--cc=emacs-devel@gnu.org \
--cc=pipcet@protonmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.