GNU bug report logs - #28496
25.2; Crash when manipulating fullscreen frames on macOS

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 28496 in the body.
You can then email your comments to 28496 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

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

From: Duncan Harvey <djh-emacs-bugs <at> syndrig.co.uk>
To: bug-gnu-emacs <at> gnu.org
Subject: 25.2; Crash when manipulating fullscreen frames on macOS
Date: Mon, 18 Sep 2017 16:10:47 +0100

[Message part 1 (text/plain, inline)]

Run:

  open -na Emacs --args -Q -l .../path/to/macos-fullscreen-frame-crash.el

with the attached script.

On my system this crashes every time: "Fatal error 11: Segmentation faultAbort trap: 6"

Emacs will still crash if one runs the Emacs executable directly (with the -Q and -l arguments), rather then via the 'open' command.  I only use 'open' as a convenience, to avoid including the entire path to Emacs' executable.


In GNU Emacs 25.2.1 (x86_64-apple-darwin13.4.0, NS appkit-1265.21 Version 10.9.5 (Build 13F1911))
of 2017-04-21 built on builder10-9.porkrind.org
Windowing system distributor 'Apple', version 10.3.1504
Configured using:
'configure --with-ns '--enable-locallisppath=/Library/Application
Support/Emacs/${version}/site-lisp:/Library/Application
Support/Emacs/site-lisp' --with-modules'

Configured features:
NOTIFY ACL GNUTLS LIBXML2 ZLIB TOOLKIT_SCROLL_BARS NS MODULES

Important settings:
  value of $LANG: en_GB.UTF-8
  locale-coding-system: utf-8-unix

Major mode: Lisp Interaction

Minor modes in effect:
  tooltip-mode: t
  global-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

Recent messages:
For information about GNU Emacs and the GNU system, type C-h C-a.

Load-path shadows:
None found.

Features:
(shadow sort mail-extr emacsbug message dired format-spec rfc822 mml
mml-sec password-cache epg epg-config gnus-util mm-decode mm-bodies
mm-encode mail-parse rfc2231 mailabbrev gmm-utils mailheader sendmail
rfc2047 rfc2045 ietf-drums mm-util help-fns help-mode easymenu
cl-loaddefs pcase cl-lib mail-prsvr mail-utils time-date mule-util
tooltip eldoc electric uniquify ediff-hook vc-hooks lisp-float-type
mwheel ns-win ucs-normalize term/common-win tool-bar dnd fontset image
regexp-opt fringe tabulated-list newcomment elisp-mode lisp-mode
prog-mode register page menu-bar rfn-eshadow timer select scroll-bar
mouse jit-lock font-lock syntax facemenu font-core frame 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 charscript case-table epa-hook
jka-cmpr-hook help simple abbrev minibuffer cl-preloaded nadvice
loaddefs button faces cus-face macroexp files text-properties overlay
sha1 md5 base64 format env code-pages mule custom widget
hashtable-print-readable backquote kqueue cocoa ns multi-tty
make-network-process emacs)

Memory information:
((conses 16 195600 7784)
(symbols 48 19499 0)
(miscs 40 51 182)
(strings 32 14880 5859)
(string-bytes 1 430423)
(vectors 16 32840)
(vector-slots 8 649625 3900)
(floats 8 160 40)
(intervals 56 199 0)
(buffers 976 18))

[macos-fullscreen-frame-crash.el (application/octet-stream, attachment)]

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

From: Alan Third <alan <at> idiocy.org>
To: Duncan Harvey <djh-emacs-bugs <at> syndrig.co.uk>
Cc: 28496 <at> debbugs.gnu.org
Subject: Re: bug#28496: 25.2; Crash when manipulating fullscreen frames on
 macOS
Date: Mon, 18 Sep 2017 17:39:22 +0100

On Mon, Sep 18, 2017 at 04:10:47PM +0100, Duncan Harvey wrote:
> Run:
> 
>   open -na Emacs --args -Q -l .../path/to/macos-fullscreen-frame-crash.el
> 
> with the attached script.
> 
> On my system this crashes every time: "Fatal error 11: Segmentation faultAbort trap: 6"
> 
> Emacs will still crash if one runs the Emacs executable directly
> (with the -Q and -l arguments), rather then via the 'open' command.
> I only use 'open' as a convenience, to avoid including the entire
> path to Emacs' executable.

