* bug#30800: 26.0.91; unknown crash on macos @ 2018-03-13 16:18 Aaron Jensen 2018-03-13 16:36 ` Aaron Jensen 0 siblings, 1 reply; 50+ messages in thread From: Aaron Jensen @ 2018-03-13 16:18 UTC (permalink / raw) To: 30800 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)) ^ permalink raw reply [flat|nested] 50+ messages in thread
* bug#30800: 26.0.91; unknown crash on macos 2018-03-13 16:18 bug#30800: 26.0.91; unknown crash on macos Aaron Jensen @ 2018-03-13 16:36 ` Aaron Jensen 2018-03-20 23:39 ` Aaron Jensen 0 siblings, 1 reply; 50+ messages in thread From: Aaron Jensen @ 2018-03-13 16:36 UTC (permalink / raw) To: 30800 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 ^ permalink raw reply [flat|nested] 50+ messages in thread
* bug#30800: 26.0.91; unknown crash on macos 2018-03-13 16:36 ` Aaron Jensen @ 2018-03-20 23:39 ` Aaron Jensen 2018-03-21 6:37 ` Eli Zaretskii 0 siblings, 1 reply; 50+ messages in thread From: Aaron Jensen @ 2018-03-20 23:39 UTC (permalink / raw) To: 30800 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 ^ permalink raw reply [flat|nested] 50+ messages in thread
* bug#30800: 26.0.91; unknown crash on macos 2018-03-20 23:39 ` Aaron Jensen @ 2018-03-21 6:37 ` Eli Zaretskii 2018-03-21 16:25 ` Aaron Jensen 0 siblings, 1 reply; 50+ messages in thread From: Eli Zaretskii @ 2018-03-21 6:37 UTC (permalink / raw) To: Aaron Jensen; +Cc: 30800 > 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? ^ permalink raw reply [flat|nested] 50+ messages in thread
* bug#30800: 26.0.91; unknown crash on macos 2018-03-21 6:37 ` Eli Zaretskii @ 2018-03-21 16:25 ` Aaron Jensen 2018-03-21 17:00 ` Eli Zaretskii 0 siblings, 1 reply; 50+ messages in thread From: Aaron Jensen @ 2018-03-21 16:25 UTC (permalink / raw) To: Eli Zaretskii; +Cc: 30800 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 ^ permalink raw reply [flat|nested] 50+ messages in thread
* bug#30800: 26.0.91; unknown crash on macos 2018-03-21 16:25 ` Aaron Jensen @ 2018-03-21 17:00 ` Eli Zaretskii 2018-03-21 17:09 ` Eli Zaretskii 0 siblings, 1 reply; 50+ messages in thread From: Eli Zaretskii @ 2018-03-21 17:00 UTC (permalink / raw) To: Aaron Jensen; +Cc: 30800 > 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. ^ permalink raw reply [flat|nested] 50+ messages in thread
* bug#30800: 26.0.91; unknown crash on macos 2018-03-21 17:00 ` Eli Zaretskii @ 2018-03-21 17:09 ` Eli Zaretskii 2018-03-21 17:31 ` Aaron Jensen 0 siblings, 1 reply; 50+ messages in thread From: Eli Zaretskii @ 2018-03-21 17:09 UTC (permalink / raw) To: aaronjensen, Alan Third; +Cc: 30800 > 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. ^ permalink raw reply [flat|nested] 50+ messages in thread
* bug#30800: 26.0.91; unknown crash on macos 2018-03-21 17:09 ` Eli Zaretskii @ 2018-03-21 17:31 ` Aaron Jensen 2018-03-21 18:22 ` Eli Zaretskii 0 siblings, 1 reply; 50+ messages in thread From: Aaron Jensen @ 2018-03-21 17:31 UTC (permalink / raw) To: Eli Zaretskii; +Cc: Alan Third, 30800 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. ^ permalink raw reply [flat|nested] 50+ messages in thread
* bug#30800: 26.0.91; unknown crash on macos 2018-03-21 17:31 ` Aaron Jensen @ 2018-03-21 18:22 ` Eli Zaretskii 2018-03-21 18:31 ` Aaron Jensen 0 siblings, 1 reply; 50+ messages in thread From: Eli Zaretskii @ 2018-03-21 18:22 UTC (permalink / raw) To: Aaron Jensen; +Cc: alan, 30800 > 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? ^ permalink raw reply [flat|nested] 50+ messages in thread
* bug#30800: 26.0.91; unknown crash on macos 2018-03-21 18:22 ` Eli Zaretskii @ 2018-03-21 18:31 ` Aaron Jensen 2018-03-21 18:48 ` Eli Zaretskii 0 siblings, 1 reply; 50+ messages in thread From: Aaron Jensen @ 2018-03-21 18:31 UTC (permalink / raw) To: Eli Zaretskii; +Cc: alan, 30800 [-- 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 --] ^ permalink raw reply [flat|nested] 50+ messages in thread
* bug#30800: 26.0.91; unknown crash on macos 2018-03-21 18:31 ` Aaron Jensen @ 2018-03-21 18:48 ` Eli Zaretskii 2018-03-21 19:19 ` Alan Third 0 siblings, 1 reply; 50+ messages in thread From: Eli Zaretskii @ 2018-03-21 18:48 UTC (permalink / raw) To: Aaron Jensen; +Cc: alan, 30800 > 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.) ^ permalink raw reply [flat|nested] 50+ messages in thread
* bug#30800: 26.0.91; unknown crash on macos 2018-03-21 18:48 ` Eli Zaretskii @ 2018-03-21 19:19 ` Alan Third 2018-03-21 19:36 ` Eli Zaretskii 0 siblings, 1 reply; 50+ messages in thread From: Alan Third @ 2018-03-21 19:19 UTC (permalink / raw) To: Eli Zaretskii; +Cc: 30800, Aaron Jensen 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 ^ permalink raw reply [flat|nested] 50+ messages in thread
* bug#30800: 26.0.91; unknown crash on macos 2018-03-21 19:19 ` Alan Third @ 2018-03-21 19:36 ` Eli Zaretskii 2018-03-21 20:12 ` Alan Third 2018-03-22 5:35 ` Aaron Jensen 0 siblings, 2 replies; 50+ messages in thread From: Eli Zaretskii @ 2018-03-21 19:36 UTC (permalink / raw) To: Alan Third; +Cc: 30800, aaronjensen > 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? ^ permalink raw reply [flat|nested] 50+ messages in thread
* bug#30800: 26.0.91; unknown crash on macos 2018-03-21 19:36 ` Eli Zaretskii @ 2018-03-21 20:12 ` Alan Third 2018-03-22 5:40 ` Aaron Jensen 2018-03-22 5:35 ` Aaron Jensen 1 sibling, 1 reply; 50+ messages in thread From: Alan Third @ 2018-03-21 20:12 UTC (permalink / raw) To: Eli Zaretskii; +Cc: 30800, aaronjensen 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 ^ permalink raw reply [flat|nested] 50+ messages in thread
* bug#30800: 26.0.91; unknown crash on macos 2018-03-21 20:12 ` Alan Third @ 2018-03-22 5:40 ` Aaron Jensen 2018-03-22 7:26 ` Eli Zaretskii 0 siblings, 1 reply; 50+ messages in thread From: Aaron Jensen @ 2018-03-22 5:40 UTC (permalink / raw) To: Alan Third; +Cc: 30800 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? ^ permalink raw reply [flat|nested] 50+ messages in thread
* bug#30800: 26.0.91; unknown crash on macos 2018-03-22 5:40 ` Aaron Jensen @ 2018-03-22 7:26 ` Eli Zaretskii 2018-03-22 15:39 ` Aaron Jensen 0 siblings, 1 reply; 50+ messages in thread From: Eli Zaretskii @ 2018-03-22 7:26 UTC (permalink / raw) To: Aaron Jensen; +Cc: alan, 30800 > 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? ^ permalink raw reply [flat|nested] 50+ messages in thread
* bug#30800: 26.0.91; unknown crash on macos 2018-03-22 7:26 ` Eli Zaretskii @ 2018-03-22 15:39 ` Aaron Jensen 2018-03-22 15:57 ` Eli Zaretskii 0 siblings, 1 reply; 50+ messages in thread From: Aaron Jensen @ 2018-03-22 15:39 UTC (permalink / raw) To: Eli Zaretskii; +Cc: Alan Third, 30800 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. ^ permalink raw reply [flat|nested] 50+ messages in thread
* bug#30800: 26.0.91; unknown crash on macos 2018-03-22 15:39 ` Aaron Jensen @ 2018-03-22 15:57 ` Eli Zaretskii 2018-03-23 1:49 ` Aaron Jensen 2018-03-23 19:52 ` Alan Third 0 siblings, 2 replies; 50+ messages in thread From: Eli Zaretskii @ 2018-03-22 15:57 UTC (permalink / raw) To: Aaron Jensen; +Cc: alan, 30800 > 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. ^ permalink raw reply [flat|nested] 50+ messages in thread
* bug#30800: 26.0.91; unknown crash on macos 2018-03-22 15:57 ` Eli Zaretskii @ 2018-03-23 1:49 ` Aaron Jensen 2018-03-23 8:16 ` Eli Zaretskii 2018-03-23 19:52 ` Alan Third 1 sibling, 1 reply; 50+ messages in thread From: Aaron Jensen @ 2018-03-23 1:49 UTC (permalink / raw) To: Eli Zaretskii; +Cc: Alan Third, 30800 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. ^ permalink raw reply [flat|nested] 50+ messages in thread
* bug#30800: 26.0.91; unknown crash on macos 2018-03-23 1:49 ` Aaron Jensen @ 2018-03-23 8:16 ` Eli Zaretskii 0 siblings, 0 replies; 50+ messages in thread From: Eli Zaretskii @ 2018-03-23 8:16 UTC (permalink / raw) To: Aaron Jensen; +Cc: alan, 30800 > 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. ^ permalink raw reply [flat|nested] 50+ messages in thread
* bug#30800: 26.0.91; unknown crash on macos 2018-03-22 15:57 ` Eli Zaretskii 2018-03-23 1:49 ` Aaron Jensen @ 2018-03-23 19:52 ` Alan Third 2018-03-23 20:57 ` Aaron Jensen ` (2 more replies) 1 sibling, 3 replies; 50+ messages in thread From: Alan Third @ 2018-03-23 19:52 UTC (permalink / raw) To: Eli Zaretskii; +Cc: 30800, Aaron Jensen 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 ^ permalink raw reply [flat|nested] 50+ messages in thread
* bug#30800: 26.0.91; unknown crash on macos 2018-03-23 19:52 ` Alan Third @ 2018-03-23 20:57 ` Aaron Jensen 2018-03-23 21:47 ` macOS support (was: bug#30800: 26.0.91; unknown crash on macos) Alan Third 2018-03-24 7:20 ` bug#30800: 26.0.91; unknown crash on macos Aaron Jensen 2018-03-24 10:49 ` Charles A. Roelli 2 siblings, 1 reply; 50+ messages in thread From: Aaron Jensen @ 2018-03-23 20:57 UTC (permalink / raw) To: Alan Third; +Cc: 30800 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? ^ permalink raw reply [flat|nested] 50+ messages in thread
* macOS support (was: bug#30800: 26.0.91; unknown crash on macos) 2018-03-23 20:57 ` Aaron Jensen @ 2018-03-23 21:47 ` Alan Third 2018-03-24 6:35 ` Eli Zaretskii 0 siblings, 1 reply; 50+ messages in thread From: Alan Third @ 2018-03-23 21:47 UTC (permalink / raw) To: Aaron Jensen; +Cc: emacs-devel 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 ^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: macOS support (was: bug#30800: 26.0.91; unknown crash on macos) 2018-03-23 21:47 ` macOS support (was: bug#30800: 26.0.91; unknown crash on macos) Alan Third @ 2018-03-24 6:35 ` Eli Zaretskii 2018-03-24 7:18 ` Aaron Jensen 2018-03-25 20:08 ` David Reitter 0 siblings, 2 replies; 50+ messages in thread From: Eli Zaretskii @ 2018-03-24 6:35 UTC (permalink / raw) To: Alan Third; +Cc: aaronjensen, emacs-devel > 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? ^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: macOS support (was: bug#30800: 26.0.91; unknown crash on macos) 2018-03-24 6:35 ` Eli Zaretskii @ 2018-03-24 7:18 ` Aaron Jensen 2018-03-24 10:27 ` Alan Third 2018-03-24 14:52 ` Eli Zaretskii 2018-03-25 20:08 ` David Reitter 1 sibling, 2 replies; 50+ messages in thread From: Aaron Jensen @ 2018-03-24 7:18 UTC (permalink / raw) To: Eli Zaretskii; +Cc: Alan Third, emacs-devel 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. ^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: macOS support (was: bug#30800: 26.0.91; unknown crash on macos) 2018-03-24 7:18 ` Aaron Jensen @ 2018-03-24 10:27 ` Alan Third 2018-03-24 14:52 ` Eli Zaretskii 1 sibling, 0 replies; 50+ messages in thread From: Alan Third @ 2018-03-24 10:27 UTC (permalink / raw) To: Aaron Jensen; +Cc: Eli Zaretskii, emacs-devel 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 ^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: macOS support (was: bug#30800: 26.0.91; unknown crash on macos) 2018-03-24 7:18 ` Aaron Jensen 2018-03-24 10:27 ` Alan Third @ 2018-03-24 14:52 ` Eli Zaretskii 1 sibling, 0 replies; 50+ messages in thread From: Eli Zaretskii @ 2018-03-24 14:52 UTC (permalink / raw) To: Aaron Jensen; +Cc: alan, emacs-devel > 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. ^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: macOS support (was: bug#30800: 26.0.91; unknown crash on macos) 2018-03-24 6:35 ` Eli Zaretskii 2018-03-24 7:18 ` Aaron Jensen @ 2018-03-25 20:08 ` David Reitter 2018-03-25 21:24 ` Tim Cross 1 sibling, 1 reply; 50+ messages in thread From: David Reitter @ 2018-03-25 20:08 UTC (permalink / raw) To: Eli Zaretskii; +Cc: Alan Third, aaronjensen, emacs-devel 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 ^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: macOS support (was: bug#30800: 26.0.91; unknown crash on macos) 2018-03-25 20:08 ` David Reitter @ 2018-03-25 21:24 ` Tim Cross 2018-03-25 22:31 ` macOS support Stefan Monnier 0 siblings, 1 reply; 50+ messages in thread From: Tim Cross @ 2018-03-25 21:24 UTC (permalink / raw) To: David Reitter; +Cc: Eli Zaretskii, Alan Third, aaronjensen, Emacs developers [-- 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 --] ^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: macOS support 2018-03-25 21:24 ` Tim Cross @ 2018-03-25 22:31 ` Stefan Monnier 2018-03-26 1:34 ` Paul Eggert 0 siblings, 1 reply; 50+ messages in thread From: Stefan Monnier @ 2018-03-25 22:31 UTC (permalink / raw) To: emacs-devel > 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 ^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: macOS support 2018-03-25 22:31 ` macOS support Stefan Monnier @ 2018-03-26 1:34 ` Paul Eggert 2018-03-26 2:14 ` Stefan Monnier 0 siblings, 1 reply; 50+ messages in thread From: Paul Eggert @ 2018-03-26 1:34 UTC (permalink / raw) To: Stefan Monnier, emacs-devel 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. ^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: macOS support 2018-03-26 1:34 ` Paul Eggert @ 2018-03-26 2:14 ` Stefan Monnier 2018-03-26 5:41 ` Tim Cross 0 siblings, 1 reply; 50+ messages in thread From: Stefan Monnier @ 2018-03-26 2:14 UTC (permalink / raw) To: emacs-devel > 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 ^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: macOS support 2018-03-26 2:14 ` Stefan Monnier @ 2018-03-26 5:41 ` Tim Cross 2018-03-26 5:49 ` Jean-Christophe Helary 2018-03-26 23:07 ` Richard Stallman 0 siblings, 2 replies; 50+ messages in thread From: Tim Cross @ 2018-03-26 5:41 UTC (permalink / raw) To: Stefan Monnier; +Cc: Emacs developers [-- 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 --] ^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: macOS support 2018-03-26 5:41 ` Tim Cross @ 2018-03-26 5:49 ` Jean-Christophe Helary 2018-03-26 23:07 ` Richard Stallman 1 sibling, 0 replies; 50+ messages in thread From: Jean-Christophe Helary @ 2018-03-26 5:49 UTC (permalink / raw) To: Emacs developers [-- 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 --] ^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: macOS support 2018-03-26 5:41 ` Tim Cross 2018-03-26 5:49 ` Jean-Christophe Helary @ 2018-03-26 23:07 ` Richard Stallman 1 sibling, 0 replies; 50+ messages in thread From: Richard Stallman @ 2018-03-26 23:07 UTC (permalink / raw) To: Tim Cross; +Cc: monnier, emacs-devel [[[ 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. ^ permalink raw reply [flat|nested] 50+ messages in thread
* bug#30800: 26.0.91; unknown crash on macos 2018-03-23 19:52 ` Alan Third 2018-03-23 20:57 ` Aaron Jensen @ 2018-03-24 7:20 ` Aaron Jensen 2018-03-24 10:29 ` Alan Third 2018-03-24 10:49 ` Charles A. Roelli 2 siblings, 1 reply; 50+ messages in thread From: Aaron Jensen @ 2018-03-24 7:20 UTC (permalink / raw) To: Alan Third; +Cc: 30800 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? ^ permalink raw reply [flat|nested] 50+ messages in thread
* bug#30800: 26.0.91; unknown crash on macos 2018-03-24 7:20 ` bug#30800: 26.0.91; unknown crash on macos Aaron Jensen @ 2018-03-24 10:29 ` Alan Third 2018-03-24 14:54 ` Eli Zaretskii 0 siblings, 1 reply; 50+ messages in thread From: Alan Third @ 2018-03-24 10:29 UTC (permalink / raw) To: Aaron Jensen; +Cc: 30800 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 ^ permalink raw reply [flat|nested] 50+ messages in thread
* bug#30800: 26.0.91; unknown crash on macos 2018-03-24 10:29 ` Alan Third @ 2018-03-24 14:54 ` Eli Zaretskii 2018-03-24 16:18 ` Alan Third 0 siblings, 1 reply; 50+ messages in thread From: Eli Zaretskii @ 2018-03-24 14:54 UTC (permalink / raw) To: Alan Third; +Cc: 30800, aaronjensen > 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? ^ permalink raw reply [flat|nested] 50+ messages in thread
* bug#30800: 26.0.91; unknown crash on macos 2018-03-24 14:54 ` Eli Zaretskii @ 2018-03-24 16:18 ` Alan Third 2018-03-24 17:48 ` Eli Zaretskii 0 siblings, 1 reply; 50+ messages in thread From: Alan Third @ 2018-03-24 16:18 UTC (permalink / raw) To: Eli Zaretskii; +Cc: 30800, aaronjensen 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 ^ permalink raw reply [flat|nested] 50+ messages in thread
* bug#30800: 26.0.91; unknown crash on macos 2018-03-24 16:18 ` Alan Third @ 2018-03-24 17:48 ` Eli Zaretskii 2018-03-25 19:17 ` Alan Third 0 siblings, 1 reply; 50+ messages in thread From: Eli Zaretskii @ 2018-03-24 17:48 UTC (permalink / raw) To: Alan Third; +Cc: 30800, aaronjensen > 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. ^ permalink raw reply [flat|nested] 50+ messages in thread
* bug#30800: 26.0.91; unknown crash on macos 2018-03-24 17:48 ` Eli Zaretskii @ 2018-03-25 19:17 ` Alan Third 0 siblings, 0 replies; 50+ messages in thread From: Alan Third @ 2018-03-25 19:17 UTC (permalink / raw) To: Eli Zaretskii; +Cc: 30800, aaronjensen 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 ^ permalink raw reply [flat|nested] 50+ messages in thread
* bug#30800: 26.0.91; unknown crash on macos 2018-03-23 19:52 ` Alan Third 2018-03-23 20:57 ` Aaron Jensen 2018-03-24 7:20 ` bug#30800: 26.0.91; unknown crash on macos Aaron Jensen @ 2018-03-24 10:49 ` Charles A. Roelli 2018-03-24 14:12 ` Alan Third 2 siblings, 1 reply; 50+ messages in thread From: Charles A. Roelli @ 2018-03-24 10:49 UTC (permalink / raw) To: Alan Third; +Cc: 30800, aaronjensen > 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. ^ permalink raw reply [flat|nested] 50+ messages in thread
* bug#30800: 26.0.91; unknown crash on macos 2018-03-24 10:49 ` Charles A. Roelli @ 2018-03-24 14:12 ` Alan Third 2018-03-25 20:14 ` Charles A. Roelli 0 siblings, 1 reply; 50+ messages in thread From: Alan Third @ 2018-03-24 14:12 UTC (permalink / raw) To: Charles A. Roelli; +Cc: 30800, aaronjensen [-- 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 ^ permalink raw reply related [flat|nested] 50+ messages in thread
* bug#30800: 26.0.91; unknown crash on macos 2018-03-24 14:12 ` Alan Third @ 2018-03-25 20:14 ` Charles A. Roelli 2018-03-26 18:37 ` Alan Third 0 siblings, 1 reply; 50+ messages in thread From: Charles A. Roelli @ 2018-03-25 20:14 UTC (permalink / raw) To: Alan Third; +Cc: 30800, aaronjensen > 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. ^ permalink raw reply [flat|nested] 50+ messages in thread
* bug#30800: 26.0.91; unknown crash on macos 2018-03-25 20:14 ` Charles A. Roelli @ 2018-03-26 18:37 ` Alan Third 2018-03-26 23:03 ` Aaron Jensen 0 siblings, 1 reply; 50+ messages in thread From: Alan Third @ 2018-03-26 18:37 UTC (permalink / raw) To: Charles A. Roelli; +Cc: 30800, aaronjensen 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 ^ permalink raw reply [flat|nested] 50+ messages in thread
* bug#30800: 26.0.91; unknown crash on macos 2018-03-26 18:37 ` Alan Third @ 2018-03-26 23:03 ` Aaron Jensen 2018-03-30 11:37 ` Alan Third 0 siblings, 1 reply; 50+ messages in thread From: Aaron Jensen @ 2018-03-26 23:03 UTC (permalink / raw) To: Alan Third; +Cc: Charles A. Roelli, 30800 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. ^ permalink raw reply [flat|nested] 50+ messages in thread
* bug#30800: 26.0.91; unknown crash on macos 2018-03-26 23:03 ` Aaron Jensen @ 2018-03-30 11:37 ` Alan Third 2018-03-30 11:57 ` Aaron Jensen 0 siblings, 1 reply; 50+ messages in thread From: Alan Third @ 2018-03-30 11:37 UTC (permalink / raw) To: Aaron Jensen; +Cc: Charles A. Roelli, 30800-done 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 ^ permalink raw reply [flat|nested] 50+ messages in thread
* bug#30800: 26.0.91; unknown crash on macos 2018-03-30 11:37 ` Alan Third @ 2018-03-30 11:57 ` Aaron Jensen 0 siblings, 0 replies; 50+ messages in thread From: Aaron Jensen @ 2018-03-30 11:57 UTC (permalink / raw) To: Alan Third; +Cc: Charles A. Roelli, 30800-done On Fri, Mar 30, 2018 at 4:37 AM, Alan Third <alan@idiocy.org> wrote: > I’ve pushed 733279abedc598a927e66c6f6ac10d1bd9271e79 to master. Thanks! ^ permalink raw reply [flat|nested] 50+ messages in thread
* bug#30800: 26.0.91; unknown crash on macos 2018-03-21 19:36 ` Eli Zaretskii 2018-03-21 20:12 ` Alan Third @ 2018-03-22 5:35 ` Aaron Jensen 2018-03-22 7:16 ` Eli Zaretskii 1 sibling, 1 reply; 50+ messages in thread From: Aaron Jensen @ 2018-03-22 5:35 UTC (permalink / raw) To: Eli Zaretskii; +Cc: Alan Third, 30800 [-- 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 ^ permalink raw reply related [flat|nested] 50+ messages in thread
* bug#30800: 26.0.91; unknown crash on macos 2018-03-22 5:35 ` Aaron Jensen @ 2018-03-22 7:16 ` Eli Zaretskii 0 siblings, 0 replies; 50+ messages in thread From: Eli Zaretskii @ 2018-03-22 7:16 UTC (permalink / raw) To: Aaron Jensen; +Cc: alan, 30800 > 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. ^ permalink raw reply [flat|nested] 50+ messages in thread
end of thread, other threads:[~2018-03-30 11:57 UTC | newest] Thread overview: 50+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2018-03-13 16:18 bug#30800: 26.0.91; unknown crash on macos Aaron Jensen 2018-03-13 16:36 ` Aaron Jensen 2018-03-20 23:39 ` Aaron Jensen 2018-03-21 6:37 ` Eli Zaretskii 2018-03-21 16:25 ` Aaron Jensen 2018-03-21 17:00 ` Eli Zaretskii 2018-03-21 17:09 ` Eli Zaretskii 2018-03-21 17:31 ` Aaron Jensen 2018-03-21 18:22 ` Eli Zaretskii 2018-03-21 18:31 ` Aaron Jensen 2018-03-21 18:48 ` Eli Zaretskii 2018-03-21 19:19 ` Alan Third 2018-03-21 19:36 ` Eli Zaretskii 2018-03-21 20:12 ` Alan Third 2018-03-22 5:40 ` Aaron Jensen 2018-03-22 7:26 ` Eli Zaretskii 2018-03-22 15:39 ` Aaron Jensen 2018-03-22 15:57 ` Eli Zaretskii 2018-03-23 1:49 ` Aaron Jensen 2018-03-23 8:16 ` Eli Zaretskii 2018-03-23 19:52 ` Alan Third 2018-03-23 20:57 ` Aaron Jensen 2018-03-23 21:47 ` macOS support (was: bug#30800: 26.0.91; unknown crash on macos) Alan Third 2018-03-24 6:35 ` Eli Zaretskii 2018-03-24 7:18 ` Aaron Jensen 2018-03-24 10:27 ` Alan Third 2018-03-24 14:52 ` Eli Zaretskii 2018-03-25 20:08 ` David Reitter 2018-03-25 21:24 ` Tim Cross 2018-03-25 22:31 ` macOS support Stefan Monnier 2018-03-26 1:34 ` Paul Eggert 2018-03-26 2:14 ` Stefan Monnier 2018-03-26 5:41 ` Tim Cross 2018-03-26 5:49 ` Jean-Christophe Helary 2018-03-26 23:07 ` Richard Stallman 2018-03-24 7:20 ` bug#30800: 26.0.91; unknown crash on macos Aaron Jensen 2018-03-24 10:29 ` Alan Third 2018-03-24 14:54 ` Eli Zaretskii 2018-03-24 16:18 ` Alan Third 2018-03-24 17:48 ` Eli Zaretskii 2018-03-25 19:17 ` Alan Third 2018-03-24 10:49 ` Charles A. Roelli 2018-03-24 14:12 ` Alan Third 2018-03-25 20:14 ` Charles A. Roelli 2018-03-26 18:37 ` Alan Third 2018-03-26 23:03 ` Aaron Jensen 2018-03-30 11:37 ` Alan Third 2018-03-30 11:57 ` Aaron Jensen 2018-03-22 5:35 ` Aaron Jensen 2018-03-22 7:16 ` Eli Zaretskii
Code repositories for project(s) associated with this external index https://git.savannah.gnu.org/cgit/emacs.git https://git.savannah.gnu.org/cgit/emacs/org-mode.git This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.