GNU bug report logs - #45541
28.0.50; Frequent crashes on ARM macOS

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 45541 in the body.
You can then email your comments to 45541 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: Philipp <p.stephani2 <at> gmail.com>
To: bug-gnu-emacs <at> gnu.org
Subject: 28.0.50; Frequent crashes on ARM macOS
Date: Tue, 29 Dec 2020 23:32:43 +0100

With an Emacs built from the emacs-27 branch I get frequent crashes on
ARM64 macOS (Big Sur).  I haven't managed to produce an Elisp stacktrace
yet, but here's the crash report:

Crashed Thread:        0  Dispatch queue: com.apple.main-thread

Exception Type:        EXC_BAD_ACCESS (SIGABRT)
Exception Codes:       KERN_INVALID_ADDRESS at 0x00000000000038d0
Exception Note:        EXC_CORPSE_NOTIFY

VM Regions Near 0x38d0:
--> 
    __TEXT                      1042fc000-10453c000    [ 2304K] r-x/r-x SM=COW  /Applications/Emacs.app/Contents/MacOS/Emacs

Thread 0 Crashed:: Dispatch queue: com.apple.main-thread
0   libsystem_kernel.dylib        	0x000000018d20fcec __pthread_kill + 8
1   libsystem_pthread.dylib       	0x000000018d240c24 pthread_kill + 292
2   libsystem_c.dylib             	0x000000018d1204d0 raise + 32
3   org.gnu.Emacs                 	0x00000001044fa394 terminate_due_to_signal + 188 (emacs.c:409)
4   org.gnu.Emacs                 	0x00000001044fab4c emacs_abort + 20 (sysdep.c:2455)
5   org.gnu.Emacs                 	0x00000001044c949c ns_term_shutdown + 144 (nsterm.m:5560)
6   org.gnu.Emacs                 	0x00000001043b60d8 shut_down_emacs + 328 (emacs.c:2491)
7   org.gnu.Emacs                 	0x00000001044fa35c terminate_due_to_signal + 132 (emacs.c:392)
8   org.gnu.Emacs                 	0x00000001043d4fb4 handle_fatal_signal + 16 (sysdep.c:1795)
9   org.gnu.Emacs                 	0x00000001043d502c deliver_thread_signal + 120 (sysdep.c:1769)
10  org.gnu.Emacs                 	0x00000001043d3a68 deliver_fatal_thread_signal + 12 (sysdep.c:1807)
11  libsystem_platform.dylib      	0x000000018d288c44 _sigtramp + 56
12  org.gnu.Emacs                 	0x00000001044d475c ns_mouse_position + 248 (nsterm.m:2519)
13  org.gnu.Emacs                 	0x000000010430d2c8 Fmouse_pixel_position + 136 (frame.c:2498)
14  org.gnu.Emacs                 	0x000000010443be48 funcall_subr + 188 (eval.c:2866)
15  org.gnu.Emacs                 	0x000000010443b420 Ffuncall + 948 (eval.c:2795)
16  org.gnu.Emacs                 	0x000000010447c208 exec_byte_code + 1560 (bytecode.c:633)
17  org.gnu.Emacs                 	0x000000010443b3a8 Ffuncall + 828
18  org.gnu.Emacs                 	0x000000010443bb0c call1 + 44 (eval.c:2655)
19  org.gnu.Emacs                 	0x00000001043bcc1c show_help_echo + 308 (keyboard.c:2093)
20  org.gnu.Emacs                 	0x00000001043bd30c read_char + 1648 (keyboard.c:3117)
21  org.gnu.Emacs                 	0x00000001043bb220 read_key_sequence + 1880 (keyboard.c:9554)
22  org.gnu.Emacs                 	0x00000001043b9cd0 command_loop_1 + 1128 (keyboard.c:1350)
23  org.gnu.Emacs                 	0x0000000104439a6c internal_condition_case + 248 (eval.c:1356)
24  org.gnu.Emacs                 	0x00000001043c86ac command_loop_2 + 44 (keyboard.c:1091)
25  org.gnu.Emacs                 	0x0000000104439354 internal_catch + 248 (eval.c:1117)
26  org.gnu.Emacs                 	0x00000001044fa690 recursive_edit_1.cold.1 + 80 (keyboard.c:1070)
27  org.gnu.Emacs                 	0x00000001043b8dc0 command_loop + 4 (keyboard.c:1067) [inlined]
28  org.gnu.Emacs                 	0x00000001043b8dc0 recursive_edit_1 + 248 (keyboard.c:714)
29  org.gnu.Emacs                 	0x00000001043b8f68 Frecursive_edit + 388 (keyboard.c:786)
30  org.gnu.Emacs                 	0x00000001043b83b0 main + 8836 (emacs.c:2066)
31  libdyld.dylib                 	0x000000018d25cf34 start + 4

