* 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 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
* 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
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 external index https://git.savannah.gnu.org/cgit/emacs.git https://git.savannah.gnu.org/cgit/emacs/org-mode.git This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.