bug#30800: 26.0.91; unknown crash on macos

bug#30800: 26.0.91; unknown crash on macos

[Aaron Jensen]

I'm reporting this with the hope of eventually providing enough
information to track it down. I've reproduced this crash a few times,
though the repro is finnicky and narrowing it down will be challenging.

I was hoping to provide more information from lldb, but I cannot figure
out how to generate dSYM files for emacs.

This is what I'm using to build:

EMACS_DIR=$(brew --prefix emacs-plus)
export PATH="/usr/local/opt/gnu-sed/libexec/gnubin:$PATH"
export LDFLAGS="-g -L/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.13.sdk/usr/lib -lxml2 -lz -lpthread -licucore"
# "-L/usr/local/opt/libxml2/lib -L/usr/local/opt/imagemagick@6/lib"
./autogen.sh
# -I/usr/local/opt/libxml2/include
./configure CFLAGS="-g -O0 -I/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.13.sdk/usr/include/libxml2 -I/usr/local/opt/imagemagick@6/include" \
            CXXFLAGS="-g -O0" \
            --enable-locallisppath=/usr/local/share/emacs/site-lisp \
            --infodir=$EMACS_DIR/share/info/emacs \
            --prefix=$EMACS_DIR

make -j8


Here is the thread list from the crash:

(lldb) thread list
Process 49855 stopped
* thread #1: tid = 0x2400ba, 0x000000010017ad9c Emacs`-[EmacsApp sendEvent:] + 110, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=1, address=0x0)
  thread #4: tid = 0x2400ca, 0x00007fff7b0b9562 libsystem_kernel.dylib`__workq_kernreturn + 10
  thread #5: tid = 0x2400cb, 0x00007fff7b0b8fca libsystem_kernel.dylib`__select + 10, name = 'gmain'
  thread #8: tid = 0x2400cd, 0x00007fff7b0b8fca libsystem_kernel.dylib`__select + 10
  thread #12: tid = 0x2400d4, 0x00007fff7b0af7c2 libsystem_kernel.dylib`mach_msg_trap + 10, name = 'com.apple.NSEventThread'
  thread #13: tid = 0x2400d7, 0x00007fff7b0b9562 libsystem_kernel.dylib`__workq_kernreturn + 10
  thread #14: tid = 0x2405b8, 0x00007fff7b0b9562 libsystem_kernel.dylib`__workq_kernreturn + 10
  thread #15: tid = 0x2405ba, 0x00007fff7b0b9562 libsystem_kernel.dylib`__workq_kernreturn + 10
  thread #16: tid = 0x2405bb, 0x00007fff7b0b9562 libsystem_kernel.dylib`__workq_kernreturn + 10
  thread #17: tid = 0x2405bc, 0x00007fff7b0b9562 libsystem_kernel.dylib`__workq_kernreturn + 10
  thread #18: tid = 0x2405bd, 0x00007fff7b0b9562 libsystem_kernel.dylib`__workq_kernreturn + 10
  thread #19: tid = 0x2405cb, 0x00007fff7b0b9562 libsystem_kernel.dylib`__workq_kernreturn + 10



(lldb) thread backtrace
* thread #1, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=1, address=0x0)
  * frame #0: 0x000000010017ad9c Emacs`-[EmacsApp sendEvent:] + 110
    frame #1: 0x00007fff50c29d9d AppKit`-[NSApplication run] + 812
    frame #2: 0x000000010017ac4c Emacs`-[EmacsApp run] + 373
    frame #3: 0x0000000100185d16 Emacs`ns_read_socket + 536
    frame #4: 0x00000001000a7018 Emacs`gobble_input + 234
    frame #5: 0x00000001000ac6d4 Emacs`process_pending_signals + 19
    frame #6: 0x00000001000e89c9 Emacs`re_match_2_internal + 14741
    frame #7: 0x00000001000e4ff0 Emacs`re_search_2 + 2934
    frame #8: 0x00000001000e4474 Emacs`re_search + 40
    frame #9: 0x00000001000cc4f2 Emacs`Ffind_file_name_handler + 194
    frame #10: 0x00000001000cdd8b Emacs`Fexpand_file_name + 230
    frame #11: 0x000000010012a229 Emacs`openp + 442
    frame #12: 0x00000001001298b4 Emacs`Fload + 346
    frame #13: 0x000000010010c79b Emacs`Fautoload_do_load + 277
    frame #14: 0x000000010010dfe1 Emacs`Ffuncall + 332
    frame #15: 0x000000010010e31b Emacs`funcall_nil + 9
    frame #16: 0x000000010010e2e2 Emacs`run_hook_with_args + 265
    frame #17: 0x000000010010e189 Emacs`Frun_hooks + 60
    frame #18: 0x000000010010e123 Emacs`Ffuncall + 654
    frame #19: 0x000000010010ddae Emacs`Fapply + 651
    frame #20: 0x000000010010e123 Emacs`Ffuncall + 654
    frame #21: 0x0000000100144643 Emacs`exec_byte_code + 1585
    frame #22: 0x000000010010e0c8 Emacs`Ffuncall + 563
    frame #23: 0x0000000100144643 Emacs`exec_byte_code + 1585
    frame #24: 0x000000010010e0c8 Emacs`Ffuncall + 563
    frame #25: 0x0000000100144643 Emacs`exec_byte_code + 1585
    frame #26: 0x000000010010e0c8 Emacs`Ffuncall + 563
    frame #27: 0x0000000100144643 Emacs`exec_byte_code + 1585
    frame #28: 0x000000010010e0c8 Emacs`Ffuncall + 563
    frame #29: 0x0000000100144643 Emacs`exec_byte_code + 1585
    frame #30: 0x000000010010e0c8 Emacs`Ffuncall + 563
    frame #31: 0x0000000100144643 Emacs`exec_byte_code + 1585
    frame #32: 0x000000010010e0c8 Emacs`Ffuncall + 563
    frame #33: 0x0000000100144643 Emacs`exec_byte_code + 1585
    frame #34: 0x000000010010e0c8 Emacs`Ffuncall + 563
    frame #35: 0x0000000100144643 Emacs`exec_byte_code + 1585
    frame #36: 0x000000010010e0c8 Emacs`Ffuncall + 563
    frame #37: 0x0000000100144643 Emacs`exec_byte_code + 1585
    frame #38: 0x000000010010e0c8 Emacs`Ffuncall + 563
    frame #39: 0x0000000100144643 Emacs`exec_byte_code + 1585
    frame #40: 0x000000010010da97 Emacs`apply_lambda + 363
    frame #41: 0x000000010010b2ea Emacs`eval_sub + 842
    frame #42: 0x000000010010ee30 Emacs`funcall_lambda + 760
    frame #43: 0x000000010010e0c8 Emacs`Ffuncall + 563
    frame #44: 0x000000010010906a Emacs`Ffuncall_interactively + 70
    frame #45: 0x000000010010e123 Emacs`Ffuncall + 654
    frame #46: 0x0000000100109536 Emacs`Fcall_interactively + 1207
    frame #47: 0x000000010010ea2a Emacs`funcall_subr + 275
    frame #48: 0x000000010010e123 Emacs`Ffuncall + 654
    frame #49: 0x0000000100144643 Emacs`exec_byte_code + 1585
    frame #50: 0x000000010010e0c8 Emacs`Ffuncall + 563
    frame #51: 0x000000010010e658 Emacs`call1 + 46
    frame #52: 0x00000001000a4985 Emacs`command_loop_1 + 1340
    frame #53: 0x000000010010cd38 Emacs`internal_condition_case + 82
    frame #54: 0x00000001000b0c4f Emacs`command_loop_2 + 37
    frame #55: 0x000000010010c8dd Emacs`internal_catch + 73
    frame #56: 0x00000001000a3d37 Emacs`command_loop + 156
    frame #57: 0x00000001000a3c55 Emacs`recursive_edit_1 + 111
    frame #58: 0x00000001000a3e77 Emacs`Frecursive_edit + 228
    frame #59: 0x00000001000a2cdc Emacs`main + 5211
    frame #60: 0x00007fff7af69115 libdyld.dylib`start + 1


In GNU Emacs 26.0.91 (build 1, x86_64-apple-darwin17.4.0, NS appkit-1561.20 Version 10.13.3 (Build 17D102))
 of 2018-03-09 built on aaron-mbt.local
Repository revision: fbc7f9ae44a2a705e37cb7d1f9585cfaac8d13ee
Windowing system distributor 'Apple', version 10.3.1561
Recent messages:
/Users/aaronjensen/.emacs.d/.cache/personal.org
Decrypting /Users/aaronjensen/Dropbox (Personal)/Notes/Layer.org.gpg...done
Added 1 event for today
Saving file /Users/aaronjensen/.emacs.d/.cache/work.org...
Wrote /Users/aaronjensen/.emacs.d/.cache/work.org
Fetched data overwrote
/Users/aaronjensen/.emacs.d/.cache/work.org
Decrypting /Users/aaronjensen/Dropbox (Personal)/Notes/Layer.org.gpg...done
Added 1 event for today
Mark saved where search started [2 times]

Configured using:
 'configure --disable-dependency-tracking --disable-silent-rules
 --enable-locallisppath=/usr/local/share/emacs/site-lisp
 --infodir=/usr/local/Cellar/emacs-plus/HEAD-fbc7f9a/share/info/emacs
 --prefix=/usr/local/Cellar/emacs-plus/HEAD-fbc7f9a --with-xml2
 --without-dbus --with-gnutls --with-imagemagick --with-modules
 --with-rsvg --with-ns --disable-ns-self-contained'

Configured features:
JPEG RSVG IMAGEMAGICK NOTIFY ACL GNUTLS LIBXML2 ZLIB TOOLKIT_SCROLL_BARS
NS MODULES THREADS LCMS2

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

Major mode: JSON

Minor modes in effect:
  flycheck-posframe-mode: t
  eros-mode: t
  company-statistics-mode: t
  company-childframe-mode: t
  goto-address-prog-mode: t
  auto-highlight-symbol-mode: t
  dtrt-indent-mode: t
  highlight-numbers-mode: t
  highlight-parentheses-mode: t
  rainbow-delimiters-mode: t
  yas-global-mode: t
  yas-minor-mode: t
  bug-reference-prog-mode: t
  magit-auto-revert-mode: t
  auto-dim-other-buffers-mode: t
  global-git-gutter+-mode: t
  git-gutter+-mode: t
  global-git-commit-mode: t
  async-bytecomp-package-mode: t
  recentf-mode: t
  desktop-save-mode: t
  global-wakatime-mode: t
  wakatime-mode: t
  evil-mc-mode: t
  hl-todo-mode: t
  global-spacemacs-whitespace-cleanup-mode: t
  spacemacs-whitespace-cleanup-mode: t
  ws-butler-global-mode: t
  ws-butler-mode: t
  winum-mode: t
  winner-mode: t
  pupo-mode: t
  purpose-mode: t
  volatile-highlights-mode: t
  global-vi-tilde-fringe-mode: t
  vi-tilde-fringe-mode: t
  save-place-mode: t
  savehist-mode: t
  projectile-rails-global-mode: t
  projectile-mode: t
  persp-mode: t
  global-origami-mode: t
  origami-mode: t
  Info-breadcrumbs-in-mode-line-mode: t
  flycheck-pos-tip-mode: t
  global-flycheck-mode: t
  flycheck-mode: t
  flx-ido-mode: t
  eyebrowse-mode: t
  global-evil-surround-mode: t
  evil-surround-mode: t
  global-evil-search-highlight-persist: t
  evil-search-highlight-persist: t
  show-smartparens-global-mode: t
  show-smartparens-mode: t
  smartparens-mode: t
  evil-lion-mode: t
  evil-escape-mode: t
  global-anzu-mode: t
  anzu-mode: t
  eval-sexp-fu-flash-mode: t
  editorconfig-mode: t
  diff-auto-refine-mode: t
  counsel-mode: t
  ivy-mode: t
  delete-selection-mode: t
  clean-aindent-mode: t
  hybrid-mode: t
  which-key-mode: t
  override-global-mode: t
  global-undo-tree-mode: t
  undo-tree-mode: t
  evil-mode: t
  evil-local-mode: t
  spacemacs-leader-override-mode: t
  global-spacemacs-leader-override-mode: t
  global-hl-line-mode: t
  xterm-mouse-mode: t
  global-auto-revert-mode: t
  auto-revert-mode: t
  shell-dirtrack-mode: t
  ido-vertical-mode: t
  global-page-break-lines-mode: t
  global-eldoc-mode: t
  electric-indent-mode: t
  mouse-wheel-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  column-number-mode: t
  line-number-mode: t
  transient-mark-mode: t
  abbrev-mode: t
  hs-minor-mode: t

