GNU bug report logs - #44313
27.1.50; ns_mouse_position EXC_BAD_ACCESS crash

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 44313 in the body.
You can then email your comments to 44313 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Aaron Jensen <aaronjensen <at> gmail.com>
To: bug-gnu-emacs <at> gnu.org
Subject: 27.1.50; ns_mouse_position EXC_BAD_ACCESS crash
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
    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

Message #8 received at 44313 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Aaron Jensen <aaronjensen <at> gmail.com>
Cc: 44313 <at> debbugs.gnu.org
Subject: Re: bug#44313: 27.1.50; ns_mouse_position EXC_BAD_ACCESS crash
Date: Fri, 30 Oct 2020 09:15:52 +0200

> From: Aaron Jensen <aaronjensen <at> 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.

Message #11 received at 44313 <at> debbugs.gnu.org (full text, mbox):

From: Aaron Jensen <aaronjensen <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 44313 <at> debbugs.gnu.org
Subject: Re: bug#44313: 27.1.50; ns_mouse_position EXC_BAD_ACCESS crash
Date: Fri, 30 Oct 2020 05:16:35 -0500

On Fri, Oct 30, 2020 at 2:16 AM Eli Zaretskii <eliz <at> 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?

Message #14 received at 44313 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Aaron Jensen <aaronjensen <at> gmail.com>
Cc: 44313 <at> debbugs.gnu.org
Subject: Re: bug#44313: 27.1.50; ns_mouse_position EXC_BAD_ACCESS crash
Date: Fri, 30 Oct 2020 13:29:31 +0200

> From: Aaron Jensen <aaronjensen <at> gmail.com>
> Date: Fri, 30 Oct 2020 05:16:35 -0500
> Cc: 44313 <at> 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.

Message #17 received at 44313 <at> debbugs.gnu.org (full text, mbox):

From: Aaron Jensen <aaronjensen <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 44313 <at> debbugs.gnu.org
Subject: Re: bug#44313: 27.1.50; ns_mouse_position EXC_BAD_ACCESS crash
Date: Fri, 30 Oct 2020 10:54:56 -0500

On Fri, Oct 30, 2020 at 6:29 AM Eli Zaretskii <eliz <at> 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

Message #20 received at 44313 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Aaron Jensen <aaronjensen <at> gmail.com>
Cc: 44313 <at> debbugs.gnu.org
Subject: Re: bug#44313: 27.1.50; ns_mouse_position EXC_BAD_ACCESS crash
Date: Fri, 30 Oct 2020 20:47:31 +0200

> From: Aaron Jensen <aaronjensen <at> gmail.com>
> Date: Fri, 30 Oct 2020 10:54:56 -0500
> Cc: 44313 <at> debbugs.gnu.org
> 
> On Fri, Oct 30, 2020 at 6:29 AM Eli Zaretskii <eliz <at> 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?

Message #23 received at 44313 <at> debbugs.gnu.org (full text, mbox):

From: Aaron Jensen <aaronjensen <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 44313 <at> debbugs.gnu.org
Subject: Re: bug#44313: 27.1.50; ns_mouse_position EXC_BAD_ACCESS crash
Date: Fri, 30 Oct 2020 13:55:10 -0500

On Fri, Oct 30, 2020 at 1:47 PM Eli Zaretskii <eliz <at> 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?

Message #26 received at 44313 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Aaron Jensen <aaronjensen <at> gmail.com>
Cc: 44313 <at> debbugs.gnu.org
Subject: Re: bug#44313: 27.1.50; ns_mouse_position EXC_BAD_ACCESS crash
Date: Fri, 30 Oct 2020 21:07:46 +0200

> From: Aaron Jensen <aaronjensen <at> gmail.com>
> Date: Fri, 30 Oct 2020 13:55:10 -0500
> Cc: 44313 <at> debbugs.gnu.org
> 
> On Fri, Oct 30, 2020 at 1:47 PM Eli Zaretskii <eliz <at> 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.

Message #29 received at 44313 <at> debbugs.gnu.org (full text, mbox):

From: Aaron Jensen <aaronjensen <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 44313 <at> debbugs.gnu.org
Subject: Re: bug#44313: 27.1.50; ns_mouse_position EXC_BAD_ACCESS crash
Date: Fri, 30 Oct 2020 14:37:04 -0500

On Fri, Oct 30, 2020 at 2:08 PM Eli Zaretskii <eliz <at> 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?

Message #32 received at 44313 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Aaron Jensen <aaronjensen <at> gmail.com>
Cc: 44313 <at> debbugs.gnu.org
Subject: Re: bug#44313: 27.1.50; ns_mouse_position EXC_BAD_ACCESS crash
Date: Fri, 30 Oct 2020 22:12:31 +0200

