GNU bug report logs - #81407
31.0.90; Crash in display_line: stale glyph_row after window-config change from menu-bar :enable eval during redisplay

Please note: This is a static page, with minimal formatting, updated once a day.
Click here to see this page with the latest information and nicer formatting.

Package: emacs; Reported by: Aaron Iba <ai@HIDDEN>; dated Tue, 14 Jul 2026 07:15:01 UTC; Maintainer for emacs is bug-gnu-emacs@HIDDEN.

Added indication that bug 81407 blocks81521 Request was from Sean Whitton <spwhitton@HIDDEN> to control <at> debbugs.gnu.org. Full text available.

Message received at 81407 <at> debbugs.gnu.org:

Received: (at 81407) by debbugs.gnu.org; 27 Jul 2026 13:15:19 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Mon Jul 27 09:15:19 2026
Received: from localhost ([127.0.0.1]:37563 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1woLAs-0001LR-GV
	for submit <at> debbugs.gnu.org; Mon, 27 Jul 2026 09:15:19 -0400
Received: from mail-lj1-x22f.google.com ([2a00:1450:4864:20::22f]:46326)
 by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128)
 (Exim 4.84_2) (envelope-from <ai@HIDDEN>) id 1woLAp-0001K2-C5
 for 81407 <at> debbugs.gnu.org; Mon, 27 Jul 2026 09:15:16 -0400
Received: by mail-lj1-x22f.google.com with SMTP id
 38308e7fff4ca-39c8e65e3f5so21804541fa.0
 for <81407 <at> debbugs.gnu.org>; Mon, 27 Jul 2026 06:15:15 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; t=1785158109; cv=none;
 d=google.com; s=arc-20260327;
 b=QK2Cp6zxMn8yN35Dm8pyey/0kKFRySmkXKoenR7irFsC3fSp4VRsnooxBJAofwWpta
 0l9Y2eFZZzEILVOyONPvVcYY+rYnQSwmzXmy+9NC48ZazxaPARjFjA6cYeWpUAWDT962
 zKRJxUErpxu7G0VjcqX/oULrIhKvnnAFK4lLi4Rw0TuDCSMHPsVVMStU7TR51A3O2m0r
 X8O/zrSCeY6pxYrSZwO/kQZKXgyY+I47RagVnWNNTHbSiY0kc4F9Id3nQFuhtQtDxJhc
 XgBKOl9LxeWSyoZ6PuJjQ1Iu4lQIFiOSPO0Oy0pAwjyfSLSlDbOaRLahaaG9FpmX+mi1
 KjTA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com;
 s=arc-20260327; 
 h=cc:to:subject:message-id:date:from:in-reply-to:references
 :mime-version:dkim-signature;
 bh=Si4p4OerXEcslYoalC+bIMw7AMCLLTY7vh/9mm8Z1TE=;
 fh=E1mpT6rvccdR4r/KFkbsjcsUW8fJe6FkaoIi2mehYwI=;
 b=swN4dljnh9uBW/1wcQy6P1vQpdE6YYTiJVFs0eyWOSG6HjEfWM4q0Zp5b8ybsPhoMl
 SyBNRs/HsmwTICcwMJJ25yYYG9s50eS9uXOrLlcDM44yRrqgSJsfvv/mLLWk3GRohmJm
 tTCk9XHXz2e568pt8KnKzrws6y9FAvrMpQMU1+Si7RbBqX62ZM/5X7rr6ZNOV9PeJeMj
 hS4JP/x6b0wBQRolJCgpC6qVYunSkUTVQ895lxASCAbEwJyWKs39jNa6OkUSVsphNZVT
 DkLlWQyv1RdGmm5yKnDwBSM90hj7JCoSpDazPUZ7cAhpmfSdtDyplDSnqKZGkqAtfXrD
 vSyA==; darn=debbugs.gnu.org
ARC-Authentication-Results: i=1; mx.google.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=aaroniba.net; s=google; t=1785158109; x=1785762909; darn=debbugs.gnu.org;
 h=content-type:cc:to:subject:message-id:date:from:in-reply-to
 :references:mime-version:from:to:cc:subject:date:message-id:reply-to
 :content-type; bh=Si4p4OerXEcslYoalC+bIMw7AMCLLTY7vh/9mm8Z1TE=;
 b=qAOuvTYLjqLhs/dYM3bKkZSHwtRLN88TxjiVrEaJMXSbQhNklGLeruGPfD0UBOcLDB
 eM9mh5ryKMh06+7cjgO2BWD/scgByyU2dF+YSjQpJLMfbF6JCb2n7OowISNwnaFMrRIv
 Umb3qbyOplNy+EKFd+AnV0tLS2JjvoN30Lr+dWeZPKDnWf7ZqJbvgg5Bo8/BWaU7x6YP
 sPQ8nBZtlNyYB9rN3C5F/u5Ye5xt12fwIWQltk7DJk1qcWNZlwvR8Mpe2aqT+l8xVEJQ
 P7FnJ0RDMhMEnoDooBTHDBw8il07M0hhZTTdppOVs4UEuQvDxfRGXM15ntO2Z7glEYXU
 ZAJg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20251104; t=1785158109; x=1785762909;
 h=content-type:cc:to:subject:message-id:date:from:in-reply-to
 :references:mime-version:x-gm-gg:x-gm-message-state:from:to:cc
 :subject:date:message-id:reply-to:content-type;
 bh=Si4p4OerXEcslYoalC+bIMw7AMCLLTY7vh/9mm8Z1TE=;
 b=DrMksNj6PZpw/hzZb+Va5vfAXzCYzNXWbwjyHPeyRmQTVmNeRm4PLg6Xc/DpTSj6Oy
 W5lLd4alZrzuccOETkt2UKv3OHVG0mt1sBQbEE3CcpaJNiKb4YqDFz/d6CT9Pres+i0n
 ylsOS+vm4iO83pLo5lqp72BKYSmJciJoTLYBzt9Sa42+cvn3nDQSBp7nCUoUKAxfK6zA
 RNKTLsnkuiXD5KUUM1ArjXnTcyRR8g74x6kng+/A9Jb3tZUB6GEr4qCHa6j7ml/xSsbi
 FzFgx/uBEdC1gA2O/UOjnlJbI9DjwXEhKgjoTEW8ZZ/u9b2xCLUVz/Zv7LtIu47Qz3lH
 TPiQ==
X-Gm-Message-State: AOJu0YxXMmGxCGSVdPvk6VCw8l9c0+6zq1mskeCT+xhyip/99b0EOr02
 YPhiz9eCRkyAK68JXGmgTd4Z64Ggt9OfOffSVlP/yglTUc7kHa/v0zmFLQkZiiwsHGgUxpgDZiR
 xNS46maBP/RfIVKyQFnUoHfBYOyAoHTlaFQQ24BIc
X-Gm-Gg: AR+sD11MKHjag9S4K6ar9VP5g4bh01q0rzTjsT6IqocxrxyVI7VB0eB8OGl6AlIyImL
 lBq7vCd7XMfWB/D0KdCFlijQJhWLlR2P716yXsQWIlVNbtMD5ilV0hHUBchI3FVETRljhhHnilQ
 yHnMZ7ye8AIlidxrgRn1vBUvwKd0iia0T76SPlsG/+VGoj7IiA5+/0qzwpoopRtayRNyHVajogF
 XWiocPzSSveT0vhXpa/7dfI24uvjDdeqE78ApAImX5QTXo4kBp0UaqcZffZHXzynfieleTEZtc0
 Lz3ACoXUaXWruf5qcpd5MzCONlo9
X-Received: by 2002:a05:6512:68b:b0:5b2:a1f2:465c with SMTP id
 2adb3069b0e04-5b2c1b16206mr1962928e87.29.1785158108537; Mon, 27 Jul 2026
 06:15:08 -0700 (PDT)
MIME-Version: 1.0
References: <CAH_c0bczVJoqNthKnZD-rMEG8Zx0n6dpfgRcc8GjqSftVho3AQ@HIDDEN>
 <865x2hg2fi.fsf@HIDDEN>
 <CAH_c0bf0VhXMURra2MBdkpUnAbNZi-nAoLFBY44gB_+sbgqd=Q@HIDDEN>
 <86ldbc2z6e.fsf@HIDDEN>
 <CAH_c0bdSVwQezySQFm3QxRgAU9dY455b-+wMSq8MXRXq6eNoxQ@HIDDEN>
 <86y0fb1c7m.fsf@HIDDEN>
In-Reply-To: <86y0fb1c7m.fsf@HIDDEN>
From: Aaron Iba <ai@HIDDEN>
Date: Mon, 27 Jul 2026 09:14:54 -0400
X-Gm-Features: AUfX_mwJVueD7Xyu7-BNYBEmHYyfEDzl02dIymlZ5oY70iptuoBs5YBAW593roc
Message-ID: <CAH_c0bc9M=H8Os=D0DGJ12P0dqKDE+TQtwS9yMw+obqJR8ON-A@HIDDEN>
Subject: Re: bug#81407: 31.0.90; Crash in display_line: stale glyph_row after
 window-config change from menu-bar :enable eval during redisplay
To: Eli Zaretskii <eliz@HIDDEN>
Content-Type: text/plain; charset="UTF-8"
X-Spam-Score: 0.0 (/)
X-Debbugs-Envelope-To: 81407
Cc: 81407 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)

> Try the patch below, it seems to avoid the trouble here.

Thanks!  I applied it to the emacs-31 branch (builds as 31.0.91 now)
and tested on macOS/NS, arm64, --without-native-compilation.  Results:
the patch helps but the guard is unreliable here -- I still get the
crash in a fair fraction of runs, and I found out why.

Test results with the -Q recipe (5 plain runs + 3 instrumented runs):

  - guard fires, evil Lisp aborted, no crash:  ~1/4 of runs
    ("Error during redisplay: (my-evil-fontify 1157) signaled (error
     \"fontification-functions cause glyph matrix reallocation;
     disabled\")" appears in *Messages*, Emacs is fine afterwards)
  - guard does NOT fire, no crash (freed block still readable): ~1/4
  - guard does NOT fire, SIGSEGV as before: ~1/2

Why the guard misses: on this code path the window's matrices are not
adjusted in place -- they are freed and new matrix structs are
allocated.  I put a logging breakpoint on adjust_glyph_matrix in the
patched build, printing MATRIX, its rows/rows_allocated on entry, and
the current value of window_desired_matrix.  After the evil
delete-other-windows, every adjust_glyph_matrix call comes in with a
fresh struct (rows == NULL, rows_allocated == 0):

  run where the guard MISSED and Emacs crashed:
    [adjust] matrix=0x80e1fc4d0 rows=0x0 alloc=0
window_desired_matrix=0x80efa2e60 MATCH=False
    [adjust] matrix=0x80e1fc540 rows=0x0 alloc=0
window_desired_matrix=0x80efa2e60 MATCH=False
    [adjust] matrix=0x80e1fc7e0 rows=0x0 alloc=0
window_desired_matrix=0x80efa2e60 MATCH=False
    [adjust] matrix=0x80e1fc850 rows=0x0 alloc=0
