bug#44313: 27.1.50; ns_mouse_position EXC_BAD_ACCESS crash

bug#44313: 27.1.50; ns_mouse_position EXC_BAD_ACCESS crash

[Aaron Jensen]

Not sure how to reproduce this, but it has happened multiple times
today. I'm on e29cace60a

* thread #1, queue = 'com.apple.main-thread', stop reason =
EXC_BAD_ACCESS (code=1, address=0x9038f6d4d)
  * frame #0: 0x0000000100378558
emacs`ns_mouse_position(fp=0x00007ffeefbfd3e8, insist=-1,
bar_window=0x00007ffeefbfd3e0, part=0x00007ffeefbfd3c4,
x=0x00007ffeefbfd3d8, y=0x00007ffeefbfd3d0, time=0x00007ffeefbfd3b8)
at nsterm.m:2536:12
    frame #1: 0x000000010001fefc emacs`Fmouse_pixel_position at frame.c:2494:7
    frame #2: 0x00000001002693c6
emacs`funcall_subr(subr=0x0000000100412bc8, numargs=0,
args=0x00007ffeefbfd588) at eval.c:2866:19
    frame #3: 0x0000000100268204 emacs`Ffuncall(nargs=1,
args=0x00007ffeefbfd580) at eval.c:2795:11
    frame #4: 0x00000001002d951e
emacs`exec_byte_code(bytestr=0x000000010422a0a4,
vector=0x0000000104229fa5, maxdepth=0x000000000000002a,
args_template=0x0000000000000406, nargs=1, args=0x00007ffeefbfdcf8) at
bytecode.c:633:12
    frame #5: 0x000000010026985c
emacs`funcall_lambda(fun=0x0000000104229f75, nargs=1,
arg_vector=0x00007ffeefbfdcf0) at eval.c:2990:11
    frame #6: 0x000000010026824e emacs`Ffuncall(nargs=2,
args=0x00007ffeefbfdce8) at eval.c:2797:11
    frame #7: 0x0000000100268d2f emacs`call1(fn=0x00000000000094b0,
arg1=0x0000000158414eb4) at eval.c:2655:10
    frame #8: 0x0000000100169ebf
emacs`show_help_echo(help=0x0000000158414eb4,
window=0x000000017dca1e35, object=0x00000001755c90a5,
pos=0x0000000000000346) at keyboard.c:2093:14
    frame #9: 0x000000010016cb33 emacs`read_char(commandflag=1,
map=0x00000001950c1a83, prev_event=0x0000000000000000,
used_mouse_menu=0x00007ffeefbfe7ef, end_time=0x0000000000000000) at
keyboard.c:3117:7
    frame #10: 0x0000000100166719
emacs`read_key_sequence(keybuf=0x00007ffeefbfeaf0,
prompt=0x0000000000000000, dont_downcase_last=false,
can_return_switch_frame=true, fix_current_buffer=true,
prevent_redisplay=false) at keyboard.c:9554:12
    frame #11: 0x0000000100165139 emacs`command_loop_1 at keyboard.c:1350:15
    frame #12: 0x0000000100261b4f
emacs`internal_condition_case(bfun=(emacs`command_loop_1 at
keyboard.c:1236), handlers=0x0000000000000090, hfun=(emacs`cmd_error
at keyboard.c:919)) at eval.c:1356:25
    frame #13: 0x000000010017ce8c
emacs`command_loop_2(ignore=0x0000000000000000) at keyboard.c:1091:11
    frame #14: 0x00000001002614ba
emacs`internal_catch(tag=0x000000000000c840,
func=(emacs`command_loop_2 at keyboard.c:1087),
arg=0x0000000000000000) at eval.c:1117:25
    frame #15: 0x00000001001640ca emacs`command_loop at keyboard.c:1070:2
    frame #16: 0x0000000100163f50 emacs`recursive_edit_1 at keyboard.c:714:9
    frame #17: 0x0000000100164299 emacs`Frecursive_edit at keyboard.c:786:3
    frame #18: 0x0000000100161764 emacs`main(argc=1,
