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

Previous Next

Full log

Message #38 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: Sun, 28 Jul 2024 19:50:52 -0700

Alright. After some flailing I was able to make it crash with rr, so now
I can see EVERYTHING. rr is truly a miracle, and figuring this out
without it would have been impossible.

I walked around the rr trace, and I clearly see the crashing mechanism.
I don't dare fix it myself, but hopefully one of you will be able to,
without a lot of trouble.

The buggy function is message_dolog():

  https://github.com/dkogan/emacs-snapshot/blob/439ec471961/src/xdisp.c#L12041

On line 12075 we save the current point as a marker (i.e. both the byte
and char positions):

  oldpoint = message_dolog_marker1;
  set_marker_restricted_both (oldpoint, Qnil, PT, PT_BYTE);

In the failing sequence I had some non-ascii characters, so PT_BYTE
would be ahead of PT (by either 4 or 8 bytes). This difference is
recorded into oldpoint.

Then on line 12177 we check if we're exceeding message-log-max, and if
so, delete some stuff from the *Messages*.

  if (FIXNATP (Vmessage_log_max))
    {
      scan_newline (Z, Z_BYTE, BEG, BEG_BYTE,
                    -XFIXNAT (Vmessage_log_max) - 1, false);
      del_range_both (BEG, BEG_BYTE, PT, PT_BYTE, false);
    }

In the failing sequence we delete some of the non-ascii characters. So
the byte-char offset changes: it was 4 or 8 bytes, and it becomes 0 or 4
bytes. At this point we're still correct. But very shortly after this,
on line 12205 we restore the oldpoint into the current point. Since we
just deleted stuff from the BEGINNING of the buffer, the oldpoint
doesn't point to the same thing as before. Restoring it directly is
wrong, but this normally doesn't cause crashes. The thing that causes
crashing is that sometimes the byte-char offset in oldpoint is no longer
correct, and we fail the consistency checks in redisplay_window().

OK. If more investigating is needed, I still have the rr trace, and can
pull it up again. But I think we're clear on what's happening, and
hopefully no more digging is required.

Thanks!

Previous Next

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