* bug#45541: 28.0.50; Frequent crashes on ARM macOS
@ 2020-12-29 22:32 Philipp
2020-12-30 0:10 ` Alan Third
0 siblings, 1 reply; 12+ messages in thread
From: Philipp @ 2020-12-29 22:32 UTC (permalink / raw)
To: 45541
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))
^ permalink raw reply [flat|nested] 12+ messages in thread
* bug#45541: 28.0.50; Frequent crashes on ARM macOS
2020-12-29 22:32 bug#45541: 28.0.50; Frequent crashes on ARM macOS Philipp
@ 2020-12-30 0:10 ` Alan Third
2020-12-30 13:01 ` Philipp Stephani
0 siblings, 1 reply; 12+ messages in thread
From: Alan Third @ 2020-12-30 0:10 UTC (permalink / raw)
To: Philipp; +Cc: 45541
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
^ permalink raw reply [flat|nested] 12+ messages in thread
* bug#45541: 28.0.50; Frequent crashes on ARM macOS
2020-12-30 0:10 ` Alan Third
@ 2020-12-30 13:01 ` Philipp Stephani
2020-12-30 14:05 ` Alan Third
0 siblings, 1 reply; 12+ messages in thread
From: Philipp Stephani @ 2020-12-30 13:01 UTC (permalink / raw)
To: Alan Third, Philipp, 45541
Am Mi., 30. Dez. 2020 um 01:10 Uhr schrieb Alan Third <alan@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?
^ permalink raw reply [flat|nested] 12+ messages in thread
* bug#45541: 28.0.50; Frequent crashes on ARM macOS
2020-12-30 13:01 ` Philipp Stephani
@ 2020-12-30 14:05 ` Alan Third
2020-12-30 14:42 ` Philipp Stephani
0 siblings, 1 reply; 12+ messages in thread
From: Alan Third @ 2020-12-30 14:05 UTC (permalink / raw)
To: Philipp Stephani; +Cc: 45541
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@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
^ permalink raw reply [flat|nested] 12+ messages in thread
* bug#45541: 28.0.50; Frequent crashes on ARM macOS
2020-12-30 14:05 ` Alan Third
@ 2020-12-30 14:42 ` Philipp Stephani
2020-12-30 14:49 ` Philipp Stephani
2020-12-30 20:35 ` Eli Zaretskii
0 siblings, 2 replies; 12+ messages in thread
From: Philipp Stephani @ 2020-12-30 14:42 UTC (permalink / raw)
To: Alan Third, Philipp Stephani, 45541
Am Mi., 30. Dez. 2020 um 15:05 Uhr schrieb Alan Third <alan@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@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
^ permalink raw reply [flat|nested] 12+ messages in thread
* bug#45541: 28.0.50; Frequent crashes on ARM macOS
2020-12-30 14:42 ` Philipp Stephani
@ 2020-12-30 14:49 ` Philipp Stephani
2020-12-30 14:53 ` Philipp Stephani
2020-12-30 20:35 ` Eli Zaretskii
1 sibling, 1 reply; 12+ messages in thread
From: Philipp Stephani @ 2020-12-30 14:49 UTC (permalink / raw)
To: Alan Third, Philipp Stephani, 45541
Am Mi., 30. Dez. 2020 um 15:42 Uhr schrieb Philipp Stephani
<p.stephani2@gmail.com>:
>
> Am Mi., 30. Dez. 2020 um 15:05 Uhr schrieb Alan Third <alan@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@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?
^ permalink raw reply [flat|nested] 12+ messages in thread
* bug#45541: 28.0.50; Frequent crashes on ARM macOS
2020-12-30 14:49 ` Philipp Stephani
@ 2020-12-30 14:53 ` Philipp Stephani
2020-12-30 15:22 ` Alan Third
0 siblings, 1 reply; 12+ messages in thread
From: Philipp Stephani @ 2020-12-30 14:53 UTC (permalink / raw)
To: Alan Third, Philipp Stephani, 45541
Am Mi., 30. Dez. 2020 um 15:49 Uhr schrieb Philipp Stephani
<p.stephani2@gmail.com>:
>
> Am Mi., 30. Dez. 2020 um 15:42 Uhr schrieb Philipp Stephani
> <p.stephani2@gmail.com>:
> >
> > Am Mi., 30. Dez. 2020 um 15:05 Uhr schrieb Alan Third <alan@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@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.
^ permalink raw reply [flat|nested] 12+ messages in thread
* bug#45541: 28.0.50; Frequent crashes on ARM macOS
2020-12-30 14:53 ` Philipp Stephani
@ 2020-12-30 15:22 ` Alan Third
2021-01-01 10:40 ` Alan Third
0 siblings, 1 reply; 12+ messages in thread
From: Alan Third @ 2020-12-30 15:22 UTC (permalink / raw)
To: Philipp Stephani; +Cc: 45541
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@gmail.com>:
> >
> > Am Mi., 30. Dez. 2020 um 15:42 Uhr schrieb Philipp Stephani
> > <p.stephani2@gmail.com>:
> > >
> > > Am Mi., 30. Dez. 2020 um 15:05 Uhr schrieb Alan Third <alan@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@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
^ permalink raw reply [flat|nested] 12+ messages in thread
* bug#45541: 28.0.50; Frequent crashes on ARM macOS
2020-12-30 14:42 ` Philipp Stephani
2020-12-30 14:49 ` Philipp Stephani
@ 2020-12-30 20:35 ` Eli Zaretskii
2020-12-30 21:10 ` Philipp Stephani
1 sibling, 1 reply; 12+ messages in thread
From: Eli Zaretskii @ 2020-12-30 20:35 UTC (permalink / raw)
To: Philipp Stephani; +Cc: alan, 45541, p.stephani2
> From: Philipp Stephani <p.stephani2@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?
^ permalink raw reply [flat|nested] 12+ messages in thread
* bug#45541: 28.0.50; Frequent crashes on ARM macOS
2020-12-30 20:35 ` Eli Zaretskii
@ 2020-12-30 21:10 ` Philipp Stephani
0 siblings, 0 replies; 12+ messages in thread
From: Philipp Stephani @ 2020-12-30 21:10 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: Alan Third, 45541
Am Mi., 30. Dez. 2020 um 21:35 Uhr schrieb Eli Zaretskii <eliz@gnu.org>:
>
> > From: Philipp Stephani <p.stephani2@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.
^ permalink raw reply [flat|nested] 12+ messages in thread
* bug#45541: 28.0.50; Frequent crashes on ARM macOS
2020-12-30 15:22 ` Alan Third
@ 2021-01-01 10:40 ` Alan Third
2021-01-01 11:21 ` Philipp Stephani
0 siblings, 1 reply; 12+ messages in thread
From: Alan Third @ 2021-01-01 10:40 UTC (permalink / raw)
To: Philipp Stephani, 45541-done
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@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
^ permalink raw reply [flat|nested] 12+ messages in thread
* bug#45541: 28.0.50; Frequent crashes on ARM macOS
2021-01-01 10:40 ` Alan Third
@ 2021-01-01 11:21 ` Philipp Stephani
0 siblings, 0 replies; 12+ messages in thread
From: Philipp Stephani @ 2021-01-01 11:21 UTC (permalink / raw)
To: Alan Third, Philipp Stephani, 45541-done
Am Fr., 1. Jan. 2021 um 11:40 Uhr schrieb Alan Third <alan@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@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!
^ permalink raw reply [flat|nested] 12+ messages in thread
end of thread, other threads:[~2021-01-01 11:21 UTC | newest]
Thread overview: 12+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-12-29 22:32 bug#45541: 28.0.50; Frequent crashes on ARM macOS Philipp
2020-12-30 0:10 ` Alan Third
2020-12-30 13:01 ` Philipp Stephani
2020-12-30 14:05 ` Alan Third
2020-12-30 14:42 ` Philipp Stephani
2020-12-30 14:49 ` Philipp Stephani
2020-12-30 14:53 ` Philipp Stephani
2020-12-30 15:22 ` Alan Third
2021-01-01 10:40 ` Alan Third
2021-01-01 11:21 ` Philipp Stephani
2020-12-30 20:35 ` Eli Zaretskii
2020-12-30 21:10 ` Philipp Stephani
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).