GNU bug report logs - #58857
28.2; Emacs on macOS seg faults when deleting fullscreen frame

Previous Next

Full log

View this message in rfc822 format

From: Eli Zaretskii <eliz <at> gnu.org>
To: Gerd Möllmann <gerd.moellmann <at> gmail.com>
Cc: kkylin <at> alum.mit.edu, 58857 <at> debbugs.gnu.org
Subject: bug#58857: 28.2; Emacs on macOS seg faults when deleting fullscreen frame
Date: Sat, 29 Oct 2022 11:04:51 +0300

> From: Gerd Möllmann <gerd.moellmann <at> gmail.com>
> Cc: kkylin <at> alum.mit.edu,  58857 <at> debbugs.gnu.org
> Date: Sat, 29 Oct 2022 09:36:11 +0200
> 
> Eli Zaretskii <eliz <at> gnu.org> writes:
> 
> >> From: Gerd Möllmann <gerd.moellmann <at> 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.

Previous Next

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