window_desired_matrix=0x80efa2e60 MATCH=False
    ... none of the new structs equals the old desired matrix; the old
    struct (0x80efa2e60) was freed; display_line crashes afterwards at
    xdisp.c:26855 (it->current_y += row->height) reading the freed row.

  run where the guard FIRED:
    [adjust] matrix=0xbd8faf870 rows=0x0 alloc=0
window_desired_matrix=0xbd8faf870 MATCH=True
    ... note rows == NULL and rows_allocated == 0: this is also a
    brand-new struct -- malloc just happened to reuse the freed old
    struct's address, so the pointer comparison matched by accident.

So `matrix == window_desired_matrix' compares against a pointer that
is dangling by the time the comparison runs; whether it matches is
heap-layout luck.  (I suspect the same was true when it "avoided the
trouble" on your machine.)

This also means the crashing scenario is slightly different from what
the patch assumes: the desired matrix is not enlarged behind
redisplay's back -- it is destroyed and replaced.  Perhaps the check
belongs where matrices are freed or detached from the window rather
than (only) in adjust_glyph_matrix: e.g. remember the window (or
compare w->desired_matrix against the matrix captured at
handle_fontified_prop time after the fontification call returns), or
error in free_glyph_matrix when it is called on window_desired_matrix.
The post-fontification check in handle_fontified_prop could then
detect "w->desired_matrix != saved pointer" and abort the window's
redisplay the way your patch already does.

Two smaller observations, in case they matter:

  - disable_fontification_functions_p is never reset, so one offense
    permanently disables fontification in that buffer (until it is
    killed).  Maybe intended as punishment, but a buffer whose hook
    misbehaved once (e.g. transiently, via some state in another
    library) stays unfontified with no way back that I can see short
    of killing it.

  - The crash backtrace in the guard-miss case is the same as in my
    original report: try_window (xdisp.c:21693) -> display_line
    reading the stale ROW right after the fontification call returns.

One more scope finding: fontification-functions is not the only
Lisp-during-window-redisplay entry point that can do this.  The same
evil call fired from a mode-line :eval form also crashes the patched
build (SIGSEGV inside display_mode_line <- display_mode_lines), and
window_desired_matrix is not set around mode-line evaluation, so the
new guard cannot see it at all:

;;; repro-modeline.el --- emacs -Q -l repro-modeline.el
(defvar my-armed nil)
(setq-default
 mode-line-format
 (list "%b "
       '(:eval (progn
                 (when my-armed
                   (setq my-armed nil)
                   (delete-other-windows))
                 ""))))
(defun my-go ()
  (switch-to-buffer (get-buffer-create "*top*"))
  (split-window-below)
  (select-window (next-window))        ; select bottom window
  (switch-to-buffer (get-buffer-create "*bottom*"))
  (run-at-time 0.5 nil (lambda ()
                         (setq my-armed t)
                         (force-mode-line-update t)
                         (redisplay t)
                         (kill-emacs 0))))
(add-hook 'window-setup-hook #'my-go)
;;; end

Here the top window's mode line is being displayed when the :eval form
deletes that very window, so the mode-line display continues with
freed matrices.  I mention it because a fix scoped to
fontification-functions would still leave this (and presumably
header-line/tab-line eval, window-scroll-functions, etc.) exposed;
whatever invariant the fix enforces probably wants to hold for any
Lisp called from inside the window-redisplay loop.

Happy to run further instrumented tests or try a revised patch.

Information forwarded to bug-gnu-emacs@HIDDEN:
bug#81407; Package emacs. Full text available.

Message received at 81407 <at> debbugs.gnu.org:

Received: (at 81407) by debbugs.gnu.org; 16 Jul 2026 10:05:52 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Thu Jul 16 06:05:52 2026
Received: from localhost ([127.0.0.1]:56320 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1wkIyV-0006dF-AG
	for submit <at> debbugs.gnu.org; Thu, 16 Jul 2026 06:05:51 -0400
Received: from eggs.gnu.org ([2001:470:142:3::10]:35460)
 by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
 (Exim 4.84_2) (envelope-from <eliz@HIDDEN>) id 1wkIyS-0006cy-Si
 for 81407 <at> debbugs.gnu.org; Thu, 16 Jul 2026 06:05:49 -0400
Received: from fencepost.gnu.org ([2001:470:142:3::e])
 by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
 (Exim 4.90_1) (envelope-from <eliz@HIDDEN>)
 id 1wkIyN-0003cj-Bd; Thu, 16 Jul 2026 06:05:43 -0400
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org;
 s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date:
 mime-version; bh=4102N61cYf2XbtdbKjPVTz0kL8qGNS/Gvush/fBoSvE=; b=nw3qf4lZpNW/
 +qCNLeQNPJJlDLcuu7U8S4NQEl1FVaRRs50/6S8ICrCoOHR+IRgrg5XTITSaO2PDrX++7q1xb0vOy
 x0EIArjlvJfy4InTdX9d6m6+KHsHR5wiwNczju9GCZc7hyOQtWan3GdHO1RvThnEvlTQKHAJzTexK
 8C/a3A8k/KNxx1OoWaZbvAcsqPfXD1yfouz/E7KlFchA9Z3lrqM2MuTv3Pu1oY6cH2OiH2OMryCKp
 WJrtHmQGqLF+xLzAMq28HAiSLXwgxkgczSl0naPGsUY7OUDOtIuZhper/w0l2njX1uWA5QEnIWJKg
 6BIl6EDHOE+sKVCg0mLs6Q==;
Date: Thu, 16 Jul 2026 13:05:33 +0300
Message-Id: <86y0fb1c7m.fsf@HIDDEN>
From: Eli Zaretskii <eliz@HIDDEN>
To: Aaron Iba <ai@HIDDEN>
In-Reply-To: <CAH_c0bdSVwQezySQFm3QxRgAU9dY455b-+wMSq8MXRXq6eNoxQ@HIDDEN>
 (message from Aaron Iba on Wed, 15 Jul 2026 09:23:56 -0400)
Subject: Re: bug#81407: 31.0.90; Crash in display_line: stale glyph_row after
 window-config change from menu-bar :enable eval during redisplay
References: <CAH_c0bczVJoqNthKnZD-rMEG8Zx0n6dpfgRcc8GjqSftVho3AQ@HIDDEN>
 <865x2hg2fi.fsf@HIDDEN>
 <CAH_c0bf0VhXMURra2MBdkpUnAbNZi-nAoLFBY44gB_+sbgqd=Q@HIDDEN>
 <86ldbc2z6e.fsf@HIDDEN>
 <CAH_c0bdSVwQezySQFm3QxRgAU9dY455b-+wMSq8MXRXq6eNoxQ@HIDDEN>
X-Spam-Score: -2.3 (--)
X-Debbugs-Envelope-To: 81407
Cc: 81407 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)

> From: Aaron Iba <ai@HIDDEN>
> Date: Wed, 15 Jul 2026 09:23:56 -0400
> Cc: 81407 <at> debbugs.gnu.org
> 
> > We need something smarter, and perhaps more radical.  Let me think
> > about this.
> 
> Understood, and agreed on the infloop risk: in the recipe the second
> pass happens to stabilize only because the rows array moves just when
> the window exceeds its historical maximum height, so a retry
> succeeds; Lisp that alternates between two window configurations
> would defeat any plain retry scheme.  Happy to test whatever you
> settle on -- I can reproduce at will, both with the -Q recipe and
> with the original configuration.

Try the patch below, it seems to avoid the trouble here.

diff --git a/src/buffer.h b/src/buffer.h
index 986cc6f..208fac3 100644
--- a/src/buffer.h
+++ b/src/buffer.h
@@ -715,6 +715,8 @@ #define BVAR(buf, field) ((buf)->field ## _)
      display optimizations must be used.  */
   bool_bf long_line_optimizations_p : 1;
 
+  bool_bf disable_fontification_functions_p : 1;
+
   /* The interval tree containing this buffer's overlays. */
   struct itree_tree *overlays;
 
diff --git a/src/dispextern.h b/src/dispextern.h
index 357504d..6da86cb 100644
--- a/src/dispextern.h
+++ b/src/dispextern.h
@@ -1153,6 +1153,9 @@ #define CHECK_MATRIX(MATRIX) ((void) 0)
 #endif
 };
 
+/* The desired_matrix used by redisplay_window, to allow detection of
+   reallocation behind its back.  */
+extern struct glyph_matrix *window_desired_matrix;
 
 /* Get a pointer to row number ROW in matrix MATRIX.  If GLYPH_DEBUG
    is defined, the function matrix_row checks that we don't try to
diff --git a/src/dispnew.c b/src/dispnew.c
index dd799c6..be936ac 100644
--- a/src/dispnew.c
+++ b/src/dispnew.c
@@ -413,6 +413,15 @@ adjust_glyph_matrix (struct window *w, struct glyph_matrix *matrix, int x, int y
   /* Enlarge MATRIX->rows if necessary.  New rows are cleared.  */
   if (matrix->rows_allocated < dim.height)
     {
+      /* Don't allow reallocation of the desired matrix while it is
+         being used by redisplay_window and its subroutines.  */
+      if (matrix == window_desired_matrix)
+	{
+	  eassert (BUFFERP (w->contents));
+	  XBUFFER (w->contents)->disable_fontification_functions_p = 1;
+	  error ("fontification-functions cause glyph matrix reallocation; disabled");
+	}
+
       int old_alloc = matrix->rows_allocated;
       new_rows = dim.height - matrix->rows_allocated;
       matrix->rows = xpalloc (matrix->rows, &matrix->rows_allocated,
@@ -495,6 +504,15 @@ adjust_glyph_matrix (struct window *w, struct glyph_matrix *matrix, int x, int y
 	  || header_line_changed_p
 	  || marginal_areas_changed_p)
 	{
+	  /* Don't allow reallocation of the desired matrix while it is
+             being used by redisplay_window and its subroutines.  */
+	  if (matrix == window_desired_matrix)
+	    {
+	      eassert (BUFFERP (w->contents));
+	      XBUFFER (w->contents)->disable_fontification_functions_p = 1;
+	      error ("fontification-functions cause glyph matrix reallocation; disabled");
+	    }
+
 	  struct glyph_row *row = matrix->rows;
 	  struct glyph_row *end = row + matrix->rows_allocated;
 
diff --git a/src/window.c b/src/window.c
index 78a5a44..97766c6 100644
--- a/src/window.c
+++ b/src/window.c
@@ -3709,11 +3709,11 @@ DEFUN ("delete-other-windows-internal", Fdelete_other_windows_internal,
 	}
     }
 
+  FRAME_WINDOW_CHANGE (f) = true;
+
   adjust_frame_glyphs (f);
   unblock_input ();
 
-  FRAME_WINDOW_CHANGE (f) = true;
-
   return Qnil;
 }
 
diff --git a/src/xdisp.c b/src/xdisp.c
index caea8e7..81ac6dc 100644
--- a/src/xdisp.c
+++ b/src/xdisp.c
@@ -822,6 +822,11 @@ #define MAX_SCRATCH_GLYPHS 100
 
 bool help_echo_showing_p;
 
+/* The desired_matrix used by redisplay_window, to allow detection of
+   reallocation behind its back.  */
+
+struct glyph_matrix *window_desired_matrix;
+
 /* The maximum distance to look ahead for text properties.  Values
    that are too small let us call compute_char_face and similar
    functions too often which is expensive.  Values that are too large
@@ -4669,7 +4674,8 @@ handle_fontified_prop (struct it *it)
   Lisp_Object prop, pos;
   enum prop_handled handled = HANDLED_NORMALLY;
 
-  if (!NILP (Vmemory_full))
+  if (!NILP (Vmemory_full)
+      || current_buffer->disable_fontification_functions_p)
     return handled;
 
   /* Get the value of the `fontified' property at IT's current buffer
