GNU bug report logs - #72165
31.0.50; Intermittent crashing with recent emacs build

Previous Next

Full log

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

From: Dima Kogan <dima <at> secretsauce.net>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 72165 <at> debbugs.gnu.org
Subject: Re: bug#72165: 31.0.50; Intermittent crashing with recent emacs build
Date: Wed, 31 Jul 2024 05:39:28 +0900

> So let me see if I understand you correctly regarding what happens:
>
>   . The *Messages* buffer is displayed in a window, which is
>     redisplayed, and the display engine calls redisplay_window for it.
>   . redisplay_window records the original position of point in the
>     *Messages* buffer, then calls display_mode_lines, as it does for
>     any window whose mode line needs to be redrawn for some reason
>   . somewhere inside display_mode_lines, we call message_dolog, most
>     probably because the mode-line format calls :eval, which signals
>     an error
>   . message_dolog adds some text to *Messages* and removes some other
>     text from it, which invalidates the position of point recorded at
>     the beginning of redisplay_window
>   . redisplay_window then uses invalid value of point (including its
>     byte position, which no longer corresponds to the character
>     position) to set point, and that opens the gates of hell
>
> Is that correct?

Yes


> If so, this puzzle has the following pieces:
>
>   . *Messages* is displayed and includes non-ASCII text

Yes. My current understanding is that ASCII-only text could make the new
stuff in *Messages* end up in the wrong place, but wouldn't cause a
crash


>   . mode-line-format that signals an error when the window showing
>     *Messages* is redisplayed
>   . the size of *Messages* buffer and its contents are such that
>     moving point to the value recorded at entry to redisplay_window
>     produces a mismatch between PT and PT_BYTE
>
> If all of the above happen, we are toast.  Right?

Yes


> Can you verify that the above theory is true?

This is consistent with everything I see.


> For example does CHARS_MODIFF value of the buffer after
> display_mode_lines returns differ from its value before the call?

Top    of display_mode_lines(): CHARS_MODIFF = 29606
Bottom of display_mode_lines(): CHARS_MODIFF = 29703

Previous Next

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