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

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

[Andrii Kolomoiets]

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.


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

Thread 3 received signal SIGSEGV, Segmentation fault.
0x0000000100456e88 in ns_clear_under_internal_border (f=0x13cedafe8) at nsterm.m:3052
3052	      [ns_lookup_indexed_color (NS_FACE_BACKGROUND (face), f) set];
(gdb) bt full
#0  0x0000000100456e88 in ns_clear_under_internal_border (f=0x13cedafe8) at nsterm.m:3052
        frame_rect = {origin = {x = 0, y = 0}, size = {width = 595, height = 508}}
        face_id = 15
        border_width = 2
        view = 0x10bfb2b70
        edge_rect = {origin = {x = 0, y = 6.9529314086768113e-310}, size = {width = 2.6133677750952917e-314,
            height = 2.6133668897296544e-314}}
        edge = {NSRectEdgeMinX, NSRectEdgeMinY, NSRectEdgeMaxX, NSRectEdgeMaxY}
        face = 0x0
#1  0x0000000100067b8d in redisplay_internal () at xdisp.c:16014
        gcscrollbars = false
        f_redisplay_flag = false
        f = 0x13cedafe8
        w = 0x105046430
        sw = 0x105046430
        fr = 0x10503b430
        pending = false
        must_finish = true
        match_p = true
        tlbufpos = {charpos = 304, bytepos = 304}
        tlendpos = {charpos = 0, bytepos = 0}
        number_of_visible_frames = 101
        count = 3
        sf = 0x10503b430
        polling_stopped_here = true
        tail = {i = 0x102227d93}
        frame = {i = 0x13cedafed}
        hscroll_retries = 0
        garbaged_frame_retries = 0
        consider_all_windows_p = true
        update_miniwindow_p = false
#2  0x000000010006ceb9 in redisplay () at xdisp.c:15159
No locals.

(Just for the record: in my usual workflow I don't create that much
child frames)

Thanks! And hope Emacs is crashing on your side too ;)

In GNU Emacs 28.0.50 (build 3, x86_64-apple-darwin19.6.0, NS appkit-1894.60 Version 10.15.6 (Build 19G2021))
Windowing system distributor 'Apple', version 10.3.1894
System Description:  Mac OS X 10.15.6

Configured using:
 'configure --enable-checking=yes,glyphs --enable-check-lisp-object-type
 'CFLAGS=-O0 -g3''

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

[Robert Pluim]