argv=0x00007ffeefbff0a0) at emacs.c:2066:3
    frame #19: 0x00007fff6a33dcc9 libdyld.dylib`start + 1
(lldb) frame select 3
frame #3: 0x0000000100268204 emacs`Ffuncall(nargs=1,
args=0x00007ffeefbfd580) at eval.c:2795:11
   2792     fun = indirect_function (fun);
   2793
   2794   if (SUBRP (fun))
-> 2795     val = funcall_subr (XSUBR (fun), numargs, args + 1);
   2796   else if (COMPILEDP (fun) || MODULE_FUNCTIONP (fun))
   2797     val = funcall_lambda (fun, numargs, args + 1);
   2798   else
(lldb) p XSTRING(XSYMBOL(args[0])->u.s.name)->u.s.data
(unsigned char *) $0 = 0x00000001003e2c94 "mouse-pixel-position"

In GNU Emacs 27.1.50 (build 2, x86_64-apple-darwin19.6.0, NS
appkit-1894.60 Version 10.15.7 (Build 19H2))
 of 2020-10-28 built on my-machine
Repository revision: e29cace60afdab04ff20c4f4043a3ee64ec9d01d
Repository branch: emacs-27
Windowing system distributor 'Apple', version 10.3.1894
System Description:  Mac OS X 10.15.7


Memory information:
((conses 16 777153 878287)
 (symbols 48 68934 1027)
 (strings 32 241222 115526)
 (string-bytes 1 8380649)
 (vectors 16 109859)
 (vector-slots 8 1221060 903756)
 (floats 8 1729 3395)
 (intervals 56 6128 1401)
 (buffers 1000 18))


Aaron

bug#44313: 27.1.50; ns_mouse_position EXC_BAD_ACCESS crash

[Eli Zaretskii]

> From: Aaron Jensen <aaronjensen@gmail.com>
> Date: Thu, 29 Oct 2020 15:16:22 -0500
> 
> Not sure how to reproduce this, but it has happened multiple times
> today. I'm on e29cace60a
> 
> * thread #1, queue = 'com.apple.main-thread', stop reason =
> EXC_BAD_ACCESS (code=1, address=0x9038f6d4d)
>   * frame #0: 0x0000000100378558
> emacs`ns_mouse_position(fp=0x00007ffeefbfd3e8, insist=-1,
> bar_window=0x00007ffeefbfd3e0, part=0x00007ffeefbfd3c4,
> x=0x00007ffeefbfd3d8, y=0x00007ffeefbfd3d0, time=0x00007ffeefbfd3b8)
> at nsterm.m:2536:12
>     frame #1: 0x000000010001fefc emacs`Fmouse_pixel_position at frame.c:2494:7
[...]
> (lldb) frame select 3

The crash is in frame #0, so please show the relevant variables
there.  According to the line number the crash is here:

  if (f && FRAME_NS_P (f))

So why does FRAME_NS_P crash? which part of the frame's structure are
invalid?

Thanks.

bug#44313: 27.1.50; ns_mouse_position EXC_BAD_ACCESS crash

[Aaron Jensen]

On Fri, Oct 30, 2020 at 2:16 AM Eli Zaretskii <eliz@gnu.org> wrote:
> The crash is in frame #0, so please show the relevant variables
> there.

Okay, next time it crashes I will get what I can.

> According to the line number the crash is here:
>
>   if (f && FRAME_NS_P (f))
>
> So why does FRAME_NS_P crash? which part of the frame's structure are
> invalid?

I believe that macro is defined as:

    #define FRAME_NS_P(f) ((f)->output_method == output_ns)

Would the de-reference cause an EXC_BAD_ACCESS if the frame had been released?

I make use of child frames via the posframe packages. I wonder if
something requested a mouse pixel position for a frame either as it
was being released or after it was being released?

bug#44313: 27.1.50; ns_mouse_position EXC_BAD_ACCESS crash

[Eli Zaretskii]

