bug#28496: 25.2; Crash when manipulating fullscreen frames on macOS

bug#28496: 25.2; Crash when manipulating fullscreen frames on macOS

[Duncan Harvey]

[-- Attachment #1: Type: text/plain, Size: 3005 bytes --]

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))


[-- Attachment #2: macos-fullscreen-frame-crash.el --]
[-- Type: application/octet-stream, Size: 233 bytes --]

;;; open -na Emacs --args -Q -l `pwd`/macos-fullscreen-frame-crash.el

(progn
  (toggle-frame-fullscreen)
  (sit-for 1)
  (let ((frame (make-frame)))
    (select-frame frame)
    (make-frame-visible frame)
    (delete-frame frame)))

bug#28496: 25.2; Crash when manipulating fullscreen frames on macOS

[Alan Third]

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

bug#28496: 25.2; Crash when manipulating fullscreen frames on macOS

[Duncan Harvey]

> On 18 Sep 2017, at 17:39, Alan Third <alan@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

bug#28496: 25.2; Crash when manipulating fullscreen frames on macOS

[Duncan Harvey]

> On 18 Sep 2017, at 17:39, Alan Third <alan@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

bug#28496: 25.2; Crash when manipulating fullscreen frames on macOS

[Alan Third]

[-- Attachment #1: Type: text/plain, Size: 1118 bytes --]

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

[-- Attachment #2: 0001-Fix-fullscreen-crash-on-macOS-bug-28496.patch --]
[-- Type: text/plain, Size: 1087 bytes --]

From 2d756250d7990dc9a6a452e8282cc32d16d2099a Mon Sep 17 00:00:00 2001
From: Alan Third <alan@idiocy.org>
Date: Sun, 1 Oct 2017 00:06:23 +0100
Subject: [PATCH] Fix fullscreen crash on macOS (bug#28496)

* lisp/frame.el (toggle-frame-fullscreen): Wait for animation to
complete on macOS.
---
 lisp/frame.el | 6 +++++-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/lisp/frame.el b/lisp/frame.el
index 76c1842455..b70f55e981 100644
--- a/lisp/frame.el
+++ b/lisp/frame.el
@@ -2434,7 +2434,11 @@ toggle-frame-fullscreen
 	      (set-frame-parameter nil 'fullscreen fullscreen-restore)
 	    (set-frame-parameter nil 'fullscreen nil)))
       (modify-frame-parameters
-       nil `((fullscreen . fullboth) (fullscreen-restore . ,fullscreen))))))
+       nil `((fullscreen . fullboth) (fullscreen-restore . ,fullscreen))))
+    ;; Manipulating a frame without waiting for the fullscreen
+    ;; animation to complete can cause a crash, or other unexpected
+    ;; behaviour, on macOS (bug#28496).
+    (when (featurep 'cocoa) (sit-for 1))))
 \f
 ;;;; Key bindings
 
-- 
2.14.1