unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
From: Eli Zaretskii <eliz@gnu.org>
To: contovob@tcd.ie
Cc: 50571@debbugs.gnu.org
Subject: bug#50571: 28.0.50; Redisplay segfaults with empty face cache
Date: Tue, 14 Sep 2021 16:33:43 +0300	[thread overview]
Message-ID: <83a6kfcmdk.fsf@gnu.org> (raw)
In-Reply-To: <83bl4vcnsp.fsf@gnu.org> (message from Eli Zaretskii on Tue, 14 Sep 2021 16:03:02 +0300)

> Date: Tue, 14 Sep 2021 16:03:02 +0300
> From: Eli Zaretskii <eliz@gnu.org>
> Cc: 50571@debbugs.gnu.org
> 
> Thanks, I see the reason now.  It's because we allow to have arbitrary
> Lisp to be registered in jit-lock-functions, and then that arbitrary
> Lisp is called in the middle of redisplay, and in this case creates a
> whole new frame with faces.  As luck would have it, we decide right
> there and then perform routine maintenance and release all the faces
> on all the frames...
> 
> I'm thinking about the best solution for this.

Does the patch below give good results?

diff --git a/src/frame.h b/src/frame.h
index a8ad011..3dd7680 100644
--- a/src/frame.h
+++ b/src/frame.h
@@ -449,8 +449,8 @@ #define EMACS_FRAME_H
   /* Non-zero if this frame's faces need to be recomputed.  */
   bool_bf face_change : 1;
 
-  /* Non-zero if this frame's image cache cannot be freed because the
-     frame is in the process of being redisplayed.  */
+  /* Non-zero if this frame's image cache and face cache cannot be
+     freed because the frame is in the process of being redisplayed.  */
   bool_bf inhibit_clear_image_cache : 1;
 
   /* True when new_width or new_height were set by change_frame_size,
diff --git a/src/xdisp.c b/src/xdisp.c
index d30a685..2e72f6b 100644
--- a/src/xdisp.c
+++ b/src/xdisp.c
@@ -16061,12 +16061,13 @@ #define AINC(a,i)							\
 	      if (FRAME_VISIBLE_P (f) && !FRAME_OBSCURED_P (f))
 		{
 
-		  /* Don't allow freeing images for this frame as long
-		     as the frame's update wasn't completed.  This
-		     prevents crashes when some Lisp that runs from
-		     the various hooks or font-lock decides to clear
-		     the frame's image cache, when the images in that
-		     cache are referenced by the desired matrix.  */
+		  /* Don't allow freeing images and faces for this
+		     frame as long as the frame's update wasn't
+		     completed.  This prevents crashes when some Lisp
+		     that runs from the various hooks or font-lock
+		     decides to clear the frame's image cache and face
+		     cache, when the images and faces in those caches
+		     are referenced by the desired matrix.  */
 		  f->inhibit_clear_image_cache = true;
 		  redisplay_windows (FRAME_ROOT_WINDOW (f));
 		}
diff --git a/src/xfaces.c b/src/xfaces.c
index 2273fb4..aefed54 100644
--- a/src/xfaces.c
+++ b/src/xfaces.c
@@ -674,7 +674,8 @@ clear_face_cache (bool clear_fonts_p)
 	{
 	  struct frame *f = XFRAME (frame);
 	  if (FRAME_WINDOW_P (f)
-	      && FRAME_DISPLAY_INFO (f)->n_fonts > CLEAR_FONT_TABLE_NFONTS)
+	      && FRAME_DISPLAY_INFO (f)->n_fonts > CLEAR_FONT_TABLE_NFONTS
+	      && !f->inhibit_clear_image_cache)
 	    {
 	      clear_font_cache (f);
 	      free_all_realized_faces (frame);





  reply	other threads:[~2021-09-14 13:33 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-09-13 14:59 bug#50571: 28.0.50; Redisplay segfaults with empty face cache Basil L. Contovounesios via Bug reports for GNU Emacs, the Swiss army knife of text editors
2021-09-13 16:03 ` Eli Zaretskii
2021-09-13 23:21   ` Basil L. Contovounesios via Bug reports for GNU Emacs, the Swiss army knife of text editors
2021-09-14 13:03     ` Eli Zaretskii
2021-09-14 13:33       ` Eli Zaretskii [this message]
2021-09-14 19:45         ` Basil L. Contovounesios via Bug reports for GNU Emacs, the Swiss army knife of text editors
2021-09-15 13:16           ` Eli Zaretskii
2021-09-19 13:57           ` Basil L. Contovounesios via Bug reports for GNU Emacs, the Swiss army knife of text editors
2021-09-19 15:47             ` Eli Zaretskii
2021-09-19 18:21               ` Basil L. Contovounesios via Bug reports for GNU Emacs, the Swiss army knife of text editors
2021-09-19 18:41                 ` Eli Zaretskii

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=83a6kfcmdk.fsf@gnu.org \
    --to=eliz@gnu.org \
    --cc=50571@debbugs.gnu.org \
    --cc=contovob@tcd.ie \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).