> From: Aaron Jensen <aaronjensen@gmail.com>
> Date: Fri, 30 Oct 2020 05:16:35 -0500
> Cc: 44313@debbugs.gnu.org
> 
> >   if (f && FRAME_NS_P (f))
> >
> > So why does FRAME_NS_P crash? which part of the frame's structure are
> > invalid?
> 
> I believe that macro is defined as:
> 
>     #define FRAME_NS_P(f) ((f)->output_method == output_ns)
> 
> Would the de-reference cause an EXC_BAD_ACCESS if the frame had been released?

If f is non-NULL, I don't think it could case EXC_BAD_ACCESS, unless f
is garbled and points outside of the process's address space.  Which
is why we need to see the value of f and whether the address it points
to could be accessed.

> I make use of child frames via the posframe packages. I wonder if
> something requested a mouse pixel position for a frame either as it
> was being released or after it was being released?

For this, we need to see the Lisp-level backtrace at the crash.
Sadly, AFAIK lldb doesn't support the commands in src/.gdbinit, so the
only way to generate this I know of is to manually show the function
called by each Funcall in the C backtrace.  Which is quite tedious.

bug#44313: 27.1.50; ns_mouse_position EXC_BAD_ACCESS crash

[Aaron Jensen]

On Fri, Oct 30, 2020 at 6:29 AM Eli Zaretskii <eliz@gnu.org> wrote:
> If f is non-NULL, I don't think it could case EXC_BAD_ACCESS, unless f
> is garbled and points outside of the process's address space.  Which
> is why we need to see the value of f and whether the address it points
> to could be accessed.

Looks like it's non-NULL and it can't be accessed.

(lldb) p f
(frame *) $12 = 0x00000009040f6c5d
(lldb) p *f
error: Couldn't apply expression side effects : Couldn't dematerialize
a result variable: couldn't read its memory
(lldb) p (f)->output_method
error: supposed to interpret, but failed: Interpreter couldn't read from memory

> For this, we need to see the Lisp-level backtrace at the crash.
> Sadly, AFAIK lldb doesn't support the commands in src/.gdbinit, so the
> only way to generate this I know of is to manually show the function
> called by each Funcall in the C backtrace.  Which is quite tedious.

Here is the lisp trace, deepest first:

(unsigned char *) $14 = 0x00000001003f413d "mouse-fixup-help-message"
(unsigned char *) $15 = 0x00000001003e2c94 "mouse-pixel-position"

And the whole trace:

* thread #1, queue = 'com.apple.main-thread', stop reason =
EXC_BAD_ACCESS (code=1, address=0x9040f6d4d)
  * frame #0: 0x0000000100378558
emacs`ns_mouse_position(fp=0x00007ffeefbfd3e8, insist=-1,
bar_window=0x00007ffeefbfd3e0, part=0x00007ffeefbfd3c4,
x=0x00007ffeefbfd3d8, y=0x00007ffeefbfd3d0, time=0x00007ffeefbfd3b8)
at nsterm.m:2536:12
    frame #1: 0x000000010001fefc emacs`Fmouse_pixel_position at frame.c:2494:7
    frame #2: 0x00000001002693c6
emacs`funcall_subr(subr=0x0000000100412bc8, numargs=0,
args=0x00007ffeefbfd588) at eval.c:2866:19
    frame #3: 0x0000000100268204 emacs`Ffuncall(nargs=1,
args=0x00007ffeefbfd580) at eval.c:2795:11
    frame #4: 0x00000001002d951e
emacs`exec_byte_code(bytestr=0x0000000104a2a0a4,
vector=0x0000000104a29fa5, maxdepth=0x000000000000002a,
args_template=0x0000000000000406, nargs=1, args=0x00007ffeefbfdcf8) at
bytecode.c:633:12
    frame #5: 0x000000010026985c
emacs`funcall_lambda(fun=0x0000000104a29f75, nargs=1,
arg_vector=0x00007ffeefbfdcf0) at eval.c:2990:11
    frame #6: 0x000000010026824e emacs`Ffuncall(nargs=2,
args=0x00007ffeefbfdce8) at eval.c:2797:11
    frame #7: 0x0000000100268d2f emacs`call1(fn=0x00000000000094b0,
arg1=0x00000001497f07f4) at eval.c:2655:10
    frame #8: 0x0000000100169ebf