@@ -4719,6 +4725,11 @@ handle_fontified_prop (struct it *it)
 	 clear our face and image caches behind our back.  */
       it->f->inhibit_clear_image_cache = true;
 
+      /* Allow detection of reallocation of the desired glyph matrix due
+         to Lisp code in 'fontification-functions'.  */
+      struct glyph_matrix *saved_matrix = window_desired_matrix;
+      window_desired_matrix = it->w->desired_matrix;
+
       if (!CONSP (val) || EQ (XCAR (val), Qlambda))
 	dsafe_call1 (val, pos);
       else
@@ -4752,6 +4763,7 @@ handle_fontified_prop (struct it *it)
 	    }
 	}
 
+      window_desired_matrix = saved_matrix;
       it->f->inhibit_clear_image_cache = saved_inhibit_flag;
       unbind_to (count, Qnil);
 
@@ -4779,6 +4791,14 @@ handle_fontified_prop (struct it *it)
 	 into face properties (bug#7876).  */
       it->end_charpos = ZV;
 
+      if (current_buffer->disable_fontification_functions_p)
+	{
+	  if (it->w->desired_matrix)
+	    it->w->desired_matrix->no_scrolling_p = true;
+	  it->f->fonts_changed = true;
+	  error ("misbehaving fontification, redisplay of window aborted");
+	}
+
       /* Return HANDLED_RECOMPUTE_PROPS only if function fontified
 	 something.  This avoids an endless loop if they failed to
 	 fontify the text for which reason ever.  */

Information forwarded to bug-gnu-emacs@HIDDEN:
bug#81407; Package emacs. Full text available.

Message received at 81407 <at> debbugs.gnu.org:

Received: (at 81407) by debbugs.gnu.org; 15 Jul 2026 13:24:24 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Wed Jul 15 09:24:23 2026
Received: from localhost ([127.0.0.1]:48986 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1wjzb2-0006td-VB
	for submit <at> debbugs.gnu.org; Wed, 15 Jul 2026 09:24:23 -0400
Received: from mail-lf1-x132.google.com ([2a00:1450:4864:20::132]:55580)
 by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128)
 (Exim 4.84_2) (envelope-from <ai@HIDDEN>) id 1wjzay-0006rb-14
 for 81407 <at> debbugs.gnu.org; Wed, 15 Jul 2026 09:24:18 -0400
Received: by mail-lf1-x132.google.com with SMTP id
 2adb3069b0e04-5b021916bd3so4517105e87.3
 for <81407 <at> debbugs.gnu.org>; Wed, 15 Jul 2026 06:24:15 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; t=1784121849; cv=none;
 d=google.com; s=arc-20260327;
 b=dVj8IdJtOS/0a9qufgXHWqJQAx6Ri6DFJ8Kr16ASlf7WzAP+u9dzjrB83nFXXgm5tz
 NIqjVt8ic/r/dK090UKgMgEJqurVS/H1lcgqfJ+Cj0v1O+17r114NL7djaTqazBUo5Kf
 GML33rCnqoPMP+BrByAKEnNbr4z1KildmhWxKsxIPGwaryX9MIfwSkAi9J5eqnxxZkjv
 NjMEIHbjGMR20Ndf3HeNqe10VJi/5qZK9EeBeolbGgsiq8QdDY0ZwCMockO/9w/dFm6v
 +de5Nv9fUQIk4/JQSu1eXofR+Ng/4rnlgb/sYEBHs8pEzqRfq/iCnlNamoruibMRUYiE
 dgzw==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com;
 s=arc-20260327; 
 h=cc:to:subject:message-id:date:from:in-reply-to:references
 :mime-version:dkim-signature;
 bh=DRuG34QPbdmHjAOHae5R6z1a1GOWrYriPS1YdHxPYv0=;
 fh=E1mpT6rvccdR4r/KFkbsjcsUW8fJe6FkaoIi2mehYwI=;
 b=kBdtxSIBeYs38ZdIysHVUkHIpHC7pJEoVbHC3DJ0fPbAGYpoqFbgKRjsbgEnKJnmh4
 +fTII+fbXx17z1HJyMb0Y82KsOhY+0Qg/wXjm/09hv5nuKFARL1JWpjBifv1dYxma9ZC
 tDQyEKDUI2DyT7RZ2ERXn4DLOaaeEESQir9c+zexwWyPNdxQYD4pg+262HKpbk7W7s22
 kpHIHEfptIlV07o/CndGN9mQw4xplB4UXOlAaTokx0GfCQYCEuUlaHz1tfKKzX9Dft8Z
 F2U1B9UnWRuEkS5l85N+Ka8As97y1zAv0nvg0L9ohAXl0cC+UO2tbl/dMEBuTF75+i8x
 YbQg==; darn=debbugs.gnu.org
ARC-Authentication-Results: i=1; mx.google.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=aaroniba.net; s=google; t=1784121849; x=1784726649; darn=debbugs.gnu.org;
 h=content-type:cc:to:subject:message-id:date:from:in-reply-to
 :references:mime-version:from:to:cc:subject:date:message-id:reply-to
 :content-type; bh=DRuG34QPbdmHjAOHae5R6z1a1GOWrYriPS1YdHxPYv0=;
 b=BVUt6Kf/tRg+pch/98bK3yNS1bYMHmoa5lcCMfI+CKNRJ0NhzKOlhgZ56GDPdvhWpl
 0vew7gCasSj04Qy6qEIDVpreoS7DGc5DNQWTple9etRQ7VcxhjBllxT3C0HoMyHtYZNO
 wJSauUo5VJo4oMnZPyzysyPhSINZVRRjG83ot3VxeO5z5P67xelDudv/QtiKtTZoAUy8
 KWvHKLDf63muM/nKRER0GmGvCONUcbfd1UB1sDc9T9paBmTpwk/yk5IK2O8CvOS0HvJ/
 oyEjNlWrgd3O/BErnqeVoYO3DelIf1G2UqFXcTWhiNUkUgjEpwNcvJm5k1ufugO8NA3e
 cA5A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20251104; t=1784121849; x=1784726649;
 h=content-type:cc:to:subject:message-id:date:from:in-reply-to
 :references:mime-version:x-gm-gg:x-gm-message-state:from:to:cc
 :subject:date:message-id:reply-to:content-type;
 bh=DRuG34QPbdmHjAOHae5R6z1a1GOWrYriPS1YdHxPYv0=;
 b=aaEVknfyEX55mAfK1NuC6HGhPz6jSBuZOl2LLS8do+YU5NIT3zdmRWhWMG7XrAC6El
 2My5EE7fG2JaRMC0VYzWUGbzdRHirzNlc+KR3KP4hQXssX9Z3N5ymq+/Y/WN/cWsFe0b
 ZrlLIAGYTSppILxnVL4uEbZuvphLDOOYmgoi9XMSYa9TZgLpF+GFl6yfZq+aWK9mnBwm
 WJ+hPAvZ82eJG9J0E6FMyjyX/LzY2DjTV6ml/fdG4qkmK1l9/ywkM6HvbU3P6wdqvem6
 Uv0wIbgZ5llicFu1C4cmlVR2rk+KECF4gBzGXlbt1VcCiWTGVffwoi6Nu7ijeUD/4gKe
 kY7g==
X-Gm-Message-State: AOJu0Yzi+S4IHtyd2IxfqjFnP1uoQAAKABYQmRMMVN7pzc+aOcQ1CwyS
 6NDZ+Yn+lhUaue3Hynmc/omNmEMibjalFoLTBMBbYltca6m05KkiLRlBpEvYkkfHef+rG4rouqi
 /h/Mw7CM5HTeVyGoobJTw03Oc3cD12YWK4beAsEKqlYPrMEFtqu0ysA==
X-Gm-Gg: AfdE7cmE3h+rcumW7uYyhm6CXlmggtqJejJuzcZVHLvCnc7I8KHtt8XrjHeSdhYnitb
 HXCR5ty4bCNDW552V2BxM2u8GrodDndTKFW3+riNZQYl7nuYVzwDR5tkATYVgrn5Gs63QV4ehXg
 sX00LUOdNTHuAVbDRjTcvSO3NBmRhsu0qfB1dEPOOVWf7PdPXhFErvw1oNsIIPtbC/hNmu9Talk
 pXBUpV7pixkJJXrMbQhqDUU1ksNlJy2iNazLXYriQF7goF6FYsDb2R9+Sl6yOyWPZJDVMeCNjTR
 gDkOrrZTDK8eLSaUdzFRF1VmA979
X-Received: by 2002:a05:6512:66da:b0:5b0:1f61:f5e with SMTP id
 2adb3069b0e04-5b15d79d300mr445069e87.33.1784121849209; Wed, 15 Jul 2026
 06:24:09 -0700 (PDT)
MIME-Version: 1.0
References: <CAH_c0bczVJoqNthKnZD-rMEG8Zx0n6dpfgRcc8GjqSftVho3AQ@HIDDEN>
 <865x2hg2fi.fsf@HIDDEN>
 <CAH_c0bf0VhXMURra2MBdkpUnAbNZi-nAoLFBY44gB_+sbgqd=Q@HIDDEN>
 <86ldbc2z6e.fsf@HIDDEN>
In-Reply-To: <86ldbc2z6e.fsf@HIDDEN>
From: Aaron Iba <ai@HIDDEN>
Date: Wed, 15 Jul 2026 09:23:56 -0400
X-Gm-Features: AUfX_mw9-9QTAByy8-pNYGee58_7L-ew3AFoVxD4J-Pq41hor4qLH8emoZOAVmc
Message-ID: <CAH_c0bdSVwQezySQFm3QxRgAU9dY455b-+wMSq8MXRXq6eNoxQ@HIDDEN>
Subject: Re: bug#81407: 31.0.90; Crash in display_line: stale glyph_row after
 window-config change from menu-bar :enable eval during redisplay
To: Eli Zaretskii <eliz@HIDDEN>
Content-Type: text/plain; charset="UTF-8"
X-Spam-Score: 0.0 (/)
X-Debbugs-Envelope-To: 81407
Cc: 81407 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)

> Is that what the original code you found in your real-life use case
> does -- calls delete-other-windows from a function in
> fontification-functions?  If not, what does it do, exactly?

