GNU bug report logs - #79478
31.0.50; One to two minute hangs

Previous

To reply to this bug, email your comments to 79478 AT debbugs.gnu.org.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Sean Whitton <spwhitton <at> spwhitton.name>
To: bug-gnu-emacs <at> gnu.org
Subject: 31.0.50; One to two minute hangs
Date: Sat, 20 Sep 2025 15:48:46 +0100

For the past week or so my pgtk, native comp Emacs has been hanging for
a minute or so at a time, sometimes.

Usually my other Emacs instance running gdb hangs in the same way at the
same times so I haven't been able to get a backtrace, but the gdb Emacs
didn't so I was able to get a backtrace:

 0 in CHECK_STRING of /home/swhitton/src/emacs/primary/src/lisp.h:1596
 1 in Fstring_equal of fns.c:351
 2 in assoc_ignore_text_properties of buffer.c:473
 3 in Fget_buffer of buffer.c:490
 4 in Fget_buffer_create of buffer.c:588
 5 in message_dolog of xdisp.c:12205
 6 in message_log_maybe_newline of xdisp.c:12165
 7 in Fcommand_error_default_function of keyboard.c:1088
 8 in F68656c702d636f6d6d616e642d6572726f722d636f6e66757361626c652d73756767657374696f6e73_help_command_error_confusable_suggestions_0
 9 in funcall_subr of eval.c:3246
10 in funcall_general of eval.c:3121
11 in Ffuncall of eval.c:3174
12 in cmd_error_internal of keyboard.c:1042
13 in cmd_error of keyboard.c:1010
14 in internal_condition_case of eval.c:1686
15 in command_loop_2 of keyboard.c:1163
16 in internal_catch of eval.c:1370
17 in command_loop of keyboard.c:1141
18 in recursive_edit_1 of keyboard.c:749
19 in Frecursive_edit of keyboard.c:832
20 in main of emacs.c:2629

If I let it continue a bit and then interrupt again it's similar:

 0 in __memrchr_avx2 of ../sysdeps/x86_64/multiarch/memrchr-avx2.S:89
 1 in find_newline of search.c:910
 2 in scan_newline of search.c:974
 3 in message_dolog of xdisp.c:12317
 4 in message_log_maybe_newline of xdisp.c:12165
 5 in Fcommand_error_default_function of keyboard.c:1088
 6 in F68656c702d636f6d6d616e642d6572726f722d636f6e66757361626c652d73756767657374696f6e73_help_command_error_confusable_suggestions_0
 7 in funcall_subr of eval.c:3246
 8 in funcall_general of eval.c:3121
 9 in Ffuncall of eval.c:3174
10 in cmd_error_internal of keyboard.c:1042
11 in cmd_error of keyboard.c:1010
12 in internal_condition_case of eval.c:1686
13 in command_loop_2 of keyboard.c:1163
14 in internal_catch of eval.c:1370
15 in command_loop of keyboard.c:1141
16 in recursive_edit_1 of keyboard.c:749
17 in Frecursive_edit of keyboard.c:832
18 in main of emacs.c:2629

The commonality each time is a call to a very long function with name
containing "_help_command_error_confusable_suggestions".

While this is going on Emacs shows up at 90--100 CPU% in top(1).

-- 
Sean Whitton

Message #8 received at 79478 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Sean Whitton <spwhitton <at> spwhitton.name>
Cc: 79478 <at> debbugs.gnu.org
Subject: Re: bug#79478: 31.0.50; One to two minute hangs
Date: Sat, 20 Sep 2025 18:01:22 +0300