Load-path shadows:
/Users/aaronjensen/.emacs.d/elpa/26.0/develop/ht-20180129.1434/ht hides /Users/aaronjensen/.emacs.d/core/libs/ht
/Users/aaronjensen/.emacs.d/elpa/26.0/develop/inf-ruby-20180309.433/inf-ruby hides /usr/local/share/emacs/site-lisp/ruby/inf-ruby
/Users/aaronjensen/.emacs.d/elpa/26.0/develop/org-plus-contrib-20180312/ob-stan hides /usr/local/Cellar/emacs-plus/HEAD-fbc7f9a/share/emacs/26.0.91/lisp/org/ob-stan
/Users/aaronjensen/.emacs.d/elpa/26.0/develop/org-plus-contrib-20180312/ob-exp hides /usr/local/Cellar/emacs-plus/HEAD-fbc7f9a/share/emacs/26.0.91/lisp/org/ob-exp
/Users/aaronjensen/.emacs.d/elpa/26.0/develop/org-plus-contrib-20180312/ob-J hides /usr/local/Cellar/emacs-plus/HEAD-fbc7f9a/share/emacs/26.0.91/lisp/org/ob-J
/Users/aaronjensen/.emacs.d/elpa/26.0/develop/org-plus-contrib-20180312/org-eshell hides /usr/local/Cellar/emacs-plus/HEAD-fbc7f9a/share/emacs/26.0.91/lisp/org/org-eshell
/Users/aaronjensen/.emacs.d/elpa/26.0/develop/org-plus-contrib-20180312/ob-emacs-lisp hides /usr/local/Cellar/emacs-plus/HEAD-fbc7f9a/share/emacs/26.0.91/lisp/org/ob-emacs-lisp
/Users/aaronjensen/.emacs.d/elpa/26.0/develop/org-plus-contrib-20180312/org-gnus hides /usr/local/Cellar/emacs-plus/HEAD-fbc7f9a/share/emacs/26.0.91/lisp/org/org-gnus
/Users/aaronjensen/.emacs.d/elpa/26.0/develop/org-plus-contrib-20180312/ob-css hides /usr/local/Cellar/emacs-plus/HEAD-fbc7f9a/share/emacs/26.0.91/lisp/org/ob-css
/Users/aaronjensen/.emacs.d/elpa/26.0/develop/org-plus-contrib-20180312/ob-lob hides /usr/local/Cellar/emacs-plus/HEAD-fbc7f9a/share/emacs/26.0.91/lisp/org/ob-lob
/Users/aaronjensen/.emacs.d/elpa/26.0/develop/org-plus-contrib-20180312/ob-forth hides /usr/local/Cellar/emacs-plus/HEAD-fbc7f9a/share/emacs/26.0.91/lisp/org/ob-forth
/Users/aaronjensen/.emacs.d/elpa/26.0/develop/org-plus-contrib-20180312/org-macs hides /usr/local/Cellar/emacs-plus/HEAD-fbc7f9a/share/emacs/26.0.91/lisp/org/org-macs
/Users/aaronjensen/.emacs.d/elpa/26.0/develop/org-plus-contrib-20180312/ob hides /usr/local/Cellar/emacs-plus/HEAD-fbc7f9a/share/emacs/26.0.91/lisp/org/ob
/Users/aaronjensen/.emacs.d/elpa/26.0/develop/org-plus-contrib-20180312/org-version hides /usr/local/Cellar/emacs-plus/HEAD-fbc7f9a/share/emacs/26.0.91/lisp/org/org-version
/Users/aaronjensen/.emacs.d/elpa/26.0/develop/org-plus-contrib-20180312/ob-scheme hides /usr/local/Cellar/emacs-plus/HEAD-fbc7f9a/share/emacs/26.0.91/lisp/org/ob-scheme
/Users/aaronjensen/.emacs.d/elpa/26.0/develop/org-plus-contrib-20180312/ox hides /usr/local/Cellar/emacs-plus/HEAD-fbc7f9a/share/emacs/26.0.91/lisp/org/ox
/Users/aaronjensen/.emacs.d/elpa/26.0/develop/org-plus-contrib-20180312/ob-abc hides /usr/local/Cellar/emacs-plus/HEAD-fbc7f9a/share/emacs/26.0.91/lisp/org/ob-abc
/Users/aaronjensen/.emacs.d/elpa/26.0/develop/org-plus-contrib-20180312/ob-C hides /usr/local/Cellar/emacs-plus/HEAD-fbc7f9a/share/emacs/26.0.91/lisp/org/ob-C
/Users/aaronjensen/.emacs.d/elpa/26.0/develop/org-plus-contrib-20180312/org-capture hides /usr/local/Cellar/emacs-plus/HEAD-fbc7f9a/share/emacs/26.0.91/lisp/org/org-capture
/Users/aaronjensen/.emacs.d/elpa/26.0/develop/org-plus-contrib-20180312/ob-ref hides /usr/local/Cellar/emacs-plus/HEAD-fbc7f9a/share/emacs/26.0.91/lisp/org/ob-ref
/Users/aaronjensen/.emacs.d/elpa/26.0/develop/org-plus-contrib-20180312/ob-clojure hides /usr/local/Cellar/emacs-plus/HEAD-fbc7f9a/share/emacs/26.0.91/lisp/org/ob-clojure
/Users/aaronjensen/.emacs.d/elpa/26.0/develop/org-plus-contrib-20180312/org-mouse hides /usr/local/Cellar/emacs-plus/HEAD-fbc7f9a/share/emacs/26.0.91/lisp/org/org-mouse
/Users/aaronjensen/.emacs.d/elpa/26.0/develop/org-plus-contrib-20180312/ob-ledger hides /usr/local/Cellar/emacs-plus/HEAD-fbc7f9a/share/emacs/26.0.91/lisp/org/ob-ledger
/Users/aaronjensen/.emacs.d/elpa/26.0/develop/org-plus-contrib-20180312/org-ctags hides /usr/local/Cellar/emacs-plus/HEAD-fbc7f9a/share/emacs/26.0.91/lisp/org/org-ctags
/Users/aaronjensen/.emacs.d/elpa/26.0/develop/org-plus-contrib-20180312/org-entities hides /usr/local/Cellar/emacs-plus/HEAD-fbc7f9a/share/emacs/26.0.91/lisp/org/org-entities
/Users/aaronjensen/.emacs.d/elpa/26.0/develop/org-plus-contrib-20180312/org-archive hides /usr/local/Cellar/emacs-plus/HEAD-fbc7f9a/share/emacs/26.0.91/lisp/org/org-archive
/Users/aaronjensen/.emacs.d/elpa/26.0/develop/org-plus-contrib-20180312/ob-screen hides /usr/local/Cellar/emacs-plus/HEAD-fbc7f9a/share/emacs/26.0.91/lisp/org/ob-screen
/Users/aaronjensen/.emacs.d/elpa/26.0/develop/org-plus-contrib-20180312/ob-haskell hides /usr/local/Cellar/emacs-plus/HEAD-fbc7f9a/share/emacs/26.0.91/lisp/org/ob-haskell
/Users/aaronjensen/.emacs.d/elpa/26.0/develop/org-plus-contrib-20180312/ob-asymptote hides /usr/local/Cellar/emacs-plus/HEAD-fbc7f9a/share/emacs/26.0.91/lisp/org/ob-asymptote
/Users/aaronjensen/.emacs.d/elpa/26.0/develop/org-plus-contrib-20180312/org-mhe hides /usr/local/Cellar/emacs-plus/HEAD-fbc7f9a/share/emacs/26.0.91/lisp/org/org-mhe
/Users/aaronjensen/.emacs.d/elpa/26.0/develop/org-plus-contrib-20180312/org-table hides /usr/local/Cellar/emacs-plus/HEAD-fbc7f9a/share/emacs/26.0.91/lisp/org/org-table
/Users/aaronjensen/.emacs.d/elpa/26.0/develop/org-plus-contrib-20180312/ob-keys hides /usr/local/Cellar/emacs-plus/HEAD-fbc7f9a/share/emacs/26.0.91/lisp/org/ob-keys
/Users/aaronjensen/.emacs.d/elpa/26.0/develop/org-plus-contrib-20180312/ox-org hides /usr/local/Cellar/emacs-plus/HEAD-fbc7f9a/share/emacs/26.0.91/lisp/org/ox-org
/Users/aaronjensen/.emacs.d/elpa/26.0/develop/org-plus-contrib-20180312/org-plot hides /usr/local/Cellar/emacs-plus/HEAD-fbc7f9a/share/emacs/26.0.91/lisp/org/org-plot
/Users/aaronjensen/.emacs.d/elpa/26.0/develop/org-plus-contrib-20180312/ob-awk hides /usr/local/Cellar/emacs-plus/HEAD-fbc7f9a/share/emacs/26.0.91/lisp/org/ob-awk
/Users/aaronjensen/.emacs.d/elpa/26.0/develop/org-plus-contrib-20180312/ob-groovy hides /usr/local/Cellar/emacs-plus/HEAD-fbc7f9a/share/emacs/26.0.91/lisp/org/ob-groovy
/Users/aaronjensen/.emacs.d/elpa/26.0/develop/org-plus-contrib-20180312/ob-octave hides /usr/local/Cellar/emacs-plus/HEAD-fbc7f9a/share/emacs/26.0.91/lisp/org/ob-octave
/Users/aaronjensen/.emacs.d/elpa/26.0/develop/org-plus-contrib-20180312/org-faces hides /usr/local/Cellar/emacs-plus/HEAD-fbc7f9a/share/emacs/26.0.91/lisp/org/org-faces
/Users/aaronjensen/.emacs.d/elpa/26.0/develop/org-plus-contrib-20180312/org-colview hides /usr/local/Cellar/emacs-plus/HEAD-fbc7f9a/share/emacs/26.0.91/lisp/org/org-colview
/Users/aaronjensen/.emacs.d/elpa/26.0/develop/org-plus-contrib-20180312/ob-R hides /usr/local/Cellar/emacs-plus/HEAD-fbc7f9a/share/emacs/26.0.91/lisp/org/ob-R
/Users/aaronjensen/.emacs.d/elpa/26.0/develop/org-plus-contrib-20180312/org-timer hides /usr/local/Cellar/emacs-plus/HEAD-fbc7f9a/share/emacs/26.0.91/lisp/org/org-timer
/Users/aaronjensen/.emacs.d/elpa/26.0/develop/org-plus-contrib-20180312/ob-ebnf hides /usr/local/Cellar/emacs-plus/HEAD-fbc7f9a/share/emacs/26.0.91/lisp/org/ob-ebnf
/Users/aaronjensen/.emacs.d/elpa/26.0/develop/org-plus-contrib-20180312/org-mobile hides /usr/local/Cellar/emacs-plus/HEAD-fbc7f9a/share/emacs/26.0.91/lisp/org/org-mobile
/Users/aaronjensen/.emacs.d/elpa/26.0/develop/org-plus-contrib-20180312/ob-fortran hides /usr/local/Cellar/emacs-plus/HEAD-fbc7f9a/share/emacs/26.0.91/lisp/org/ob-fortran
/Users/aaronjensen/.emacs.d/elpa/26.0/develop/org-plus-contrib-20180312/ob-shell hides /usr/local/Cellar/emacs-plus/HEAD-fbc7f9a/share/emacs/26.0.91/lisp/org/ob-shell
/Users/aaronjensen/.emacs.d/elpa/26.0/develop/org-plus-contrib-20180312/ob-perl hides /usr/local/Cellar/emacs-plus/HEAD-fbc7f9a/share/emacs/26.0.91/lisp/org/ob-perl
/Users/aaronjensen/.emacs.d/elpa/26.0/develop/org-plus-contrib-20180312/ob-sqlite hides /usr/local/Cellar/emacs-plus/HEAD-fbc7f9a/share/emacs/26.0.91/lisp/org/ob-sqlite
/Users/aaronjensen/.emacs.d/elpa/26.0/develop/org-plus-contrib-20180312/ob-sed hides /usr/local/Cellar/emacs-plus/HEAD-fbc7f9a/share/emacs/26.0.91/lisp/org/ob-sed
/Users/aaronjensen/.emacs.d/elpa/26.0/develop/org-plus-contrib-20180312/org-list hides /usr/local/Cellar/emacs-plus/HEAD-fbc7f9a/share/emacs/26.0.91/lisp/org/org-list
/Users/aaronjensen/.emacs.d/elpa/26.0/develop/org-plus-contrib-20180312/ob-ruby hides /usr/local/Cellar/emacs-plus/HEAD-fbc7f9a/share/emacs/26.0.91/lisp/org/ob-ruby
/Users/aaronjensen/.emacs.d/elpa/26.0/develop/org-plus-contrib-20180312/ob-eval hides /usr/local/Cellar/emacs-plus/HEAD-fbc7f9a/share/emacs/26.0.91/lisp/org/ob-eval
/Users/aaronjensen/.emacs.d/elpa/26.0/develop/org-plus-contrib-20180312/org-habit hides /usr/local/Cellar/emacs-plus/HEAD-fbc7f9a/share/emacs/26.0.91/lisp/org/org-habit
/Users/aaronjensen/.emacs.d/elpa/26.0/develop/org-plus-contrib-20180312/org-clock hides /usr/local/Cellar/emacs-plus/HEAD-fbc7f9a/share/emacs/26.0.91/lisp/org/org-clock
/Users/aaronjensen/.emacs.d/elpa/26.0/develop/org-plus-contrib-20180312/ox-html hides /usr/local/Cellar/emacs-plus/HEAD-fbc7f9a/share/emacs/26.0.91/lisp/org/ox-html
/Users/aaronjensen/.emacs.d/elpa/26.0/develop/org-plus-contrib-20180312/org-src hides /usr/local/Cellar/emacs-plus/HEAD-fbc7f9a/share/emacs/26.0.91/lisp/org/org-src
/Users/aaronjensen/.emacs.d/elpa/26.0/develop/org-plus-contrib-20180312/ob-lisp hides /usr/local/Cellar/emacs-plus/HEAD-fbc7f9a/share/emacs/26.0.91/lisp/org/ob-lisp
/Users/aaronjensen/.emacs.d/elpa/26.0/develop/org-plus-contrib-20180312/ob-ditaa hides /usr/local/Cellar/emacs-plus/HEAD-fbc7f9a/share/emacs/26.0.91/lisp/org/ob-ditaa
/Users/aaronjensen/.emacs.d/elpa/26.0/develop/org-plus-contrib-20180312/org-pcomplete hides /usr/local/Cellar/emacs-plus/HEAD-fbc7f9a/share/emacs/26.0.91/lisp/org/org-pcomplete
/Users/aaronjensen/.emacs.d/elpa/26.0/develop/org-plus-contrib-20180312/org-lint hides /usr/local/Cellar/emacs-plus/HEAD-fbc7f9a/share/emacs/26.0.91/lisp/org/org-lint
/Users/aaronjensen/.emacs.d/elpa/26.0/develop/org-plus-contrib-20180312/org-rmail hides /usr/local/Cellar/emacs-plus/HEAD-fbc7f9a/share/emacs/26.0.91/lisp/org/org-rmail
/Users/aaronjensen/.emacs.d/elpa/26.0/develop/org-plus-contrib-20180312/ox-latex hides /usr/local/Cellar/emacs-plus/HEAD-fbc7f9a/share/emacs/26.0.91/lisp/org/ox-latex
/Users/aaronjensen/.emacs.d/elpa/26.0/develop/org-plus-contrib-20180312/ob-sass hides /usr/local/Cellar/emacs-plus/HEAD-fbc7f9a/share/emacs/26.0.91/lisp/org/ob-sass
/Users/aaronjensen/.emacs.d/elpa/26.0/develop/org-plus-contrib-20180312/ob-io hides /usr/local/Cellar/emacs-plus/HEAD-fbc7f9a/share/emacs/26.0.91/lisp/org/ob-io
/Users/aaronjensen/.emacs.d/elpa/26.0/develop/org-plus-contrib-20180312/ob-tangle hides /usr/local/Cellar/emacs-plus/HEAD-fbc7f9a/share/emacs/26.0.91/lisp/org/ob-tangle
/Users/aaronjensen/.emacs.d/elpa/26.0/develop/org-plus-contrib-20180312/ob-calc hides /usr/local/Cellar/emacs-plus/HEAD-fbc7f9a/share/emacs/26.0.91/lisp/org/ob-calc
/Users/aaronjensen/.emacs.d/elpa/26.0/develop/org-plus-contrib-20180312/ob-java hides /usr/local/Cellar/emacs-plus/HEAD-fbc7f9a/share/emacs/26.0.91/lisp/org/ob-java
/Users/aaronjensen/.emacs.d/elpa/26.0/develop/org-plus-contrib-20180312/ox-icalendar hides /usr/local/Cellar/emacs-plus/HEAD-fbc7f9a/share/emacs/26.0.91/lisp/org/ox-icalendar
/Users/aaronjensen/.emacs.d/elpa/26.0/develop/org-plus-contrib-20180312/org-eww hides /usr/local/Cellar/emacs-plus/HEAD-fbc7f9a/share/emacs/26.0.91/lisp/org/org-eww
/Users/aaronjensen/.emacs.d/elpa/26.0/develop/org-plus-contrib-20180312/ox-md hides /usr/local/Cellar/emacs-plus/HEAD-fbc7f9a/share/emacs/26.0.91/lisp/org/ox-md
/Users/aaronjensen/.emacs.d/elpa/26.0/develop/org-plus-contrib-20180312/ox-beamer hides /usr/local/Cellar/emacs-plus/HEAD-fbc7f9a/share/emacs/26.0.91/lisp/org/ox-beamer
/Users/aaronjensen/.emacs.d/elpa/26.0/develop/org-plus-contrib-20180312/org-element hides /usr/local/Cellar/emacs-plus/HEAD-fbc7f9a/share/emacs/26.0.91/lisp/org/org-element
/Users/aaronjensen/.emacs.d/elpa/26.0/develop/org-plus-contrib-20180312/org-protocol hides /usr/local/Cellar/emacs-plus/HEAD-fbc7f9a/share/emacs/26.0.91/lisp/org/org-protocol
/Users/aaronjensen/.emacs.d/elpa/26.0/develop/org-plus-contrib-20180312/ob-mscgen hides /usr/local/Cellar/emacs-plus/HEAD-fbc7f9a/share/emacs/26.0.91/lisp/org/ob-mscgen
/Users/aaronjensen/.emacs.d/elpa/26.0/develop/org-plus-contrib-20180312/ob-gnuplot hides /usr/local/Cellar/emacs-plus/HEAD-fbc7f9a/share/emacs/26.0.91/lisp/org/ob-gnuplot
/Users/aaronjensen/.emacs.d/elpa/26.0/develop/org-plus-contrib-20180312/ob-latex hides /usr/local/Cellar/emacs-plus/HEAD-fbc7f9a/share/emacs/26.0.91/lisp/org/ob-latex
/Users/aaronjensen/.emacs.d/elpa/26.0/develop/org-plus-contrib-20180312/org-id hides /usr/local/Cellar/emacs-plus/HEAD-fbc7f9a/share/emacs/26.0.91/lisp/org/org-id
/Users/aaronjensen/.emacs.d/elpa/26.0/develop/org-plus-contrib-20180312/ob-vala hides /usr/local/Cellar/emacs-plus/HEAD-fbc7f9a/share/emacs/26.0.91/lisp/org/ob-vala
/Users/aaronjensen/.emacs.d/elpa/26.0/develop/org-plus-contrib-20180312/ox-man hides /usr/local/Cellar/emacs-plus/HEAD-fbc7f9a/share/emacs/26.0.91/lisp/org/ox-man
/Users/aaronjensen/.emacs.d/elpa/26.0/develop/org-plus-contrib-20180312/org-feed hides /usr/local/Cellar/emacs-plus/HEAD-fbc7f9a/share/emacs/26.0.91/lisp/org/org-feed
/Users/aaronjensen/.emacs.d/elpa/26.0/develop/org-plus-contrib-20180312/ob-lua hides /usr/local/Cellar/emacs-plus/HEAD-fbc7f9a/share/emacs/26.0.91/lisp/org/ob-lua
/Users/aaronjensen/.emacs.d/elpa/26.0/develop/org-plus-contrib-20180312/ob-table hides /usr/local/Cellar/emacs-plus/HEAD-fbc7f9a/share/emacs/26.0.91/lisp/org/ob-table
/Users/aaronjensen/.emacs.d/elpa/26.0/develop/org-plus-contrib-20180312/ob-ocaml hides /usr/local/Cellar/emacs-plus/HEAD-fbc7f9a/share/emacs/26.0.91/lisp/org/ob-ocaml
/Users/aaronjensen/.emacs.d/elpa/26.0/develop/org-plus-contrib-20180312/ob-coq hides /usr/local/Cellar/emacs-plus/HEAD-fbc7f9a/share/emacs/26.0.91/lisp/org/ob-coq
/Users/aaronjensen/.emacs.d/elpa/26.0/develop/org-plus-contrib-20180312/ob-picolisp hides /usr/local/Cellar/emacs-plus/HEAD-fbc7f9a/share/emacs/26.0.91/lisp/org/ob-picolisp
/Users/aaronjensen/.emacs.d/elpa/26.0/develop/org-plus-contrib-20180312/org-indent hides /usr/local/Cellar/emacs-plus/HEAD-fbc7f9a/share/emacs/26.0.91/lisp/org/org-indent
/Users/aaronjensen/.emacs.d/elpa/26.0/develop/org-plus-contrib-20180312/ob-lilypond hides /usr/local/Cellar/emacs-plus/HEAD-fbc7f9a/share/emacs/26.0.91/lisp/org/ob-lilypond
/Users/aaronjensen/.emacs.d/elpa/26.0/develop/org-plus-contrib-20180312/ob-matlab hides /usr/local/Cellar/emacs-plus/HEAD-fbc7f9a/share/emacs/26.0.91/lisp/org/ob-matlab
/Users/aaronjensen/.emacs.d/elpa/26.0/develop/org-plus-contrib-20180312/org-datetree hides /usr/local/Cellar/emacs-plus/HEAD-fbc7f9a/share/emacs/26.0.91/lisp/org/org-datetree
/Users/aaronjensen/.emacs.d/elpa/26.0/develop/org-plus-contrib-20180312/ob-python hides /usr/local/Cellar/emacs-plus/HEAD-fbc7f9a/share/emacs/26.0.91/lisp/org/ob-python
/Users/aaronjensen/.emacs.d/elpa/26.0/develop/org-plus-contrib-20180312/org-bbdb hides /usr/local/Cellar/emacs-plus/HEAD-fbc7f9a/share/emacs/26.0.91/lisp/org/org-bbdb
/Users/aaronjensen/.emacs.d/elpa/26.0/develop/org-plus-contrib-20180312/ob-makefile hides /usr/local/Cellar/emacs-plus/HEAD-fbc7f9a/share/emacs/26.0.91/lisp/org/ob-makefile
/Users/aaronjensen/.emacs.d/elpa/26.0/develop/org-plus-contrib-20180312/org-duration hides /usr/local/Cellar/emacs-plus/HEAD-fbc7f9a/share/emacs/26.0.91/lisp/org/org-duration
/Users/aaronjensen/.emacs.d/elpa/26.0/develop/org-plus-contrib-20180312/org-agenda hides /usr/local/Cellar/emacs-plus/HEAD-fbc7f9a/share/emacs/26.0.91/lisp/org/org-agenda
/Users/aaronjensen/.emacs.d/elpa/26.0/develop/org-plus-contrib-20180312/ob-dot hides /usr/local/Cellar/emacs-plus/HEAD-fbc7f9a/share/emacs/26.0.91/lisp/org/ob-dot
/Users/aaronjensen/.emacs.d/elpa/26.0/develop/org-plus-contrib-20180312/ob-js hides /usr/local/Cellar/emacs-plus/HEAD-fbc7f9a/share/emacs/26.0.91/lisp/org/ob-js
/Users/aaronjensen/.emacs.d/elpa/26.0/develop/org-plus-contrib-20180312/ox-publish hides /usr/local/Cellar/emacs-plus/HEAD-fbc7f9a/share/emacs/26.0.91/lisp/org/ox-publish
/Users/aaronjensen/.emacs.d/elpa/26.0/develop/org-plus-contrib-20180312/org-inlinetask hides /usr/local/Cellar/emacs-plus/HEAD-fbc7f9a/share/emacs/26.0.91/lisp/org/org-inlinetask
/Users/aaronjensen/.emacs.d/elpa/26.0/develop/org-plus-contrib-20180312/ob-org hides /usr/local/Cellar/emacs-plus/HEAD-fbc7f9a/share/emacs/26.0.91/lisp/org/ob-org
/Users/aaronjensen/.emacs.d/elpa/26.0/develop/org-plus-contrib-20180312/ob-core hides /usr/local/Cellar/emacs-plus/HEAD-fbc7f9a/share/emacs/26.0.91/lisp/org/ob-core
/Users/aaronjensen/.emacs.d/elpa/26.0/develop/org-plus-contrib-20180312/org-compat hides /usr/local/Cellar/emacs-plus/HEAD-fbc7f9a/share/emacs/26.0.91/lisp/org/org-compat
/Users/aaronjensen/.emacs.d/elpa/26.0/develop/org-plus-contrib-20180312/org-docview hides /usr/local/Cellar/emacs-plus/HEAD-fbc7f9a/share/emacs/26.0.91/lisp/org/org-docview
/Users/aaronjensen/.emacs.d/elpa/26.0/develop/org-plus-contrib-20180312/ox-odt hides /usr/local/Cellar/emacs-plus/HEAD-fbc7f9a/share/emacs/26.0.91/lisp/org/ox-odt
/Users/aaronjensen/.emacs.d/elpa/26.0/develop/org-plus-contrib-20180312/ob-plantuml hides /usr/local/Cellar/emacs-plus/HEAD-fbc7f9a/share/emacs/26.0.91/lisp/org/ob-plantuml
/Users/aaronjensen/.emacs.d/elpa/26.0/develop/org-plus-contrib-20180312/ox-ascii hides /usr/local/Cellar/emacs-plus/HEAD-fbc7f9a/share/emacs/26.0.91/lisp/org/ox-ascii
/Users/aaronjensen/.emacs.d/elpa/26.0/develop/org-plus-contrib-20180312/org-loaddefs hides /usr/local/Cellar/emacs-plus/HEAD-fbc7f9a/share/emacs/26.0.91/lisp/org/org-loaddefs
/Users/aaronjensen/.emacs.d/elpa/26.0/develop/org-plus-contrib-20180312/org-w3m hides /usr/local/Cellar/emacs-plus/HEAD-fbc7f9a/share/emacs/26.0.91/lisp/org/org-w3m
/Users/aaronjensen/.emacs.d/elpa/26.0/develop/org-plus-contrib-20180312/org-bibtex hides /usr/local/Cellar/emacs-plus/HEAD-fbc7f9a/share/emacs/26.0.91/lisp/org/org-bibtex
/Users/aaronjensen/.emacs.d/elpa/26.0/develop/org-plus-contrib-20180312/org-info hides /usr/local/Cellar/emacs-plus/HEAD-fbc7f9a/share/emacs/26.0.91/lisp/org/org-info
/Users/aaronjensen/.emacs.d/elpa/26.0/develop/org-plus-contrib-20180312/ob-hledger hides /usr/local/Cellar/emacs-plus/HEAD-fbc7f9a/share/emacs/26.0.91/lisp/org/ob-hledger
/Users/aaronjensen/.emacs.d/elpa/26.0/develop/org-plus-contrib-20180312/ob-maxima hides /usr/local/Cellar/emacs-plus/HEAD-fbc7f9a/share/emacs/26.0.91/lisp/org/ob-maxima
/Users/aaronjensen/.emacs.d/elpa/26.0/develop/org-plus-contrib-20180312/org hides /usr/local/Cellar/emacs-plus/HEAD-fbc7f9a/share/emacs/26.0.91/lisp/org/org
/Users/aaronjensen/.emacs.d/elpa/26.0/develop/org-plus-contrib-20180312/org-macro hides /usr/local/Cellar/emacs-plus/HEAD-fbc7f9a/share/emacs/26.0.91/lisp/org/org-macro
/Users/aaronjensen/.emacs.d/elpa/26.0/develop/org-plus-contrib-20180312/ob-sql hides /usr/local/Cellar/emacs-plus/HEAD-fbc7f9a/share/emacs/26.0.91/lisp/org/ob-sql
/Users/aaronjensen/.emacs.d/elpa/26.0/develop/org-plus-contrib-20180312/org-attach hides /usr/local/Cellar/emacs-plus/HEAD-fbc7f9a/share/emacs/26.0.91/lisp/org/org-attach
/Users/aaronjensen/.emacs.d/elpa/26.0/develop/org-plus-contrib-20180312/ob-processing hides /usr/local/Cellar/emacs-plus/HEAD-fbc7f9a/share/emacs/26.0.91/lisp/org/ob-processing
/Users/aaronjensen/.emacs.d/elpa/26.0/develop/org-plus-contrib-20180312/ox-texinfo hides /usr/local/Cellar/emacs-plus/HEAD-fbc7f9a/share/emacs/26.0.91/lisp/org/ox-texinfo
/Users/aaronjensen/.emacs.d/elpa/26.0/develop/org-plus-contrib-20180312/org-irc hides /usr/local/Cellar/emacs-plus/HEAD-fbc7f9a/share/emacs/26.0.91/lisp/org/org-irc
/Users/aaronjensen/.emacs.d/elpa/26.0/develop/org-plus-contrib-20180312/org-crypt hides /usr/local/Cellar/emacs-plus/HEAD-fbc7f9a/share/emacs/26.0.91/lisp/org/org-crypt
/Users/aaronjensen/.emacs.d/elpa/26.0/develop/org-plus-contrib-20180312/org-footnote hides /usr/local/Cellar/emacs-plus/HEAD-fbc7f9a/share/emacs/26.0.91/lisp/org/org-footnote
/Users/aaronjensen/.emacs.d/elpa/26.0/develop/org-plus-contrib-20180312/org-install hides /usr/local/Cellar/emacs-plus/HEAD-fbc7f9a/share/emacs/26.0.91/lisp/org/org-install
/Users/aaronjensen/.emacs.d/elpa/26.0/develop/org-plus-contrib-20180312/ob-comint hides /usr/local/Cellar/emacs-plus/HEAD-fbc7f9a/share/emacs/26.0.91/lisp/org/ob-comint
/Users/aaronjensen/.emacs.d/elpa/26.0/develop/org-plus-contrib-20180312/ob-shen hides /usr/local/Cellar/emacs-plus/HEAD-fbc7f9a/share/emacs/26.0.91/lisp/org/ob-shen