> From: Aaron Jensen <aaronjensen <at> gmail.com>
> Date: Fri, 30 Oct 2020 14:37:04 -0500
> Cc: 44313 <at> debbugs.gnu.org
> 
> On Fri, Oct 30, 2020 at 2:08 PM Eli Zaretskii <eliz <at> 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.

Message #35 received at 44313 <at> debbugs.gnu.org (full text, mbox):

From: Aaron Jensen <aaronjensen <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 44313 <at> debbugs.gnu.org
Subject: Re: bug#44313: 27.1.50; ns_mouse_position EXC_BAD_ACCESS crash
Date: Fri, 30 Oct 2020 15:18:54 -0500

On Fri, Oct 30, 2020 at 3:12 PM Eli Zaretskii <eliz <at> 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.

Message #38 received at 44313 <at> debbugs.gnu.org (full text, mbox):

From: Alan Third <alan <at> idiocy.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 44313 <at> debbugs.gnu.org, Aaron Jensen <aaronjensen <at> gmail.com>
Subject: Re: 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 <at> gmail.com>
> > Date: Fri, 30 Oct 2020 14:37:04 -0500
> > Cc: 44313 <at> debbugs.gnu.org
> > 
> > On Fri, Oct 30, 2020 at 2:08 PM Eli Zaretskii <eliz <at> 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

Message #41 received at 44313 <at> debbugs.gnu.org (full text, mbox):

From: Aaron Jensen <aaronjensen <at> gmail.com>
To: Alan Third <alan <at> idiocy.org>, Eli Zaretskii <eliz <at> gnu.org>,
 Aaron Jensen <aaronjensen <at> gmail.com>, 44313 <at> debbugs.gnu.org
Subject: Re: bug#44313: 27.1.50; ns_mouse_position EXC_BAD_ACCESS crash
Date: Mon, 2 Nov 2020 12:11:52 -0600

On Fri, Oct 30, 2020 at 5:35 PM Alan Third <alan <at> 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)

Message #44 received at 44313 <at> debbugs.gnu.org (full text, mbox):

From: Aaron Jensen <aaronjensen <at> gmail.com>
To: Alan Third <alan <at> idiocy.org>, Eli Zaretskii <eliz <at> gnu.org>,
 Aaron Jensen <aaronjensen <at> gmail.com>, 44313 <at> debbugs.gnu.org
Subject: Re: bug#44313: 27.1.50; ns_mouse_position EXC_BAD_ACCESS crash
Date: Fri, 6 Nov 2020 08:29:34 -0600

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 <at> gmail.com> wrote:
>
> On Fri, Oct 30, 2020 at 5:35 PM Alan Third <alan <at> 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)

Message #47 received at 44313 <at> debbugs.gnu.org (full text, mbox):

From: Alan Third <alan <at> idiocy.org>
To: Aaron Jensen <aaronjensen <at> gmail.com>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 44313 <at> debbugs.gnu.org
Subject: Re: bug#44313: 27.1.50; ns_mouse_position EXC_BAD_ACCESS crash
Date: Sat, 7 Nov 2020 16:29:22 +0000

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

Message #50 received at 44313 <at> debbugs.gnu.org (full text, mbox):

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Alan Third <alan <at> idiocy.org>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 44313 <at> debbugs.gnu.org,
 Aaron Jensen <aaronjensen <at> gmail.com>
Subject: Re: bug#44313: 27.1.50; ns_mouse_position EXC_BAD_ACCESS crash
Date: Mon, 09 Nov 2020 15:43:01 +0100

Alan Third <alan <at> 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

Message #53 received at 44313 <at> debbugs.gnu.org (full text, mbox):

From: Alan Third <alan <at> idiocy.org>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: 44313 <at> debbugs.gnu.org, Aaron Jensen <aaronjensen <at> gmail.com>
Subject: Re: bug#44313: 27.1.50; ns_mouse_position EXC_BAD_ACCESS crash
Date: Mon, 9 Nov 2020 14:54:50 +0000

On Mon, Nov 09, 2020 at 03:43:01PM +0100, Lars Ingebrigtsen wrote:
> Alan Third <alan <at> 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

Message #58 received at 44313-done <at> debbugs.gnu.org (full text, mbox):

From: Alan Third <alan <at> idiocy.org>
To: Lars Ingebrigtsen <larsi <at> gnus.org>, 44313-done <at> debbugs.gnu.org,
 Aaron Jensen <aaronjensen <at> gmail.com>
Subject: Re: bug#44313: 27.1.50; ns_mouse_position EXC_BAD_ACCESS crash
Date: Sat, 12 Dec 2020 10:43:01 +0000

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

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.