[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#43973: 28.0.50; [NS] Two crashes on macOS
From: |
Eli Zaretskii |
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@idiocy.org>
> Cc: 43973@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.