Features:
(shadow sort mail-extr emacsbug sendmail smex json-mode json-reformat
json-snatcher smartparens-javascript js smartparens-html sgml-mode dom
misearch multi-isearch make-mode magit-bookmark bookmark
flycheck-posframe prettier-js tide tide-lv add-node-modules-path
typescript-mode cc-mode cc-fonts cc-guess cc-menus cc-cmds cc-styles
cc-align cc-engine cc-vars cc-defs counsel-projectile appt diary-lib
diary-loaddefs org-duration epa-file org-agenda pp vc-git org-gcal
org-archive request-deferred deferred request alert log4e notifications
dbus xml gntp overseer auto-compile packed elisp-slime-nav eros
flycheck-package package-lint finder lispyville lispy iedit iedit-lib
multiple-cursors-core lispy-inline avy semantic/db semantic/util-modes
semantic/util semantic semantic/tag semantic/lex semantic/fw mode-local
cedet evil-ediff ediff-merg ediff-wind ediff-diff ediff-mult ediff-help
ediff-init ediff-util ediff edebug lispy-tags nameless shrink-path
open-junk-file company-emoji company-emoji-list org-eldoc evil-org
org-table ob-shell ob-ruby company-lua smartparens-lua lua-mode
company-statistics company-files company-keywords company-capf alchemist
alchemist-macroexpand alchemist-company alchemist-help
alchemist-complete company-dabbrev-code company-dabbrev
alchemist-refcard alchemist-phoenix alchemist-compile alchemist-iex
alchemist-message alchemist-hooks alchemist-hex alchemist-mix
alchemist-info alchemist-goto alchemist-scope alchemist-eval
alchemist-interact alchemist-server alchemist-execute alchemist-report
alchemist-test-mode alchemist-project alchemist-file alchemist-key
alchemist-utils company-childframe posframe company flycheck-dialyxir
flycheck-credo flycheck-dogma smartparens-elixir elixir-mode pkg-info
epl elixir-smie goto-addr auto-highlight-symbol dtrt-indent
highlight-numbers parent-mode highlight-parentheses hideshow
rainbow-delimiters sh-script executable org-bullets org-download toc-org
typo yasnippet-snippets yasnippet elec-pair org-indent image-file
org-rmail org-mhe org-irc org-info org-gnus nnir gnus-sum gnus-group
gnus-undo gnus-start gnus-cloud nnimap nnmail mail-source utf7 netrc
nnoo gnus-spec gnus-int gnus-range gnus-win gnus nnheader org-docview
doc-view jka-compr org-bibtex bibtex org-bbdb org-w3m org-checklist
org-inlinetask smartparens-org ob-elixir ob-http ob-http-mode
ob-restclient restclient ox-gfm ox-md ox-reveal ox-odt rng-loc rng-uri
rng-parse rng-match rng-dt rng-util rng-pttrn nxml-parse nxml-ns
nxml-enc xmltok nxml-util ox-latex ox-icalendar ox-html table ox-ascii
ox-publish ox orgit org-element avl-tree generator magithub
magithub-dash magithub-notification magithub-issue-view magithub-comment
magithub-repo magithub-orgs magithub-issue-tricks magithub-issue-post
magithub-edit-mode magithub-ci magithub-issue magithub-label
magithub-user magithub-core magithub-faces magithub-settings
smartparens-markdown markdown-mode bug-reference ghub+ apiwrap apropos
evil-magit git-rebase magit-gh-pulls gh gh-users gh-issues gh-pulls
gh-repos gh-comments gh-gist gh-oauth gh-api logito gh-cache gh-auth
gh-url url-http tls gnutls url-gw nsm gh-profile magit-obsolete
magit-blame magit-stash magit-bisect magit-remote magit-commit
magit-sequence magit-notes magit-worktree magit-tag magit-merge
magit-branch magit-reset magit-collab ghub url-auth url url-proxy
url-privacy url-expand url-methods url-history url-cookie url-domsuf
url-util mailcap magit-files magit-refs magit-status magit magit-repos
magit-apply magit-wip magit-log magit-diff smerge-mode magit-core
magit-autorevert magit-process magit-margin magit-mode org org-macro
org-footnote org-pcomplete org-list org-faces org-entities org-version
ob-emacs-lisp ob ob-tangle org-src ob-ref ob-lob ob-table ob-keys ob-exp
ob-comint ob-core ob-eval org-compat org-macs org-loaddefs cal-menu
calendar cal-loaddefs editorconfig-core editorconfig-core-handle
editorconfig-fnmatch colir face-remap auto-dim-other-buffers
git-gutter-fringe+ fringe-helper git-gutter+ git-commit with-editor
magit-git magit-section magit-utils crm magit-popup async-bytecomp async
log-edit message rmc puny rfc822 mml mml-sec epa gnus-util rmail
rmail-loaddefs mailabbrev mail-utils gmm-utils mailheader pcvs-util
add-log recentf tree-widget desktop frameset wakatime-mode
contextual-menubar quiet-emacs fill-or-unfill
init-macos-terminal-copy-paste init-flyspell init-terminal-cursor
evil-terminal-cursor-changer init-org init-magit evil-mc
evil-mc-command-execute evil-mc-command-record evil-mc-cursor-make
evil-mc-region evil-mc-cursor-state evil-mc-undo evil-mc-vars
evil-mc-known-commands evil-mc-common hl-todo persistent-soft list-utils
pcache eieio-base font-utils server zone xterm-color
spacemacs-whitespace-cleanup ws-butler winum winner
spacemacs-purpose-popwin window-purpose-x imenu-list imenu
window-purpose window-purpose-fixes window-purpose-prefix-overload
window-purpose-switch window-purpose-layout window-purpose-core
window-purpose-configuration window-purpose-utils volatile-highlights
vi-tilde-fringe unicode-fonts tmux string-inflection smartparens-config
smartparens-text smartparens-ruby saveplace savehist ruby-test-mode
pcre2el rxt re-builder projectile-rails rake f inflections inf-ruby
ruby-mode smie projectile grep ibuf-ext ibuffer ibuffer-loaddefs popwin
persp-mode osx-trash origami origami-parsers s linum ivy-hydra info+
image-mode google-c-style flycheck-pos-tip pos-tip flycheck find-func
flx-ido eyebrowse evil-surround evil-search-highlight-persist
evil-numbers evil-lisp-state smartparens dash evil-lion evil-indent-plus
evil-exchange evil-escape evil-args evil-anzu anzu eval-sexp-fu
highlight font-lock+ frame-fns avoid editorconfig noutline outline
doom-modeline let-alist powerline-separators color all-the-icons
all-the-icons-faces data-material data-weathericons data-octicons
data-fileicons data-faicons data-alltheicons memoize diff-hl vc-dir ewoc
vc vc-dispatcher diff-mode counsel dired dired-loaddefs compile esh-util
etags xref project swiper ivy flx delsel ivy-overlay ffap
clean-aindent-mode adaptive-wrap gh-common marshal rx docker-tramp
tramp-cache hybrid-mode evil-evilified-state which-key use-package
use-package-ensure use-package-delight use-package-diminish
use-package-bind-key bind-key use-package-core hydra lv
exec-path-from-shell cus-edit cus-start cus-load evil evil-integration
undo-tree diff evil-maps evil-commands reveal flyspell ispell evil-jumps
evil-command-window evil-types evil-search evil-ex evil-macros
evil-repeat evil-states evil-core evil-common windmove thingatpt rect
evil-digraphs diminish evil-vars bind-map quelpa help-fns radix-tree
package-build mm-decode mm-bodies mm-encode mail-parse rfc2231 rfc2047
rfc2045 mm-util ietf-drums mail-prsvr json map lisp-mnt hl-line xt-mouse
autorevert filenotify cl-extra disp-table wid-edit monokai-theme info
finder-inf patch-server init-sass init-php init-html init-evil tramp
tramp-compat tramp-loaddefs trampver shell pcomplete comint ansi-color
ring parse-time format-spec ido-vertical-mode ido core-spacemacs
core-use-package-ext core-transient-state core-micro-state core-toggle
core-keybindings core-fonts-support core-themes-support
core-display-init core-jump core-release-management core-custom-settings
core-configuration-layer eieio-compat core-spacemacs-buffer core-funcs
core-dotspacemacs ht cl help-mode warnings package url-handlers
url-parse auth-source cl-seq password-cache url-vars seq eieio byte-opt
bytecomp byte-compile cconv eieio-core eieio-loaddefs epg epg-config
core-command-line pcase core-debug edmacro kmacro derived cl-macs gv
advice profiler easymenu cl-loaddefs cl-lib page-break-lines easy-mmode
core-emacs-backports subr-x time-date tooltip eldoc electric uniquify
ediff-hook vc-hooks lisp-float-type 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 elisp-mode
lisp-mode prog-mode register page menu-bar rfn-eshadow isearch timer
select scroll-bar mouse jit-lock font-lock syntax facemenu font-core
term/tty-colors 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 composite charscript charprop case-table epa-hook jka-cmpr-hook
help simple abbrev obarray 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 lcms2 multi-tty make-network-process emacs)