> From: Sean Whitton <spwhitton <at> spwhitton.name>
> Date: Sat, 20 Sep 2025 15:48:46 +0100
> 
> For the past week or so my pgtk, native comp Emacs has been hanging for
> a minute or so at a time, sometimes.
> 
> Usually my other Emacs instance running gdb hangs in the same way at the
> same times so I haven't been able to get a backtrace, but the gdb Emacs
> didn't so I was able to get a backtrace:
> 
>  0 in CHECK_STRING of /home/swhitton/src/emacs/primary/src/lisp.h:1596
>  1 in Fstring_equal of fns.c:351
>  2 in assoc_ignore_text_properties of buffer.c:473
>  3 in Fget_buffer of buffer.c:490
>  4 in Fget_buffer_create of buffer.c:588
>  5 in message_dolog of xdisp.c:12205
>  6 in message_log_maybe_newline of xdisp.c:12165
>  7 in Fcommand_error_default_function of keyboard.c:1088
>  8 in F68656c702d636f6d6d616e642d6572726f722d636f6e66757361626c652d73756767657374696f6e73_help_command_error_confusable_suggestions_0
>  9 in funcall_subr of eval.c:3246
> 10 in funcall_general of eval.c:3121
> 11 in Ffuncall of eval.c:3174
> 12 in cmd_error_internal of keyboard.c:1042
> 13 in cmd_error of keyboard.c:1010
> 14 in internal_condition_case of eval.c:1686
> 15 in command_loop_2 of keyboard.c:1163
> 16 in internal_catch of eval.c:1370
> 17 in command_loop of keyboard.c:1141
> 18 in recursive_edit_1 of keyboard.c:749
> 19 in Frecursive_edit of keyboard.c:832
> 20 in main of emacs.c:2629
> 
> If I let it continue a bit and then interrupt again it's similar:
> 
>  0 in __memrchr_avx2 of ../sysdeps/x86_64/multiarch/memrchr-avx2.S:89
>  1 in find_newline of search.c:910
>  2 in scan_newline of search.c:974
>  3 in message_dolog of xdisp.c:12317
>  4 in message_log_maybe_newline of xdisp.c:12165
>  5 in Fcommand_error_default_function of keyboard.c:1088
>  6 in F68656c702d636f6d6d616e642d6572726f722d636f6e66757361626c652d73756767657374696f6e73_help_command_error_confusable_suggestions_0
>  7 in funcall_subr of eval.c:3246
>  8 in funcall_general of eval.c:3121
>  9 in Ffuncall of eval.c:3174
> 10 in cmd_error_internal of keyboard.c:1042
> 11 in cmd_error of keyboard.c:1010
> 12 in internal_condition_case of eval.c:1686
> 13 in command_loop_2 of keyboard.c:1163
> 14 in internal_catch of eval.c:1370
> 15 in command_loop of keyboard.c:1141
> 16 in recursive_edit_1 of keyboard.c:749
> 17 in Frecursive_edit of keyboard.c:832
> 18 in main of emacs.c:2629
> 
> The commonality each time is a call to a very long function with name
> containing "_help_command_error_confusable_suggestions".
> 
> While this is going on Emacs shows up at 90--100 CPU% in top(1).

This is help-command-error-confusable-suggestions, in help.el.

But what is more interesting is the call to
command-error-default-function, which calls to message_dolog: it means
Emacs is logging some error message in *Messages*>  What do you see
there after these minute-long pauses end?

Message #11 received at 79478 <at> debbugs.gnu.org (full text, mbox):

From: Sean Whitton <spwhitton <at> spwhitton.name>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 79478 <at> debbugs.gnu.org
Subject: Re: bug#79478: 31.0.50; One to two minute hangs
Date: Sat, 20 Sep 2025 19:39:57 +0100

Hello,

On Sat 20 Sep 2025 at 06:01pm +03, Eli Zaretskii wrote:

> This is help-command-error-confusable-suggestions, in help.el.
>
> But what is more interesting is the call to
> command-error-default-function, which calls to message_dolog: it means
> Emacs is logging some error message in *Messages*>  What do you see
> there after these minute-long pauses end?