No.  In the real-life case nothing looks like it touches windows at
all -- the delete-other-windows is buried two libraries down inside
what its callers use as a pure predicate.  The exact chain, captured
with a breakpoint on adjust_frame_glyphs (Lisp frames are
native-compiled .eln in this session):

  adjust_glyph_matrix
  allocate_matrices_for_window_redisplay
  adjust_frame_glyphs
  Fdelete_other_windows_internal
  delete-other-windows                 ; window.el
  persp-reset-windows                  ; perspective.el
  persp-activate                       ;   (persp-switch restores a
  persp-switch                         ;    saved window configuration)
  persp-current-buffers*               ; perspective.el
  persp-is-current-buffer              ; perspective.el
  ...seq-filter over session list...   ; my configuration (advice)
  sesman-current-session               ; sesman.el
  cider-repls                          ; CIDER
  cider-current-repl
  cider-connected-p                    ; CIDER's menu-bar :enable form
  eval_sub / internal_condition_case_1
  menu_item_eval_property
  parse_menu_item
  menu_bar_item / map_keymap / menu_bar_items
  update_menu_bar
  redisplay_internal

What happens is: CIDER's menu has items with :enable forms like
(cider-connected-p).  Evaluating that consults sesman for the current
session; an advice in my configuration filters the session list by
perspective using perspective.el's persp-is-current-buffer.  That
predicate, when asked to also consider the "frame global" perspective,
internally does a `with-perspective' round trip: persp-switch to the
global perspective and back, where each switch restores a saved window
configuration, and persp-activate additionally runs
delete-other-windows via persp-reset-windows.  So "is this buffer in
the current perspective?" destroys and rebuilds the frame's window
configuration -- twice.  (I've since fixed my configuration to read
the perspective's buffer list directly, and submitted the same fix to
perspective.el.)

One honest caveat: the capture above is from the menu-update phase,
which as you explained is benign by itself.  The predicate is invoked
from CIDER/sesman in several contexts, and I fixed my configuration
before capturing which in-window-loop entry point invoked it in the
actual crash cycles; candidates present in that setup are mode-line
:eval segments (doom-modeline) and jit-lock.  If the exact real-life
entry point would inform the fix, I can temporarily restore the broken
configuration under the debugger and produce a chronological trace of
adjust_frame_glyphs calls vs. the corrupting store -- the
instrumentation is ready.  The emacs -Q recipe was my attempt to
distill the mechanism without the third-party stack.

> We need something smarter, and perhaps more radical.  Let me think
> about this.

Understood, and agreed on the infloop risk: in the recipe the second
pass happens to stabilize only because the rows array moves just when
the window exceeds its historical maximum height, so a retry
succeeds; Lisp that alternates between two window configurations
would defeat any plain retry scheme.  Happy to test whatever you
settle on -- I can reproduce at will, both with the -Q recipe and
with the original configuration.

Information forwarded to bug-gnu-emacs@HIDDEN:
bug#81407; Package emacs. Full text available.

Message received at 81407 <at> debbugs.gnu.org:

Received: (at 81407) by debbugs.gnu.org; 15 Jul 2026 12:52:08 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Wed Jul 15 08:52:08 2026
Received: from localhost ([127.0.0.1]:48804 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1wjz5r-0003GP-Bv
	for submit <at> debbugs.gnu.org; Wed, 15 Jul 2026 08:52:07 -0400
Received: from eggs.gnu.org ([2001:470:142:3::10]:50258)
 by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
 (Exim 4.84_2) (envelope-from <eliz@HIDDEN>) id 1wjz5o-0003Fn-DH
 for 81407 <at> debbugs.gnu.org; Wed, 15 Jul 2026 08:52:05 -0400
Received: from fencepost.gnu.org ([2001:470:142:3::e])
 by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
 (Exim 4.90_1) (envelope-from <eliz@HIDDEN>)
 id 1wjz5i-0000FJ-2u; Wed, 15 Jul 2026 08:51:58 -0400
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org;
 s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date:
 mime-version; bh=vkQbgAfHouaqRWNjUDIs79FmblpcTgnECGmRrzMxCA8=; b=DdRGd0qUh1we
 +WmNN9s2dGszGrSmO7TAlKAnGIN3EzueNayiy+Og/xrXZ5qYQOhBBhzDPtvc4Lvw//ws8ki3RmT8Q
 QIcXtdFj+DkE6asqepp4Ab6dU5w3lHilY20oNVddWvdE/cqCT7EACocJmwBo1bRr+inzjXUFYIpW0
 izRLuyxV8+0/XHON5R8nNqCPBum2XTuNAal5Zixa3rowF2ozcchHl1C6iWn79SFrn9dsHf1orKwqa
 TX96AII0yTOrIbimJlnEm3u/8UXRMt2zE4j44O2yBYu+vyLrKl8VoIXW97fzJD+mHk1jlQAE0VFPZ
 FtCij6AbKTUeX+24mvFc4A==;
Date: Wed, 15 Jul 2026 15:51:53 +0300
Message-Id: <86ldbc2z6e.fsf@HIDDEN>
From: Eli Zaretskii <eliz@HIDDEN>
To: Aaron Iba <ai@HIDDEN>
In-Reply-To: <CAH_c0bf0VhXMURra2MBdkpUnAbNZi-nAoLFBY44gB_+sbgqd=Q@HIDDEN>
 (message from Aaron Iba on Tue, 14 Jul 2026 13:07:27 -0400)
Subject: Re: bug#81407: 31.0.90; Crash in display_line: stale glyph_row after
 window-config change from menu-bar :enable eval during redisplay
References: <CAH_c0bczVJoqNthKnZD-rMEG8Zx0n6dpfgRcc8GjqSftVho3AQ@HIDDEN>
 <865x2hg2fi.fsf@HIDDEN>
 <CAH_c0bf0VhXMURra2MBdkpUnAbNZi-nAoLFBY44gB_+sbgqd=Q@HIDDEN>
X-Spam-Score: -2.3 (--)
X-Debbugs-Envelope-To: 81407
Cc: 81407 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)

> From: Aaron Iba <ai@HIDDEN>
> Date: Tue, 14 Jul 2026 13:07:27 -0400
> Cc: 81407 <at> debbugs.gnu.org
> 
> > Please show a backtrace when the above line computes a bogus value of
> > cursor's vpos.  set_cursor_from_row is called from many places, and
> > it's important to know which one(s) cause this.
> 
> It is display_line's own call at the end of the function ("Maybe set
> the cursor", xdisp.c ~26838), with MATRIX = it->w->desired_matrix.
> Full backtrace from the conditional breakpoint on the vpos store:
> 
>   * frame #0: Emacs`set_cursor_from_row + 3676   ; str w8,[x28,#0x19c]
>     frame #1: Emacs`display_line + 9740
>     frame #2: Emacs`try_window + 200
>     frame #3: Emacs`redisplay_window + 10932
>     frame #4: Emacs`redisplay_window_0 + 44
>     frame #5: Emacs`internal_condition_case_1 + 100
>     frame #6: Emacs`redisplay_windows + 156
>     frame #7: Emacs`redisplay_windows + 128
>     frame #8: Emacs`redisplay_internal + 5120
>     frame #9: Emacs`read_char + 2148
>     frame #10: Emacs`read_key_sequence + 1200
>     frame #11: Emacs`command_loop_1 + 708
>     ...
> 
> At that stop, ROW (= display_line's local `row', i.e. it->glyph_row)
> was 0x780344308 while matrix->rows was 0x78034e000 -- ROW pointed into
> a freed rows allocation.  So this is not reuse of a stale
> current_matrix: the enabled_p protection never enters the picture,
> because the dangling pointers are the desired-matrix row pointers held
> by the *running* try_window/display_line iteration (it->glyph_row and
> friends).  Depending on where the reallocation lands within the line
> loop, the same corruption instead crashes while writing glyphs through
> the stale row:
> 
>   * frame #0: Emacs`gui_produce_glyphs + 6656
>     frame #1: Emacs`display_line + 1312
>     frame #2: Emacs`try_window + 200
>     frame #3: Emacs`redisplay_window + 10932
>     ...

Thanks, now this begins to make sense.

> > It would be very useful if you could provide a reproducible recipe
> > starting from "emacs -Q" and without loading any packages that
> > aren't part of Emacs.
> 
> Done -- recipe below.

Thanks.

> > My reading of the code is that where redisplay_internal calls
> > prepare_menu_bars, redisplay didn't yet start [...] So it is not
> > clear to me what exactly should we "restart" here.
> 
> You are right about prepare_menu_bars, and I withdraw that part of my
> suggestion: matrix reallocation from the menu-update phase is benign
> on its own, and my instrumented traces confirm reallocations from
> update_menu_bar happen before the window loop.  In my original
> configuration the same window-configuration change was reachable
> through more than one path, and the one that corrupts is the
> fontification path (or anything else evaluated from within the window
> loop).  The -Q recipe demonstrates that path with no third-party code.

Is that what the original code you found in your real-life use case
does -- calls delete-other-windows from a function in
fontification-functions?  If not, what does it do, exactly?

> Given that, a possible shape for the real fix: after
> handle_fontified_prop returns (it already anticipates that
> fontification can change things), also detect that the window's
> desired matrix was adjusted -- e.g. compare w->desired_matrix->rows
> against the value captured when the window's redisplay started, or
> bump a generation counter in adjust_glyph_matrix -- and abort
> try_window with the same kind of retry that fonts_changed gets.

Thanks, but I'm not sure this is the correct fix.  First, the callers
of display_line not always return right away when f->fonts_changed
flag is set.  Moreover, this flag can be masked if try_window is
called with a specific value of FLAGS.  More importantly, what to do
after aborting the display_line call?  Restarting redisplay, which is
what we do in other cases of the fonts_changed flag set, is not
necessarily TRT, because depending on what the "evil Lisp" does, it
could do that again and again, in which case we have a redisplay
infloop (which will lock up Emacs).

We need something smarter, and perhaps more radical.  Let me think
about this.

Information forwarded to bug-gnu-emacs@HIDDEN:
bug#81407; Package emacs. Full text available.

Message received at 81407 <at> debbugs.gnu.org:

Received: (at 81407) by debbugs.gnu.org; 15 Jul 2026 04:17:17 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Wed Jul 15 00:17:16 2026
Received: from localhost ([127.0.0.1]:46010 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1wjr3X-0005U9-N7
	for submit <at> debbugs.gnu.org; Wed, 15 Jul 2026 00:17:16 -0400
Received: from mail-lf1-x12f.google.com ([2a00:1450:4864:20::12f]:47117)
 by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128)
 (Exim 4.84_2) (envelope-from <ai@HIDDEN>) id 1wjgbj-0008G6-Hg
 for 81407 <at> debbugs.gnu.org; Tue, 14 Jul 2026 13:07:52 -0400
Received: by mail-lf1-x12f.google.com with SMTP id
 2adb3069b0e04-5b01cb18515so4266125e87.2
 for <81407 <at> debbugs.gnu.org>; Tue, 14 Jul 2026 10:07:47 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; t=1784048861; cv=none;
 d=google.com; s=arc-20260327;
 b=If8ByDyd3ETNu8fFHWw3MkiQuRlRW7w/Tpdp0dIEaZ8yTVR39SIdtoIx/GPE3P6UbB
 j4yII6HGUJ1fQ519Obl0KDehYQC5+i2f7CviJKPbarex6Y5mm5va3zSTQ0XIOYFoLZtH
 HITW3NCeeNXO13qkW7hWgfYItkSeaX4Fe8WX2FW9d3wVzb0zaXncAZLUwKlHbf8ko7bs
 z6C4Wjby2QazdWI1hsALXFlsAPZm8TW2IM+2wWC+lkIFH0s/2GGGHL+1hENFUx2bP2UP
 vnWOMliQwoHEEEDbelwYytiSI73TsNNQEm9Y6ldpc6KeLU8lgfbdAuxB4yPlN7tqpjUF
 tbSw==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com;
 s=arc-20260327; 
 h=cc:to:subject:message-id:date:from:in-reply-to:references
 :mime-version:dkim-signature;
 bh=ypoP/5pW8mFSu6IaXnvUS43rJT5o389IsXrEvO4xMlQ=;
 fh=E1mpT6rvccdR4r/KFkbsjcsUW8fJe6FkaoIi2mehYwI=;
 b=NXsmFlK7TLzRhmRvTUbNFMJSiLcuA7ezMAB32k3zHkvOXr18SBMMvxmPMeLtlNaLBK
 Z2jq3ot+VJoxLJuLr5CRhWR1cGFXkvJjaQ+D5EEON6UJaZRiLAT79SAj/eDUDPM5Yz/w
 aB7rOmSTJYHRUzOZXvq7uXBQCUp9/WVPSUwhw7Kzzikgbril4MH6tpYKC4KgDwaiIjIX
 p6aVH0XKS0EFhXhk6gOhWWnZPgaOf+27b2v7lb70qGWe94HoOWmnNkinC59zmFCNQxSz
 AcGVZvacB+3huo3Kr/xCbo+ZGsivlVSOiWZv+jEH8HpocOi/jY2o353GZESJ7oMY0SHr
 gK2Q==; darn=debbugs.gnu.org
ARC-Authentication-Results: i=1; mx.google.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=aaroniba.net; s=google; t=1784048861; x=1784653661; darn=debbugs.gnu.org;
 h=content-type:cc:to:subject:message-id:date:from:in-reply-to
 :references:mime-version:from:to:cc:subject:date:message-id:reply-to
 :content-type; bh=ypoP/5pW8mFSu6IaXnvUS43rJT5o389IsXrEvO4xMlQ=;
 b=h7cmI9cYzADynPubwWdqgv/HCPx3mU3xsmLx9Nm+Vfb2hJJgVRWQgThNx+Rqk7PIBu
 Ixa0s0iY0245ASTvCtVi41p8TVEfh9rJOEKBQsJrtOtB1W+nzFJmHCBgFStxL/bdkc0v
 ssIpVplog/ncMIfSOgYP0jV3ytoeYhmDlwCNtgVarLV4HY46CjF6jJbzm6F44XdTZC6y
 ZP9wdLapH5Ijv3pHXwiazHh9F0DlIYsjMh79l9ce9z+UOmwh1IjF8pmANC9nLxh0neg3
 t9MtlnubQ/BOqNRqV6M5f7kqMhBMQ0wI23yDunSNVredJl6q+NmEbzQtAmSLZBnRNKKn
 2MXA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20251104; t=1784048861; x=1784653661;
 h=content-type:cc:to:subject:message-id:date:from:in-reply-to
 :references:mime-version:x-gm-gg:x-gm-message-state:from:to:cc
 :subject:date:message-id:reply-to:content-type;
 bh=ypoP/5pW8mFSu6IaXnvUS43rJT5o389IsXrEvO4xMlQ=;
 b=Yc6aXHfzl2+AqFhgx7TSTZWUb8yTnM9PZj6p6mBrIMSwQLNVzIdrAqdt3b+Xlw3HfH
 dnpYxa4sx07xJUgTkXTL0JEJ02Am1NnhmVtOo1ST2O9z2AjjBGqKu43gWppNuQZO7/D6
 MWLQ1Y+mtByDh+4QuGb5x6Dfzl1ivaH4/7HNYFFHB1TWeZob8V5JfLRTdQS0wJNpU7PD
 2N1kMm2FS0FKRwgKPtl625pECblmImkDNTOmJRct5LnQTklsADSPZCoTyalkQkGLk0sX
 +Uxl04jsw6+fUz96UOox4rb4ow8cO+zFhm1XR73fyp4hGBjiJlJ2+I16a6DgO8jo1AdC
 zKhA==
X-Gm-Message-State: AOJu0Yy0FoBcA5kT/DMFIAU9uot4XDkzTanFhfDvYEpabtK87XSGcVSt
 2ai58HKF3reuXHiu8iBUfexPBFzSczgppPphT9tRLOOcvdYq27hecr+qm/mbqq4RJwkXIRjAWYO
 8h0gDqiastefmsrZoQI5aHZKUJdXv5Fq/++ziejzWCDxHBGcSvbYM2Q==
X-Gm-Gg: AfdE7cnauJ2HcmpKm0HCINqgxhje1hHXJxhoQDyjNKguUfHeWimSL7jOQJo9eRFNUpU
 YhLLo0sPJgQTpftlu1Se0S6VXUIE7DTEEyfT5D6q6W8sAgO4nJWxCs2RXYlWy9dpD0M5Ncv8NzI
 0cvi/haK3CUqDzJbCsqhcqweUyzZ0D1jCXTyTcfR7Al/6P/pQWQY01jiSaTQI67XW/1yh7QB6sH
 EkFRCP9BUb3pW7F9UkkNsjAnM3Dhqo31g8mAv18Ab+9ilQ2PUlMaEiIKmvBrZP8qthCxD/WN8qV
 FR+9e9LqVdqK8ptGpRj9L4lOCfw19A==
X-Received: by 2002:a05:6512:3da7:b0:5ae:c34c:aefe with SMTP id
 2adb3069b0e04-5b159b8fd19mr668747e87.62.1784048860576; Tue, 14 Jul 2026
 10:07:40 -0700 (PDT)
MIME-Version: 1.0
References: <CAH_c0bczVJoqNthKnZD-rMEG8Zx0n6dpfgRcc8GjqSftVho3AQ@HIDDEN>
 <865x2hg2fi.fsf@HIDDEN>
In-Reply-To: <865x2hg2fi.fsf@HIDDEN>
From: Aaron Iba <ai@HIDDEN>
Date: Tue, 14 Jul 2026 13:07:27 -0400
X-Gm-Features: AUfX_my5r2BwUvswiHzPvG95VE_Yhd2O4dwTySxYtVHU2tZD8ai1dKPCFTaTVxM
Message-ID: <CAH_c0bf0VhXMURra2MBdkpUnAbNZi-nAoLFBY44gB_+sbgqd=Q@HIDDEN>
Subject: Re: bug#81407: 31.0.90; Crash in display_line: stale glyph_row after
 window-config change from menu-bar :enable eval during redisplay
To: Eli Zaretskii <eliz@HIDDEN>
Content-Type: text/plain; charset="UTF-8"
X-Spam-Score: 0.0 (/)
X-Debbugs-Envelope-To: 81407
X-Mailman-Approved-At: Wed, 15 Jul 2026 00:16:47 -0400
Cc: 81407 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)