Memory information:
((conses 16 1750585 315298)
 (symbols 48 100490 2)
 (miscs 40 4978 9354)
 (strings 32 371144 39730)
 (string-bytes 1 12347400)
 (vectors 16 147093)
 (vector-slots 8 3308598 156650)
 (floats 8 1035 908)
 (intervals 56 60864 3395)
 (buffers 992 67))

bug#30800: 26.0.91; unknown crash on macos

[Aaron Jensen]

I was able to get more information, though this trace is different.

I believe this crash has to do with child frames as my repro involves
using flycheck-posframe. For what it's worth, my repro is as follows:

1. Start emacs w/ my config
2. Open a typescript file
3. Cause a flycheck error by deleting a character from an identifier
4. Put the point on the error and move it off several times to see the
child frame w/ the error appear and disappear
5. Click away from emacs
6. Click back in
7. split-window-right
8. Sometimes this is enough to crash it, sometimes I hit a binding
that uses find-file-existing to open my init.el and that crashes it.

On emacs-26 (e4b73abd38)

I'll leave the debugger running in case anyone has any questions about
its state.

Here is the crash:

* thread #1, queue = 'com.apple.main-thread', stop reason =
EXC_BAD_ACCESS (code=1, address=0x0)
    frame #0: 0x00000001003aadcb emacs`-[EmacsApp
