bug#44313: 27.1.50; ns_mouse_position EXC_BAD_ACCESS crash

[Eli Zaretskii <eliz@gnu.org>]

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