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

Previous Next

Full log

View this message in rfc822 format

From: Eli Zaretskii <eliz <at> gnu.org>
To: Dima Kogan <dima <at> secretsauce.net>
Cc: 72165 <at> debbugs.gnu.org
Subject: bug#72165: 31.0.50; Intermittent crashing with recent emacs build
Date: Thu, 01 Aug 2024 14:03:22 +0300

> From: Dima Kogan <dima <at> secretsauce.net>
> Cc: 72165 <at> debbugs.gnu.org
> 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

Thanks.  I've now installed a fix on the emacs-30 branch; let's hope
this bug will not happen anymore.

Previous Next

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