sendEvent:](self=0x0000000101739740, _cmd="sendEvent:",
theEvent=0x00000001119c7cf0) at nsterm.m:5449
   5446   if (represented_filename != nil && represented_frame)
   5447     {
   5448       NSString *fstr = represented_filename;
-> 5449       NSView *view = FRAME_NS_VIEW (represented_frame);
   5450 #ifdef NS_IMPL_COCOA
   5451       /* work around a bug observed on 10.3 and later where
   5452          setTitleWithRepresentedFilename does not clear out
previous state
Target 0: (emacs) stopped.

(lldb) thread backtrace
* thread #1, queue = 'com.apple.main-thread', stop reason =
EXC_BAD_ACCESS (code=1, address=0x0)
  * frame #0: 0x00000001003aadcb emacs`-[EmacsApp
sendEvent:](self=0x0000000101739740, _cmd="sendEvent:",
theEvent=0x00000001119c7cf0) at nsterm.m:5449
    frame #1: 0x00007fff50c29d9d AppKit`-[NSApplication run] + 812
    frame #2: 0x00000001003aaaca emacs`-[EmacsApp
run](self=0x0000000101739740, _cmd="run") at nsterm.m:5374
    frame #3: 0x00000001003bf7b1
emacs`ns_read_socket(terminal=0x0000000102830830,
hold_quit=0x00007ffeefbfdf68) at nsterm.m:4401
    frame #4: 0x000000010017d208 emacs`gobble_input at keyboard.c:6909
    frame #5: 0x000000010018385f emacs`get_input_pending(flags=1) at
keyboard.c:6830
    frame #6: 0x00000001001803b6
emacs`detect_input_pending_run_timers(do_display=false) at
keyboard.c:9951
    frame #7: 0x000000010017e0c6 emacs`read_char(commandflag=1,
map=4657228643, prev_event=0, used_mouse_menu=0x00007ffeefbfe967,
end_time=0x0000000000000000) at keyboard.c:2469
    frame #8: 0x000000010017a1a0
emacs`read_key_sequence(keybuf=0x00007ffeefbfec80, bufsize=30,
prompt=0, dont_downcase_last=false, can_return_switch_frame=true,
fix_current_buffer=true, prevent_redisplay=false) at keyboard.c:9147
    frame #9: 0x0000000100178d52 emacs`command_loop_1 at keyboard.c:1368
    frame #10: 0x000000010028b0ef
emacs`internal_condition_case(bfun=(emacs`command_loop_1 at
keyboard.c:1259), handlers=18672, hfun=(emacs`cmd_error at
keyboard.c:938)) at eval.c:1332
    frame #11: 0x000000010018e30c emacs`command_loop_2(ignore=0) at
keyboard.c:1110
    frame #12: 0x000000010028a8a8 emacs`internal_catch(tag=47520,
func=(emacs`command_loop_2 at keyboard.c:1106), arg=0) at eval.c:1097
    frame #13: 0x0000000100177d08 emacs`command_loop at keyboard.c:1089
    frame #14: 0x0000000100177b70 emacs`recursive_edit_1 at keyboard.c:695
    frame #15: 0x0000000100177ea8 emacs`Frecursive_edit at keyboard.c:766
    frame #16: 0x0000000100175b03 emacs`main(argc=1,
argv=0x00007ffeefbff2e8) at emacs.c:1713
    frame #17: 0x00007fff7af69115 libdyld.dylib`start + 1
    frame #18: 0x00007fff7af69115 libdyld.dylib`start + 1

(lldb) thread list
Process 92691 stopped
* thread #1: tid = 0x25ef22, 0x00000001003aadcb emacs`-[EmacsApp
sendEvent:](self=0x0000000101739740, _cmd="sendEvent:",
theEvent=0x00000001119c7cf0) at nsterm.m:5449, queue =
'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=1,
address=0x0)
  thread #2: tid = 0x25ef50, 0x00007fff7b0b9562
libsystem_kernel.dylib`__workq_kernreturn + 10
  thread #3: tid = 0x25ef51, 0x00007fff7b1f3c40
libsystem_pthread.dylib`start_wqthread
  thread #4: tid = 0x25ef59, 0x00007fff7b0b8fca
libsystem_kernel.dylib`__select + 10, name = 'gmain'
  thread #6: tid = 0x25ef60, 0x00007fff7b0b8fca
libsystem_kernel.dylib`__select + 10
  thread #8: tid = 0x25ef6a, 0x00007fff7b0af7c2
libsystem_kernel.dylib`mach_msg_trap + 10, name =
'com.apple.NSEventThread'
  thread #9: tid = 0x25ef70, 0x00007fff7b0b9562
libsystem_kernel.dylib`__workq_kernreturn + 10
  thread #13: tid = 0x25ef74, 0x00007fff7b0b9562
libsystem_kernel.dylib`__workq_kernreturn + 10
  thread #14: tid = 0x25effd, 0x00007fff7b0b9562
libsystem_kernel.dylib`__workq_kernreturn + 10
  thread #15: tid = 0x25effe, 0x00007fff7b0af7c2
libsystem_kernel.dylib`mach_msg_trap + 10, queue =
'NSCGSDisableUpdates'
  thread #16: tid = 0x25efff, 0x00007fff7b0b9562
libsystem_kernel.dylib`__workq_kernreturn + 10
  thread #17: tid = 0x25f000, 0x00007fff7b0b9562
libsystem_kernel.dylib`__workq_kernreturn + 10

bug#30800: 26.0.91; unknown crash on macos

[Aaron Jensen]

Emacs is crashing more often today with this crash. Here is another
trace. Again, it's the `FRAME_NS_VIEW (represented_frame)' that is
crashing:

* thread #1, queue = 'com.apple.main-thread', stop reason =
EXC_BAD_ACCESS (code=1, address=0x0)
  * frame #0: 0x00000001003aadbb emacs`-[EmacsApp
sendEvent:](self=0x00000001018285e0, _cmd="sendEvent:",
theEvent=0x000000011a202f40) at nsterm.m:5449

frame #0: 0x00000001003aadbb emacs`-[EmacsApp
sendEvent:](self=0x00000001018285e0, _cmd="sendEvent:",
theEvent=0x000000011a202f40) at nsterm.m:5449
   5446   if (represented_filename != nil && represented_frame)
   5447     {
   5448       NSString *fstr = represented_filename;
-> 5449       NSView *view = FRAME_NS_VIEW (represented_frame);
   5450 #ifdef NS_IMPL_COCOA
   5451       /* work around a bug observed on 10.3 and later where
   5452          setTitleWithRepresentedFilename does not clear out
previous state
(

    frame #1: 0x00007fff351c0d9d AppKit`-[NSApplication run] + 812
    frame #2: 0x00000001003aaaba emacs`-[EmacsApp
run](self=0x00000001018285e0, _cmd="run") at nsterm.m:5374
    frame #3: 0x00000001003bf7a1
emacs`ns_read_socket(terminal=0x0000000107016430,
hold_quit=0x00007ffeefbf7758) at nsterm.m:4401
    frame #4: 0x000000010017d1f8 emacs`gobble_input at keyboard.c:6909
    frame #5: 0x000000010018384f emacs`get_input_pending(flags=1) at
keyboard.c:6830
    frame #6: 0x00000001001803a6
emacs`detect_input_pending_run_timers(do_display=false) at
keyboard.c:9951
    frame #7: 0x000000010017e0b6 emacs`read_char(commandflag=0,
map=4678764355, prev_event=0, used_mouse_menu=0x00007ffeefbf8157,
end_time=0x0000000000000000) at keyboard.c:2469
    frame #8: 0x000000010017a190
emacs`read_key_sequence(keybuf=0x00007ffeefbf8310, bufsize=30,
prompt=4299522708, dont_downcase_last=false,
can_return_switch_frame=false, fix_current_buffer=false,
prevent_redisplay=false) at keyboard.c:9147
    frame #9: 0x000000010018884a
emacs`read_key_sequence_vs(prompt=4299522708, continue_echo=0,
dont_downcase_last=0, can_return_switch_frame=0, cmd_loop=0,
allow_string=true) at keyboard.c:9840
    frame #10: 0x00000001001885bb
emacs`Fread_key_sequence(prompt=4299522708, continue_echo=0,
dont_downcase_last=0, can_return_switch_frame=0, cmd_loop=0) at
keyboard.c:9913
    frame #11: 0x000000010029b2b8
emacs`funcall_subr(subr=0x0000000100455438, numargs=5,
args=0x00007ffeefbf85d0) at eval.c:2856
    frame #12: 0x0000000100299f2d emacs`Ffuncall(nargs=6,
args=0x00007ffeefbf85c8) at eval.c:2769

unknown

    frame #13: 0x00000001003243cb
emacs`exec_byte_code(bytestr=4560856100, vector=4641979157,
maxdepth=30, args_template=0, nargs=0, args=0x0000000000000000) at
bytecode.c:629
    frame #14: 0x000000010029ba65 emacs`funcall_lambda(fun=4641979301,
nargs=2, arg_vector=0x00007ffeefbf99f0) at eval.c:3052
    frame #15: 0x0000000100299f75 emacs`Ffuncall(nargs=3,
    args=0x00007ffeefbf99e8) at eval.c:2771

ad-Advice-read-key-sequence

    frame #16: 0x00000001002907d2 emacs`Fapply(nargs=3,
args=0x00007ffeefbf99e8) at eval.c:2346
    frame #17: 0x000000010029b0f8
emacs`funcall_subr(subr=0x00000001007b58e8, numargs=3,
args=0x00007ffeefbf99e8) at eval.c:2824
    frame #18: 0x0000000100299f2d emacs`Ffuncall(nargs=4,
    args=0x00007ffeefbf99e0) at eval.c:2769

apply

    frame #19: 0x00000001003243cb
emacs`exec_byte_code(bytestr=4324444556, vector=4642509733,
maxdepth=22, args_template=514, nargs=1, args=0x00007ffeefbfa490) at
bytecode.c:629
    frame #20: 0x000000010029b655 emacs`funcall_lambda(fun=4641978373,
nargs=1, arg_vector=0x00007ffeefbfa490) at eval.c:2970
    frame #21: 0x0000000100299f75 emacs`Ffuncall(nargs=2,
    args=0x00007ffeefbfa488) at eval.c:2771

read-key-sequence

    frame #22: 0x00000001003243cb
emacs`exec_byte_code(bytestr=4560568916, vector=4642277973,
maxdepth=30, args_template=0, nargs=0, args=0x0000000000000000) at
bytecode.c:629
    frame #23: 0x000000010029ba65 emacs`funcall_lambda(fun=4642278229,
nargs=0, arg_vector=0x00007ffeefbfb020) at eval.c:3052
    frame #24: 0x0000000100299f75 emacs`Ffuncall(nargs=1,
    args=0x00007ffeefbfb018) at eval.c:2771

evil-keypress-parser

    frame #25: 0x00000001003243cb
emacs`exec_byte_code(bytestr=4560569572, vector=4642299733,
maxdepth=22, args_template=0, nargs=0, args=0x0000000000000000) at
bytecode.c:629
    frame #26: 0x000000010029ba65 emacs`funcall_lambda(fun=4642299893,
nargs=1, arg_vector=0x00007ffeefbfbb50) at eval.c:3052
    frame #27: 0x0000000100299f75 emacs`Ffuncall(nargs=2,
    args=0x00007ffeefbfbb48) at eval.c:2771

evil-read-motion

    frame #28: 0x00000001003243cb
emacs`exec_byte_code(bytestr=4559603716, vector=4647802117,
maxdepth=30, args_template=0, nargs=0, args=0x0000000000000000) at
bytecode.c:629
    frame #29: 0x000000010029ba65 emacs`funcall_lambda(fun=4647802725,
nargs=1, arg_vector=0x00007ffeefbfc7a8) at eval.c:3052
    frame #30: 0x0000000100299f75 emacs`Ffuncall(nargs=2,
    args=0x00007ffeefbfc7a0) at eval.c:2771

evil-operator-range

    frame #31: 0x00000001003243cb
emacs`exec_byte_code(bytestr=4560742708, vector=4642983765,
maxdepth=22, args_template=0, nargs=0, args=0x0000000000000000) at
bytecode.c:629
    frame #32: 0x000000010031f15c emacs`Fbyte_code(bytestr=4560742708,
vector=4642983765, maxdepth=22) at bytecode.c:321
    frame #33: 0x0000000100284224 emacs`eval_sub(form=4642959219) at eval.c:2240
    frame #34: 0x000000010028c3cd emacs`Feval(form=4642959219,
lexical=0) at eval.c:2054
    frame #35: 0x000000010027b2f3
emacs`Fcall_interactively(function=339231936, record_flag=0,
keys=4427386789) at callint.c:357
    frame #36: 0x000000010029b231
emacs`funcall_subr(subr=0x00000001007b52e8, numargs=3,
args=0x00007ffeefbfdf30) at eval.c:2849
    frame #37: 0x0000000100299f2d emacs`Ffuncall(nargs=4,
    args=0x00007ffeefbfdf28) at eval.c:2769

call-interactively

    frame #38: 0x00000001003243cb
emacs`exec_byte_code(bytestr=4300314780, vector=4300314813,
maxdepth=54, args_template=4102, nargs=1, args=0x00007ffeefbfeaa8) at
bytecode.c:629
    frame #39: 0x000000010029b655 emacs`funcall_lambda(fun=4300314733,
nargs=1, arg_vector=0x00007ffeefbfeaa0) at eval.c:2970
    frame #40: 0x0000000100299f75 emacs`Ffuncall(nargs=2,
    args=0x00007ffeefbfea98) at eval.c:2771

command-execute

    frame #41: 0x000000010029aa44 emacs`call1(fn=13920,
arg1=339231936) at eval.c:2620
    frame #42: 0x0000000100179204 emacs`command_loop_1 at keyboard.c:1482
    frame #43: 0x000000010028b0df
emacs`internal_condition_case(bfun=(emacs`command_loop_1 at
keyboard.c:1259), handlers=18672, hfun=(emacs`cmd_error at
keyboard.c:938)) at eval.c:1332
    frame #44: 0x000000010018e2fc emacs`command_loop_2(ignore=0) at
keyboard.c:1110
    frame #45: 0x000000010028a898 emacs`internal_catch(tag=47520,
func=(emacs`command_loop_2 at keyboard.c:1106), arg=0) at eval.c:1097
    frame #46: 0x0000000100177cf8 emacs`command_loop at keyboard.c:1089
    frame #47: 0x0000000100177b60 emacs`recursive_edit_1 at keyboard.c:695
    frame #48: 0x0000000100177e98 emacs`Frecursive_edit at keyboard.c:766
    frame #49: 0x0000000100175af3 emacs`main(argc=1,
argv=0x00007ffeefbff348) at emacs.c:1713
    frame #50: 0x00007fff5f500115 libdyld.dylib`start + 1
    frame #51: 0x00007fff5f500115 libdyld.dylib`start + 1

bug#30800: 26.0.91; unknown crash on macos

[Eli Zaretskii]

> From: Aaron Jensen <aaronjensen@gmail.com>
> Date: Tue, 20 Mar 2018 16:39:52 -0700
> 
> Emacs is crashing more often today with this crash. Here is another
> trace. Again, it's the `FRAME_NS_VIEW (represented_frame)' that is
> crashing:
> 
> * thread #1, queue = 'com.apple.main-thread', stop reason =
> EXC_BAD_ACCESS (code=1, address=0x0)
>   * frame #0: 0x00000001003aadbb emacs`-[EmacsApp
> sendEvent:](self=0x00000001018285e0, _cmd="sendEvent:",
> theEvent=0x000000011a202f40) at nsterm.m:5449
> 
> frame #0: 0x00000001003aadbb emacs`-[EmacsApp
> sendEvent:](self=0x00000001018285e0, _cmd="sendEvent:",
> theEvent=0x000000011a202f40) at nsterm.m:5449
>    5446   if (represented_filename != nil && represented_frame)
>    5447     {
>    5448       NSString *fstr = represented_filename;
> -> 5449       NSView *view = FRAME_NS_VIEW (represented_frame);
>    5450 #ifdef NS_IMPL_COCOA

Which part of FRAME_NS_VIEW causes the crash?  There are 2
dereferences there; which one is the culprit?

bug#30800: 26.0.91; unknown crash on macos

[Aaron Jensen]

On Tue, Mar 20, 2018 at 11:37 PM, Eli Zaretskii <eliz@gnu.org> wrote:
> Which part of FRAME_NS_VIEW causes the crash?  There are 2
> dereferences there; which one is the culprit?

I believe it's the first:

(lldb) p represented_frame->output_data
error: Couldn't apply expression side effects : Couldn't dematerialize
a result variable: couldn't read its memory

bug#30800: 26.0.91; unknown crash on macos

[Eli Zaretskii]

> From: Aaron Jensen <aaronjensen@gmail.com>
> Date: Wed, 21 Mar 2018 09:25:57 -0700
> Cc: 30800@debbugs.gnu.org
> 
> On Tue, Mar 20, 2018 at 11:37 PM, Eli Zaretskii <eliz@gnu.org> wrote:
> > Which part of FRAME_NS_VIEW causes the crash?  There are 2
> > dereferences there; which one is the culprit?
> 
> I believe it's the first:
> 
> (lldb) p represented_frame->output_data
> error: Couldn't apply expression side effects : Couldn't dematerialize
> a result variable: couldn't read its memory

Please also show the value of represented_frame itself.

Thanks.

bug#30800: 26.0.91; unknown crash on macos

[Eli Zaretskii]

> Date: Wed, 21 Mar 2018 19:00:12 +0200
> From: Eli Zaretskii <eliz@gnu.org>
> Cc: 30800@debbugs.gnu.org
> 
> > > Which part of FRAME_NS_VIEW causes the crash?  There are 2
> > > dereferences there; which one is the culprit?
> > 
> > I believe it's the first:
> > 
> > (lldb) p represented_frame->output_data
> > error: Couldn't apply expression side effects : Couldn't dematerialize
> > a result variable: couldn't read its memory
> 
> Please also show the value of represented_frame itself.

And crystal ball says this has something to do with commit f7a853d.

bug#30800: 26.0.91; unknown crash on macos

[Aaron Jensen]

On Wed, Mar 21, 2018 at 10:09 AM, Eli Zaretskii <eliz@gnu.org> wrote:
>> Please also show the value of represented_frame itself.

(lldb) p represented_frame
(frame *) $17 = 0x0ae80ae70ae60ae5
(lldb) po represented_frame
eeelTainMuhxud

Let me know if there's a way to get more information from that.


> And crystal ball says this has something to do with commit f7a853d.

This repros on emacs-26, which, afaict, does not have this commit.

bug#30800: 26.0.91; unknown crash on macos

[Eli Zaretskii]

> From: Aaron Jensen <aaronjensen@gmail.com>
> Date: Wed, 21 Mar 2018 10:31:11 -0700
> Cc: Alan Third <alan@idiocy.org>, 30800@debbugs.gnu.org
> 
> This repros on emacs-26, which, afaict, does not have this commit.

Then I don't understand: you said this started happening only very
recently, but I could see no related changes on emacs-26.  Is your
build --with-wide-int, per chance?  Can you try bisecting?

bug#30800: 26.0.91; unknown crash on macos

[Aaron Jensen]

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

I didn’t pass wide int afaik. So whatever the default is. I believe it has
to do with posframe. I use both flycheck posframe and company posframe. If
I disable the flycheck one I do not get crashes. It’s possible that they
are both doing frame manipulation that is more frequent and new, which is
exposing these. I believe that new package is more why this is happening
now.

Aaron


On Mar 21, 2018 at 11:22 AM, Eli Zaretskii <eliz@gnu.org> wrote:


From: Aaron Jensen <aaronjensen@gmail.com>
Date: Wed, 21 Mar 2018 10:31:11 -0700
Cc: Alan Third <alan@idiocy.org>, 30800@debbugs.gnu.org

This repros on emacs-26, which, afaict, does not have this commit.


Then I don't understand: you said this started happening only very
recently, but I could see no related changes on emacs-26. Is your
build --with-wide-int, per chance? Can you try bisecting?

[-- Attachment #2: Type: text/html, Size: 1593 bytes --]

bug#30800: 26.0.91; unknown crash on macos

[Eli Zaretskii]

> From: Aaron Jensen <aaronjensen@gmail.com>
> Date: Wed, 21 Mar 2018 11:31:12 -0700
> Cc: alan@idiocy.org, 30800@debbugs.gnu.org
> 
> I didn’t pass wide int afaik. So whatever the default is. I believe it has to do with posframe. I use both flycheck
> posframe and company posframe. If I disable the flycheck one I do not get crashes. It’s possible that they are
> both doing frame manipulation that is more frequent and new, which is exposing these. I believe that new
> package is more why this is happening now. 

OK.

It sounds like represented_frame might not get updated when the frame
whose pointer it holds is deleted.  Maybe x_destroy_window should make
sure represented_frame is not the frame being deleted?

Or maybe NS should not update represented_frame for child frames?

(I'm really stabbing in the dark here.)

bug#30800: 26.0.91; unknown crash on macos

[Alan Third]

On Wed, Mar 21, 2018 at 08:48:12PM +0200, Eli Zaretskii wrote:
> It sounds like represented_frame might not get updated when the frame
> whose pointer it holds is deleted.  Maybe x_destroy_window should make
> sure represented_frame is not the frame being deleted?
> 
> Or maybe NS should not update represented_frame for child frames?

The commit that introduced represented_frame was fixing some
flickering. What it seems to have done is move the updating of the
represented filename from being set synchronously to asynchronously.
The represented filename tells the WM which file is being edited so it
can show a matching icon in the titlebar and maybe some other stuff.

It seems quite possible to me that the frame could be deleted in the
interim.

Could we check that the frame is still live in sendEvent?

    if (represented_filename != nil && FRAME_LIVE_P (represented_frame))

or just add

    if (represented_frame == f)
      represented_frame = NULL;

to x_destroy_frame as you say.

(I can’t help thinking it should be possible to update several frames
in quick succession but only have the last actually updated since
represented_filename and represented_frame are simply over‐written.)
-- 
Alan Third

bug#30800: 26.0.91; unknown crash on macos

[Eli Zaretskii]

> Date: Wed, 21 Mar 2018 19:19:03 +0000
> From: Alan Third <alan@idiocy.org>
> Cc: Aaron Jensen <aaronjensen@gmail.com>, 30800@debbugs.gnu.org
> 
> The commit that introduced represented_frame was fixing some
> flickering. What it seems to have done is move the updating of the
> represented filename from being set synchronously to asynchronously.
> The represented filename tells the WM which file is being edited so it
> can show a matching icon in the titlebar and maybe some other stuff.
> 
> It seems quite possible to me that the frame could be deleted in the
> interim.
> 
> Could we check that the frame is still live in sendEvent?
> 
>     if (represented_filename != nil && FRAME_LIVE_P (represented_frame))

I'd expect FRAME_LIVE_P to crash in the same way FRAME_NS_VIEW does,
because FRAME_LIVE_P also dereferences the pointer, and the pointer
appears to be garbage in this case (probably because its memory was
free'd).

> or just add
> 
>     if (represented_frame == f)
>       represented_frame = NULL;
> 
> to x_destroy_frame as you say.

If that fixes the problem, it's the safest change I can think of, so
perhaps Aaron could try running Emacs 26.0.91 with it.

> (I can’t help thinking it should be possible to update several frames
> in quick succession but only have the last actually updated since
> represented_filename and represented_frame are simply over‐written.)

Yes, this machinery looks quite fragile to me.

Is there any reason not to use selected_frame instead?

bug#30800: 26.0.91; unknown crash on macos

[Alan Third]

On Wed, Mar 21, 2018 at 09:36:18PM +0200, Eli Zaretskii wrote:
> > Date: Wed, 21 Mar 2018 19:19:03 +0000
> > From: Alan Third <alan@idiocy.org>
> > Cc: Aaron Jensen <aaronjensen@gmail.com>, 30800@debbugs.gnu.org
> > 
> > The commit that introduced represented_frame was fixing some
> > flickering. What it seems to have done is move the updating of the
> > represented filename from being set synchronously to asynchronously.
> > The represented filename tells the WM which file is being edited so it
> > can show a matching icon in the titlebar and maybe some other stuff.
<snip>
> > (I can’t help thinking it should be possible to update several frames
> > in quick succession but only have the last actually updated since
> > represented_filename and represented_frame are simply over‐written.)
> 
> Yes, this machinery looks quite fragile to me.
> 
> Is there any reason not to use selected_frame instead?

I think we could end up in a similar situation if the selected frame
changed soon after ns_set_represented_filename was called (i.e. it
will set it for the wrong frame).

It might be best to try setting the represented filename synchronously
again and come up with some other way of avoiding the flicker.

(Original bug report was 18757 and the commit was
d9d383147219f8e6a90d4c177e1b454e19acfac9.)
-- 
Alan Third

bug#30800: 26.0.91; unknown crash on macos

[Aaron Jensen]

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

On Wed, Mar 21, 2018 at 12:36 PM, Eli Zaretskii <eliz@gnu.org> wrote:
>> or just add
>>
>>     if (represented_frame == f)
>>       represented_frame = NULL;
>>
>> to x_destroy_frame as you say.
>
> If that fixes the problem, it's the safest change I can think of, so
> perhaps Aaron could try running Emacs 26.0.91 with it.

It seems to fix it. I'm unable to reproduce the crash with this patch
applied. I tried to represent what was going on in my comments/commit
messages but I'm happy to change them if anyone has a better way to
describe it. That is if you want to apply this instead of fixing it in
another way.

Thanks.

[-- Attachment #2: 0001-Fix-crash-after-frame-is-freed-on-macOS-bug-30800.patch --]
[-- Type: application/octet-stream, Size: 892 bytes --]

From 323740bf0d554fbfc6afc90ed81c68879cd46ece Mon Sep 17 00:00:00 2001
From: Aaron Jensen <aaronjensen@gmail.com>
Date: Wed, 21 Mar 2018 22:30:08 -0700
Subject: [PATCH] Fix crash after frame is freed on macOS (bug#30800)

* src/nsterm.m (x_free_frame_resources): Clear represented_frame.
(bug#30800)
---
 src/nsterm.m | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/src/nsterm.m b/src/nsterm.m
index 3d58cd5ec6..c8ae31abc0 100644
--- a/src/nsterm.m
+++ b/src/nsterm.m
@@ -1692,6 +1692,10 @@ -(void)remove
     dpyinfo->x_highlight_frame = 0;
   if (f == hlinfo->mouse_face_mouse_frame)
     reset_mouse_highlight (hlinfo);
+  /* Ensure that sendEvent does not attempt to dereference a freed
+     frame. (bug#30800) */
+  if (represented_frame == f)
+    represented_frame = NULL;
 
   if (f->output_data.ns->miniimage != nil)
     [f->output_data.ns->miniimage release];
-- 
2.16.2

bug#30800: 26.0.91; unknown crash on macos

[Aaron Jensen]

On Wed, Mar 21, 2018 at 1:12 PM, Alan Third <alan@idiocy.org> wrote:
> It might be best to try setting the represented filename synchronously
> again and come up with some other way of avoiding the flicker.
>
> (Original bug report was 18757 and the commit was
> d9d383147219f8e6a90d4c177e1b454e19acfac9.)

I do not understand why setting the represented filename where it was
set originally causes a flicker.

It's probably a dumb question, but would using the start/stop paint
stuff from the flicker bug help to eliminate the flicker in some way?

bug#30800: 26.0.91; unknown crash on macos

[Eli Zaretskii]

> From: Aaron Jensen <aaronjensen@gmail.com>
> Date: Wed, 21 Mar 2018 22:35:23 -0700
> Cc: Alan Third <alan@idiocy.org>, 30800@debbugs.gnu.org
> 
> >>     if (represented_frame == f)
> >>       represented_frame = NULL;
> >>
> >> to x_destroy_frame as you say.
> >
> > If that fixes the problem, it's the safest change I can think of, so
> > perhaps Aaron could try running Emacs 26.0.91 with it.
> 
> It seems to fix it. I'm unable to reproduce the crash with this patch
> applied.

Thanks.  Let's see if you encounter the crash while running with the
change a little longer.

bug#30800: 26.0.91; unknown crash on macos

[Eli Zaretskii]

> From: Aaron Jensen <aaronjensen@gmail.com>
> Date: Wed, 21 Mar 2018 22:40:33 -0700
> Cc: Eli Zaretskii <eliz@gnu.org>, 30800@debbugs.gnu.org
> 
> > (Original bug report was 18757 and the commit was
> > d9d383147219f8e6a90d4c177e1b454e19acfac9.)
> 
> I do not understand why setting the represented filename where it was
> set originally causes a flicker.

I don't understand, either, especially since I don't see this on w32.

The recipes in bug#18757 seem to indicate that redisplaying the
frame's title, due to the change in the selected buffer, causes the
flickering.  That flickering started happening with the upgrade to
version 10.10 of the OS, so perhaps it's no linger an issue with the
current OS versions?

> It's probably a dumb question, but would using the start/stop paint
> stuff from the flicker bug help to eliminate the flicker in some way?

Do you still see the flicker if you revert the above commit?

bug#30800: 26.0.91; unknown crash on macos

[Aaron Jensen]

On Thu, Mar 22, 2018 at 12:26 AM, Eli Zaretskii <eliz@gnu.org> wrote:
>> I do not understand why setting the represented filename where it was
>> set originally causes a flicker.
>
> I don't understand, either, especially since I don't see this on w32.
>
> The recipes in bug#18757 seem to indicate that redisplaying the
> frame's title, due to the change in the selected buffer, causes the
> flickering.  That flickering started happening with the upgrade to
> version 10.10 of the OS, so perhaps it's no linger an issue with the
> current OS versions?
>
>> It's probably a dumb question, but would using the start/stop paint
>> stuff from the flicker bug help to eliminate the flicker in some way?
>
> Do you still see the flicker if you revert the above commit?

I do not on 10.13.2 when I follow the steps outlined in the original report.

I don't know what's going on in the code exactly, but would it be
worth it to risk the flicker on older macOS (or people's setups that
can repro it if mine just can't) in order to ensure that the
represented filename gets set on a frame that is about to be freed? Or
maybe there's something more that's going on here that I don't
understand.

By the way, flycheck-posframe changed it so that they hide the frame
(and eventually reuse it) instead of killing it after it is used,
which should make this crash less likely in the future for others. I
still think it should be patched, but that's some good news.

Related to that, the more consistent repro for this is to use
flycheck-posframe and move the point to and from an error, which
causes the a new frame to flicker in and out of existence. It's
probably possible to script this to an even more concise repro.

bug#30800: 26.0.91; unknown crash on macos

[Eli Zaretskii]

> From: Aaron Jensen <aaronjensen@gmail.com>
> Date: Thu, 22 Mar 2018 08:39:32 -0700
> Cc: Alan Third <alan@idiocy.org>, 30800@debbugs.gnu.org
> 
> > Do you still see the flicker if you revert the above commit?
> 
> I do not on 10.13.2 when I follow the steps outlined in the original report.
> 
> I don't know what's going on in the code exactly, but would it be
> worth it to risk the flicker on older macOS (or people's setups that
> can repro it if mine just can't) in order to ensure that the
> represented filename gets set on a frame that is about to be freed?

I don't know.  I leave it to you, users of macOS, to make that
decision.  Perhaps the patch you are trying is indeed the best fix
(assuming it works), given that the problem is less likely to happen
now.

bug#30800: 26.0.91; unknown crash on macos

[Aaron Jensen]

On Thu, Mar 22, 2018 at 8:57 AM, Eli Zaretskii <eliz@gnu.org> wrote:
> I don't know.  I leave it to you, users of macOS, to make that
> decision.  Perhaps the patch you are trying is indeed the best fix
> (assuming it works), given that the problem is less likely to happen
> now.

The patch appears to work. Not a single crash all day and no other ill
effects afaict. The patch isn't a fix for a bug introduced in 26, but
it does fix a bug that made more accessible by the frame changes in 26
(and posframe). Would you consider it for emacs-26?

Thanks.

bug#30800: 26.0.91; unknown crash on macos

[Eli Zaretskii]

> From: Aaron Jensen <aaronjensen@gmail.com>
> Date: Thu, 22 Mar 2018 18:49:33 -0700
> Cc: Alan Third <alan@idiocy.org>, 30800@debbugs.gnu.org
> 
> The patch appears to work. Not a single crash all day and no other ill
> effects afaict. The patch isn't a fix for a bug introduced in 26, but
> it does fix a bug that made more accessible by the frame changes in 26
> (and posframe). Would you consider it for emacs-26?

Yes, I'm okay with pushing this to emacs-26.

Thanks.

bug#30800: 26.0.91; unknown crash on macos

[Alan Third]

On Thu, Mar 22, 2018 at 05:57:56PM +0200, Eli Zaretskii wrote:
> > From: Aaron Jensen <aaronjensen@gmail.com>
> > Date: Thu, 22 Mar 2018 08:39:32 -0700
> > Cc: Alan Third <alan@idiocy.org>, 30800@debbugs.gnu.org
> > 
> > I don't know what's going on in the code exactly, but would it be
> > worth it to risk the flicker on older macOS (or people's setups that
> > can repro it if mine just can't) in order to ensure that the
> > represented filename gets set on a frame that is about to be freed?
> 
> I don't know.  I leave it to you, users of macOS, to make that
> decision.  Perhaps the patch you are trying is indeed the best fix
> (assuming it works), given that the problem is less likely to happen
> now.

I would like to revert it if only simplify the code, but I don’t feel
that strongly. It may have been fixed in later releases of 10.10. It
would be nice if someone using 10.10 could check, but I don’t know who
could do that.

It might be worth putting a comment or two in to explain why it’s
using this asynchronous method.

-- 
Alan Third

bug#30800: 26.0.91; unknown crash on macos

[Aaron Jensen]

On Fri, Mar 23, 2018 at 12:52 PM, Alan Third <alan@idiocy.org> wrote:
> I would like to revert it if only simplify the code, but I don’t feel
> that strongly. It may have been fixed in later releases of 10.10. It
> would be nice if someone using 10.10 could check, but I don’t know who
> could do that.

How far back is Emacs meant to support, out of curiosity?

macOS support (was: bug#30800: 26.0.91; unknown crash on macos)

[Alan Third]

On Fri, Mar 23, 2018 at 01:57:21PM -0700, Aaron Jensen wrote:
> On Fri, Mar 23, 2018 at 12:52 PM, Alan Third <alan@idiocy.org> wrote:
> > I would like to revert it if only simplify the code, but I don’t feel
> > that strongly. It may have been fixed in later releases of 10.10. It
> > would be nice if someone using 10.10 could check, but I don’t know who
> > could do that.
> 
> How far back is Emacs meant to support, out of curiosity?

Emacs 26 supports 10.6 and up. I’m not aware of any official line on
how far back we should support, but I know there’s at least one Emacs
dev who uses 10.6, and would argue against desupporting it, and
another who uses 10.9.

-- 
Alan Third

Re: macOS support (was: bug#30800: 26.0.91; unknown crash on macos)

[Eli Zaretskii]

> Date: Fri, 23 Mar 2018 21:47:05 +0000
> From: Alan Third <alan@idiocy.org>
> Cc: emacs-devel@gnu.org
> 
> On Fri, Mar 23, 2018 at 01:57:21PM -0700, Aaron Jensen wrote:
> > On Fri, Mar 23, 2018 at 12:52 PM, Alan Third <alan@idiocy.org> wrote:
> > > I would like to revert it if only simplify the code, but I don’t feel
> > > that strongly. It may have been fixed in later releases of 10.10. It
> > > would be nice if someone using 10.10 could check, but I don’t know who
> > > could do that.
> > 
> > How far back is Emacs meant to support, out of curiosity?
> 
> Emacs 26 supports 10.6 and up. I’m not aware of any official line on
> how far back we should support, but I know there’s at least one Emacs
> dev who uses 10.6, and would argue against desupporting it, and
> another who uses 10.9.

Are there any numbers about how widespread each version is on end-user
machines?

Re: macOS support (was: bug#30800: 26.0.91; unknown crash on macos)

[Aaron Jensen]

On Fri, Mar 23, 2018 at 11:35 PM, Eli Zaretskii <eliz@gnu.org> wrote:
> Are there any numbers about how widespread each version is on end-user
> machines?

According to http://gs.statcounter.com/macos-version-market-share/desktop/worldwide

| macOS High Sierra     | 10.13 | 37.76% |
| macOS Sierra          | 10.12 | 23.49% |
| OS X El Capitan       | 10.11 |  18.6% |
| OS X Yosemite         | 10.10 | 11.51% |
| OS X Mavericks        |  10.9 |  3.96% |
| mac OS X Snow Leopard |  10.6 |  1.78% |

I couldn't find anything else to corroborate that though.

bug#30800: 26.0.91; unknown crash on macos

[Aaron Jensen]

On Fri, Mar 23, 2018 at 12:52 PM, Alan Third <alan@idiocy.org> wrote:
> I would like to revert it if only simplify the code, but I don’t feel
> that strongly. It may have been fixed in later releases of 10.10. It
> would be nice if someone using 10.10 could check, but I don’t know who
> could do that.

Maybe this is a weird idea, but what if we apply my patch, then revert
the code and my patch so that if the flicker returns and the revert is
reverted at least the crash would be fixed?

Re: macOS support (was: bug#30800: 26.0.91; unknown crash on macos)

[Alan Third]

On Sat, Mar 24, 2018 at 12:18:47AM -0700, Aaron Jensen wrote:
> On Fri, Mar 23, 2018 at 11:35 PM, Eli Zaretskii <eliz@gnu.org> wrote:
> > Are there any numbers about how widespread each version is on end-user
> > machines?
> 
> According to http://gs.statcounter.com/macos-version-market-share/desktop/worldwide
> 
> | macOS High Sierra     | 10.13 | 37.76% |
> | macOS Sierra          | 10.12 | 23.49% |
> | OS X El Capitan       | 10.11 |  18.6% |
> | OS X Yosemite         | 10.10 | 11.51% |
> | OS X Mavericks        |  10.9 |  3.96% |
> | mac OS X Snow Leopard |  10.6 |  1.78% |
> 
> I couldn't find anything else to corroborate that though.

These chat app devs publish their installation statistics:

https://www.adium.im/sparkle/

| 10.13.3 | 35.42% |
| 10.11.6 | 17.15% |
| 10.12.6 | 15.96% |
| 10.10.5 |  5.37% |
|  10.6.8 |  5.37% |
|  10.9.5 |  3.54% |
| 10.4.11 |  3.02% |
| 10.11.4 |  2.31% |
| 10.13.2 |  1.75% |
|   Other | 10.10% |

I wonder what stops those 10.11.4 hold‐outs upgrading to 10.11.6?
-- 
Alan Third

bug#30800: 26.0.91; unknown crash on macos

[Alan Third]

On Sat, Mar 24, 2018 at 12:20:11AM -0700, Aaron Jensen wrote:
> On Fri, Mar 23, 2018 at 12:52 PM, Alan Third <alan@idiocy.org> wrote:
> > I would like to revert it if only simplify the code, but I don’t feel
> > that strongly. It may have been fixed in later releases of 10.10. It
> > would be nice if someone using 10.10 could check, but I don’t know who
> > could do that.
> 
> Maybe this is a weird idea, but what if we apply my patch, then revert
> the code and my patch so that if the flicker returns and the revert is
> reverted at least the crash would be fixed?

That would be up to Eli, but I think we should at least put your patch
in Emacs 26. Anything bigger should go in master.
-- 
Alan Third

bug#30800: 26.0.91; unknown crash on macos

[Charles A. Roelli]

> Date: Fri, 23 Mar 2018 19:52:10 +0000
> From: Alan Third <alan@idiocy.org>
>
> I would like to revert it if only simplify the code, but I don’t feel
> that strongly. It may have been fixed in later releases of 10.10. It
> would be nice if someone using 10.10 could check, but I don’t know who
> could do that.

What would you like to check?  I have a partition with 10.10.

bug#30800: 26.0.91; unknown crash on macos

[Alan Third]

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

On Sat, Mar 24, 2018 at 11:49:43AM +0100, Charles A. Roelli wrote:
> > Date: Fri, 23 Mar 2018 19:52:10 +0000
> > From: Alan Third <alan@idiocy.org>
> >
> > I would like to revert it if only simplify the code, but I don’t feel
> > that strongly. It may have been fixed in later releases of 10.10. It
> > would be nice if someone using 10.10 could check, but I don’t know who
> > could do that.
> 
> What would you like to check?  I have a partition with 10.10.

Hi Charles, thanks for offering to check this.

I’ve attached a patch for the emacs-26 branch that reverts
d9d383147219f8e6a90d4c177e1b454e19acfac9. It doesn’t revert cleanly,
hence the patch. You could try reverting it on master if you want, but
I suspect it will be harder to do.

Once that’s applied try the reproduction steps in

https://debbugs.gnu.org/cgi/bugreport.cgi?bug=18757#41

Basically the code in question has at least one reproducible bug and
looks as though it should have several more that we haven’t seen yet,
and although we have a work‐around we’re wondering if we can just get
rid of it completely as it appears to have been a work‐around for a
bug introduced in macOS 10.10 and fixed some time later, hopefully
before 10.10 stopped getting fixes.
-- 
Alan Third

[-- Attachment #2: 0001-Revert-More-flicker-fixes-for-OSX-related-to-bug-187.patch --]
[-- Type: text/plain, Size: 4303 bytes --]

From 0e7da51a70ab7ea0dace246919a575890a061908 Mon Sep 17 00:00:00 2001
From: Alan Third <alan@idiocy.org>
Date: Sat, 24 Mar 2018 13:50:17 +0000
Subject: [PATCH] Revert "More flicker fixes for OSX, related to bug 18757."

This reverts commit d9d383147219f8e6a90d4c177e1b454e19acfac9.
---
 src/ChangeLog.13 |  2 +-
 src/nsfns.m      |  9 ++++++++-
 src/nsterm.h     |  6 +++---
 src/nsterm.m     | 29 +----------------------------
 4 files changed, 13 insertions(+), 33 deletions(-)

diff --git a/src/ChangeLog.13 b/src/ChangeLog.13
index 31e01306a0..eddf85a367 100644
--- a/src/ChangeLog.13
+++ b/src/ChangeLog.13
@@ -13,7 +13,7 @@
 	outside of this function (Bug#16737).
 	(set_property_change_object): New function.
 
-2015-04-03  Jan Djärv  <jan.h.d@swipnet.se>
+2014-11-27  Eli Zaretskii  <eliz@gnu.org>
 
 	* xterm.c (handle_one_xevent): Always redraw tool tips on
 	MapNotify.  Update tool tip frame sizes on ConfigureNotify.
diff --git a/src/nsfns.m b/src/nsfns.m
index 7f2f060dda..83b5fc9541 100644
--- a/src/nsfns.m
+++ b/src/nsfns.m
@@ -578,11 +578,18 @@ Turn the input menu (an NSMenu) into a lisp list for tracking on lisp side
 
           fstr = [NSString stringWithUTF8String: SSDATA (encoded_filename)];
           if (fstr == nil) fstr = @"";
+#ifdef NS_IMPL_COCOA
+          /* work around a bug observed on 10.3 and later where
+             setTitleWithRepresentedFilename does not clear out previous state
+             if given filename does not exist */
+          if (! [[NSFileManager defaultManager] fileExistsAtPath: fstr])
+            [[view window] setRepresentedFilename: @""];
+#endif
         }
       else
         fstr = @"";
 
-      ns_set_represented_filename (fstr, f);
+      [[view window] setRepresentedFilename: fstr];
       [[view window] setTitle: str];
       fset_name (f, name);
     }
diff --git a/src/nsterm.h b/src/nsterm.h
index 588b9fc644..2308e0a994 100644
--- a/src/nsterm.h
+++ b/src/nsterm.h
@@ -1230,11 +1230,11 @@ struct input_event;
 extern void ns_init_events (struct input_event *);
 extern void ns_finish_events (void);
 
+/* From nsterm.m, needed in nsfont.m. */
 #ifdef __OBJC__
-/* Needed in nsfns.m.  */
 extern void
-ns_set_represented_filename (NSString *fstr, struct frame *f);
-
+ns_draw_text_decoration (struct glyph_string *s, struct face *face,
+                         NSColor *defaultCol, CGFloat width, CGFloat x);
 #endif
 
 #ifdef NS_IMPL_GNUSTEP
diff --git a/src/nsterm.m b/src/nsterm.m
index 3d58cd5ec6..2530a86ab6 100644
--- a/src/nsterm.m
+++ b/src/nsterm.m
@@ -322,9 +322,6 @@ - (NSColor *)colorUsingDefaultColorSpace
   NULL, 0, 0
 };
 
-static NSString *represented_filename = nil;
-static struct frame *represented_frame = 0;
-
 #ifdef NS_IMPL_COCOA
 /*
  * State for pending menu activation:
@@ -442,13 +439,6 @@ - (NSColor *)colorUsingDefaultColorSpace
 
    ========================================================================== */
 
-void
-ns_set_represented_filename (NSString *fstr, struct frame *f)
-{
-  represented_filename = [fstr retain];
-  represented_frame = f;
-}
-
 void
 ns_init_events (struct input_event *ev)
 {
@@ -3323,7 +3313,7 @@ Note that CURSOR_WIDTH is meaningful only for (h)bar cursors.
 
 
 
-static void
+void
 ns_draw_text_decoration (struct glyph_string *s, struct face *face,
                          NSColor *defaultCol, CGFloat width, CGFloat x)
 /* --------------------------------------------------------------------------
@@ -5443,23 +5433,6 @@ - (void)sendEvent: (NSEvent *)theEvent
     }
 #endif
 
-  if (represented_filename != nil && represented_frame)
-    {
-      NSString *fstr = represented_filename;
-      NSView *view = FRAME_NS_VIEW (represented_frame);
-#ifdef NS_IMPL_COCOA
-      /* work around a bug observed on 10.3 and later where
-         setTitleWithRepresentedFilename does not clear out previous state
-         if given filename does not exist */
-      if (! [[NSFileManager defaultManager] fileExistsAtPath: fstr])
-        [[view window] setRepresentedFilename: @""];
-#endif
-      [[view window] setRepresentedFilename: fstr];
-      [represented_filename release];
-      represented_filename = nil;
-      represented_frame = NULL;
-    }
-
   if (type == NSEventTypeApplicationDefined)
     {
       switch ([theEvent data2])
-- 
2.16.1

Re: macOS support (was: bug#30800: 26.0.91; unknown crash on macos)

[Eli Zaretskii]

> From: Aaron Jensen <aaronjensen@gmail.com>
> Date: Sat, 24 Mar 2018 00:18:47 -0700
> Cc: Alan Third <alan@idiocy.org>, emacs-devel@gnu.org
> 
> On Fri, Mar 23, 2018 at 11:35 PM, Eli Zaretskii <eliz@gnu.org> wrote:
> > Are there any numbers about how widespread each version is on end-user
> > machines?
> 
> According to http://gs.statcounter.com/macos-version-market-share/desktop/worldwide
> 
> | macOS High Sierra     | 10.13 | 37.76% |
> | macOS Sierra          | 10.12 | 23.49% |
> | OS X El Capitan       | 10.11 |  18.6% |
> | OS X Yosemite         | 10.10 | 11.51% |
> | OS X Mavericks        |  10.9 |  3.96% |
> | mac OS X Snow Leopard |  10.6 |  1.78% |

6% is quite high, I think.

bug#30800: 26.0.91; unknown crash on macos

[Eli Zaretskii]

> Date: Sat, 24 Mar 2018 10:29:58 +0000
> From: Alan Third <alan@idiocy.org>
> Cc: Eli Zaretskii <eliz@gnu.org>, 30800@debbugs.gnu.org
> 
> > Maybe this is a weird idea, but what if we apply my patch, then revert
> > the code and my patch so that if the flicker returns and the revert is
> > reverted at least the crash would be fixed?
> 
> That would be up to Eli, but I think we should at least put your patch
> in Emacs 26.

What patch is that?  Can you show it to me?

bug#30800: 26.0.91; unknown crash on macos

[Alan Third]

On Sat, Mar 24, 2018 at 05:54:16PM +0300, Eli Zaretskii wrote:
> > Date: Sat, 24 Mar 2018 10:29:58 +0000
> > From: Alan Third <alan@idiocy.org>
> > Cc: Eli Zaretskii <eliz@gnu.org>, 30800@debbugs.gnu.org
> > 
> > > Maybe this is a weird idea, but what if we apply my patch, then revert
> > > the code and my patch so that if the flicker returns and the revert is
> > > reverted at least the crash would be fixed?
> > 
> > That would be up to Eli, but I think we should at least put your patch
> > in Emacs 26.
> 
> What patch is that?  Can you show it to me?

The one at https://debbugs.gnu.org/cgi/bugreport.cgi?bug=30800#47
-- 
Alan Third

bug#30800: 26.0.91; unknown crash on macos

[Eli Zaretskii]

> Date: Sat, 24 Mar 2018 16:18:37 +0000
> From: Alan Third <alan@idiocy.org>
> Cc: aaronjensen@gmail.com, 30800@debbugs.gnu.org
> 
> > > That would be up to Eli, but I think we should at least put your patch
> > > in Emacs 26.
> > 
> > What patch is that?  Can you show it to me?
> 
> The one at https://debbugs.gnu.org/cgi/bugreport.cgi?bug=30800#47

That patch is okay for emacs-26, and I think it's a change that should
be made regardless of the issue discussed here.

bug#30800: 26.0.91; unknown crash on macos

[Alan Third]

On Sat, Mar 24, 2018 at 08:48:01PM +0300, Eli Zaretskii wrote:
> > Date: Sat, 24 Mar 2018 16:18:37 +0000
> > From: Alan Third <alan@idiocy.org>
> > Cc: aaronjensen@gmail.com, 30800@debbugs.gnu.org
> > 
> > > > That would be up to Eli, but I think we should at least put your patch
> > > > in Emacs 26.
> > > 
> > > What patch is that?  Can you show it to me?
> > 
> > The one at https://debbugs.gnu.org/cgi/bugreport.cgi?bug=30800#47
> 
> That patch is okay for emacs-26, and I think it's a change that should
> be made regardless of the issue discussed here.

Pushed to emacs-26.
-- 
Alan Third

Re: macOS support (was: bug#30800: 26.0.91; unknown crash on macos)

[David Reitter]

On Mar 24, 2018, at 2:35 AM, Eli Zaretskii <eliz@gnu.org> wrote:

> Are there any numbers about how widespread each version is on end-user
> machines?

Better, I can show you the number of unique (and somewhat frequent) Aquamacs Emacs users throughout 2017, below.
(Some of them will have upgraded throughout the year, so they would be counted multiple times.)

In these data, we’re seeing that out of all users, only 2.15% are still on Mac OS X 10.6.  (Full distribution shown below.)

If we do the same for November and December 2017 only.  Now we’re down to 1.21% and 1.24% 10.6 users, respectively.

Looking at queries (which run every third day, as long as Emacs is in use):  Out of the Dec 2017 queries (838) from machine that still run 10.6, only 6% (54) bothered to upgrade to the latest version, which was released in mid-2016.  Clearly, users of very old operating systems also don’t care to upgrade their Emacs.

Now, there are some old Macs that can only run 10.6.  However, clearly, few users will update applications but not never the OS.

I hope these data can support your decision where to direct scarce volunteer resources.



[aquamacs /home/protected]$ ./macos-users v2017
unique users with more than 10 startups:
OS X 10.6 Snow Leopard:
    1074
OS X 10.7 Lion:
     776
OS X 10.8 Mountain Lion:
     726
OS X 10.9 Mavericks:
    2631
OS X 10.10 Yosemite:
    5418
OS X 10.11 El Capitan:
   11526
macOS 10.12 Sierra:
   20594
macOS 10.13 High Sierra:
    7116
—
Total 49861

bug#30800: 26.0.91; unknown crash on macos

[Charles A. Roelli]

> Date: Sat, 24 Mar 2018 14:12:29 +0000
> From: Alan Third <alan@idiocy.org>
> Cc: eliz@gnu.org, 30800@debbugs.gnu.org, aaronjensen@gmail.com
>
> Hi Charles, thanks for offering to check this.
> 
> I’ve attached a patch for the emacs-26 branch that reverts
> d9d383147219f8e6a90d4c177e1b454e19acfac9. It doesn’t revert cleanly,
> hence the patch. You could try reverting it on master if you want, but
> I suspect it will be harder to do.
> 
> Once that’s applied try the reproduction steps in
> 
> https://debbugs.gnu.org/cgi/bugreport.cgi?bug=18757#41
> 
> Basically the code in question has at least one reproducible bug and
> looks as though it should have several more that we haven’t seen yet,
> and although we have a work‐around we’re wondering if we can just get
> rid of it completely as it appears to have been a work‐around for a
> bug introduced in macOS 10.10 and fixed some time later, hopefully
> before 10.10 stopped getting fixes.

Under 10.10.5, I saw no flicker with or without the patch applied.

Re: macOS support (was: bug#30800: 26.0.91; unknown crash on macos)

[Tim Cross]

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

I don't think we are doing users any favours by providing long backwards
compatibility for OS versions, especially if that comes at the cost of code
clarity, maintainability and feature stability. There have been some
significant security patches applied to later versions of OSX. I'm not
suiggesting we immediately drop support for earlier versions, but 10.6 was
released in 2009 - a 9 to 10 year backwards compatibility is probably
excessive - 5 years would probably be a better target.



On 26 March 2018 at 07:08, David Reitter <david.reitter@gmail.com> wrote:

> On Mar 24, 2018, at 2:35 AM, Eli Zaretskii <eliz@gnu.org> wrote:
>
> > Are there any numbers about how widespread each version is on end-user
> > machines?
>
> Better, I can show you the number of unique (and somewhat frequent)
> Aquamacs Emacs users throughout 2017, below.
> (Some of them will have upgraded throughout the year, so they would be
> counted multiple times.)
>
> In these data, we’re seeing that out of all users, only 2.15% are still on
> Mac OS X 10.6.  (Full distribution shown below.)
>
> If we do the same for November and December 2017 only.  Now we’re down to
> 1.21% and 1.24% 10.6 users, respectively.
>
> Looking at queries (which run every third day, as long as Emacs is in
> use):  Out of the Dec 2017 queries (838) from machine that still run 10.6,
> only 6% (54) bothered to upgrade to the latest version, which was released
> in mid-2016.  Clearly, users of very old operating systems also don’t care
> to upgrade their Emacs.
>
> Now, there are some old Macs that can only run 10.6.  However, clearly,
> few users will update applications but not never the OS.
>
> I hope these data can support your decision where to direct scarce
> volunteer resources.
>
>
>
> [aquamacs /home/protected]$ ./macos-users v2017
> unique users with more than 10 startups:
> OS X 10.6 Snow Leopard:
>     1074
> OS X 10.7 Lion:
>      776
> OS X 10.8 Mountain Lion:
>      726
> OS X 10.9 Mavericks:
>     2631
> OS X 10.10 Yosemite:
>     5418
> OS X 10.11 El Capitan:
>    11526
> macOS 10.12 Sierra:
>    20594
> macOS 10.13 High Sierra:
>     7116
> —
> Total 49861
>



-- 
regards,

Tim

--
Tim Cross

[-- Attachment #2: Type: text/html, Size: 2930 bytes --]

Re: macOS support

[Stefan Monnier]

> suiggesting we immediately drop support for earlier versions, but 10.6 was
> released in 2009 - a 9 to 10 year backwards compatibility is probably
> excessive - 5 years would probably be a better target.

As a user of one of those machines which are only supported upto OSX
10.6 (a 2006 macmini), I'm split on this one:
- on the one hand, I strongly disagree with Apple and the rest of the
  industry who wants to force users to keep buying new machines, even
  tho the old ones would still do the job just fine.  So I'd rather that
  Emacs doesn't encourage its users to buy a new machine just because we
  don't support their version of OSX any more.
- on the other, I of course don't use OSX but Debian on that machine,
  and find it actually supports the hardware better than OSX ever has
  (e.g. I can use both the VGA and the DVI output at the same time).
  So I strongly encourage those users who think they're stuck with OSX
  10.6 to upgrade to a Free operating system.


-- Stefan

Re: macOS support

[Paul Eggert]

Stefan Monnier wrote:
>    So I strongly encourage those users who think they're stuck with OSX
>    10.6 to upgrade to a Free operating system.

This makes sense to me too.

Generally speaking Emacs and other GNU projects shouldn't bother supporting 
platforms that are no longer supported by their original issuers. For example, 
starting in 2014 we no longer needed to bother to support IRIX, because SGI no 
longer supported IRIX.

As I understand it, Apple itself supports only the last three or four macOS 
versions. This is not a formal rule that Apple publishes -- Apple being Apple 
keeps such info a secret -- but it's a reasonably accurate description of their 
behavior. With this in mind, I suggest that we now stop worrying about OS X 10.9 
"Mavericks" and earlier, as Apple itself no longer supports these older 
releases. This doesn't mean we need to rip out older code immediately, it just 
means we shouldn't worry about these older releases. Really, we have better 
things to do with our limited resources.

Re: macOS support

[Stefan Monnier]

> Generally speaking Emacs and other GNU projects shouldn't bother supporting
> platforms that are no longer supported by their original issuers.

While I agree with this, by and large, there can be good reasons not to
follow this rule when we disagree with the issuers.

> For example, starting in 2014 we no longer needed to bother to support
> IRIX, because SGI no longer supported IRIX.

This a good example: I think SGI made a pretty good effort of supporting
IRIX for as long as it could make sense, so I'm fine with dropping IRIX
support at the same time as SGI.

> As I understand it, Apple itself supports only the last three or four macOS
> versions.

Note that the issue is not really software support but hardware support:
Apple is pretty aggressive about dropping support for old hardware in
its newer OSes.  They could make OSX 10.11 work on my old macmini but
decided it would be counterproductive for their business.


        Stefan

Re: macOS support

[Tim Cross]

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

I'm not a big fan of Apple either, but do use it (primarily because
employers are more willing to support/allow Apple than Linux and I just
can't do windows, so lesser of two evils really).

However, I have upgraded my old mac mini to High Sierra with no problems. I
can't remember when I actually purchased it, but from vague memory, it
originally came with mountain lion, so that would be 10.8

I believe 10.12/10.13 are supposed to be supported on all mac mini, imac
and macbooks from 2009 models onwards.  My macmini is slow, but it was
always slow. I do run Emacs on it.

Tim

P.S. I also will be putting Debian on my Mini at the end of this year.


On 26 March 2018 at 13:14, Stefan Monnier <monnier@iro.umontreal.ca> wrote:

> > Generally speaking Emacs and other GNU projects shouldn't bother
> supporting
> > platforms that are no longer supported by their original issuers.
>
> While I agree with this, by and large, there can be good reasons not to
> follow this rule when we disagree with the issuers.
>
> > For example, starting in 2014 we no longer needed to bother to support
> > IRIX, because SGI no longer supported IRIX.
>
> This a good example: I think SGI made a pretty good effort of supporting
> IRIX for as long as it could make sense, so I'm fine with dropping IRIX
> support at the same time as SGI.
>
> > As I understand it, Apple itself supports only the last three or four
> macOS
> > versions.
>
> Note that the issue is not really software support but hardware support:
> Apple is pretty aggressive about dropping support for old hardware in
> its newer OSes.  They could make OSX 10.11 work on my old macmini but
> decided it would be counterproductive for their business.
>
>
>         Stefan
>
>
>


-- 
regards,

Tim

--
Tim Cross

[-- Attachment #2: Type: text/html, Size: 2622 bytes --]

Re: macOS support

[Jean-Christophe Helary]

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



> On Mar 26, 2018, at 14:41, Tim Cross <theophilusx@gmail.com> wrote:
> 
> I'm not a big fan of Apple either, but do use it (primarily because employers are more willing to support/allow Apple than Linux and I just can't do windows, so lesser of two evils really). 
> 
> However, I have upgraded my old mac mini to High Sierra with no problems. I can't remember when I actually purchased it, but from vague memory, it originally came with mountain lion, so that would be 10.8
> 
> I believe 10.12/10.13 are supposed to be supported on all mac mini, imac and macbooks from 2009 models onwards.  My macmini is slow, but it was always slow. I do run Emacs on it.

The good thing about Apple hardware is that it is very robust. I still have 15+ years old PPC machines that work flawlessly. If there is a need to draw a line in the sand somewhere it should either be the OS version that first supported intel/32bits *only* or the one that first supported intel/64bits *only*. I'm not sure which is which though.

(@Tim: if you need some speed, think of changing your hard disk to an SSD disk, my 2011 MBP has rejuvenated a way that I never though possible thank to that.)

Jean-Christophe 

> 
> Tim
> 
> P.S. I also will be putting Debian on my Mini at the end of this year. 
> 
> 
> On 26 March 2018 at 13:14, Stefan Monnier <monnier@iro.umontreal.ca <mailto:monnier@iro.umontreal.ca>> wrote:
> > Generally speaking Emacs and other GNU projects shouldn't bother supporting
> > platforms that are no longer supported by their original issuers.
> 
> While I agree with this, by and large, there can be good reasons not to
> follow this rule when we disagree with the issuers.
> 
> > For example, starting in 2014 we no longer needed to bother to support
> > IRIX, because SGI no longer supported IRIX.
> 
> This a good example: I think SGI made a pretty good effort of supporting
> IRIX for as long as it could make sense, so I'm fine with dropping IRIX
> support at the same time as SGI.
> 
> > As I understand it, Apple itself supports only the last three or four macOS
> > versions.
> 
> Note that the issue is not really software support but hardware support:
> Apple is pretty aggressive about dropping support for old hardware in
> its newer OSes.  They could make OSX 10.11 work on my old macmini but
> decided it would be counterproductive for their business.


Jean-Christophe Helary
-----------------------------------------------
http://mac4translators.blogspot.com @brandelune



[-- Attachment #2: Type: text/html, Size: 5024 bytes --]

bug#30800: 26.0.91; unknown crash on macos

[Alan Third]

On Sun, Mar 25, 2018 at 10:14:49PM +0200, Charles A. Roelli wrote:
> Under 10.10.5, I saw no flicker with or without the patch applied.

Thanks Charles.

I think we should revert the change on master and see if anyone
complains. I’ll give it a go in a few days.
-- 
Alan Third

bug#30800: 26.0.91; unknown crash on macos

[Aaron Jensen]

On Mon, Mar 26, 2018 at 11:37 AM, Alan Third <alan@idiocy.org> wrote:
> I think we should revert the change on master and see if anyone
> complains. I’ll give it a go in a few days.

Works for me, assuming the merge from emacs-26 is there w/ the crash
fix so it's all reverted at once.

Re: macOS support

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > I'm not a big fan of Apple either, but do use it (primarily because
  > employers are more willing to support/allow Apple than Linux and I just
  > can't do windows, so lesser of two evils really).

If you're talking about a system roughly comparable with MacOS,
I'm sure you mean GNU/Linux, not Linux which is a kernel only.

Many people do call the system "Linux", but when they do, it treats us
unfairly by attributing our work to someone else.  "Us" includes
everyone contributing to the GNU Project, including everyone that
works on GNU Emacs.  Would you please give us equal mention by saying
"GNU/Linux"?

-- 
Dr Richard Stallman
President, Free Software Foundation (https://gnu.org, https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)
Skype: No way! See https://stallman.org/skype.html.

bug#30800: 26.0.91; unknown crash on macos

[Alan Third]

On Mon, Mar 26, 2018 at 04:03:58PM -0700, Aaron Jensen wrote:
> On Mon, Mar 26, 2018 at 11:37 AM, Alan Third <alan@idiocy.org> wrote:
> > I think we should revert the change on master and see if anyone
> > complains. I’ll give it a go in a few days.
> 
> Works for me, assuming the merge from emacs-26 is there w/ the crash
> fix so it's all reverted at once.

I’ve pushed 733279abedc598a927e66c6f6ac10d1bd9271e79 to master.
-- 
Alan Third

bug#30800: 26.0.91; unknown crash on macos

[Aaron Jensen]

On Fri, Mar 30, 2018 at 4:37 AM, Alan Third <alan@idiocy.org> wrote:
> I’ve pushed 733279abedc598a927e66c6f6ac10d1bd9271e79 to master.

Thanks!