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" <bug-gnu-emacs@gnu.org>]

[-- Attachment #1: Type: text/plain, Size: 1602 bytes --]

reopen 50571
quit

Basil L. Contovounesios [2021-09-14 20:45 +0100] wrote:

> Eli Zaretskii [2021-09-14 16:33 +0300] wrote:
>
>>> 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?
>
> Yes, applying it makes the issue go away, and reverting it reintroduces
> the segfault.  I didn't notice any other issues.  Thanks!

Unfortunately I found another hole that needs plugging, but fortunately
I can reliably reproduce it with the following site-specific steps:

0. emacs
1. C-x p p (project-switch-project)
2. Select a checkout of https://github.com/abo-abo/swiper,
   using Ivy completion.
3. f (project-find-file)
4. ivy.el RET
5. C-s (isearch-forward)
6. C-g
7. M-s s (counsel-grep-or-swiper)
8. #[[:digit:]]

This brings a bug-reference-bug-regexp match onto screen, which again
triggers a frame creation via bug-reference's call to display-warning.

The attached GDB log shows where the relevant frame's face cache is
cleared right before the crash (search for 'New value = 0'), at which
point f->inhibit_clear_image_cache is false.

-- 
Basil


[-- Attachment #2: GDB log --]
[-- Type: application/gzip, Size: 22503 bytes --]