I'm no longer sure this is the pause I have been seeing because it
hasn't managed to get unstuck.  When I interrupt it now it's in GC:

  0 in process_mark_stack of alloc.c:6488
  1 in mark_object of alloc.c:6724
  2 in mark_char_table of alloc.c:6180
  3 in mark_char_table of alloc.c:6177
  4 in mark_char_table of alloc.c:6177
  5 in mark_char_table of alloc.c:6177
  6 in process_mark_stack of alloc.c:6563
  7 in mark_objects of alloc.c:6732
  8 in mark_vectorlike of alloc.c:6151
  9 in mark_buffer of alloc.c:6214
 10 in process_mark_stack of alloc.c:6521
 11 in mark_objects of alloc.c:6732
 12 in mark_vectorlike of alloc.c:6151
 13 in mark_buffer of alloc.c:6214
 14 in process_mark_stack of alloc.c:6521
 15 in mark_objects of alloc.c:6732
 16 in mark_vectorlike of alloc.c:6151
 17 in mark_buffer of alloc.c:6214
 18 in process_mark_stack of alloc.c:6521
 19 in mark_objects of alloc.c:6732
 20 in mark_vectorlike of alloc.c:6151
 21 in mark_buffer of alloc.c:6214
 22 in process_mark_stack of alloc.c:6521
 23 in mark_object of alloc.c:6724
 24 in mark_char_table of alloc.c:6180
 25 in mark_char_table of alloc.c:6177
 26 in process_mark_stack of alloc.c:6563
 27 in mark_object of alloc.c:6724
 28 in mark_char_table of alloc.c:6180
 29 in mark_char_table of alloc.c:6177
 30 in process_mark_stack of alloc.c:6563
 31 in mark_objects of alloc.c:6732
 32 in mark_vectorlike of alloc.c:6151
 33 in mark_buffer of alloc.c:6214
 34 in process_mark_stack of alloc.c:6521
 35 in mark_objects of alloc.c:6732
 36 in mark_vectorlike of alloc.c:6151
 37 in mark_buffer of alloc.c:6214
 38 in process_mark_stack of alloc.c:6521
 39 in mark_objects of alloc.c:6732
 40 in mark_vectorlike of alloc.c:6151
 41 in mark_buffer of alloc.c:6214
 42 in process_mark_stack of alloc.c:6521
 43 in mark_objects of alloc.c:6732
 44 in mark_vectorlike of alloc.c:6151
 45 in mark_buffer of alloc.c:6214
 46 in process_mark_stack of alloc.c:6521
 47 in mark_objects of alloc.c:6732
 48 in mark_vectorlike of alloc.c:6151
 49 in mark_buffer of alloc.c:6214
 50 in process_mark_stack of alloc.c:6521
 51 in mark_objects of alloc.c:6732
 52 in mark_vectorlike of alloc.c:6151
 53 in mark_buffer of alloc.c:6214
 54 in process_mark_stack of alloc.c:6521
 55 in mark_object of alloc.c:6724
 56 in mark_overlay of alloc.c:6193
 57 in process_mark_stack of alloc.c:6577
 58 in mark_objects of alloc.c:6732
 59 in mark_vectorlike of alloc.c:6151
 60 in mark_buffer of alloc.c:6214
 61 in process_mark_stack of alloc.c:6521
 62 in mark_objects of alloc.c:6732
 63 in mark_vectorlike of alloc.c:6151
 64 in mark_buffer of alloc.c:6214
 65 in process_mark_stack of alloc.c:6521
 66 in mark_objects of alloc.c:6732
 67 in mark_vectorlike of alloc.c:6151
 68 in mark_buffer of alloc.c:6214
 69 in process_mark_stack of alloc.c:6521
 70 in mark_objects of alloc.c:6732
 71 in mark_vectorlike of alloc.c:6151
 72 in mark_buffer of alloc.c:6214
 73 in process_mark_stack of alloc.c:6521
 74 in mark_objects of alloc.c:6732
 75 in mark_vectorlike of alloc.c:6151
 76 in mark_buffer of alloc.c:6214
 77 in process_mark_stack of alloc.c:6521
 78 in mark_objects of alloc.c:6732
 79 in mark_vectorlike of alloc.c:6151
 80 in mark_buffer of alloc.c:6214
 81 in process_mark_stack of alloc.c:6521
 82 in mark_objects of alloc.c:6732
 83 in mark_vectorlike of alloc.c:6151
 84 in mark_buffer of alloc.c:6214
 85 in process_mark_stack of alloc.c:6521
 86 in mark_objects of alloc.c:6732
 87 in mark_vectorlike of alloc.c:6151
 88 in mark_buffer of alloc.c:6214
 89 in process_mark_stack of alloc.c:6521
 90 in mark_objects of alloc.c:6732
 91 in mark_vectorlike of alloc.c:6151
 92 in mark_buffer of alloc.c:6214
 93 in process_mark_stack of alloc.c:6521
 94 in mark_object of alloc.c:6724
 95 in mark_object_root_visitor of alloc.c:5661
 96 in visit_vectorlike_root of alloc.c:5613
 97 in visit_buffer_root of alloc.c:5627
 98 in visit_static_gc_roots of alloc.c:5639
 99 in garbage_collect of alloc.c:5863
100 in maybe_garbage_collect of alloc.c:5772
101 in maybe_gc of /home/swhitton/src/emacs/primary/src/lisp.h:5901
102 in Ffuncall of eval.c:3169
103 in safe_run_hooks_1 of keyboard.c:1881
104 in internal_condition_case_n of eval.c:1770
105 in safe_run_hook_funcall of keyboard.c:1939
106 in run_hook_with_args of eval.c:3019
107 in safe_run_hooks_maybe_narrowed of keyboard.c:1977
108 in command_loop_1 of keyboard.c:1339
109 in internal_condition_case of eval.c:1690
110 in command_loop_2 of keyboard.c:1163
111 in internal_catch of eval.c:1370
112 in command_loop of keyboard.c:1141
113 in recursive_edit_1 of keyboard.c:749
114 in Frecursive_edit of keyboard.c:832
115 in main of emacs.c:2629

Is there some function I can call from gdb to get it to exit to
toplevel?

-- 
Sean Whitton

Message #14 received at 79478 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Sean Whitton <spwhitton <at> spwhitton.name>
Cc: 79478 <at> debbugs.gnu.org
Subject: Re: bug#79478: 31.0.50; One to two minute hangs
Date: Sat, 20 Sep 2025 21:54:58 +0300

> From: Sean Whitton <spwhitton <at> spwhitton.name>
> Cc: 79478 <at> debbugs.gnu.org
> Date: Sat, 20 Sep 2025 19:39:57 +0100
> 
> Hello,
> 
> On Sat 20 Sep 2025 at 06:01pm +03, Eli Zaretskii wrote:
> 
> > This is help-command-error-confusable-suggestions, in help.el.
> >
> > But what is more interesting is the call to
> > command-error-default-function, which calls to message_dolog: it means
> > Emacs is logging some error message in *Messages*>  What do you see
> > there after these minute-long pauses end?
> 
> I'm no longer sure this is the pause I have been seeing because it
> hasn't managed to get unstuck.  When I interrupt it now it's in GC:

You mean, this GC never ends?  It must end at some point, because the
number of Lisp objects in an Emacs session is finite.

> Is there some function I can call from gdb to get it to exit to
> toplevel?

Something like

  (gdb) call Ftop_level()

should do it.  But longjmp-ing out of GC is not something I'd
recommend, better wait for it to finish.

Previous

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