GNU bug report logs - #59794
29.0.60; NSport segfaults when a fullscreen frame is being closed

Previous Next

Full log

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

From: Po Lu <luangruo <at> yahoo.com>
To: Kai Ma <justksqsf <at> gmail.com>
Cc: 59794 <at> debbugs.gnu.org
Subject: Re: bug#59794: 29.0.60; NSport segfaults when a fullscreen frame is
 being closed
Date: Sat, 03 Dec 2022 18:08:56 +0800

Kai Ma <justksqsf <at> gmail.com> writes:

> Emacs segfaults when a fullscreen frame is being deleted.
>
> Steps to reproduce on emacs -Q:
>
> 1. Launch an emacs instance.  The default frame should be in the window
>    mode for now.
>
> 2. C-x 5 2
>
> 3. In the new frame, M-x toggle-frame-fullscreen.
>
> 4. In the new frame, C-x 5 0 to delete the frame.
>
> Emacs then segfaults.
>
> LLDB trace:
>
> * thread #1, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=1, address=0xc0)
>     frame #0: 0x0000000100238ed5 emacs`-[EmacsView resetCursorRects](self=0x0000000102e3ddd0, _cmd=<unavailable>) at nsterm.m:6707:29 [opt]
>    6704	- (void)resetCursorRects
>    6705	{
>    6706	  NSRect visible = [self visibleRect];
> -> 6707	  NSCursor *currentCursor = FRAME_POINTER_TYPE (emacsframe);
>    6708	  NSTRACE ("[EmacsView resetCursorRects]");
>    6709
>    6710	  if (currentCursor == nil)
> Target 0: (emacs) stopped.
> warning: emacs was compiled with optimization - stepping may behave oddly; variables may not be available.
> (lldb) bt
> * thread #1, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=1, address=0xc0)
>   * frame #0: 0x0000000100238ed5 emacs`-[EmacsView resetCursorRects](self=0x0000000102e3ddd0, _cmd=<unavailable>) at nsterm.m:6707:29 [opt]
>     frame #1: 0x00007ff819be1b95 AppKit`-[_NSTrackingAreaAKViewHelper updateTrackingAreasWithInvalidCursorRects:] + 357
>     frame #2: 0x00007ff819e520f0 AppKit`_NSViewSubViewMutationSafeApply + 227
>     frame #3: 0x00007ff819be1c53 AppKit`-[_NSTrackingAreaAKViewHelper updateTrackingAreasWithInvalidCursorRects:] + 547
>     frame #4: 0x00007ff819e520f0 AppKit`_NSViewSubViewMutationSafeApply + 227
>     frame #5: 0x00007ff819be1c53 AppKit`-[_NSTrackingAreaAKViewHelper updateTrackingAreasWithInvalidCursorRects:] + 547
>     frame #6: 0x00007ff819bdfddf AppKit`-[_NSTrackingAreaAKManager displayCycleUpdateStructuralRegions] + 227
>     frame #7: 0x00007ff8195f4a84 AppKit`__NSWindowGetDisplayCycleObserverForUpdateStructuralRegions_block_invoke + 390
>     frame #8: 0x00007ff8195ef701 AppKit`NSDisplayCycleObserverInvoke + 142
>     frame #9: 0x00007ff8195ef331 AppKit`NSDisplayCycleFlush + 878
>     frame #10: 0x00007ff81de68f46 QuartzCore`CA::Transaction::run_commit_handlers(CATransactionPhase) + 98
>     frame #11: 0x00007ff81de67a10 QuartzCore`CA::Transaction::commit() + 380
>     frame #12: 0x00007ff81968cedf AppKit`__62+[CATransaction(NSCATransaction) NS_setFlushesWithDisplayLink]_block_invoke + 285
>     frame #13: 0x00007ff819ea3513 AppKit`___NSRunLoopObserverCreateWithHandler_block_invoke + 41
>     frame #14: 0x00007ff81640d0e2 CoreFoundation`__CFRUNLOOP_IS_CALLING_OUT_TO_AN_OBSERVER_CALLBACK_FUNCTION__ + 23
>     frame #15: 0x00007ff81640d00a CoreFoundation`__CFRunLoopDoObservers + 482
>     frame #16: 0x00007ff81640c590 CoreFoundation`__CFRunLoopRun + 870
>     frame #17: 0x00007ff81640bbb0 CoreFoundation`CFRunLoopRunSpecific + 560
>     frame #18: 0x00007ff81fcedbd6 HIToolbox`RunCurrentEventLoopInMode + 292
>     frame #19: 0x00007ff81fced9e6 HIToolbox`ReceiveNextEventCommon + 679
>     frame #20: 0x00007ff81fced723 HIToolbox`_BlockUntilNextEventMatchingListInModeWithFilter + 70
>     frame #21: 0x00007ff81952eb37 AppKit`_DPSNextEvent + 909
>     frame #22: 0x00007ff81952d9b8 AppKit`-[NSApplication(NSEvent) _nextEventMatchingEventMask:untilDate:inMode:dequeue:] + 1219
>     frame #23: 0x00007ff81951fff3 AppKit`-[NSApplication run] + 586
>     frame #24: 0x000000010023680d emacs`-[EmacsApp run](self=0x0000000102e09540, _cmd=<unavailable>) at nsterm.m:5818:7 [opt]
>     frame #25: 0x0000000100235395 emacs`ns_select_1(nfds=0, readfds=0x00007ff7bfefdcb0, writefds=0x00007ff7bfefdc00, exceptfds=0x0000000000000000, timeout=0x00007ff7bfefddb0, sigmask=0x0000000000000000, run_loop_only=NO) at nsterm.m:4833:3 [opt]
>     frame #26: 0x0000000100234f54 emacs`ns_select(nfds=<unavailable>, readfds=<unavailable>, writefds=<unavailable>, exceptfds=<unavailable>, timeout=<unavailable>, sigmask=<unavailable>) at nsterm.m:4885:10 [opt]

This time I cannot reproduce the bug on GNUstep.

It looks as if a reference to the EmacsFrame is being kept even after
the frame has been destroyed.  Would someone who knows what
`NSView resetCursorRects' does in Mac OS speak up?

Previous Next

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