> Please show a backtrace when the above line computes a bogus value of
> cursor's vpos.  set_cursor_from_row is called from many places, and
> it's important to know which one(s) cause this.

It is display_line's own call at the end of the function ("Maybe set
the cursor", xdisp.c ~26838), with MATRIX = it->w->desired_matrix.
Full backtrace from the conditional breakpoint on the vpos store:

  * frame #0: Emacs`set_cursor_from_row + 3676   ; str w8,[x28,#0x19c]
    frame #1: Emacs`display_line + 9740
    frame #2: Emacs`try_window + 200
    frame #3: Emacs`redisplay_window + 10932
    frame #4: Emacs`redisplay_window_0 + 44
    frame #5: Emacs`internal_condition_case_1 + 100
    frame #6: Emacs`redisplay_windows + 156
    frame #7: Emacs`redisplay_windows + 128
    frame #8: Emacs`redisplay_internal + 5120
    frame #9: Emacs`read_char + 2148
    frame #10: Emacs`read_key_sequence + 1200
    frame #11: Emacs`command_loop_1 + 708
    ...

At that stop, ROW (= display_line's local `row', i.e. it->glyph_row)
was 0x780344308 while matrix->rows was 0x78034e000 -- ROW pointed into
a freed rows allocation.  So this is not reuse of a stale
current_matrix: the enabled_p protection never enters the picture,
because the dangling pointers are the desired-matrix row pointers held
by the *running* try_window/display_line iteration (it->glyph_row and
friends).  Depending on where the reallocation lands within the line
loop, the same corruption instead crashes while writing glyphs through
the stale row:

  * frame #0: Emacs`gui_produce_glyphs + 6656
    frame #1: Emacs`display_line + 1312
    frame #2: Emacs`try_window + 200
    frame #3: Emacs`redisplay_window + 10932
    ...

> It would be very useful if you could provide a reproducible recipe
> starting from "emacs -Q" and without loading any packages that
> aren't part of Emacs.

Done -- recipe below.  Your naive attempt failed, I believe, for three
reasons: (1) pre-redisplay-function runs before any window is
redisplayed, so nothing is stale yet, exactly as you said about
prepare_menu_bars; the Lisp has to run from *inside* the window
redisplay loop, and fontification-functions (called via
handle_fontified_prop from display_line) is such a place; (2)
delete-other-windows is a no-op when there is only one window; and
(3), the subtle one: the rows array of a window's desired matrix only
moves when the window becomes TALLER than it has ever been, because
adjust_glyph_matrix reallocates rows only when rows_allocated <
dim.height, and rows_allocated never shrinks.  Width-only changes
(e.g. deleting a side-by-side window) never move the rows array and
never crash.  I verified both negative cases on my machine.

;;; repro-81407.el --- emacs -Q -l repro-81407.el
;; A window that has never been full-height grows to full height
;; mid-redisplay, from Lisp called by display_line via
;; fontification-functions.

(defvar my-armed nil)