Looks like a crash in ns_mouse_position.


In GNU Emacs 28.0.50 (build 28, aarch64-apple-darwin20.2.0, NS appkit-2022.20 Version 11.1 (Build 20C69))
 of 2020-12-29
Repository revision: 90bd3b3d69d40339127b4744c459cedb7eb962b0
Repository branch: master
Windowing system distributor 'Apple', version 10.3.2022
System Description:  macOS 11.1

Configured using:
 'configure --with-modules --without-xml2 --without-pop --with-mailutils
 --enable-gcc-warnings=warn-only --enable-checking=all
 --enable-check-lisp-object-type 'CFLAGS=-ggdb3 -O0''

Configured features:
PNG NOTIFY KQUEUE ACL GNUTLS ZLIB TOOLKIT_SCROLL_BARS XIM NS MODULES
THREADS JSON PDUMPER LCMS2

Important settings:
  value of $LANG: de_DE.UTF-8
  locale-coding-system: utf-8-unix

Major mode: Lisp Interaction

Minor modes in effect:
  tooltip-mode: t
  global-eldoc-mode: t
  eldoc-mode: t
  electric-indent-mode: t
  mouse-wheel-mode: t
  tool-bar-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  blink-cursor-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  line-number-mode: t
  transient-mark-mode: t

Load-path shadows:
None found.

Features:
(shadow sort mail-extr emacsbug message rmc dired dired-loaddefs rfc822
mml easymenu mml-sec epa epg epg-config gnus-util rmail rmail-loaddefs
time-date mm-decode mm-bodies mm-encode mail-parse rfc2231 mailabbrev
gmm-utils mailheader sendmail rfc2047 rfc2045 ietf-drums mm-util
mail-prsvr mail-utils phst skeleton derived edmacro kmacro pcase ffap
thingatpt url url-proxy url-privacy url-expand url-methods url-history
url-cookie url-domsuf url-util url-parse auth-source cl-seq eieio
eieio-core cl-macs eieio-loaddefs password-cache json map url-vars
mailcap rx gnutls puny dbus xml subr-x seq byte-opt gv bytecomp
byte-compile cconv compile text-property-search comint ansi-color ring
cl-loaddefs cl-lib iso-transl tooltip eldoc electric uniquify ediff-hook
vc-hooks lisp-float-type mwheel term/ns-win ns-win ucs-normalize
mule-util term/common-win tool-bar dnd fontset image regexp-opt fringe
tabulated-list replace newcomment text-mode elisp-mode lisp-mode
prog-mode register page tab-bar menu-bar rfn-eshadow isearch timer
select scroll-bar mouse jit-lock font-lock syntax facemenu font-core
term/tty-colors frame minibuffer cl-generic cham georgian utf-8-lang
misc-lang vietnamese tibetan thai tai-viet lao korean japanese eucjp-ms
cp51932 hebrew greek romanian slovak czech european ethiopic indian
cyrillic chinese composite charscript charprop case-table epa-hook
jka-cmpr-hook help simple abbrev obarray cl-preloaded nadvice button
loaddefs faces cus-face macroexp files window text-properties overlay
sha1 md5 base64 format env code-pages mule custom widget
hashtable-print-readable backquote threads kqueue cocoa ns lcms2
multi-tty make-network-process emacs)

