GNU bug report logs - #43973
28.0.50; [NS] Two crashes on macOS

Previous Next

Full log

View this message in rfc822 format

From: Eli Zaretskii <eliz <at> gnu.org>
To: Alan Third <alan <at> idiocy.org>
Cc: 43973 <at> debbugs.gnu.org, andreyk.mad <at> gmail.com
Subject: bug#43973: 28.0.50; [NS] Two crashes on macOS
Date: Sat, 24 Oct 2020 13:35:02 +0300

> Date: Tue, 13 Oct 2020 20:09:46 +0100
> From: Alan Third <alan <at> idiocy.org>
> Cc: 43973 <at> debbugs.gnu.org
> 
> > The second one is not reproducible every time:
> > 
> > 1. M-x tool-bar-mode
> > 2. Evaluate
> >     (let ((params `((parent-frame . ,(selected-frame))
> >                     (undecorated . t))))
> >       (dotimes (_z 100)
> >         (set-face-background 'internal-border "black"
> >                              (make-frame params))))
> > 3. Move the frame
> 
> I can replicate this one, every time.
> 
> I'm not sure exactly what's going on, but it's resulting in face ==
> NULL, so
> 
> modified   src/nsterm.m
> @@ -3048,6 +3048,9 @@ so some key presses (TAB) are swallowed by the system.  */
>        if (!face)
>          face = FRAME_DEFAULT_FACE (f);
>  
> +      if (!face)
> +        return;
> +
>        ns_focus (f, &frame_rect, 1);
>        [ns_lookup_indexed_color (NS_FACE_BACKGROUND (face), f) set];
>        for (int i = 0; i < 4 ; i++)
> 
> 
> "fixes" it, but leaves Emacs in a bit of a strange state where I can
> only see one frame and it's incredibly slow.

Can you spot which code calls free_all_realized_faces in this case?
We could either try to prevent that, or call recompute_basic_faces,
then the behavior should be better, I think.

Previous Next

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