>>>>> On Tue, 13 Oct 2020 10:35:28 +0300, Andrii Kolomoiets <andreyk.mad@gmail.com> said:

    Andrii> Update to recent trunk brought me everyone's favorite random crashes.
    Andrii> In an attempt to find the recipe for reproduce the bug somehow, I spot
    Andrii> two crashes that I actually can reproduce in 'emacs -Q'.

    Andrii> The first one is more "stable":

    Andrii> With this code in scratch and point at '|':

    Andrii>     (make-frame `((parent-frame . ,(selected-frame))
    Andrii>                   (width . 0.5)
    Andrii>                   (height . 0.5)
    Andrii>                   (top . 0.5)
    Andrii>                   (left . 0.5)))|

    Andrii> 1. C-x C-e
    Andrii> 2. s-w

    Andrii> Repeating these two steps 3-5 times leads to crash.  Most of the time
    Andrii> the only meaningfull record in the 'bt' is:

    Andrii> Thread 3 received signal SIGSEGV, Segmentation fault.
    Andrii> 0x00007fff6fa97678 in ?? ()
    Andrii> (gdb) bt full
    Andrii> #0  0x00007fff6fa97678 in ?? ()
    Andrii> No symbol table info available.
    Andrii> #1  0x0000000100476338 in -[EmacsImage dealloc] (self=0x1014c77f0, _cmd=0x7fff7afcdc58) at nsimage.m:286
    Andrii> No locals.

    Andrii> It may be tool bar related, because Emacs is not crashing with
    Andrii> tool-bar-mode turned of.

I think you may be right:

(lldb) bt
* thread #1, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=1, address=0x20)
  * frame #0: 0x00007fff6be26678 libobjc.A.dylib`objc_release + 24
    frame #1: 0x00000001001f5d1f emacs`-[EmacsImage dealloc](self=0x0000000102ac8ff0, _cmd=<unavailable>) at nsimage.m:286:3 [opt]
    frame #2: 0x00007fff6be2beb3 libobjc.A.dylib`objc_object::sidetable_release(bool) + 229
    frame #3: 0x00007fff301e46e1 AppKit`-[NSMenuItem dealloc] + 108
    frame #4: 0x00007fff304523f8 AppKit`-[NSToolbarItem dealloc] + 110
    frame #5: 0x00007fff32f072a5 CoreFoundation`__RELEASE_OBJECTS_IN_THE_ARRAY__ + 118
    frame #6: 0x00007fff32f071e8 CoreFoundation`-[__NSArrayM dealloc] + 279
    frame #7: 0x00007fff305b1a99 AppKit`-[NSToolbarClippedItemsIndicator dealloc] + 84
    frame #8: 0x00007fff6be42054 libobjc.A.dylib`AutoreleasePoolPage::releaseUntil(objc_object**) + 134
    frame #9: 0x00007fff6be26dba libobjc.A.dylib`objc_autoreleasePoolPop + 175
    frame #10: 0x00007fff32f69335 CoreFoundation`__CFRUNLOOP_IS_CALLING_OUT_TO_AN_OBSERVER_CALLBACK_FUNCTION__ + 23
    frame #11: 0x00007fff32f69267 CoreFoundation`__CFRunLoopDoObservers + 457
    frame #12: 0x00007fff32f68805 CoreFoundation`__CFRunLoopRun + 874
    frame #13: 0x00007fff32f67e3e CoreFoundation`CFRunLoopRunSpecific + 462
    frame #14: 0x00007fff31b94abd HIToolbox`RunCurrentEventLoopInMode + 292
    frame #15: 0x00007fff31b946f4 HIToolbox`ReceiveNextEventCommon + 359
    frame #16: 0x00007fff31b94579 HIToolbox`_BlockUntilNextEventMatchingListInModeWithFilter + 64
    frame #17: 0x00007fff301da039 AppKit`_DPSNextEvent + 883
    frame #18: 0x00007fff301d8880 AppKit`-[NSApplication(NSEvent) _nextEventMatchingEventMask:untilDate:inMode:dequeue:] + 1352
    frame #19: 0x00007fff301ca58e AppKit`-[NSApplication run] + 658
    frame #20: 0x00000001001d708d emacs`-[EmacsApp run](self=0x0000000102a10a70, _cmd=<unavailable>) at nsterm.m:5765:9 [opt]
    frame #21: 0x00000001001e3a1e emacs`ns_read_socket(terminal=<unavailable>, hold_quit=<unavailable>) at nsterm.m:4741:11 [opt]
    frame #22: 0x00000001000d11cd emacs`gobble_input at keyboard.c:6889:17 [opt]

which is nsimage.m:

- (void)dealloc
{
  [stippleMask release];
  [bmRep release];
  [transform release];  <====
  [super dealloc];
}

Alan?

    Andrii> The second one is not reproducible every time:

    Andrii> 1. M-x tool-bar-mode
    Andrii> 2. Evaluate
    Andrii>     (let ((params `((parent-frame . ,(selected-frame))
    Andrii>                     (undecorated . t))))
    Andrii>       (dotimes (_z 100)
    Andrii>         (set-face-background 'internal-border "black"
    Andrii>                              (make-frame params))))
    Andrii> 3. Move the frame

And this I see as well, however lldb does warn us:

2020-10-13 14:54:46.765446+0200 emacs[65592:8296279] [Window] WARNING: NSWindow has detected an excessive live window count of 101. Window 0x2e668 of class 'EmacsWindow' created after passing the threshold of 100. This window is not necessarily the cause, and this warning will only be shown once per window class.

    Andrii> Thread 3 received signal SIGSEGV, Segmentation fault.
    Andrii> 0x0000000100456e88 in ns_clear_under_internal_border (f=0x13cedafe8) at nsterm.m:3052
    Andrii> 3052	      [ns_lookup_indexed_color (NS_FACE_BACKGROUND (face), f) set];
    Andrii> (gdb) bt full

I suspect some initialization has been skipped somewhere:

    frame #0: 0x00000001001e81bc emacs`ns_clear_under_internal_border(f=0x0000000132288150) at nsterm.m:3052:33 [opt]
   3049         face = FRAME_DEFAULT_FACE (f);
   3050
   3051       ns_focus (f, &frame_rect, 1);
-> 3052       [ns_lookup_indexed_color (NS_FACE_BACKGROUND (face), f) set];
   3053       for (int i = 0; i < 4 ; i++)
   3054         {
   3055           NSDivideRect (frame_rect, &edge_rect, &frame_rect, border_width, edge[i]);
Target 0: (emacs) stopped.
(lldb) p face
(face *) $0 = 0x0000000000000000

Robert
-- 

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

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

[Alan Third]

On Tue, Oct 13, 2020 at 03:00:31PM +0200, Robert Pluim wrote:
> 
> (lldb) bt
> * thread #1, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=1, address=0x20)
>   * frame #0: 0x00007fff6be26678 libobjc.A.dylib`objc_release + 24
>     frame #1: 0x00000001001f5d1f emacs`-[EmacsImage dealloc](self=0x0000000102ac8ff0, _cmd=<unavailable>) at nsimage.m:286:3 [opt]
<snip>
> 
> which is nsimage.m:
> 
> - (void)dealloc
> {
>   [stippleMask release];
>   [bmRep release];
>   [transform release];  <====
>   [super dealloc];
> }
> 
> Alan?

Are you sure it's crashing on that line? That makes no sense as
there's nowhere else that can release the transform, and if the image
doesn't have a transform set it should be nil so releasing it would be
a no-op... 

But even if it's a neighbouring line, I can't see why that would be
happening...

I have no ideas.
-- 
Alan Third

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

[Andrii Kolomoiets]

Alan Third <alan@idiocy.org> writes:

> On Tue, Oct 13, 2020 at 10:35:28AM +0300, Andrii Kolomoiets wrote:
>> 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.
>
> +      if (!face)
> +        return;
>
> "fixes" it, but leaves Emacs in a bit of a strange state where I can
> only see one frame and it's incredibly slow.

It's because all child frames are undecorated.  Just remove
'(undecorated . t)' from 'params' and you'll see all the frames.

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

[Andrii Kolomoiets]

Alan Third <alan@idiocy.org> writes:

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

Was working in Emacs under lldb for almost two days to catch my random
crash and here it is:

Process 78804 stopped
* thread #1, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=1, address=0xc0)
    frame #0: 0x0000000100456e88 emacs`ns_clear_under_internal_border + 424
emacs`ns_clear_under_internal_border:
->  0x100456e88 <+424>: movq   0xc0(%rax), %rdi
    0x100456e8f <+431>: movq   -0x38(%rbp), %rsi
    0x100456e93 <+435>: callq  0x1004375a0               ; ns_lookup_indexed_color
    0x100456e98 <+440>: movq   0xce5a1(%rip), %rsi       ; "set"
Target 0: (emacs) stopped.
(lldb) bt
* thread #1, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=1, address=0xc0)
  * frame #0: 0x0000000100456e88 emacs`ns_clear_under_internal_border + 424
    frame #1: 0x00000001000afe95 emacs`clear_garbaged_frames at xdisp.c:12110:17

Debug map object file for nsterm.o is ignored because it has changed, so
backtrace may be not so useful.

Going to work in Emacs under lldb with your patch applied to see if it
will crash again.

Thanks!

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

[Robert Pluim]

>>>>> On Tue, 13 Oct 2020 21:33:42 +0100, Alan Third <alan@idiocy.org> said:

    Alan> On Tue, Oct 13, 2020 at 03:00:31PM +0200, Robert Pluim wrote:
    >> 
    >> (lldb) bt
    >> * thread #1, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=1, address=0x20)
    >> * frame #0: 0x00007fff6be26678 libobjc.A.dylib`objc_release + 24
    >> frame #1: 0x00000001001f5d1f emacs`-[EmacsImage dealloc](self=0x0000000102ac8ff0, _cmd=<unavailable>) at nsimage.m:286:3 [opt]
    Alan> <snip>
    >> 
    >> which is nsimage.m:
    >> 
    >> - (void)dealloc
    >> {
    >> [stippleMask release];
    >> [bmRep release];
    >> [transform release];  <====
    >> [super dealloc];
    >> }
    >> 
    >> Alan?

    Alan> Are you sure it's crashing on that line? That makes no sense as
    Alan> there's nowhere else that can release the transform, and if the image
    Alan> doesn't have a transform set it should be nil so releasing it would be
    Alan> a no-op... 

If I comment out [transform release]; I canʼt make it crash.

Robert
-- 

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:
>     (make-frame `((parent-frame . ,(selected-frame))
>                   (width . 0.5)
>                   (height . 0.5)
>                   (top . 0.5)
>                   (left . 0.5)))|

Out of interest, does the frame need to be smaller than default for
the crash to happen? For example if width is 1 does it still crash?
-- 
Alan Third

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

[Andrii Kolomoiets]

Alan Third <alan@idiocy.org> writes:

> On Tue, Oct 13, 2020 at 10:35:28AM +0300, Andrii Kolomoiets wrote:
>>     (make-frame `((parent-frame . ,(selected-frame))
>>                   (width . 0.5)
>>                   (height . 0.5)
>>                   (top . 0.5)
>>                   (left . 0.5)))|
>
> Out of interest, does the frame need to be smaller than default for
> the crash to happen? For example if width is 1 does it still crash?

The frame must be small enough to not all the toolbar buttons fits the
toolbar:

(setq test-frame (make-frame `((parent-frame . ,(selected-frame))
			                   (width . 41))))

The last button (isearch) is replaced by ">>".

There are no crash if '(width . 42)'.

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

[Alan Third]

On Thu, Oct 15, 2020 at 12:01:17AM +0300, Andrii Kolomoiets wrote:
> Alan Third <alan@idiocy.org> writes:
> 
> > On Tue, Oct 13, 2020 at 10:35:28AM +0300, Andrii Kolomoiets wrote:
> >>     (make-frame `((parent-frame . ,(selected-frame))
> >>                   (width . 0.5)
> >>                   (height . 0.5)
> >>                   (top . 0.5)
> >>                   (left . 0.5)))|
> >
> > Out of interest, does the frame need to be smaller than default for
> > the crash to happen? For example if width is 1 does it still crash?
> 
> The frame must be small enough to not all the toolbar buttons fits the
> toolbar:
> 
> (setq test-frame (make-frame `((parent-frame . ,(selected-frame))
> 			                   (width . 41))))
> 
> The last button (isearch) is replaced by ">>".

Funnily enough that ">>" is what I was looking at. I guess it's a
toolkit image and not something we provide with Emacs...?

> There are no crash if '(width . 42)'.

Can you try this:

modified   src/nsmenu.m
@@ -1207,7 +1207,7 @@ - (BOOL) changed
     enablement == prevEnablement ? NO : YES;
 }
 
-- (void) addDisplayItemWithImage: (EmacsImage *)img
+- (void) addDisplayItemWithImage: (NSImage *)img
                              idx: (int)idx
                              tag: (int)tag
                         helpText: (const char *)help

modified   src/nsterm.h
@@ -561,7 +561,7 @@ #define NS_DRAW_TO_BUFFER 1
 - (void) clearActive;
 - (void) clearAll;
 - (BOOL) changed;
-- (void) addDisplayItemWithImage: (EmacsImage *)img
+- (void) addDisplayItemWithImage: (NSImage *)img
                              idx: (int)idx
                              tag: (int)tag
                         helpText: (const char *)help

-- 
Alan Third

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

[Andrii Kolomoiets]

Alan Third <alan@idiocy.org> writes:

>> The frame must be small enough to not all the toolbar buttons fits the
>> toolbar:
>> 
>> (setq test-frame (make-frame `((parent-frame . ,(selected-frame))
>> 			                   (width . 41))))
>> 
>> The last button (isearch) is replaced by ">>".
>
> Funnily enough that ">>" is what I was looking at. I guess it's a
> toolkit image and not something we provide with Emacs...?
>
>> There are no crash if '(width . 42)'.
>
> Can you try this:

Process 28381 stopped
* thread #1, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=1, address=0x10c94fc8)
    frame #0: 0x00007fff6fa97678 libobjc.A.dylib`objc_release + 24
libobjc.A.dylib`objc_release:
->  0x7fff6fa97678 <+24>: testb  $0x4, 0x20(%rax)
    0x7fff6fa9767c <+28>: je     0x7fff6fa976e7            ; <+135>
    0x7fff6fa9767e <+30>: movabsq $0x100000000000000, %rcx  ; imm = 0x100000000000000 
    0x7fff6fa97688 <+40>: movabsq $0x40000000000000, %rdx   ; imm = 0x40000000000000 
Target 0: (emacs) stopped.
(lldb) bt
* thread #1, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=1, address=0x10c94fc8)
  * frame #0: 0x00007fff6fa97678 libobjc.A.dylib`objc_release + 24
    frame #1: 0x0000000100476338 emacs`-[EmacsImage dealloc](self=0x000000010178c650, _cmd="dealloc") at nsimage.m:286:3
    frame #2: 0x00007fff6fa9ceb3 libobjc.A.dylib`objc_object::sidetable_release(bool) + 229
    frame #3: 0x00007fff33e5a6e1 AppKit`-[NSMenuItem dealloc] + 108
    frame #4: 0x00007fff340c83f8 AppKit`-[NSToolbarItem dealloc] + 110
    frame #5: 0x00007fff36b7d2a5 CoreFoundation`__RELEASE_OBJECTS_IN_THE_ARRAY__ + 118
    frame #6: 0x00007fff36b7d1e8 CoreFoundation`-[__NSArrayM dealloc] + 279
    frame #7: 0x00007fff34227a99 AppKit`-[NSToolbarClippedItemsIndicator dealloc] + 84
    frame #8: 0x00007fff6fab3054 libobjc.A.dylib`AutoreleasePoolPage::releaseUntil(objc_object**) + 134
    frame #9: 0x00007fff6fa97dba libobjc.A.dylib`objc_autoreleasePoolPop + 175
    frame #10: 0x00007fff36bdf335 CoreFoundation`__CFRUNLOOP_IS_CALLING_OUT_TO_AN_OBSERVER_CALLBACK_FUNCTION__ + 23
    frame #11: 0x00007fff36bdf267 CoreFoundation`__CFRunLoopDoObservers + 457
    frame #12: 0x00007fff36bde805 CoreFoundation`__CFRunLoopRun + 874
    frame #13: 0x00007fff36bdde3e CoreFoundation`CFRunLoopRunSpecific + 462
    frame #14: 0x00007fff3580aabd HIToolbox`RunCurrentEventLoopInMode + 292
    frame #15: 0x00007fff3580a6f4 HIToolbox`ReceiveNextEventCommon + 359
    frame #16: 0x00007fff3580a579 HIToolbox`_BlockUntilNextEventMatchingListInModeWithFilter + 64
    frame #17: 0x00007fff33e50039 AppKit`_DPSNextEvent + 883
    frame #18: 0x00007fff33e4e880 AppKit`-[NSApplication(NSEvent) _nextEventMatchingEventMask:untilDate:inMode:dequeue:] + 1352
    frame #19: 0x00007fff33e4058e AppKit`-[NSApplication run] + 658
    frame #20: 0x000000010043b9ba emacs`-[EmacsApp run](self=0x000000010152b3a0, _cmd="run") at nsterm.m:5768:9

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

[Win Treese]

I got curious about what was going on with this bug after looking at other alloc/dealloc problems on the Mac, and I’m wondering if there is an initialization problem in setTranform:

The code is:

- (void)setTransform: (double[3][3]) m
{
  transform = [[NSAffineTransform transform] retain];
  NSAffineTransformStruct tm
    = { m[0][0], m[0][1], m[1][0], m[1][1], m[2][0], m[2][1]};
  [transform setTransformStruct:tm];
}

It seems to create a new NSAffineTransform object with the existing value of transform. I imagine that would be NULL the first time through. When the deallocation happens (the [transform dealloc] mentioned earlier in the thread, I think the following might happen:

[transform dealloc] essentially calls [NSAffineTransform dealloc], which then tries to dealloc the object it was initialized with, which was null, and it crashes there.

Could that be what’s going on?

- Win

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

[Eli Zaretskii]

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

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

[Alan Third]

On Fri, Oct 23, 2020 at 09:37:43PM -0400, Win Treese wrote:
> I got curious about what was going on with this bug after looking at
> other alloc/dealloc problems on the Mac, and I’m wondering if there
> is an initialization problem in setTranform:
> 
> The code is:
> 
> - (void)setTransform: (double[3][3]) m
> {
>   transform = [[NSAffineTransform transform] retain];
>   NSAffineTransformStruct tm
>     = { m[0][0], m[0][1], m[1][0], m[1][1], m[2][0], m[2][1]};
>   [transform setTransformStruct:tm];
> }
>
> It seems to create a new NSAffineTransform object with the existing
> value of transform.

No, [NSAffineTransform transform] is a call to the class method
"transform", it's not actually a reference to the variable transform,
although I can see why that is confusing.

https://developer.apple.com/documentation/foundation/nsaffinetransform?language=objc

-- 
Alan Third

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

[Alan Third]

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

On Thu, Oct 15, 2020 at 12:33:44AM +0300, Andrii Kolomoiets wrote:
> Alan Third <alan@idiocy.org> writes:
> 
> >> The frame must be small enough to not all the toolbar buttons fits the
> >> toolbar:
> >> 
> >> (setq test-frame (make-frame `((parent-frame . ,(selected-frame))
> >> 			                   (width . 41))))
> >> 
> >> The last button (isearch) is replaced by ">>".
> >
> > Funnily enough that ">>" is what I was looking at. I guess it's a
> > toolkit image and not something we provide with Emacs...?
> >
> >> There are no crash if '(width . 42)'.
> >
> > Can you try this:

Can you please try the attached patch. It looks like NSToolbarItem
makes a copy of the image, but EmacsImage is not set up to create
copies of itself correctly.
-- 
Alan Third

[-- Attachment #2: 0001-Fix-crash-in-NS-toolbar-image-releasing-bug-43973.patch --]
[-- Type: text/plain, Size: 1195 bytes --]

From d111484d44744e3f68775a47b7f15ddf0d9b38c0 Mon Sep 17 00:00:00 2001
From: Alan Third <alan@idiocy.org>
Date: Sat, 2 Jan 2021 18:19:39 +0000
Subject: [PATCH] Fix crash in NS toolbar image releasing (bug#43973)

The toolbar fails to make a proper copy of EmacsImage objects, so
releasing the copy incorrectly released instance variables from the
original objects.

* src/nsimage.m ([EmacsImage copyWithZone:]): New function to enable
correct copying of EmacsImage.
---
 src/nsimage.m | 12 ++++++++++++
 1 file changed, 12 insertions(+)

diff --git a/src/nsimage.m b/src/nsimage.m
index f0014b50b9..fa81a41a51 100644
--- a/src/nsimage.m
+++ b/src/nsimage.m
@@ -293,6 +293,18 @@ - (void)dealloc
 }
 
 
+- (id)copyWithZone:(NSZone *)zone
+{
+  EmacsImage *copy = [super copyWithZone:zone];
+
+  copy->stippleMask = [stippleMask copyWithZone:zone];
+  copy->bmRep = [bmRep copyWithZone:zone];
+  copy->transform = [transform copyWithZone:zone];
+
+  return copy;
+}
+
+
 /* Create image from monochrome bitmap. If both FG and BG are 0
    (black), set the background to white and make it transparent.  */
 - (instancetype)initFromXBM: (unsigned char *)bits width: (int)w height: (int)h
-- 
2.29.2

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

[Andrii Kolomoiets]

Alan Third <alan@idiocy.org> writes:

> On Thu, Oct 15, 2020 at 12:33:44AM +0300, Andrii Kolomoiets wrote:
>> Alan Third <alan@idiocy.org> writes:
>> 
>> >> The frame must be small enough to not all the toolbar buttons fits the
>> >> toolbar:
>> >> 
>> >> (setq test-frame (make-frame `((parent-frame . ,(selected-frame))
>> >> 			                   (width . 41))))
>> >> 
>> >> The last button (isearch) is replaced by ">>".
>> >
>> > Funnily enough that ">>" is what I was looking at. I guess it's a
>> > toolkit image and not something we provide with Emacs...?
>> >
>> >> There are no crash if '(width . 42)'.
>> >
>> > Can you try this:
>
> Can you please try the attached patch. It looks like NSToolbarItem
> makes a copy of the image, but EmacsImage is not set up to create
> copies of itself correctly.

Since reporting that bug, I have updated my operating system and cannot
reproduce it on the latest Emacs version.

Toolbar items are now placed in the title bar.  I've tried to reproduce
the bug (but with no luck) after switching to old toolbar items
placement with command:

  defaults write -g NSWindowSupportsAutomaticInlineTitle -bool false

We need someone with the previous macos version to help with testing.

For me Emacs with your patch applied works fine.

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

[Alan Third]

On Sun, Jan 03, 2021 at 12:03:40AM +0200, Andrii Kolomoiets wrote:
> 
> Since reporting that bug, I have updated my operating system and cannot
> reproduce it on the latest Emacs version.
> 
> Toolbar items are now placed in the title bar.  I've tried to reproduce
> the bug (but with no luck) after switching to old toolbar items
> placement with command:
> 
>   defaults write -g NSWindowSupportsAutomaticInlineTitle -bool false
> 
> We need someone with the previous macos version to help with testing.
> 
> For me Emacs with your patch applied works fine.

OK, thanks. It fixes, what is at the very least, a related crash for
me, so I'm going to assume it's the same problem and close this bug
report.

If anyone still sees this crash on master, please reopen the bug
report.
-- 
Alan Third