emacs`show_help_echo(help=0x00000001497f07f4,
window=0x000000028c2d1c05, object=0x00000001b3a638e5,
pos=0x00000000000007ce) at keyboard.c:2093:14
    frame #9: 0x000000010016cb33 emacs`read_char(commandflag=1,
map=0x000000029d82b233, prev_event=0x0000000000000000,
used_mouse_menu=0x00007ffeefbfe7ef, end_time=0x0000000000000000) at
keyboard.c:3117:7
    frame #10: 0x0000000100166719
emacs`read_key_sequence(keybuf=0x00007ffeefbfeaf0,
prompt=0x0000000000000000, dont_downcase_last=false,
can_return_switch_frame=true, fix_current_buffer=true,
prevent_redisplay=false) at keyboard.c:9554:12
    frame #11: 0x0000000100165139 emacs`command_loop_1 at keyboard.c:1350:15
    frame #12: 0x0000000100261b4f
emacs`internal_condition_case(bfun=(emacs`command_loop_1 at
keyboard.c:1236), handlers=0x0000000000000090, hfun=(emacs`cmd_error
at keyboard.c:919)) at eval.c:1356:25
    frame #13: 0x000000010017ce8c
emacs`command_loop_2(ignore=0x0000000000000000) at keyboard.c:1091:11
    frame #14: 0x00000001002614ba
emacs`internal_catch(tag=0x000000000000c840,
func=(emacs`command_loop_2 at keyboard.c:1087),
arg=0x0000000000000000) at eval.c:1117:25
    frame #15: 0x00000001001640ca emacs`command_loop at keyboard.c:1070:2
    frame #16: 0x0000000100163f50 emacs`recursive_edit_1 at keyboard.c:714:9
    frame #17: 0x0000000100164299 emacs`Frecursive_edit at keyboard.c:786:3
    frame #18: 0x0000000100161764 emacs`main(argc=1,
argv=0x00007ffeefbff0a0) at emacs.c:2066:3
    frame #19: 0x00007fff6a33dcc9 libdyld.dylib`start + 1

bug#44313: 27.1.50; ns_mouse_position EXC_BAD_ACCESS crash

[Eli Zaretskii]

> From: Aaron Jensen <aaronjensen@gmail.com>
> Date: Fri, 30 Oct 2020 10:54:56 -0500
> Cc: 44313@debbugs.gnu.org
> 
> On Fri, Oct 30, 2020 at 6:29 AM Eli Zaretskii <eliz@gnu.org> wrote:
> > If f is non-NULL, I don't think it could case EXC_BAD_ACCESS, unless f
> > is garbled and points outside of the process's address space.  Which
> > is why we need to see the value of f and whether the address it points
> > to could be accessed.
> 
> Looks like it's non-NULL and it can't be accessed.
> 
> (lldb) p f
> (frame *) $12 = 0x00000009040f6c5d
> (lldb) p *f
> error: Couldn't apply expression side effects : Couldn't dematerialize
> a result variable: couldn't read its memory
> (lldb) p (f)->output_method
> error: supposed to interpret, but failed: Interpreter couldn't read from memory

That doesn't sound like a frame that is not live, that sounds like a
frame whose memory was freed.  Or a frame pointer that is just
garbage.

So the question now is: where did that frame pointer come from?

bug#44313: 27.1.50; ns_mouse_position EXC_BAD_ACCESS crash

[Aaron Jensen]

On Fri, Oct 30, 2020 at 1:47 PM Eli Zaretskii <eliz@gnu.org> wrote:
> That doesn't sound like a frame that is not live, that sounds like a
> frame whose memory was freed.  Or a frame pointer that is just
> garbage.
>
> So the question now is: where did that frame pointer come from?

Good question--how might I debug that next time it happens?

bug#44313: 27.1.50; ns_mouse_position EXC_BAD_ACCESS crash

[Eli Zaretskii]

