bug#43973: 28.0.50; [NS] Two crashes on macOS

[Alan Third]

On Tue, Oct 13, 2020 at 10:35:28AM +0300, Andrii Kolomoiets wrote:
> Update to recent trunk brought me everyone's favorite random crashes.
> 
> In an attempt to find the recipe for reproduce the bug somehow, I spot
> two crashes that I actually can reproduce in 'emacs -Q'.
> 
> The first one is more "stable":
> 
> With this code in scratch and point at '|':
> 
>     (make-frame `((parent-frame . ,(selected-frame))
>                   (width . 0.5)
>                   (height . 0.5)
>                   (top . 0.5)
>                   (left . 0.5)))|
> 
> 1. C-x C-e
> 2. s-w
> 
> Repeating these two steps 3-5 times leads to crash.  Most of the time
> the only meaningfull record in the 'bt' is:
> 
> Thread 3 received signal SIGSEGV, Segmentation fault.
> 0x00007fff6fa97678 in ?? ()
> (gdb) bt full
> #0  0x00007fff6fa97678 in ?? ()
> No symbol table info available.
> #1  0x0000000100476338 in -[EmacsImage dealloc] (self=0x1014c77f0, 
> _cmd=0x7fff7afcdc58) at nsimage.m:286
> No locals.
> 
> It may be tool bar related, because Emacs is not crashing with
> tool-bar-mode turned of.

This is almost definitely the result of some image being released
twice. We've had a few crash reports where this has happened in the
past, but never actually managed to work out what's causing it.

I can't replicate the crash, fwiw.

> 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.

I suspect Emacs thinks there are 101 frames open but for whatever
reason the OS hasn't opened them...
-- 
Alan Third