(defun my-evil-fontify (pos)
  (put-text-property pos (point-max) 'fontified t)
  (when my-armed
    (setq my-armed nil)
    ;; Grow this window from ~half to full frame height, mid-redisplay.
    (delete-other-windows)))

(defun my-go ()
  (split-window-below)              ; the NEW bottom window: never been tall
  (select-window (next-window))
  (switch-to-buffer (get-buffer-create "*repro*"))
  (dotimes (i 30)
    (insert (format "line %d: the quick brown fox jumps over the lazy
dog\n" i)))
  (goto-char (point-max))           ; point row displayed after trigger rows
  (setq-local fontification-functions '(my-evil-fontify))
  (run-at-time
   0.5 nil
   (lambda ()
     (with-current-buffer "*repro*"
       (put-text-property (point-min) (point-max) 'fontified nil))
     (setq my-armed t)
     (redisplay t)
     (kill-emacs 0))))              ; only reached if we survived

(add-hook 'window-setup-hook #'my-go)
;;; end

On my machine (macOS 26.5, NS build, arm64) this crashes in roughly
half the runs -- whether it crashes or corrupts silently depends on
whether the freed rows block is still accessible, so a couple of
attempts may be needed; under a debugger it crashed on the first try.
On GNU/Linux, MALLOC_PERTURB_ (or valgrind) should make it
deterministic.  I have five crash reports from this recipe, all
SIGSEGV in gui_produce_glyphs <- display_line <- try_window.  I have
not tested on other platforms, but nothing in the mechanism looks
macOS-specific except the malloc behavior.

> My reading of the code is that where redisplay_internal calls
> prepare_menu_bars, redisplay didn't yet start [...] So it is not
> clear to me what exactly should we "restart" here.

You are right about prepare_menu_bars, and I withdraw that part of my
suggestion: matrix reallocation from the menu-update phase is benign
on its own, and my instrumented traces confirm reallocations from
update_menu_bar happen before the window loop.  In my original
configuration the same window-configuration change was reachable
through more than one path, and the one that corrupts is the
fontification path (or anything else evaluated from within the window
loop).  The -Q recipe demonstrates that path with no third-party code.

Given that, a possible shape for the real fix: after
handle_fontified_prop returns (it already anticipates that
fontification can change things), also detect that the window's
desired matrix was adjusted -- e.g. compare w->desired_matrix->rows
against the value captured when the window's redisplay started, or
bump a generation counter in adjust_glyph_matrix -- and abort
try_window with the same kind of retry that fonts_changed gets.  The
cvpos upper-bound check would then be defense-in-depth only, as you
say.

Happy to test patches; I can reproduce at will.

Information forwarded to bug-gnu-emacs@HIDDEN:
bug#81407; Package emacs. Full text available.

Message received at 81407 <at> debbugs.gnu.org:

Received: (at 81407) by debbugs.gnu.org; 14 Jul 2026 12:59:32 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Tue Jul 14 08:59:32 2026
Received: from localhost ([127.0.0.1]:39964 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1wjcjU-0001RK-2S
	for submit <at> debbugs.gnu.org; Tue, 14 Jul 2026 08:59:32 -0400
Received: from flow-a5-smtp.messagingengine.com ([103.168.172.140]:36149)
 by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
 (Exim 4.84_2) (envelope-from <spwhitton@HIDDEN>)
 id 1wjcjR-0001R7-Uq
 for 81407 <at> debbugs.gnu.org; Tue, 14 Jul 2026 08:59:30 -0400
Received: from phl-compute-05.internal (phl-compute-05.internal [10.202.2.45])
 by mailflow.phl.internal (Postfix) with ESMTP id 97ED013802CE;
 Tue, 14 Jul 2026 08:59:24 -0400 (EDT)
Received: from phl-frontend-04 ([10.202.2.163])
 by phl-compute-05.internal (MEProxy); Tue, 14 Jul 2026 08:59:24 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=spwhitton.name;
 h=cc:content-type:content-type:date:date:from:from:in-reply-to
 :in-reply-to:message-id:mime-version:references:reply-to:subject
 :subject:to:to; s=fm1; t=1784033964; x=1784041164; bh=zWN2/WP8ih
 qrXjxYy6qh2uipKVboOD1arAFB/pr1QUU=; b=muEhJL9Og1hoyklE5zAVINlme5
 OwwIzgOFLuq6E1X22/ed5LNnLBqNXy0SRDBI2ZhD7IPOzkLU4KiOOYDBw+BjGp0p
 gpzmyZugwAjgCYq/gKzFSXRqsey+npi9j/tx4jxEj+UUCF6w9TKjBev4nkf4hjAG
 Y9SQ9oXqXW/N3vHmV0JCgW4I7cmEQhdIRN+uYB1GmRVJcYJBAht+3Po0OZS+0WDH
 ZLkTzAH/KVfn2vb2XphZax3QulklkToqpnZf+x/bbVoShrEuN1+P7YybudHsTUhV
 VYdKEX2kvtX5zfjmLN0bo7ZYr9JHCuLGADVwRXl3RFCG0rNeKaAEOxmvVWtw==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=
 messagingengine.com; h=cc:content-type:content-type:date:date
 :feedback-id:feedback-id:from:from:in-reply-to:in-reply-to
 :message-id:mime-version:references:reply-to:subject:subject:to
 :to:x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm2; t=
 1784033964; x=1784041164; bh=zWN2/WP8ihqrXjxYy6qh2uipKVboOD1arAF
 B/pr1QUU=; b=WDqElb4R+KJoI0Yuizo1FeTHfnRYVjzAENb+58qquV6ywotdlen
 xrc0t39LpduoxpXVksoILqgqAO7QdYKUM9gX84yY5y4pZ8qFPC0KjL4MNJtkQwyO
 +gkn9T2YGerr6toSIaAkA9usaaKmejfYwImx3ptQit9DN9Gu3Y1GAxoysAycvrvw
 1R4QXT/Xj+rmiA0q3E+pVaXKocQTLeVInt3dEl0GOAo1mRrki4Q2afjthgsciMIb
 lQvfwq4JJ+obPLRgFN2Oz3fWh0hIl0NrTiRSCBS+dSmjwx4WKRWxjpMa3nh+jH38
 34xv5YcDUfZqOKlew5zUQ6j48SBFbbr5y2Q==
X-ME-Sender: <xms:rDJWak7QCqzRjsJK2-H8gUlZZO8rMHAXAO80TrRKxUwgr5P21kFiZg>
 <xme:rDJWar5kPHxrNX5OEuBSLR-Xug0lrugpYpZT6Jl5_n8cxdATZykMgAz6kf541eLhw
 SK63FMEYFbuX9YLJn0hlz4CchX4uNya8pTQxAtdPTnS42CFrYQYc_c>
X-ME-Received: <xmr:rDJWahGPqv-sAvoAmNetmL0KNQt1R-SkFNWwbolKQolszYa0u81PDGRXVlkCxHfwpm-kA8V0cfoy>
X-ME-Proxy-Cause: dmFkZTE7q9K1uzLRsLWcFghktPGOeQ4d8xx6UEM9A8qEz+xdW1oA5vsJZFy4ZDYGM4zM8F
 uelAdEdricbppsrr8zX832z1LjM3MU1vSZ5jG1yXDUyQ9qSPBj6z6e9UpL86WWdi3gAz1n
 iwwfZdJFah4m4N/vEuU2tXQfF3AYfqQeJTmJx09jnkXR0/ShF+b/6G0nqP2D1fMVRjiy7T
 fyowWBLx1nDq+2Ggp11EjJdtPipm9A5BLAMeWVRgie2KHkqydWkvrXVlUkVgnzGVl37k+B
 jOml20G+I8EZdgSgybIjO+83j/q870310UDl4ceyiQrtkCYcTjYaJwdvwAuA0czzCiyRGz
 f+qi12sRe2G783g05+PQZ/FeCSInpo5krar9+R/IKbCp5dOh1/dWcHt8uSQyuCVr0TjRhW
 oqW15GpmU9dvkdQ/sRKFAH8Sn8TMDUnfqQ7p9XJE0T5XHZGUFLcyQX2+4ZZZ7b6e7axgDL
 HSPBUKbE0PxZJ36zYMaPz+LDdHYmzMjYW5arN7dyPuxM+UaTXtrbNjxlCfTMdpiaZ637wS
 MJ3QiObMoYTbORFhf7mEjKfxTjvg2kknEt6QMHplBkgaOEgGjb1m4AqnG2NV128BDuLER/
 wqCeroRTVDvmu36wkRAsz6DuKRu3NwZYqa7agZgQg9AVTvy435bxVbMvlBAg
X-ME-Proxy: <xmx:rDJWakR5ruHI5XNLfxaq5681WS2vhbSTRAkn5CxtH204b4wuyV0w5A>
 <xmx:rDJWaqs3s4T0Tw3X6i4YJT9VN1tYU-DCqEMtgCp3Qpd9HSXAA6mmnQ>
 <xmx:rDJWajxBjr1tL-2HhDpZehAAAX_hyYsek9QW4lgq4-wQskHTcDYstQ>
 <xmx:rDJWak5hEovQp_sZdpvL81qeN62dSO4xwMYl8SQJL2GHJjTEyGergA>
 <xmx:rDJWaj7vF8jksH3zUVe0LJ-xiUFJwIxY-YHhv-swczg7UALjGGj7A_Yf>
Feedback-ID: i62564b17:Fastmail
Received: by mail.messagingengine.com (Postfix) with ESMTPA; Tue,
 14 Jul 2026 08:59:24 -0400 (EDT)
Received: by melete.silentflame.com (Postfix, from userid 1000)
 id 6C1437E8099; Tue, 14 Jul 2026 13:59:23 +0100 (BST)
From: Sean Whitton <spwhitton@HIDDEN>
To: Aaron Iba <ai@HIDDEN>, 81407 <at> debbugs.gnu.org
Subject: Re: bug#81407: 31.0.90; Crash in display_line: stale glyph_row
 after window-config change from menu-bar :enable eval during redisplay
In-Reply-To: <CAH_c0bczVJoqNthKnZD-rMEG8Zx0n6dpfgRcc8GjqSftVho3AQ@HIDDEN>
References: <CAH_c0bczVJoqNthKnZD-rMEG8Zx0n6dpfgRcc8GjqSftVho3AQ@HIDDEN>
Date: Tue, 14 Jul 2026 13:59:23 +0100
Message-ID: <878q7dd8wk.fsf@HIDDEN>
MIME-Version: 1.0
Content-Type: text/plain
X-Spam-Score: -0.7 (/)
X-Debbugs-Envelope-To: 81407
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.7 (-)

Aaron Iba [13/Jul  9:20pm -04] wrote:
> Emacs 31.0.90 pretest crashes reproducibly in redisplay on macOS. I
> debugged it to completion under lldb, including catching the corrupting
> store live and backtracing the root-cause event. Full analysis below.
>
> Build: emacs-plus@31 (Homebrew tap d12frosted/emacs-plus), built
> 2026-07-01 from the emacs-31 branch, NS build, aarch64 (Apple Silicon),
> native-comp enabled, macOS 26.5.2.

Reading your report, I think that this isn't really a macOS specific,
problem, right?  That's just the platform you are using?

-- 
Sean Whitton

Information forwarded to bug-gnu-emacs@HIDDEN:
bug#81407; Package emacs. Full text available.

Message received at 81407 <at> debbugs.gnu.org:

Received: (at 81407) by debbugs.gnu.org; 14 Jul 2026 12:51:10 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Tue Jul 14 08:51:10 2026
Received: from localhost ([127.0.0.1]:39881 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1wjcbN-0000Td-H8
	for submit <at> debbugs.gnu.org; Tue, 14 Jul 2026 08:51:10 -0400
Received: from eggs.gnu.org ([2001:470:142:3::10]:51848)
 by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
 (Exim 4.84_2) (envelope-from <eliz@HIDDEN>) id 1wjcbK-0000T2-Li
 for 81407 <at> debbugs.gnu.org; Tue, 14 Jul 2026 08:51:07 -0400
Received: from fencepost.gnu.org ([2001:470:142:3::e])
 by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
 (Exim 4.90_1) (envelope-from <eliz@HIDDEN>)
 id 1wjcbF-0000FO-1W; Tue, 14 Jul 2026 08:51:01 -0400
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org;
 s=fencepost-gnu-org; h=MIME-version:References:Subject:In-Reply-To:To:From:
 Date; bh=Emnan6XNfCc5QmjbQUh1GLBXh0nlcfzZlUM775ExM3g=; b=Dj90aDNB2P/gF7HYJbmH
 lhTVT1Sci3xrS+XxHPNeiBKs2NtRDa3VxiizEZ2Df72jDf+SoLUNXjQ87AHYIOeedOfzpOTs+9DJQ
 0J3o65M10q4s+dtP9I7K6ZnNtpQoXuO0PBSKzbRxkI38dZGBRj7NKgA6fjvTIHuoIi9t0IW+QMRvg
 Wuwmfm3ShhlpmAd7oIXBDwzFq7kCOKGRLvhfqPWP9PGfeFdtNxWkzZszbJxjp8drQWd50uXE59ea2
 lpapI0TfYQKrwATwshhB54DIQg4s1UGeRJqDfkLVUjiAHNt2UXN5jHaJmtgm+OtwlHLTM6U6SOnfN
 31YHPwDO9ZzsiQ==;
Date: Tue, 14 Jul 2026 15:50:57 +0300
Message-Id: <865x2hg2fi.fsf@HIDDEN>
From: Eli Zaretskii <eliz@HIDDEN>
To: Aaron Iba <ai@HIDDEN>
In-Reply-To: <CAH_c0bczVJoqNthKnZD-rMEG8Zx0n6dpfgRcc8GjqSftVho3AQ@HIDDEN>
 (message from Aaron Iba on Mon, 13 Jul 2026 21:20:01 -0400)
Subject: Re: bug#81407: 31.0.90;
 Crash in display_line: stale glyph_row after window-config change
 from menu-bar :enable eval during redisplay
References: <CAH_c0bczVJoqNthKnZD-rMEG8Zx0n6dpfgRcc8GjqSftVho3AQ@HIDDEN>
MIME-version: 1.0
Content-type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
X-Spam-Score: -2.3 (--)
X-Debbugs-Envelope-To: 81407
Cc: 81407 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)

> From: Aaron Iba <ai@HIDDEN>
> Date: Mon, 13 Jul 2026 21:20:01 -0400
> 
> CRASH MECHANICS (all captured live in lldb)
> 
>   1. The corrupting store, caught by a conditional breakpoint:
> 
>      * stop reason = breakpoint (str w8, [x28, #0x19c])
>        frame #0: Emacs`set_cursor_from_row + 3676
>        frame #1: Emacs`display_line + 9740
>        frame #2: Emacs`try_window + 200
>        frame #3: Emacs`redisplay_window + 10932
>        ...
> 
>      This is xdisp.c: w->cursor.vpos = MATRIX_ROW_VPOS (row, matrix) + dvpos;

Please show a backtrace when the above line computes a bogus value of
cursor's vpos.  set_cursor_from_row is called from many places, and
it's important to know which one(s) cause this.

>      Registers at the stop:
>        value stored (w8)      = 0x4d936441  (1301701697)
>        row (x11)              = 0x780344308
>        matrix (x21)           = 0x77ff1e140
>        matrix->rows           = 0x78034e000   (nrows = 95)
>        w->current_matrix rows = 0x780355000   (nrows = 95)
> 
>      ROW is 40184 bytes BEFORE matrix->rows and belongs to neither the
>      desired nor the current matrix (not even 264-byte aligned against
>      them): it points into a freed rows allocation from before
>      adjust_glyph_matrix reallocated the matrix.  (row - rows)/264 with
>      the negative, non-integral delta yields the huge garbage vpos.

Normally, the call to prepare_menu_bars, which you say is where the
problem starts, is called before the display engine begins
redisplaying windows, and AFAIK the adjust_frame_glyphs calls results
in all the glyph rows of the reallocated current_matrix to be
disabled.  So the following redisplay of the window should disable all
redisplay optimizations and produce all the glyph rows anew.  Thus,
stale current_matrix should not be an issue, as long as we pay
attention to the enabled_p flag of the matrix's rows.  Which is why it
is important to know the caller of set_cursor_from_row in this case.

> REPRODUCTION
> 
>   In my configuration (CIDER + sesman + perspective.el + an advice
>   that filters sesman sessions by perspective): open a Clojure buffer,
>   M-x cider-connect-clj, then type any self-inserting character.
>   Crashes within seconds, 100% reproducible.  Minimal recipe for core:
>   arrange for a menu-bar item's :enable form (or anything else
>   evaluated from update_menu_bar / mode-line eval) to call
>   (delete-other-windows) — or any window-configuration-changing
>   function — while redisplay is in progress.

It would be very useful if you could provide a reproducible recipe
starting from "emacs -Q" and without loading any packages that aren't
part of Emacs.  My naïve attempt to do something similar to what you
describe above, by adding a call to delete-other-windows to
pre-redisplay-function, failed to reproduce the crash, so either it
was too naïve or maybe this only happens on macOS.

>   - After update_menu_bar / prepare_menu_bars runs Lisp, detect
>     window-configuration/matrix changes and restart redisplay rather
>     than continuing with pointers into freed matrices.

My reading of the code is that where redisplay_internal calls
prepare_menu_bars, redisplay didn't yet start, in the sense that we
didn't yet redisplay any windows, and there are no pointers to
current_matrix of any window that redisplay will reuse.  So it is not
clear to me what exactly should we "restart" here.

>   - Defensively: in display_line's "Maybe set the cursor" check
>     cvpos < w->desired_matrix->nrows before MATRIX_ROW, and/or make
>     set_cursor_from_row eassert/clamp when ROW is not inside MATRIX
>     (row < rows || row >= rows + nrows or misaligned).

That's plausible, but it's a band-aid.  We should first try to fix the
root cause of the problem.

Thanks.

Information forwarded to bug-gnu-emacs@HIDDEN:
bug#81407; Package emacs. Full text available.

Message received at submit <at> debbugs.gnu.org:

Received: (at submit) by debbugs.gnu.org; 14 Jul 2026 07:14:26 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Tue Jul 14 03:14:26 2026
Received: from localhost ([127.0.0.1]:37976 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1wjXLV-0003V6-Is
	for submit <at> debbugs.gnu.org; Tue, 14 Jul 2026 03:14:26 -0400
Received: from lists1p.gnu.org ([2001:470:142::17]:38174)
 by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
 (Exim 4.84_2) (envelope-from <ai@HIDDEN>) id 1wjRou-0004NZ-DT
 for submit <at> debbugs.gnu.org; Mon, 13 Jul 2026 21:20:25 -0400
Received: from eggs.gnu.org ([2001:470:142:3::10])
 by lists1p.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
 (Exim 4.90_1) (envelope-from <ai@HIDDEN>) id 1wjRoo-0004Ft-Ab
 for bug-gnu-emacs@HIDDEN; Mon, 13 Jul 2026 21:20:18 -0400
Received: from mail-lf1-x132.google.com ([2a00:1450:4864:20::132])
 by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128)
 (Exim 4.90_1) (envelope-from <ai@HIDDEN>) id 1wjRom-0005Zr-4e
 for bug-gnu-emacs@HIDDEN; Mon, 13 Jul 2026 21:20:17 -0400
Received: by mail-lf1-x132.google.com with SMTP id
 2adb3069b0e04-5aebc8cb5bcso2578185e87.2
 for <bug-gnu-emacs@HIDDEN>; Mon, 13 Jul 2026 18:20:15 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; t=1783992013; cv=none;
 d=google.com; s=arc-20260327;
 b=ePgzSGhRSx8Fb2qXquynUoOFJiVV1MLOuZ5G4afW7h/qItND2Zst6zDAresaC+IoFq
 o0M60ZOGcXDOuP6LwsvjsQB/A7hEk4xKqE29H6nkaZlDukfobqT2j86AcRM2TITAZQOd
 vADgNChFLX8PQokSjrvSeuOYJybrsVj0FZYLDovCSSLA16xlGZsCxL5exdn0CstYldL2
 1a6KWHBYgTaaSdO86QIz0HFL1UwYroU63h6Mfz4XDc7JefFE4r56UDcIo1U+BiJzOdFb
 QeqyEVp3jR8xnFR+zin91XqUFxMgO9f4nSc4k/+SxS+fOwqV6yz1oDTRLxcWgwvstriM
 uonA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com;
 s=arc-20260327; 
 h=content-transfer-encoding:to:subject:message-id:date:from
 :mime-version:dkim-signature;
 bh=b5XHNFAAmDYD6ec/2Rf75BtkGgkVMFYPpKrtJsYCqLY=;
 fh=+R8aXOFVnuBbN1nRXJJI02Ia//JUQJmLW/Uk/VaA0ag=;
 b=ZgzGafiupqNKFoVueYu1q5s+/Zqsm+9Sgx+6y7RngCvxlgOu0+rNQUfm4miI1nChHT
 7vQs0l3KlcRoqeX9bsMJqkqIn5JOQ6hje+PtJDFCLEnmbHgltogmZqJU//kdUvgqnhpq
 SFJ7jYMZDvu+GSy2nX5JaMdnIpocML+MmjdUMFFD4q+toj/9nz5iFbUikZs26BlYUHpb
 2nYFVFMWtFLc2MReToRT4thDpszL31KpHPKWHVo0X3RydNaRsvPzTUMekLiOCv6j0GQG
 uotwB1FH4AQw3sFqbweErYQNIOI9uW7dH+dINhw75HxffzlsesovaVPEobIXBb5AvUDt
 Zz/g==; darn=gnu.org
ARC-Authentication-Results: i=1; mx.google.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=aaroniba.net; s=google; t=1783992013; x=1784596813; darn=gnu.org;
 h=content-transfer-encoding:content-type:to:subject:message-id:date
 :from:mime-version:from:to:cc:subject:date:message-id:reply-to
 :content-type; bh=b5XHNFAAmDYD6ec/2Rf75BtkGgkVMFYPpKrtJsYCqLY=;
 b=C3zEtZ28ISBjV3UuxremmoM6GsfX9NT6qTJ2hd/slX++/hKg0qycCFUEl+apwHWq33
 qTydWQLsml1X192NMsspSEJz51uq0/0B4rBWCKcX9SJ7zTlHUBYU/JMVhIkncRQrfx/z
 rVtIIIvehdnTvNmCTtD5/Gw+USVOPI5BT6qKrClI9Bt3XBPdm9YLp2rNPbaSAlXzSHex
 rEIVupwEFBwPyxLuc7a1Kcy6+Nv+E47JfQXvOHkbPhj39iWdJItpfBEH7KDf9v2rjxrj
 jZRl92K06M8e6TXcgtcthXZkwLMQQRII5wpm/yDvscMvjK75ANSGGcANw9mkFrPCY8Wf
 bzhw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20251104; t=1783992013; x=1784596813;
 h=content-transfer-encoding:content-type:to:subject:message-id:date
 :from:mime-version:x-gm-gg:x-gm-message-state:from:to:cc:subject
 :date:message-id:reply-to:content-type;
 bh=b5XHNFAAmDYD6ec/2Rf75BtkGgkVMFYPpKrtJsYCqLY=;
 b=cgTT/vKOP4oejclgG5Mkz009O32pEri0GMuMmwdHXjFbZRh5ggpotHF9EwNJ+fUQPu
 m1CORDmv3syG3dpIEQsPvr8EJpL0x5TAgsMductq2xhXSn7qab/kFyqYmCYSomBaXZh7
 AT4fWZ5r1NYZeDfTT8yTqo/6c/HGwjGyHEhGDtT9jleN73BuAz3n7n86c5bc60O5esF2
 sx1NCBLByxtep6BNHfUsTPqS9k/yhhdu4nqi+1EwFW0NR+OHNUKqvNqvB3j0f9IbnxUW
 RBGExAwHmHFl4v3Giv9kdRJ8wjIoCnhEseK94GcL+aq6PfIVRYOvTNxO2bF/C0lPuPoX
 LUTA==
X-Gm-Message-State: AOJu0YwYk0fL4y0eSckJNOgd3MSaZm27mQuODhTlKqYM0oBaYJqMqqIV
 JfiMX1LNhd+YWY+ZQHc/c6Y8VT+Y5u6R4VdKNKOJEtFsRVtOrY87oIvbWpeQlyGiZz56WIdTCyC
 0It5W5Up1eIRiPQhY/v5x5VZD/sXoU6CAp9PWauWlB847BeG1vEpvHw==
X-Gm-Gg: AfdE7clmukdMZv48kBLdwlfuMCOH2sOfys0/bhbdta2zqbUTw6iu+dDs8llGuonmjcS
 268nz2PonlfmMU7WypJ57bs3+zwEf1t+qhSGwU0Nc+wqqOL/T+xbgO3Czc3jBjQlHk9UcfJ9F+E
 3LaKRls9gvLSRjClm/KAWO0ZQKCu8RpySYJGydvBTo9agvfGJl46pTXfc1Pw4WahfZ25QY/U+28
 B0CFYqOJaMOnVkPH81iietnwrCZYsmmg/2QMS2e+l6pZMB8kbY05l03MIvc0h+M6xOQgGhH73hR
 O9t9bxQMYTjm3NN1flU75L91L3gg8sF3FOUnKOfm
X-Received: by 2002:a05:6512:1094:b0:5ae:b713:f26d with SMTP id
 2adb3069b0e04-5b0236bfa48mr2423501e87.58.1783992013094; Mon, 13 Jul 2026
 18:20:13 -0700 (PDT)
MIME-Version: 1.0
From: Aaron Iba <ai@HIDDEN>
Date: Mon, 13 Jul 2026 21:20:01 -0400
X-Gm-Features: AUfX_myOBcEjiPuFCAgbcUIBv7KqeuMX7zhfKQ4y-De1ogl2-wvYUFTF4EY8cQU
Message-ID: <CAH_c0bczVJoqNthKnZD-rMEG8Zx0n6dpfgRcc8GjqSftVho3AQ@HIDDEN>
Subject: 31.0.90; Crash in display_line: stale glyph_row after window-config
 change from menu-bar :enable eval during redisplay
To: bug-gnu-emacs@HIDDEN
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Received-SPF: pass client-ip=2a00:1450:4864:20::132;
 envelope-from=ai@HIDDEN; helo=mail-lf1-x132.google.com
X-Spam_score_int: -20
X-Spam_score: -2.1
X-Spam_bar: --
X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1,
 DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1,
 RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001,
 SPF_PASS=-0.001 autolearn=ham autolearn_force=no
X-Spam_action: no action
X-Spam-Score: 1.0 (+)
X-Debbugs-Envelope-To: submit
X-Mailman-Approved-At: Tue, 14 Jul 2026 03:14:24 -0400
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -0.0 (/)

Emacs 31.0.90 pretest crashes reproducibly in redisplay on macOS. I
debugged it to completion under lldb, including catching the corrupting
store live and backtracing the root-cause event. Full analysis below.

Build: emacs-plus@31 (Homebrew tap d12frosted/emacs-plus), built
2026-07-01 from the emacs-31 branch, NS build, aarch64 (Apple Silicon),
native-comp enabled, macOS 26.5.2.

SUMMARY

  If Lisp evaluated during redisplay changes the window configuration,
  redisplay continues with a stale glyph_row pointer and either crashes
  immediately or poisons w->cursor.vpos with a huge garbage value that
  crashes the next redisplay.  In my case the Lisp is reached through
  update_menu_bar: a menu-bar item's :enable form (CIDER's
  (cider-connected-p)) ends up =E2=80=94 through sesman and perspective.el =
=E2=80=94
  calling delete-other-windows, which calls adjust_frame_glyphs and
  reallocates the window's glyph matrices mid-redisplay.

  Rude Lisp, certainly (I have fixed my configuration), but Lisp should
  not be able to segfault Emacs, and menu-bar :enable forms are
  evaluated inside redisplay by design.

CRASH MECHANICS (all captured live in lldb)

  1. The corrupting store, caught by a conditional breakpoint:

     * stop reason =3D breakpoint (str w8, [x28, #0x19c])
       frame #0: Emacs`set_cursor_from_row + 3676
       frame #1: Emacs`display_line + 9740
       frame #2: Emacs`try_window + 200
       frame #3: Emacs`redisplay_window + 10932
       ...

     This is xdisp.c: w->cursor.vpos =3D MATRIX_ROW_VPOS (row, matrix) + dv=
pos;

     Registers at the stop:
       value stored (w8)      =3D 0x4d936441  (1301701697)
       row (x11)              =3D 0x780344308
       matrix (x21)           =3D 0x77ff1e140
       matrix->rows           =3D 0x78034e000   (nrows =3D 95)
       w->current_matrix rows =3D 0x780355000   (nrows =3D 95)

     ROW is 40184 bytes BEFORE matrix->rows and belongs to neither the
     desired nor the current matrix (not even 264-byte aligned against
     them): it points into a freed rows allocation from before
     adjust_glyph_matrix reallocated the matrix.  (row - rows)/264 with
     the negative, non-integral delta yields the huge garbage vpos.

  2. The garbage vpos then crashes the *next* display_line at the end
     of display_line ("Maybe set the cursor", xdisp.c ~26823):

       cvpos =3D it->w->cursor.vpos;
       if ((cvpos < 0
            || (it->bidi_p
                && !MATRIX_ROW (it->w->desired_matrix, cvpos)->ends_at_zv_p=
))

     cvpos is only checked for < 0; the garbage positive index reads
     ~340 GB past the rows array:

       ldr    w9, [x8, #0x19c]     ; cvpos =3D 0x4d936441
       tbnz   w9, #0x1f, skip      ; only lower-bound check
       ldr    x8, [x8, #0xe8]      ; w->desired_matrix
       ldr    x8, [x8, #0x8]       ; matrix->rows
       umaddl x8, w9, w10, x8      ; rows + cvpos*264
       ldrb   w8, [x8, #0xf5]      ; ends_at_zv_p -> EXC_BAD_ACCESS

     All crash addresses across 10+ observed crashes decode as
     stale_row + k*264 + 0x50_0000_0000-style truncation artifacts of
     this arithmetic, confirming a single root cause.  A second
     signature (SIGSEGV at 0x30 inside the face-lookup call in
     extend_face_to_end_of_line) comes from the same corrupted state.

  3. The root-cause event, caught with a breakpoint on
     adjust_glyph_matrix conditioned on this window's matrices, WHILE
     redisplay_internal was on the stack:

       adjust_glyph_matrix
       allocate_matrices_for_window_redisplay
       adjust_frame_glyphs
       Fdelete_other_windows_internal
       ... (elisp, native-compiled) ...
       delete-other-windows
       persp-reset-windows          ; perspective.el
       persp-activate
       persp-switch
       persp-current-buffers*
       persp-is-current-buffer
       ... (seq-filter over sesman sessions) ...
       sesman-current-session       ; sesman
       cider-repls                  ; CIDER
       cider-current-repl
       cider-connected-p            ; menu-bar :enable form
       eval_sub / Feval
       internal_condition_case_1
       menu_item_eval_property      <-- Lisp evaluated by redisplay
       parse_menu_item
       menu_bar_item
       map_keymap_internal
       map_keymap_canonical
       menu_bar_items
       update_menu_bar
       redisplay_internal           <-- redisplay in progress
       redisplay_preserve_echo_area
       sit_for / read_char / command_loop

     (perspective.el's persp-is-current-buffer with INCLUDE-GLOBAL
     round-trips through `with-perspective`, which does two real
     persp-switch calls, each restoring a window configuration =E2=80=94 a
     side effect buried inside what callers use as a pure predicate.)

REPRODUCTION

  In my configuration (CIDER + sesman + perspective.el + an advice
  that filters sesman sessions by perspective): open a Clojure buffer,
  M-x cider-connect-clj, then type any self-inserting character.
  Crashes within seconds, 100% reproducible.  Minimal recipe for core:
  arrange for a menu-bar item's :enable form (or anything else
  evaluated from update_menu_bar / mode-line eval) to call
  (delete-other-windows) =E2=80=94 or any window-configuration-changing
  function =E2=80=94 while redisplay is in progress.

SUGGESTED HARDENING (either or both)

  - After update_menu_bar / prepare_menu_bars runs Lisp, detect
    window-configuration/matrix changes and restart redisplay rather
    than continuing with pointers into freed matrices.
  - Defensively: in display_line's "Maybe set the cursor" check
    cvpos < w->desired_matrix->nrows before MATRIX_ROW, and/or make
    set_cursor_from_row eassert/clamp when ROW is not inside MATRIX
    (row < rows || row >=3D rows + nrows or misaligned).

I can reproduce on demand and am happy to test patches.

In GNU Emacs 31.0.90 (build 1, aarch64-apple-darwin25, NS
appkit-2748.00 Version 26.5.2 (Build 25F84)) of 2026-07-01 built on
Homebrew emacs-plus@31.

Acknowledgement sent to Aaron Iba <ai@HIDDEN>:
New bug report received and forwarded. Copy sent to bug-gnu-emacs@HIDDEN. Full text available.

Report forwarded to bug-gnu-emacs@HIDDEN:
bug#81407; Package emacs. Full text available.

Please note: This is a static page, with minimal formatting, updated once a day.
Click here to see this page with the latest information and nicer formatting.

Last modified: Thu, 30 Jul 2026 12:30:04 UTC

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