bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#44313: 27.1.50; ns_mouse_position EXC_BAD_ACCESS crash


From: Alan Third
Subject: bug#44313: 27.1.50; ns_mouse_position EXC_BAD_ACCESS crash
Date: Fri, 30 Oct 2020 22:35:21 +0000

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





reply via email to

[Prev in Thread] Current Thread [Next in Thread]