GNU bug report logs - #45898
27.1; wedged in redisplay again

Previous Next

Package: emacs;

Reported by: Devon Sean McCullough <Emacs-hacker2018 <at> jovi.net>

Date: Fri, 15 Jan 2021 18:14:01 UTC

Severity: normal

Found in version 27.1

Full log


View this message in rfc822 format

From: Devon Sean McCullough <Emacs-hacker2018 <at> jovi.net>
To: 45898 <at> debbugs.gnu.org
Subject: bug#45898: 27.1; wedged in redisplay again
Date: Fri, 15 Jan 2021 13:13:16 -0500
An elisp expression output a bigger list than expected so I hit m-< and
went out for a walk.  After four hours of 99% CPU, lldb backtrace shows

main → Frecursive_edit → recursive_edit_1 → command_loop →
command_loop.cold.1 → internal_catch → command_loop_2 →
internal_condition_case → command_loop_1 → read_key_sequence → read_char
→ redisplay_internal → redisplay_windows → redisplay_windows →
internal_condition_case_1 → redisplay_window_0 → redisplay_window →
compute_window_start_on_continuation_line → move_it_to →
move_it_in_display_line_to → gui_produce_glyphs → macfont_encode_char

If lldb forces read_char to return Qnil or redisplay_internal to return,
will Emacs crash immediately or survive long enough to save all buffers
or better yet continue working?

Would calling Fgoto-char(Fpoint_min()) from the lldb break immediately 
corrupt or crash Emacs?

	Peace
		--Devon

P.S.  If there exists a way to quickly and safely abort redisplay,
perhaps there should be a hook invoked when repeated keyboard-quit
has no effect, allowing experimentation into workarounds for this
apparently intractable redisplay problem?




This bug report was last modified 2 years and 356 days ago.

Previous Next


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