bug#58857: 28.2; Emacs on macOS seg faults when deleting fullscreen frame

bug#58857: 28.2; Emacs on macOS seg faults when deleting fullscreen frame

[Kevin Lin]

Using stock Emacs 28.2 from https://emacsformacosx.com/:

1) $ /Applications/Emacs.app/Contents/MacOS/Emacs -Q

2) open a second frame by, e.g., C-X-5-2

3) make it fullscreen, e.g., by clicking the green title button

4) delete the fullscreened frame by, e.g., C-X-5-0

I don't know enough about ObjC or NS to isolate the issue in the ObjC source, but the following work-around works for me:

(defun frame-turn-off-fullscreen (theframe)
  (if (eq 'fullboth
	  (cdr (assq 'fullscreen
		     (frame-parameters theframe))))
      (set-frame-parameter theframe 'fullscreen nil)))

(if (boundp 'ns-use-native-fullscreen)
    (add-to-list 'delete-frame-functions 'frame-turn-off-fullscreen))

I haven't tried this with Emacs in gdb, but do have macOS-generated crash logs I can send along upon request.

Also, I'm running this on macOS 13 (Ventura), but this has happened to me since macOS 10.13 (High Sierra) with Emacs 27 (possibly even earlier).  Reporting it only now because the work-around above has worked for me and I forgot about it.



In GNU Emacs 28.2 (build 1, x86_64-apple-darwin18.7.0, NS appkit-1671.60 Version 10.14.6 (Build 18G95))
of 2022-09-12 built on builder10-14.lan
Windowing system distributor 'Apple', version 10.3.2299
System Description:  macOS 13.0

Configured using:
'configure --with-ns '--enable-locallisppath=/Library/Application
Support/Emacs/${version}/site-lisp:/Library/Application
Support/Emacs/site-lisp' --with-modules'

Configured features:
ACL GMP GNUTLS JSON LIBXML2 MODULES NOTIFY KQUEUE NS PDUMPER THREADS
TOOLKIT_SCROLL_BARS ZLIB

Important settings:
  value of $LANG: en_US.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
  show-paren-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
  indent-tabs-mode: t
  transient-mark-mode: t

Load-path shadows:
None found.

Features:
(shadow sort mail-extr emacsbug message rmc puny dired dired-loaddefs
rfc822 mml mml-sec epa derived epg rfc6068 epg-config gnus-util rmail
rmail-loaddefs auth-source cl-seq eieio eieio-core cl-macs
eieio-loaddefs password-cache json map text-property-search time-date
subr-x seq byte-opt gv bytecomp byte-compile cconv mm-decode mm-bodies
mm-encode mail-parse rfc2231 mailabbrev gmm-utils mailheader cl-loaddefs
cl-lib sendmail rfc2047 rfc2045 ietf-drums mm-util mail-prsvr mail-utils
iso-transl tooltip eldoc paren electric uniquify ediff-hook vc-hooks
lisp-float-type elisp-mode 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 lisp-mode prog-mode register
page tab-bar menu-bar rfn-eshadow isearch easymenu timer select
scroll-bar mouse jit-lock font-lock syntax 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 emoji-zwj 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 multi-tty
make-network-process emacs)

Memory information:
((conses 16 51043 7955)
(symbols 48 6562 1)
(strings 32 18364 2902)
(string-bytes 1 612723)
(vectors 16 13832)
(vector-slots 8 191713 10825)
(floats 8 21 39)
(intervals 56 222 0)
(buffers 992 11))
-- 

bug#58857: Acknowledgement (28.2; Emacs on macOS seg faults when deleting fullscreen frame)

[Kevin Lin]

I want to make one correction: I did indeed experience
a similar issue with macos 10.13, but just now I was
unable to reproduce it on older machines running 10.15
or 11.7.  So this may well be due solely to upgrading
to Ventura, and I may have pulled the trigger too
early on the bug report.  I will try to rebuild Emacs
on Ventura and see if that resolves the issue.


-----Original Message-----
From: help-debbugs@gnu.org (GNU bug Tracking System)
To: Kevin Lin <kkylin@alum.mit.edu>
Date: Sat, 29 Oct 2022 04:13:02 +0000 (2 hours, 19 minutes ago)
Resent-From: <kkylin@alum.mit.edu>
Reply-To: 58857@debbugs.gnu.org
Subject: bug#58857: Acknowledgement (28.2; Emacs on macOS seg faults when deleting fullscreen frame)

Thank you for filing a new bug report with debbugs.gnu.org.

This is an automatically generated reply to let you know your message
has been received.

Your message is being forwarded to the package maintainers and other
interested parties for their attention; they will reply in due course.

Your message has been sent to the package maintainer(s):
 bug-gnu-emacs@gnu.org

If you wish to submit further information on this problem, please
send it to 58857@debbugs.gnu.org.

Please do not send mail to help-debbugs@gnu.org unless you wish
to report a problem with the Bug-tracking system.


-- 

bug#58857: 28.2; Emacs on macOS seg faults when deleting fullscreen frame

[Eli Zaretskii]

> From: Kevin Lin <kkylin@alum.mit.edu>
> Date: Fri, 28 Oct 2022 10:59:16 -0700
> 
> Using stock Emacs 28.2 from https://emacsformacosx.com/:

This distribution is done by someone outside of the Emacs project.  I
therefore suggest that you first report the problem to that person.

> 1) $ /Applications/Emacs.app/Contents/MacOS/Emacs -Q
> 
> 2) open a second frame by, e.g., C-X-5-2
> 
> 3) make it fullscreen, e.g., by clicking the green title button
> 
> 4) delete the fullscreened frame by, e.g., C-X-5-0
> 
> I don't know enough about ObjC or NS to isolate the issue in the ObjC source, but the following work-around works for me:
> 
> (defun frame-turn-off-fullscreen (theframe)
>   (if (eq 'fullboth
> 	  (cdr (assq 'fullscreen
> 		     (frame-parameters theframe))))
>       (set-frame-parameter theframe 'fullscreen nil)))
> 
> (if (boundp 'ns-use-native-fullscreen)
>     (add-to-list 'delete-frame-functions 'frame-turn-off-fullscreen))
> 
> I haven't tried this with Emacs in gdb, but do have macOS-generated crash logs I can send along upon request.
> 
> Also, I'm running this on macOS 13 (Ventura), but this has happened to me since macOS 10.13 (High Sierra) with Emacs 27 (possibly even earlier).  Reporting it only now because the work-around above has worked for me and I forgot about it.

In general, we don't expect any Emacs 28 releases, so it would be of
great help to us if you could try Emacs 29 (from the master branch of
the Emacs Git repository) and see if the problem still exists there.
That's assuming the person who prepares these binaries concludes that
the problem is in the upstream code, not related to the particular way
these binaries are built.

Thanks.

bug#58857: 28.2; Emacs on macOS seg faults when deleting fullscreen frame

[Gerd Möllmann]

Eli Zaretskii <eliz@gnu.org> writes:

> In general, we don't expect any Emacs 28 releases, so it would be of
> great help to us if you could try Emacs 29 (from the master branch of
> the Emacs Git repository) and see if the problem still exists there.

I can reproduce this in feature/pkg, which should equal master in this
area.

* thread #1, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=1, address=0xc0)
    frame #0: 0x0000000100310ce8 emacs`-[EmacsView resetCursorRects](self=0x0000000102f2cb40, _cmd="resetCursorRects") at nsterm.m:6702:29
   6699	- (void)resetCursorRects
   6700	{
   6701	  NSRect visible = [self visibleRect];
-> 6702	  NSCursor *currentCursor = FRAME_POINTER_TYPE (emacsframe);
   6703	  NSTRACE ("[EmacsView resetCursorRects]");
   6704	
   6705	  if (currentCursor == nil)
Target 0: (emacs) stopped.
(lldb) bt
* thread #1, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=1, address=0xc0)
  * frame #0: 0x0000000100310ce8 emacs`-[EmacsView resetCursorRects](self=0x0000000102f2cb40, _cmd="resetCursorRects") at nsterm.m:6702:29
    frame #1: 0x00000001952beb60 AppKit`-[_NSTrackingAreaAKViewHelper updateTrackingAreasWithInvalidCursorRects:] + 276
    frame #2: 0x00000001954cb9f0 AppKit`_NSViewSubViewMutationSafeApply + 220
    frame #3: 0x00000001952bec04 AppKit`-[_NSTrackingAreaAKViewHelper updateTrackingAreasWithInvalidCursorRects:] + 440
    frame #4: 0x00000001954cb9f0 AppKit`_NSViewSubViewMutationSafeApply + 220
    frame #5: 0x00000001952bec04 AppKit`-[_NSTrackingAreaAKViewHelper updateTrackingAreasWithInvalidCursorRects:] + 440
    frame #6: 0x00000001952bd030 AppKit`-[_NSTrackingAreaAKManager displayCycleUpdateStructuralRegions] + 176
    frame #7: 0x0000000194db7708 AppKit`__NSWindowGetDisplayCycleObserverForUpdateStructuralRegions_block_invoke + 364
    frame #8: 0x0000000194db2cb4 AppKit`NSDisplayCycleObserverInvoke + 168
    frame #9: 0x0000000194db2910 AppKit`NSDisplayCycleFlush + 644
    frame #10: 0x00000001990fa120 QuartzCore`CA::Transaction::run_commit_handlers(CATransactionPhase) + 120
    frame #11: 0x00000001990f8ea0 QuartzCore`CA::Transaction::commit() + 324
    frame #12: 0x0000000194e34b90 AppKit`__62+[CATransaction(NSCATransaction) NS_setFlushesWithDisplayLink]_block_invoke + 272
    frame #13: 0x0000000195511744 AppKit`___NSRunLoopObserverCreateWithHandler_block_invoke + 64
    frame #14: 0x0000000191ab4de4 CoreFoundation`__CFRUNLOOP_IS_CALLING_OUT_TO_AN_OBSERVER_CALLBACK_FUNCTION__ + 36
    frame #15: 0x0000000191ab4cd0 CoreFoundation`__CFRunLoopDoObservers + 532
    frame #16: 0x0000000191ab4308 CoreFoundation`__CFRunLoopRun + 784
    frame #17: 0x0000000191ab38a4 CoreFoundation`CFRunLoopRunSpecific + 612
    frame #18: 0x000000019b1273bc HIToolbox`RunCurrentEventLoopInMode + 292
    frame #19: 0x000000019b127200 HIToolbox`ReceiveNextEventCommon + 672
    frame #20: 0x000000019b126f48 HIToolbox`_BlockUntilNextEventMatchingListInModeWithFilter + 72
    frame #21: 0x0000000194d0c630 AppKit`_DPSNextEvent + 632
    frame #22: 0x0000000194d0b7c0 AppKit`-[NSApplication(NSEvent) _nextEventMatchingEventMask:untilDate:inMode:dequeue:] + 728
    frame #23: 0x0000000194cffbf0 AppKit`-[NSApplication run] + 464
    frame #24: 0x000000010030df40 emacs`-[EmacsApp run](self=0x00000001053150c0, _cmd="run") at nsterm.m:5813:7
    frame #25: 0x000000010030c66c emacs`ns_select_1(nfds=20, readfds=0x000000016fdfdcdc, writefds=0x000000016fdfdc5c, exceptfds=0x0000000000000000, timeout=0x000000016fdfdc30, sigmask=0x0000000000000000, run_loop_only=NO) at nsterm.m:4828:3
    frame #26: 0x000000010030c2e8 emacs`ns_select(nfds=20, readfds=0x000000016fdfdcdc, writefds=0x000000016fdfdc5c, exceptfds=0x0000000000000000, timeout=0x000000016fdfdc30, sigmask=0x0000000000000000) at nsterm.m:4880:10
    frame #27: 0x00000001002a65ec emacs`wait_reading_process_output(time_limit=37, nsecs=0, read_kbd=-1, do_display=true, wait_for_cell=(struct Lisp_Symbol *) $3 = 0x00000001008dcb68, wait_proc=0x0000000000000000, just_wait_proc=0) at process.c:5690:18
    frame #28: 0x000000010000b724 emacs`sit_for(timeout=(EMACS_INT) $5 = 37, reading=true, display_option=1) at dispnew.c:6252:7
    frame #29: 0x00000001001587d8 emacs`read_char(commandflag=1, map=(struct Lisp_Cons *) $7 = 0x000000012bc55400, prev_event=(struct Lisp_Symbol *) $10 = 0x00000001008dcb68, used_mouse_menu=0x000000016fdfe997, end_time=0x0000000000000000) at keyboard.c:2870:11
    frame #30: 0x0000000100154c0c emacs`read_key_sequence(keybuf=(struct Lisp_Symbol *) $13 = 0x00000001008dcb68, prompt=(struct Lisp_Symbol *) $16 = 0x00000001008dcb68, dont_downcase_last=false, can_return_switch_frame=true, fix_current_buffer=true, prevent_redisplay=false) at keyboard.c:10027:12
    frame #31: 0x0000000100153338 emacs`command_loop_1 at keyboard.c:1375:15
    frame #32: 0x0000000100231650 emacs`internal_condition_case(bfun=(emacs`command_loop_1 at keyboard.c:1268), handlers=(struct Lisp_Symbol *) $19 = 0x00000001008dcbf8, hfun=(emacs`cmd_error at keyboard.c:926)) at eval.c:1471:25
    frame #33: 0x0000000100152e4c emacs`command_loop_2(handlers=(struct Lisp_Symbol *) $22 = 0x00000001008dcbf8) at keyboard.c:1123:11
    frame #34: 0x0000000100230e34 emacs`internal_catch(tag=(struct Lisp_Symbol *) $25 = 0x00000001008ebe98, func=(emacs`command_loop_2 at keyboard.c:1119), arg=(struct Lisp_Symbol *) $28 = 0x00000001008dcbf8) at eval.c:1194:25
    frame #35: 0x0000000100152164 emacs`command_loop at keyboard.c:1101:2
    frame #36: 0x0000000100151fb4 emacs`recursive_edit_1 at keyboard.c:710:9
    frame #37: 0x0000000100152500 emacs`Frecursive_edit at keyboard.c:793:3
    frame #38: 0x000000010014f1e8 emacs`main(argc=1, argv=0x000000016fdff688) at emacs.c:2523:3
    frame #39: 0x00000001916abe50 dyld`start + 2544

(lldb) p emacsframe
(frame *) $64 = 0x000000012d811600
(lldb) p emacsframe->output_data
(output_data) $63 = {
  tty = nil
  x = nil
  w32 = nil
  ns = nil
  pgtk = nil
  haiku = nil
}

Other than that, I can't help much with this, I'm afraid.  One could of
course check it output_data is valid, but if that's the right thing to
do...

bug#58857: 28.2; Emacs on macOS seg faults when deleting fullscreen frame

[Eli Zaretskii]

> From: Gerd Möllmann <gerd.moellmann@gmail.com>
> Cc: Kevin Lin <kkylin@alum.mit.edu>,  58857@debbugs.gnu.org
> Date: Sat, 29 Oct 2022 09:01:12 +0200
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > In general, we don't expect any Emacs 28 releases, so it would be of
> > great help to us if you could try Emacs 29 (from the master branch of
> > the Emacs Git repository) and see if the problem still exists there.
> 
> I can reproduce this in feature/pkg, which should equal master in this
> area.
> 
> 
> (lldb) p emacsframe
> (frame *) $64 = 0x000000012d811600
> (lldb) p emacsframe->output_data
> (output_data) $63 = {
>   tty = nil
>   x = nil
>   w32 = nil
>   ns = nil
>   pgtk = nil
>   haiku = nil
> }

So you are saying the NS-specific code that is run when Emacs is idle
somehow references a frame that was deleted?

bug#58857: 28.2; Emacs on macOS seg faults when deleting fullscreen frame

[Gerd Möllmann]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Gerd Möllmann <gerd.moellmann@gmail.com>
>> (lldb) p emacsframe
>> (frame *) $64 = 0x000000012d811600
>> (lldb) p emacsframe->output_data
>> (output_data) $63 = {
>>   tty = nil
>>   x = nil
>>   w32 = nil
>>   ns = nil
>>   pgtk = nil
>>   haiku = nil
>> }
>
> So you are saying the NS-specific code that is run when Emacs is idle
> somehow references a frame that was deleted?

I interpret the backtrace as saying that it's handling an event
(AppKit`-[NSApplication(NSEvent)
_nextEventMatchingEventMask:untilDate:inMode:dequeue:]), and the GUI
frame has been deleted.

Don't know about the idle part.

bug#58857: 28.2; Emacs on macOS seg faults when deleting fullscreen frame

[Eli Zaretskii]

> From: Gerd Möllmann <gerd.moellmann@gmail.com>
> Cc: kkylin@alum.mit.edu,  58857@debbugs.gnu.org
> Date: Sat, 29 Oct 2022 09:36:11 +0200
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >> From: Gerd Möllmann <gerd.moellmann@gmail.com>
> >> (lldb) p emacsframe
> >> (frame *) $64 = 0x000000012d811600
> >> (lldb) p emacsframe->output_data
> >> (output_data) $63 = {
> >>   tty = nil
> >>   x = nil
> >>   w32 = nil
> >>   ns = nil
> >>   pgtk = nil
> >>   haiku = nil
> >> }
> >
> > So you are saying the NS-specific code that is run when Emacs is idle
> > somehow references a frame that was deleted?
> 
> I interpret the backtrace as saying that it's handling an event
> (AppKit`-[NSApplication(NSEvent)
> _nextEventMatchingEventMask:untilDate:inMode:dequeue:]), and the GUI
> frame has been deleted.
> 
> Don't know about the idle part.

Look down the backtrace: this stuff was invoked from read_key_sequence
inside the command loop.  delete-frame is nowhere on the callstack, so
I conclude that delete-frame already exited, and we are in the idle
loop.

bug#58857: 28.2; Emacs on macOS seg faults when deleting fullscreen frame

[Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Gerd Möllmann <gerd.moellmann@gmail.com> writes:

> Eli Zaretskii <eliz@gnu.org> writes:
>
>> In general, we don't expect any Emacs 28 releases, so it would be of
>> great help to us if you could try Emacs 29 (from the master branch of
>> the Emacs Git repository) and see if the problem still exists there.
>
> I can reproduce this in feature/pkg, which should equal master in this
> area.
>
> * thread #1, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=1, address=0xc0)
>     frame #0: 0x0000000100310ce8 emacs`-[EmacsView resetCursorRects](self=0x0000000102f2cb40, _cmd="resetCursorRects") at nsterm.m:6702:29
>    6699	- (void)resetCursorRects
>    6700	{
>    6701	  NSRect visible = [self visibleRect];
> -> 6702	  NSCursor *currentCursor = FRAME_POINTER_TYPE (emacsframe);
>    6703	  NSTRACE ("[EmacsView resetCursorRects]");
>    6704	
>    6705	  if (currentCursor == nil)
> Target 0: (emacs) stopped.
> (lldb) bt
> * thread #1, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=1, address=0xc0)
>   * frame #0: 0x0000000100310ce8 emacs`-[EmacsView resetCursorRects](self=0x0000000102f2cb40, _cmd="resetCursorRects") at nsterm.m:6702:29
>     frame #1: 0x00000001952beb60 AppKit`-[_NSTrackingAreaAKViewHelper updateTrackingAreasWithInvalidCursorRects:] + 276
>     frame #2: 0x00000001954cb9f0 AppKit`_NSViewSubViewMutationSafeApply + 220
>     frame #3: 0x00000001952bec04 AppKit`-[_NSTrackingAreaAKViewHelper updateTrackingAreasWithInvalidCursorRects:] + 440
>     frame #4: 0x00000001954cb9f0 AppKit`_NSViewSubViewMutationSafeApply + 220
>     frame #5: 0x00000001952bec04 AppKit`-[_NSTrackingAreaAKViewHelper updateTrackingAreasWithInvalidCursorRects:] + 440
>     frame #6: 0x00000001952bd030 AppKit`-[_NSTrackingAreaAKManager displayCycleUpdateStructuralRegions] + 176
>     frame #7: 0x0000000194db7708 AppKit`__NSWindowGetDisplayCycleObserverForUpdateStructuralRegions_block_invoke + 364
>     frame #8: 0x0000000194db2cb4 AppKit`NSDisplayCycleObserverInvoke + 168
>     frame #9: 0x0000000194db2910 AppKit`NSDisplayCycleFlush + 644
>     frame #10: 0x00000001990fa120 QuartzCore`CA::Transaction::run_commit_handlers(CATransactionPhase) + 120
>     frame #11: 0x00000001990f8ea0 QuartzCore`CA::Transaction::commit() + 324
>     frame #12: 0x0000000194e34b90 AppKit`__62+[CATransaction(NSCATransaction) NS_setFlushesWithDisplayLink]_block_invoke + 272
>     frame #13: 0x0000000195511744 AppKit`___NSRunLoopObserverCreateWithHandler_block_invoke + 64
>     frame #14: 0x0000000191ab4de4 CoreFoundation`__CFRUNLOOP_IS_CALLING_OUT_TO_AN_OBSERVER_CALLBACK_FUNCTION__ + 36
>     frame #15: 0x0000000191ab4cd0 CoreFoundation`__CFRunLoopDoObservers + 532
>     frame #16: 0x0000000191ab4308 CoreFoundation`__CFRunLoopRun + 784
>     frame #17: 0x0000000191ab38a4 CoreFoundation`CFRunLoopRunSpecific + 612
>     frame #18: 0x000000019b1273bc HIToolbox`RunCurrentEventLoopInMode + 292
>     frame #19: 0x000000019b127200 HIToolbox`ReceiveNextEventCommon + 672
>     frame #20: 0x000000019b126f48 HIToolbox`_BlockUntilNextEventMatchingListInModeWithFilter + 72
>     frame #21: 0x0000000194d0c630 AppKit`_DPSNextEvent + 632
>     frame #22: 0x0000000194d0b7c0 AppKit`-[NSApplication(NSEvent) _nextEventMatchingEventMask:untilDate:inMode:dequeue:] + 728
>     frame #23: 0x0000000194cffbf0 AppKit`-[NSApplication run] + 464
>     frame #24: 0x000000010030df40 emacs`-[EmacsApp run](self=0x00000001053150c0, _cmd="run") at nsterm.m:5813:7
>     frame #25: 0x000000010030c66c emacs`ns_select_1(nfds=20, readfds=0x000000016fdfdcdc, writefds=0x000000016fdfdc5c, exceptfds=0x0000000000000000, timeout=0x000000016fdfdc30, sigmask=0x0000000000000000, run_loop_only=NO) at nsterm.m:4828:3
>     frame #26: 0x000000010030c2e8 emacs`ns_select(nfds=20, readfds=0x000000016fdfdcdc, writefds=0x000000016fdfdc5c, exceptfds=0x0000000000000000, timeout=0x000000016fdfdc30, sigmask=0x0000000000000000) at nsterm.m:4880:10
>     frame #27: 0x00000001002a65ec emacs`wait_reading_process_output(time_limit=37, nsecs=0, read_kbd=-1, do_display=true, wait_for_cell=(struct Lisp_Symbol *) $3 = 0x00000001008dcb68, wait_proc=0x0000000000000000, just_wait_proc=0) at process.c:5690:18
>     frame #28: 0x000000010000b724 emacs`sit_for(timeout=(EMACS_INT) $5 = 37, reading=true, display_option=1) at dispnew.c:6252:7
>     frame #29: 0x00000001001587d8 emacs`read_char(commandflag=1, map=(struct Lisp_Cons *) $7 = 0x000000012bc55400, prev_event=(struct Lisp_Symbol *) $10 = 0x00000001008dcb68, used_mouse_menu=0x000000016fdfe997, end_time=0x0000000000000000) at keyboard.c:2870:11
>     frame #30: 0x0000000100154c0c emacs`read_key_sequence(keybuf=(struct Lisp_Symbol *) $13 = 0x00000001008dcb68, prompt=(struct Lisp_Symbol *) $16 = 0x00000001008dcb68, dont_downcase_last=false, can_return_switch_frame=true, fix_current_buffer=true, prevent_redisplay=false) at keyboard.c:10027:12
>     frame #31: 0x0000000100153338 emacs`command_loop_1 at keyboard.c:1375:15
>     frame #32: 0x0000000100231650 emacs`internal_condition_case(bfun=(emacs`command_loop_1 at keyboard.c:1268), handlers=(struct Lisp_Symbol *) $19 = 0x00000001008dcbf8, hfun=(emacs`cmd_error at keyboard.c:926)) at eval.c:1471:25
>     frame #33: 0x0000000100152e4c emacs`command_loop_2(handlers=(struct Lisp_Symbol *) $22 = 0x00000001008dcbf8) at keyboard.c:1123:11
>     frame #34: 0x0000000100230e34 emacs`internal_catch(tag=(struct Lisp_Symbol *) $25 = 0x00000001008ebe98, func=(emacs`command_loop_2 at keyboard.c:1119), arg=(struct Lisp_Symbol *) $28 = 0x00000001008dcbf8) at eval.c:1194:25
>     frame #35: 0x0000000100152164 emacs`command_loop at keyboard.c:1101:2
>     frame #36: 0x0000000100151fb4 emacs`recursive_edit_1 at keyboard.c:710:9
>     frame #37: 0x0000000100152500 emacs`Frecursive_edit at keyboard.c:793:3
>     frame #38: 0x000000010014f1e8 emacs`main(argc=1, argv=0x000000016fdff688) at emacs.c:2523:3
>     frame #39: 0x00000001916abe50 dyld`start + 2544
>
> (lldb) p emacsframe
> (frame *) $64 = 0x000000012d811600
> (lldb) p emacsframe->output_data
> (output_data) $63 = {
>   tty = nil
>   x = nil
>   w32 = nil
>   ns = nil
>   pgtk = nil
>   haiku = nil
> }
>
> Other than that, I can't help much with this, I'm afraid.  One could of
> course check it output_data is valid, but if that's the right thing to
> do...

I can reproduce this on GNUstep, so expect a fix soon (anywhere between
2 to 5 hours depending on when I can get home.)

bug#58857: 28.2; Emacs on macOS seg faults when deleting fullscreen frame

[Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Please see if this has been fixed on master.

bug#58857: 28.2; Emacs on macOS seg faults when deleting fullscreen frame

[Gerd Möllmann]

Po Lu <luangruo@yahoo.com> writes:

> Please see if this has been fixed on master.

Yes it's fixed.  Thanks!

bug#58857: 28.2; Emacs on macOS seg faults when deleting fullscreen frame

[Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Gerd Möllmann <gerd.moellmann@gmail.com> writes:

> Po Lu <luangruo@yahoo.com> writes:
>
>> Please see if this has been fixed on master.
>
> Yes it's fixed.  Thanks!

Great!  Kevin, if it's fixed for you as well, then I'll close this bug.

bug#58857: 28.2; Emacs on macOS seg faults when deleting fullscreen frame

[Gerd Möllmann]

Po Lu <luangruo@yahoo.com> writes:

> Gerd Möllmann <gerd.moellmann@gmail.com> writes:
>
>> Po Lu <luangruo@yahoo.com> writes:
>>
>>> Please see if this has been fixed on master.
>>
>> Yes it's fixed.  Thanks!
>
> Great!  Kevin, if it's fixed for you as well, then I'll close this bug.

Don't know if this is important, but I see, on master, this printed to
the terminal, which is new AFAICt

2022-10-29 14:14:51.438 emacs[66923:1591049] +[CATransaction
synchronize] called within transaction

Alas, I don't know how to trigger this reproducibly.

bug#58857: 28.2; Emacs on macOS seg faults when deleting fullscreen frame

[Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Gerd Möllmann <gerd.moellmann@gmail.com> writes:

> Don't know if this is important, but I see, on master, this printed to
> the terminal, which is new AFAICt
>
> 2022-10-29 14:14:51.438 emacs[66923:1591049] +[CATransaction
> synchronize] called within transaction
>
> Alas, I don't know how to trigger this reproducibly.

Unfortunately, I can't make sense of that Apple mumbo jumbo, sorry.
According to a web search, it occurs on iOS when two animations are run
by the toolkit at the same time (which is probably the same on Mac OS.)
I guess it's fine if it doesn't lead to crashes.

bug#58857: 28.2; Emacs on macOS seg faults when deleting fullscreen frame

[Gerd Möllmann]

Po Lu <luangruo@yahoo.com> writes:

> Unfortunately, I can't make sense of that Apple mumbo jumbo, sorry.
> According to a web search, it occurs on iOS when two animations are run
> by the toolkit at the same time (which is probably the same on Mac OS.)
> I guess it's fine if it doesn't lead to crashes.

I'll holler if I find something out.

bug#58857: 28.2; Emacs on macOS seg faults when deleting fullscreen frame

[Stefan Kangas]

Po Lu <luangruo@yahoo.com> writes:

> Gerd Möllmann <gerd.moellmann@gmail.com> writes:
>
>> Po Lu <luangruo@yahoo.com> writes:
>>
>>> Please see if this has been fixed on master.
>>
>> Yes it's fixed.  Thanks!
>
> Great!  Kevin, if it's fixed for you as well, then I'll close this
> bug.

No more comments within 2 weeks, so I'm closing the bug.