I can replicate the crash in Emacs 25, but the Emacs 26 branch does
something quite strange. It doesn’t crash, it seems to leave the
fullscreen window in the background with no contents. I suspect that
Emacs is deleting the frame before the fullscreen animation has
completed.

-- 
Alan Third

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

From: Duncan Harvey <djh-emacs-bugs <at> syndrig.co.uk>
To: Alan Third <alan <at> idiocy.org>
Cc: 28496 <at> debbugs.gnu.org
Subject: Re: bug#28496: 25.2; Crash when manipulating fullscreen frames on
 macOS
Date: Tue, 19 Sep 2017 16:49:16 +0100

> On 18 Sep 2017, at 17:39, Alan Third <alan <at> idiocy.org> wrote:
> 
> [...] the Emacs 26 branch does
> something quite strange. It doesn’t crash, it seems to leave the
> fullscreen window in the background with no contents.

I can replicate that strange behaviour with Emacs 25.2 on an older operating system (El Capitan, 10.11.6) running in a VM.

In GNU Emacs 25.2.1 (x86_64-apple-darwin13.4.0, NS appkit-1265.21 Version 10.9.5 (Build 13F1911))
 of 2017-04-21 built on builder10-9.porkrind.org
Windowing system distributor 'Apple', version 10.3.1404
Configured using:
 'configure --with-ns '--enable-locallisppath=/Library/Application
 Support/Emacs/${version}/site-lisp:/Library/Application
 Support/Emacs/site-lisp' --with-modules'



That suggests to me that it is not solely an Emacs 25 vs. 26 issue.


Other observations:

On macOS Sierra, creating the new frame appears to create a macOS-style tab in the same 'space'.
On El Capitan, creating the new frame creates a new Mac OS X 'space'.

Animating the creation of a new space certainly appears to be relatively slow (when running under a VM, at least), which lends weight to your suspicion that it's timing related.

-- Duncan

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

From: Duncan Harvey <djh-emacs-bugs <at> syndrig.co.uk>
To: Alan Third <alan <at> idiocy.org>
Cc: 28496 <at> debbugs.gnu.org
Subject: Re: bug#28496: 25.2; Crash when manipulating fullscreen frames on
 macOS
Date: Tue, 19 Sep 2017 17:38:41 +0100

> On 18 Sep 2017, at 17:39, Alan Third <alan <at> idiocy.org> wrote:
> 
> I can replicate the crash in Emacs 25, but the Emacs 26 branch does
> something quite strange.

FWIW, this still crashes for me when using the 2017-06-11 nightly build from <https://emacsformacosx.com/builds>.

-- Duncan

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

From: Alan Third <alan <at> idiocy.org>
To: Duncan Harvey <djh-emacs-bugs <at> syndrig.co.uk>
Cc: 28496 <at> debbugs.gnu.org
Subject: Re: bug#28496: 25.2; Crash when manipulating fullscreen frames on
 macOS
Date: Sun, 1 Oct 2017 00:23:23 +0100

[Message part 1 (text/plain, inline)]

On Tue, Sep 19, 2017 at 04:49:16PM +0100, Duncan Harvey wrote:
> 
> On macOS Sierra, creating the new frame appears to create a macOS-style tab in the same 'space'.
> On El Capitan, creating the new frame creates a new Mac OS X 'space'.

Emacs 26 shouldn’t create a new tab any more.

> Animating the creation of a new space certainly appears to be
> relatively slow (when running under a VM, at least), which lends
> weight to your suspicion that it's timing related.

I can’t see any way around this in C. I can’t even find a way to
prevent native fullscreen from animating, so I’ve gone with just
causing toggle-frame-fullscreen to pause for 1 second on macOS.

I don’t think anyone will be too bothered by this as I don’t think you
can realistically do anything in Emacs while the animation is running
anyway.

BTW, running your script with native fullscreen disabled causes a
crash here, and this pause fixes that too. In theory non‐native
fullscreen should happen instantly, but there’s a pause in the C code
too to fix another issue, so whatever. (see bug#28443)

Patch attached.
-- 
Alan Third

[0001-Fix-fullscreen-crash-on-macOS-bug-28496.patch (text/plain, attachment)]

Previous Next

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