Memory information:
((conses 16 70926 5579)
 (symbols 48 8581 1)
 (strings 32 23907 1885)
 (string-bytes 1 779937)
 (vectors 16 14984)
 (vector-slots 8 198319 4285)
 (floats 8 26 28)
 (intervals 56 209 0)
 (buffers 984 10))

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

From: Alan Third <alan <at> idiocy.org>
To: Philipp <p.stephani2 <at> gmail.com>
Cc: 45541 <at> debbugs.gnu.org
Subject: Re: bug#45541: 28.0.50; Frequent crashes on ARM macOS
Date: Wed, 30 Dec 2020 00:10:30 +0000

On Tue, Dec 29, 2020 at 11:32:43PM +0100, Philipp wrote:
> 
> With an Emacs built from the emacs-27 branch I get frequent crashes on
> ARM64 macOS (Big Sur).  I haven't managed to produce an Elisp stacktrace
> yet, but here's the crash report:
<snip> 
> Looks like a crash in ns_mouse_position.

Can you check that the build includes this?

6aa9fe3e1b4052b2acde86404a90e35893ebfa00?
Fix crash in ns_mouse_position (bug#44313)

-- 
Alan Third

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

From: Philipp Stephani <p.stephani2 <at> gmail.com>
To: Alan Third <alan <at> idiocy.org>, Philipp <p.stephani2 <at> gmail.com>,
 45541 <at> debbugs.gnu.org
Subject: Re: bug#45541: 28.0.50; Frequent crashes on ARM macOS
Date: Wed, 30 Dec 2020 14:01:18 +0100

Am Mi., 30. Dez. 2020 um 01:10 Uhr schrieb Alan Third <alan <at> idiocy.org>:
>
> On Tue, Dec 29, 2020 at 11:32:43PM +0100, Philipp wrote:
> >
> > With an Emacs built from the emacs-27 branch I get frequent crashes on
> > ARM64 macOS (Big Sur).  I haven't managed to produce an Elisp stacktrace
> > yet, but here's the crash report:
> <snip>
> > Looks like a crash in ns_mouse_position.
>
> Can you check that the build includes this?
>
> 6aa9fe3e1b4052b2acde86404a90e35893ebfa00?
> Fix crash in ns_mouse_position (bug#44313)

Yes, according to "git branch --contains" the commit is present.  The
exception report makes me think that NSApp is null or invalid, but how
should that be possible?

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

From: Alan Third <alan <at> idiocy.org>
To: Philipp Stephani <p.stephani2 <at> gmail.com>
Cc: 45541 <at> debbugs.gnu.org
Subject: Re: bug#45541: 28.0.50; Frequent crashes on ARM macOS
Date: Wed, 30 Dec 2020 14:05:44 +0000

On Wed, Dec 30, 2020 at 02:01:18PM +0100, Philipp Stephani wrote:
> Am Mi., 30. Dez. 2020 um 01:10 Uhr schrieb Alan Third <alan <at> idiocy.org>:
> >
> > On Tue, Dec 29, 2020 at 11:32:43PM +0100, Philipp wrote:
> > >
> > > With an Emacs built from the emacs-27 branch I get frequent crashes on
> > > ARM64 macOS (Big Sur).  I haven't managed to produce an Elisp stacktrace
> > > yet, but here's the crash report:
> > <snip>
> > > Looks like a crash in ns_mouse_position.
> >
> > Can you check that the build includes this?
> >
> > 6aa9fe3e1b4052b2acde86404a90e35893ebfa00?
> > Fix crash in ns_mouse_position (bug#44313)
> 
> Yes, according to "git branch --contains" the commit is present.  The
> exception report makes me think that NSApp is null or invalid, but how
> should that be possible?

I have no idea... What's happening when the crash occurs? I take it
the mouse is being moved, but are frames opening and closing or
anything?
-- 
Alan Third

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

From: Philipp Stephani <p.stephani2 <at> gmail.com>
To: Alan Third <alan <at> idiocy.org>, Philipp Stephani <p.stephani2 <at> gmail.com>,
 45541 <at> debbugs.gnu.org
Subject: Re: bug#45541: 28.0.50; Frequent crashes on ARM macOS
Date: Wed, 30 Dec 2020 15:42:24 +0100

Am Mi., 30. Dez. 2020 um 15:05 Uhr schrieb Alan Third <alan <at> idiocy.org>:
>
> On Wed, Dec 30, 2020 at 02:01:18PM +0100, Philipp Stephani wrote:
> > Am Mi., 30. Dez. 2020 um 01:10 Uhr schrieb Alan Third <alan <at> idiocy.org>:
> > >
> > > On Tue, Dec 29, 2020 at 11:32:43PM +0100, Philipp wrote:
> > > >
> > > > With an Emacs built from the emacs-27 branch I get frequent crashes on
> > > > ARM64 macOS (Big Sur).  I haven't managed to produce an Elisp stacktrace
> > > > yet, but here's the crash report:
> > > <snip>
> > > > Looks like a crash in ns_mouse_position.
> > >
> > > Can you check that the build includes this?
> > >
> > > 6aa9fe3e1b4052b2acde86404a90e35893ebfa00?
> > > Fix crash in ns_mouse_position (bug#44313)
> >
> > Yes, according to "git branch --contains" the commit is present.  The
> > exception report makes me think that NSApp is null or invalid, but how
> > should that be possible?
>
> I have no idea... What's happening when the crash occurs? I take it
> the mouse is being moved, but are frames opening and closing or
> anything?

I'm now able to reproduce this consistently. It happens when a tooltip
appears and you hover over that tooltip (try M-x locate and move the
mouse around).
The crash is in the line
  if (f && FRAME_NS_P (f))
in nsterm.m in ns_mouse_position, so apparently "f" is not NULL, but
also not valid.
Interestingly I can only reproduce the issue in optimized builds.
The LLDB backtrace is:
* thread #1, queue = 'com.apple.main-thread', stop reason =
EXC_BAD_ACCESS (code=1, address=0x38d0)
    frame #0: 0x00000001001d87fc
emacs`ns_mouse_position(fp=<unavailable>, insist=<unavailable>,
bar_window=<unavailable>, part=<unavailable>, x=<unavailable>,
y=<unavailable>, time=<unavailable>) at nsterm.m:2538:12 [opt]
   2535       && FRAME_LIVE_P (dpyinfo->last_mouse_frame))
   2536     f = dpyinfo->last_mouse_frame;
   2537
-> 2538   if (f && FRAME_NS_P (f))
   2539     {
   2540       view = FRAME_NS_VIEW (f);
   2541
Target 0: (emacs) stopped.
(lldb) bt
* thread #1, queue = 'com.apple.main-thread', stop reason =
EXC_BAD_ACCESS (code=1, address=0x38d0)
  * frame #0: 0x00000001001d87fc
emacs`ns_mouse_position(fp=<unavailable>, insist=<unavailable>,
bar_window=<unavailable>, part=<unavailable>, x=<unavailable>,
y=<unavailable>, time=<unavailable>) at nsterm.m:2538:12 [opt]
    frame #1: 0x00000001000112c8 emacs`Fmouse_pixel_position at
frame.c:2498:7 [opt]
    frame #2: 0x000000010013fe48
emacs`funcall_subr(subr=0x0000000100251778, numargs=<unavailable>,
args=<unavailable>) at eval.c:2866:19 [opt]
    frame #3: 0x000000010013f420 emacs`Ffuncall(nargs=<unavailable>,
args=<unavailable>) at eval.c:2795:11 [opt]
    frame #4: 0x0000000100180208
emacs`exec_byte_code(bytestr=<unavailable>, vector=<unavailable>,
maxdepth=<unavailable>, args_template=<unavailable>,
nargs=4611686018813263872, args=<unavailable>) at bytecode.c:633:12
[opt]
    frame #5: 0x00000001001403c0
emacs`funcall_lambda(fun=<unavailable>, nargs=<unavailable>,
arg_vector=<unavailable>) at eval.c:2990:11 [opt] [artificial]
    frame #6: 0x000000010013f3a8 emacs`Ffuncall(nargs=<unavailable>,
args=<unavailable>) at eval.c:0 [opt]
    frame #7: 0x000000010013fb0c emacs`call1(fn=0x00000000000094b0,
arg1=0x00000001160244d4) at eval.c:2655:10 [opt]
    frame #8: 0x00000001000c0c1c
emacs`show_help_echo(help=0x00000001160244d4, window=<unavailable>,
object=<unavailable>, pos=<unavailable>) at keyboard.c:2093:14 [opt]
    frame #9: 0x00000001000c130c
emacs`read_char(commandflag=<unavailable>, map=<unavailable>,
prev_event=0x0000000000000000, used_mouse_menu=<unavailable>,
end_time=<unavailable>) at keyboard.c:3117:7 [opt]
    frame #10: 0x00000001000bf220
emacs`read_key_sequence(keybuf=0x000000016fdff1e0,
prompt=0x0000000000000000, dont_downcase_last=false,
can_return_switch_frame=true, fix_current_buffer=true,
prevent_redisplay=<unavailable>) at keyboard.c:9554:12 [opt]
    frame #11: 0x00000001000bdcd0 emacs`command_loop_1 at
keyboard.c:1350:15 [opt]
    frame #12: 0x000000010013da6c
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 [opt]
    frame #13: 0x00000001000cc6ac
emacs`command_loop_2(ignore=0x0000000000000000) at keyboard.c:1091:11
[opt]
    frame #14: 0x000000010013d354
emacs`internal_catch(tag=<unavailable>, func=(emacs`command_loop_2 at
keyboard.c:1087), arg=0x0000000000000000) at eval.c:1117:25 [opt]
    frame #15: 0x00000001001fe690 emacs`recursive_edit_1.cold.1 at
keyboard.c:1070:2 [opt]
    frame #16: 0x00000001000bcdc0 emacs`recursive_edit_1 [inlined]
command_loop at keyboard.c:1067:5 [opt]
    frame #17: 0x00000001000bcdbc emacs`recursive_edit_1 at keyboard.c:714 [opt]
    frame #18: 0x00000001000bcf68 emacs`Frecursive_edit at
keyboard.c:786:3 [opt]
    frame #19: 0x00000001000bc3b0 emacs`main(argc=<unavailable>,
argv=<unavailable>) at emacs.c:2066:3 [opt]
    frame #20: 0x000000018d25cf34 libdyld.dylib`start + 4

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

From: Philipp Stephani <p.stephani2 <at> gmail.com>
To: Alan Third <alan <at> idiocy.org>, Philipp Stephani <p.stephani2 <at> gmail.com>,
 45541 <at> debbugs.gnu.org
Subject: Re: bug#45541: 28.0.50; Frequent crashes on ARM macOS
Date: Wed, 30 Dec 2020 15:49:11 +0100

Am Mi., 30. Dez. 2020 um 15:42 Uhr schrieb Philipp Stephani
<p.stephani2 <at> gmail.com>:
>
> Am Mi., 30. Dez. 2020 um 15:05 Uhr schrieb Alan Third <alan <at> idiocy.org>:
> >
> > On Wed, Dec 30, 2020 at 02:01:18PM +0100, Philipp Stephani wrote:
> > > Am Mi., 30. Dez. 2020 um 01:10 Uhr schrieb Alan Third <alan <at> idiocy.org>:
> > > >
> > > > On Tue, Dec 29, 2020 at 11:32:43PM +0100, Philipp wrote:
> > > > >
> > > > > With an Emacs built from the emacs-27 branch I get frequent crashes on
> > > > > ARM64 macOS (Big Sur).  I haven't managed to produce an Elisp stacktrace
> > > > > yet, but here's the crash report:
> > > > <snip>
> > > > > Looks like a crash in ns_mouse_position.
> > > >
> > > > Can you check that the build includes this?
> > > >
> > > > 6aa9fe3e1b4052b2acde86404a90e35893ebfa00?
> > > > Fix crash in ns_mouse_position (bug#44313)
> > >
> > > Yes, according to "git branch --contains" the commit is present.  The
> > > exception report makes me think that NSApp is null or invalid, but how
> > > should that be possible?
> >
> > I have no idea... What's happening when the crash occurs? I take it
> > the mouse is being moved, but are frames opening and closing or
> > anything?
>
> I'm now able to reproduce this consistently. It happens when a tooltip
> appears and you hover over that tooltip (try M-x locate and move the
> mouse around).
> The crash is in the line
>   if (f && FRAME_NS_P (f))
> in nsterm.m in ns_mouse_position, so apparently "f" is not NULL, but
> also not valid.

Looks like "f" isn't initialized to NULL in that function?

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

From: Philipp Stephani <p.stephani2 <at> gmail.com>
To: Alan Third <alan <at> idiocy.org>, Philipp Stephani <p.stephani2 <at> gmail.com>,
 45541 <at> debbugs.gnu.org
Subject: Re: bug#45541: 28.0.50; Frequent crashes on ARM macOS
Date: Wed, 30 Dec 2020 15:53:01 +0100

Am Mi., 30. Dez. 2020 um 15:49 Uhr schrieb Philipp Stephani
<p.stephani2 <at> gmail.com>:
>
> Am Mi., 30. Dez. 2020 um 15:42 Uhr schrieb Philipp Stephani
> <p.stephani2 <at> gmail.com>:
> >
> > Am Mi., 30. Dez. 2020 um 15:05 Uhr schrieb Alan Third <alan <at> idiocy.org>:
> > >
> > > On Wed, Dec 30, 2020 at 02:01:18PM +0100, Philipp Stephani wrote:
> > > > Am Mi., 30. Dez. 2020 um 01:10 Uhr schrieb Alan Third <alan <at> idiocy.org>:
> > > > >
> > > > > On Tue, Dec 29, 2020 at 11:32:43PM +0100, Philipp wrote:
> > > > > >
> > > > > > With an Emacs built from the emacs-27 branch I get frequent crashes on
> > > > > > ARM64 macOS (Big Sur).  I haven't managed to produce an Elisp stacktrace
> > > > > > yet, but here's the crash report:
> > > > > <snip>
> > > > > > Looks like a crash in ns_mouse_position.
> > > > >
> > > > > Can you check that the build includes this?
> > > > >
> > > > > 6aa9fe3e1b4052b2acde86404a90e35893ebfa00?
> > > > > Fix crash in ns_mouse_position (bug#44313)
> > > >
> > > > Yes, according to "git branch --contains" the commit is present.  The
> > > > exception report makes me think that NSApp is null or invalid, but how
> > > > should that be possible?
> > >
> > > I have no idea... What's happening when the crash occurs? I take it
> > > the mouse is being moved, but are frames opening and closing or
> > > anything?
> >
> > I'm now able to reproduce this consistently. It happens when a tooltip
> > appears and you hover over that tooltip (try M-x locate and move the
> > mouse around).
> > The crash is in the line
> >   if (f && FRAME_NS_P (f))
> > in nsterm.m in ns_mouse_position, so apparently "f" is not NULL, but
> > also not valid.
>
> Looks like "f" isn't initialized to NULL in that function?

This was probably fixed with commit
b4911a6f0da0bfae3832b3aa0c111db4bb2f49d5 on master. I guess we should
backport the one-line initialization change onto the release branch,
since the crash is nasty and the fix is trivial.

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

From: Alan Third <alan <at> idiocy.org>
To: Philipp Stephani <p.stephani2 <at> gmail.com>
Cc: 45541 <at> debbugs.gnu.org
Subject: Re: bug#45541: 28.0.50; Frequent crashes on ARM macOS
Date: Wed, 30 Dec 2020 15:22:32 +0000

On Wed, Dec 30, 2020 at 03:53:01PM +0100, Philipp Stephani wrote:
> Am Mi., 30. Dez. 2020 um 15:49 Uhr schrieb Philipp Stephani
> <p.stephani2 <at> gmail.com>:
> >
> > Am Mi., 30. Dez. 2020 um 15:42 Uhr schrieb Philipp Stephani
> > <p.stephani2 <at> gmail.com>:
> > >
> > > Am Mi., 30. Dez. 2020 um 15:05 Uhr schrieb Alan Third <alan <at> idiocy.org>:
> > > >
> > > > On Wed, Dec 30, 2020 at 02:01:18PM +0100, Philipp Stephani wrote:
> > > > > Am Mi., 30. Dez. 2020 um 01:10 Uhr schrieb Alan Third <alan <at> idiocy.org>:
> > > > > >
> > > > > > On Tue, Dec 29, 2020 at 11:32:43PM +0100, Philipp wrote:
> > > > > > >
> > > > > > > With an Emacs built from the emacs-27 branch I get frequent crashes on
> > > > > > > ARM64 macOS (Big Sur).  I haven't managed to produce an Elisp stacktrace
> > > > > > > yet, but here's the crash report:
> > > > > > <snip>
> > > > > > > Looks like a crash in ns_mouse_position.
> > > > > >
> > > > > > Can you check that the build includes this?
> > > > > >
> > > > > > 6aa9fe3e1b4052b2acde86404a90e35893ebfa00?
> > > > > > Fix crash in ns_mouse_position (bug#44313)
> > > > >
> > > > > Yes, according to "git branch --contains" the commit is present.  The
> > > > > exception report makes me think that NSApp is null or invalid, but how
> > > > > should that be possible?
> > > >
> > > > I have no idea... What's happening when the crash occurs? I take it
> > > > the mouse is being moved, but are frames opening and closing or
> > > > anything?
> > >
> > > I'm now able to reproduce this consistently. It happens when a tooltip
> > > appears and you hover over that tooltip (try M-x locate and move the
> > > mouse around).
> > > The crash is in the line
> > >   if (f && FRAME_NS_P (f))
> > > in nsterm.m in ns_mouse_position, so apparently "f" is not NULL, but
> > > also not valid.
> >
> > Looks like "f" isn't initialized to NULL in that function?
> 
> This was probably fixed with commit
> b4911a6f0da0bfae3832b3aa0c111db4bb2f49d5 on master. I guess we should
> backport the one-line initialization change onto the release branch,
> since the crash is nasty and the fix is trivial.

Yes, I agree.
-- 
Alan Third

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Philipp Stephani <p.stephani2 <at> gmail.com>
Cc: alan <at> idiocy.org, 45541 <at> debbugs.gnu.org, p.stephani2 <at> gmail.com
Subject: Re: bug#45541: 28.0.50; Frequent crashes on ARM macOS
Date: Wed, 30 Dec 2020 22:35:23 +0200

> From: Philipp Stephani <p.stephani2 <at> gmail.com>
> Date: Wed, 30 Dec 2020 15:42:24 +0100
> 
> I'm now able to reproduce this consistently. It happens when a tooltip
> appears and you hover over that tooltip

How is that possible?  Tooltips are supposed to pop down as soon as
you move the mouse.  Are those native NS tooltips, and if so, do they
behave differently in this regard?

> The crash is in the line
>   if (f && FRAME_NS_P (f))
> in nsterm.m in ns_mouse_position, so apparently "f" is not NULL, but
> also not valid.

Maybe, if the tooltip popped down, we need to test whether f is a live
frame?

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

From: Philipp Stephani <p.stephani2 <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: Alan Third <alan <at> idiocy.org>, 45541 <at> debbugs.gnu.org
Subject: Re: bug#45541: 28.0.50; Frequent crashes on ARM macOS
Date: Wed, 30 Dec 2020 22:10:16 +0100

Am Mi., 30. Dez. 2020 um 21:35 Uhr schrieb Eli Zaretskii <eliz <at> gnu.org>:
>
> > From: Philipp Stephani <p.stephani2 <at> gmail.com>
> > Date: Wed, 30 Dec 2020 15:42:24 +0100
> >
> > I'm now able to reproduce this consistently. It happens when a tooltip
> > appears and you hover over that tooltip
>
> How is that possible?  Tooltips are supposed to pop down as soon as
> you move the mouse.  Are those native NS tooltips, and if so, do they
> behave differently in this regard?

Yes, they don't vanish immediately when hovering over them.

>
> > The crash is in the line
> >   if (f && FRAME_NS_P (f))
> > in nsterm.m in ns_mouse_position, so apparently "f" is not NULL, but
> > also not valid.
>
> Maybe, if the tooltip popped down, we need to test whether f is a live
> frame?

We need to initialize "f" to NULL, because the loop that sets it
doesn't necessarily find a frame.

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

From: Alan Third <alan <at> idiocy.org>
To: Philipp Stephani <p.stephani2 <at> gmail.com>, 45541-done <at> debbugs.gnu.org
Subject: Re: bug#45541: 28.0.50; Frequent crashes on ARM macOS
Date: Fri, 1 Jan 2021 10:40:27 +0000

On Wed, Dec 30, 2020 at 03:22:32PM +0000, Alan Third wrote:
> On Wed, Dec 30, 2020 at 03:53:01PM +0100, Philipp Stephani wrote:
> > Am Mi., 30. Dez. 2020 um 15:49 Uhr schrieb Philipp Stephani
> > <p.stephani2 <at> gmail.com>:
> > > Looks like "f" isn't initialized to NULL in that function?
> > 
> > This was probably fixed with commit
> > b4911a6f0da0bfae3832b3aa0c111db4bb2f49d5 on master. I guess we should
> > backport the one-line initialization change onto the release branch,
> > since the crash is nasty and the fix is trivial.
> 
> Yes, I agree.

I've pushed a change to the emacs-27 branch to initialise f to NULL.
-- 
Alan Third

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

From: Philipp Stephani <p.stephani2 <at> gmail.com>
To: Alan Third <alan <at> idiocy.org>, Philipp Stephani <p.stephani2 <at> gmail.com>,
 45541-done <at> debbugs.gnu.org
Subject: Re: bug#45541: 28.0.50; Frequent crashes on ARM macOS
Date: Fri, 1 Jan 2021 12:21:19 +0100

Am Fr., 1. Jan. 2021 um 11:40 Uhr schrieb Alan Third <alan <at> idiocy.org>:
>
> On Wed, Dec 30, 2020 at 03:22:32PM +0000, Alan Third wrote:
> > On Wed, Dec 30, 2020 at 03:53:01PM +0100, Philipp Stephani wrote:
> > > Am Mi., 30. Dez. 2020 um 15:49 Uhr schrieb Philipp Stephani
> > > <p.stephani2 <at> gmail.com>:
> > > > Looks like "f" isn't initialized to NULL in that function?
> > >
> > > This was probably fixed with commit
> > > b4911a6f0da0bfae3832b3aa0c111db4bb2f49d5 on master. I guess we should
> > > backport the one-line initialization change onto the release branch,
> > > since the crash is nasty and the fix is trivial.
> >
> > Yes, I agree.
>
> I've pushed a change to the emacs-27 branch to initialise f to NULL.

Confirmed that it doesn't crash any more. Thanks!

Previous Next

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