> From: Aaron Jensen <aaronjensen@gmail.com>
> Date: Fri, 30 Oct 2020 13:55:10 -0500
> Cc: 44313@debbugs.gnu.org
> 
> On Fri, Oct 30, 2020 at 1:47 PM Eli Zaretskii <eliz@gnu.org> wrote:
> > That doesn't sound like a frame that is not live, that sounds like a
> > frame whose memory was freed.  Or a frame pointer that is just
> > garbage.
> >
> > So the question now is: where did that frame pointer come from?
> 
> Good question--how might I debug that next time it happens?

I don't know.  The code in Fmouse_pixel_position uses the
selected-frame, so it is quite strange, to say the least, that this
frame could be garbled when you just move the mouse pointer.

bug#44313: 27.1.50; ns_mouse_position EXC_BAD_ACCESS crash

[Aaron Jensen]

On Fri, Oct 30, 2020 at 2:08 PM Eli Zaretskii <eliz@gnu.org> wrote:
> I don't know.  The code in Fmouse_pixel_position uses the
> selected-frame, so it is quite strange, to say the least, that this
> frame could be garbled when you just move the mouse pointer.

I'm in the debugger right now. It happened as soon as I started a
full-screen zoom screenshare (maybe that's a hint?)

The value of f is different than selected_frame and
dpyinfo->ns_focus_frame, which means that it's likely set in this
code:

#ifdef NS_IMPL_COCOA
  /* Find the uppermost Emacs frame under the mouse pointer.

     This doesn't work on GNUstep, although in recent versions there
     is compatibility code that makes it a noop.  */

  NSPoint screen_position = [NSEvent mouseLocation];
  NSInteger window_number = 0;
  do
    {
      NSWindow *w;

      window_number = [NSWindow windowNumberAtPoint:screen_position
                        belowWindowWithWindowNumber:window_number];
      w = [NSApp windowWithWindowNumber:window_number];

      if (w && [[w delegate] isKindOfClass:[EmacsView class]])
        f = ((EmacsView *)[w delegate])->emacsframe;
    }
  while (window_number > 0 && !f);
#endif

I wonder if a check for FRAME_LIVE_P should be added here for safety?

bug#44313: 27.1.50; ns_mouse_position EXC_BAD_ACCESS crash

[Eli Zaretskii]

> From: Aaron Jensen <aaronjensen@gmail.com>
> Date: Fri, 30 Oct 2020 14:37:04 -0500
> Cc: 44313@debbugs.gnu.org
> 
> On Fri, Oct 30, 2020 at 2:08 PM Eli Zaretskii <eliz@gnu.org> wrote:
> > I don't know.  The code in Fmouse_pixel_position uses the
> > selected-frame, so it is quite strange, to say the least, that this
> > frame could be garbled when you just move the mouse pointer.
> 
> I'm in the debugger right now. It happened as soon as I started a
> full-screen zoom screenshare (maybe that's a hint?)
> 
> The value of f is different than selected_frame and
> dpyinfo->ns_focus_frame, which means that it's likely set in this
> code:
> 
> #ifdef NS_IMPL_COCOA
>   /* Find the uppermost Emacs frame under the mouse pointer.
> 
>      This doesn't work on GNUstep, although in recent versions there
>      is compatibility code that makes it a noop.  */
> 
>   NSPoint screen_position = [NSEvent mouseLocation];
>   NSInteger window_number = 0;
>   do
>     {
>       NSWindow *w;
> 
>       window_number = [NSWindow windowNumberAtPoint:screen_position
>                         belowWindowWithWindowNumber:window_number];
>       w = [NSApp windowWithWindowNumber:window_number];
> 
>       if (w && [[w delegate] isKindOfClass:[EmacsView class]])
>         f = ((EmacsView *)[w delegate])->emacsframe;
>     }
>   while (window_number > 0 && !f);
> #endif

I'll let Alan chime in here.  This is deep in NS specific code which
I'm not familiar with.

> I wonder if a check for FRAME_LIVE_P should be added here for safety?

But the frame pointer in this case would crash FRAME_LIVE_P as well,
AFAIU, because it cannot be dereferenced.  See your last debug
session, where the debugger tells this quite explicitly.

bug#44313: 27.1.50; ns_mouse_position EXC_BAD_ACCESS crash

[Aaron Jensen]

On Fri, Oct 30, 2020 at 3:12 PM Eli Zaretskii <eliz@gnu.org> wrote:
> But the frame pointer in this case would crash FRAME_LIVE_P as well,
> AFAIU, because it cannot be dereferenced.  See your last debug
> session, where the debugger tells this quite explicitly.

Ah, yes, I should have looked at the implementation of FRAME_LIVE_P.
Not sure how it would have worked any other way in hindsight.

bug#44313: 27.1.50; ns_mouse_position EXC_BAD_ACCESS crash

[Alan Third]

On Fri, Oct 30, 2020 at 10:12:31PM +0200, Eli Zaretskii wrote:
> > From: Aaron Jensen <aaronjensen@gmail.com>
> > Date: Fri, 30 Oct 2020 14:37:04 -0500
> > Cc: 44313@debbugs.gnu.org
> > 
> > On Fri, Oct 30, 2020 at 2:08 PM Eli Zaretskii <eliz@gnu.org> wrote:
> > > I don't know.  The code in Fmouse_pixel_position uses the
> > > selected-frame, so it is quite strange, to say the least, that this
> > > frame could be garbled when you just move the mouse pointer.
> > 
> > I'm in the debugger right now. It happened as soon as I started a
> > full-screen zoom screenshare (maybe that's a hint?)
> > 
> > The value of f is different than selected_frame and
> > dpyinfo->ns_focus_frame, which means that it's likely set in this
> > code:
> > 
> > #ifdef NS_IMPL_COCOA
> >   /* Find the uppermost Emacs frame under the mouse pointer.
> > 
> >      This doesn't work on GNUstep, although in recent versions there
> >      is compatibility code that makes it a noop.  */
> > 
> >   NSPoint screen_position = [NSEvent mouseLocation];
> >   NSInteger window_number = 0;
> >   do
> >     {
> >       NSWindow *w;
> > 
> >       window_number = [NSWindow windowNumberAtPoint:screen_position
> >                         belowWindowWithWindowNumber:window_number];
> >       w = [NSApp windowWithWindowNumber:window_number];
> > 
> >       if (w && [[w delegate] isKindOfClass:[EmacsView class]])
> >         f = ((EmacsView *)[w delegate])->emacsframe;
> >     }
> >   while (window_number > 0 && !f);
> > #endif
> 
> I'll let Alan chime in here.  This is deep in NS specific code which
> I'm not familiar with.

Hmm, this just steps through the OS windows, from top to bottom and
finds the first one that is of type EmacsView, which should always be
associated with an Emacs frame.

The implication here is that we've got an Emacs frame still being
displayed after the frame has been freed. That seems a little odd.

Maybe we need to ensure that OS windows are closed. Something like
this, perhaps:

modified   src/nsterm.m
@@ -1782,6 +1782,8 @@ Hide the window (X11 semantics)
 {
   NSTRACE ("ns_destroy_window");
 
+  check_window_system (f);
+
   /* If this frame has a parent window, detach it as not doing so can
      cause a crash in GNUStep.  */
   if (FRAME_PARENT_FRAME (f) != NULL)
@@ -1792,7 +1794,7 @@ Hide the window (X11 semantics)
       [parent removeChildWindow: child];
     }
 
-  check_window_system (f);
+  [[FRAME_NS_VIEW (f) window] close];
   ns_free_frame_resources (f);
   ns_window_num--;
 }

-- 
Alan Third

bug#44313: 27.1.50; ns_mouse_position EXC_BAD_ACCESS crash

[Aaron Jensen]

On Fri, Oct 30, 2020 at 5:35 PM Alan Third <alan@idiocy.org> wrote:
>
> Maybe we need to ensure that OS windows are closed. Something like
> this, perhaps:

I'm trying this out and so far, no crashes, despite multiple Zoom
screen shares (which is often associated with the crash)

bug#44313: 27.1.50; ns_mouse_position EXC_BAD_ACCESS crash

[Aaron Jensen]

I've got even more time with this patch now and still no crashes. No
other problems that I've seen either. It seems like a good change.
Thanks, Alan. Would this be good to go in 27?

Aaron

On Mon, Nov 2, 2020 at 12:11 PM Aaron Jensen <aaronjensen@gmail.com> wrote:
>
> On Fri, Oct 30, 2020 at 5:35 PM Alan Third <alan@idiocy.org> wrote:
> >
> > Maybe we need to ensure that OS windows are closed. Something like
> > this, perhaps:
>
> I'm trying this out and so far, no crashes, despite multiple Zoom
> screen shares (which is often associated with the crash)

bug#44313: 27.1.50; ns_mouse_position EXC_BAD_ACCESS crash

[Alan Third]

On Fri, Nov 06, 2020 at 08:29:34AM -0600, Aaron Jensen wrote:
> I've got even more time with this patch now and still no crashes. No
> other problems that I've seen either. It seems like a good change.
> Thanks, Alan. Would this be good to go in 27?

I think so, unless anyone has any objections?

It fixes a real world crash and is a very small change.
-- 
Alan Third

bug#44313: 27.1.50; ns_mouse_position EXC_BAD_ACCESS crash

[Lars Ingebrigtsen]

Alan Third <alan@idiocy.org> writes:

> On Fri, Nov 06, 2020 at 08:29:34AM -0600, Aaron Jensen wrote:
>> I've got even more time with this patch now and still no crashes. No
>> other problems that I've seen either. It seems like a good change.
>> Thanks, Alan. Would this be good to go in 27?
>
> I think so, unless anyone has any objections?
>
> It fixes a real world crash and is a very small change.

My impression is that more people use the Emacs 28 branch than the 27
branch, so for low-level changes like this, I think it's often
preferable to apply them to Emacs 28 and then cherry-pick them for Emacs
27 after a week or so (if no problems have been seen).

But you're the domain expert here, so if you think this change is safe
enough for Emacs 27, then go ahead and do it there directly.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#44313: 27.1.50; ns_mouse_position EXC_BAD_ACCESS crash

[Alan Third]

On Mon, Nov 09, 2020 at 03:43:01PM +0100, Lars Ingebrigtsen wrote:
> Alan Third <alan@idiocy.org> writes:
> 
> > On Fri, Nov 06, 2020 at 08:29:34AM -0600, Aaron Jensen wrote:
> >> I've got even more time with this patch now and still no crashes. No
> >> other problems that I've seen either. It seems like a good change.
> >> Thanks, Alan. Would this be good to go in 27?
> >
> > I think so, unless anyone has any objections?
> >
> > It fixes a real world crash and is a very small change.
> 
> My impression is that more people use the Emacs 28 branch than the 27
> branch, so for low-level changes like this, I think it's often
> preferable to apply them to Emacs 28 and then cherry-pick them for Emacs
> 27 after a week or so (if no problems have been seen).

I've pushed to master as 18a7267c32a909bb26bd93d24543155aeb10e042.

-- 
Alan Third

bug#44313: 27.1.50; ns_mouse_position EXC_BAD_ACCESS crash

[Alan Third]

On Mon, Nov 09, 2020 at 02:54:50PM +0000, Alan Third wrote:
> On Mon, Nov 09, 2020 at 03:43:01PM +0100, Lars Ingebrigtsen wrote:
> > Alan Third <alan@idiocy.org> writes:
> > 
> > > On Fri, Nov 06, 2020 at 08:29:34AM -0600, Aaron Jensen wrote:
> > >> I've got even more time with this patch now and still no crashes. No
> > >> other problems that I've seen either. It seems like a good change.
> > >> Thanks, Alan. Would this be good to go in 27?
> > >
> > > I think so, unless anyone has any objections?
> > >
> > > It fixes a real world crash and is a very small change.
> > 
> > My impression is that more people use the Emacs 28 branch than the 27
> > branch, so for low-level changes like this, I think it's often
> > preferable to apply them to Emacs 28 and then cherry-pick them for Emacs
> > 27 after a week or so (if no problems have been seen).
> 
> I've pushed to master as 18a7267c32a909bb26bd93d24543155aeb10e042.

Now pushed to Emacs 27.

Thanks.
-- 
Alan Third