* bug#26323: 25.1; Closing frames (in fullscreen) under Mac OS cause immediate crash @ 2017-03-31 13:01 Kevin Sjöberg 2017-03-31 19:13 ` Steve Perry 2017-06-17 16:58 ` Alan Third 0 siblings, 2 replies; 21+ messages in thread From: Kevin Sjöberg @ 2017-03-31 13:01 UTC (permalink / raw) To: 26323 Start Emacs (GUI) and fullscreen the current frame. Create a new frame (C-x 5 2), followed by closing the frame (C-x 5 0). This cause Emacs to crash immediately. This does only happen if both frames are in fullscreen. This is not reproducible if the frames in question are not in fullscreen. In GNU Emacs 25.1.1 (x86_64-apple-darwin13.4.0, NS appkit-1265.21 Version 10.9.5 (Build 13F1911)) of 2016-09-21 built on builder10-9.porkrind.org Windowing system distributor 'Apple', version 10.3.1504 Configured using: 'configure --with-ns '--enable-locallisppath=/Library/Application Support/Emacs/${version}/site-lisp:/Library/Application Support/Emacs/site-lisp' --with-modules' Configured features: NOTIFY ACL GNUTLS LIBXML2 ZLIB TOOLKIT_SCROLL_BARS NS MODULES Important settings: value of $LANG: en_SE.UTF-8 locale-coding-system: utf-8-unix Major mode: Messages Minor modes in effect: diff-auto-refine-mode: t global-flycheck-mode: t projectile-mode: t ido-everywhere: t tooltip-mode: t global-eldoc-mode: t electric-indent-mode: t mouse-wheel-mode: t file-name-shadow-mode: t global-font-lock-mode: t font-lock-mode: t blink-cursor-mode: t auto-composition-mode: t auto-encryption-mode: t auto-compression-mode: t buffer-read-only: t line-number-mode: t transient-mark-mode: t Recent messages: user-error: No further undo information [4 times] C-x c is undefined Buffer create_game_url.go modified; kill anyway? (y or n) n Undo! [4 times] user-error: No further undo information [20 times] Quit Auto-saving...done Mark set [3 times] GNU Emacs 25.1.1 (x86_64-apple-darwin13.4.0, NS appkit-1265.21 Version 10.9.5 (Build 13F1911)) of 2016-09-21 user-error: Minibuffer window is not active Load-path shadows: None found. Features: (shadow sort mail-extr emacsbug message dired format-spec rfc822 mml mml-sec epg mm-decode mm-bodies mm-encode mail-parse rfc2231 mailabbrev gmm-utils mailheader sendmail rfc2047 rfc2045 ietf-drums mail-utils reposition kmacro term disp-table ehelp vc-git diff-mode easy-mmode imenu go-mode url url-proxy url-privacy url-expand url-methods url-history url-cookie url-domsuf url-util mailcap find-file ffap url-parse auth-source gnus-util mm-util help-fns mail-prsvr password-cache url-vars etags xref project eieio eieio-core cl-macs solarized-light-theme solarized color flycheck json map find-func rx subr-x dash projectile cl-seq advice grep compile comint ansi-color ring ibuf-ext ibuffer thingatpt exec-path-from-shell ido finder-inf info package epg-config seq byte-opt gv bytecomp byte-compile cl-extra help-mode easymenu cconv cl-loaddefs pcase cl-lib time-date mule-util tooltip eldoc electric uniquify ediff-hook vc-hooks lisp-float-type mwheel ns-win ucs-normalize term/common-win tool-bar dnd fontset image regexp-opt fringe tabulated-list newcomment elisp-mode lisp-mode prog-mode register page menu-bar rfn-eshadow timer select scroll-bar mouse jit-lock font-lock syntax facemenu font-core frame cl-generic cham georgian utf-8-lang misc-lang vietnamese tibetan thai tai-viet lao korean japanese eucjp-ms cp51932 hebrew greek romanian slovak czech european ethiopic indian cyrillic chinese charscript case-table epa-hook jka-cmpr-hook help simple abbrev minibuffer cl-preloaded nadvice loaddefs button faces cus-face macroexp files text-properties overlay sha1 md5 base64 format env code-pages mule custom widget hashtable-print-readable backquote kqueue cocoa ns multi-tty make-network-process emacs) Memory information: ((conses 16 392331 30134) (symbols 48 32221 1) (miscs 40 166 561) (strings 32 59514 9151) (string-bytes 1 1667893) (vectors 16 49476) (vector-slots 8 851380 10423) (floats 8 540 547) (intervals 56 4042 84) (buffers 976 26)) ^ permalink raw reply [flat|nested] 21+ messages in thread
* bug#26323: 25.1; Closing frames (in fullscreen) under Mac OS cause immediate crash 2017-03-31 13:01 bug#26323: 25.1; Closing frames (in fullscreen) under Mac OS cause immediate crash Kevin Sjöberg @ 2017-03-31 19:13 ` Steve Perry 2017-06-17 16:58 ` Alan Third 1 sibling, 0 replies; 21+ messages in thread From: Steve Perry @ 2017-03-31 19:13 UTC (permalink / raw) To: 26323 Can also see this problem in 26.0.50. FWIW f is non-NULL and the contents look reasonable. Backtrace etc.: Process 73590 stopped * thread #1: tid = 0x103905a, 0x00000001001bc3c1 Emacs`ns_clear_frame_area(f=0x0000000103a1cc18, x=0, y=0, width=595, height=564) + 65 at nsterm.m:2414, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=1, address=0x20) frame #0: 0x00000001001bc3c1 Emacs`ns_clear_frame_area(f=0x0000000103a1cc18, x=0, y=0, width=595, height=564) + 65 at nsterm.m:2414 [opt] 2411 { 2412 NSRect r = NSMakeRect (x, y, width, height); 2413 NSView *view = FRAME_NS_VIEW (f); -> 2414 struct face *face = FRAME_DEFAULT_FACE (f); 2415 2416 if (!view || !face) 2417 return; (lldb) bt * thread #1: tid = 0x103905a, 0x00000001001bc3c1 Emacs`ns_clear_frame_area(f=0x0000000103a1cc18, x=0, y=0, width=595, height=564) + 65 at nsterm.m:2414, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=1, address=0x20) * frame #0: 0x00000001001bc3c1 Emacs`ns_clear_frame_area(f=0x0000000103a1cc18, x=0, y=0, width=595, height=564) + 65 at nsterm.m:2414 [opt] frame #1: 0x00000001001bc334 Emacs`-[EmacsView drawRect:](self=0x0000000111626c90, _cmd=<unavailable>, rect=(origin = (x = 0, y = 0), size = (width = 595, height = 564))) + 84 at nsterm.m:7497 [opt] frame #2: 0x00007fffa00a5af9 AppKit`-[NSView _drawRect:clip:] + 2276 frame #3: 0x00007fffa00f5aab AppKit`-[NSView _recursiveDisplayAllDirtyWithLockFocus:visRect:] + 1753 frame #4: 0x00007fffa00f5f16 AppKit`-[NSView _recursiveDisplayAllDirtyWithLockFocus:visRect:] + 2884 frame #5: 0x00007fffa00f5f16 AppKit`-[NSView _recursiveDisplayAllDirtyWithLockFocus:visRect:] + 2884 frame #6: 0x00007fffa00a3632 AppKit`-[NSView _recursiveDisplayRectIfNeededIgnoringOpacity:isVisibleRect:rectIsVisibleRectForView:topView:] + 837 frame #7: 0x00007fffa00a2e0f AppKit`-[NSThemeFrame _recursiveDisplayRectIfNeededIgnoringOpacity:isVisibleRect:rectIsVisibleRectForView:topView:] + 334 frame #8: 0x00007fffa00a1238 AppKit`-[NSView _displayRectIgnoringOpacity:isVisibleRect:rectIsVisibleRectForView:] + 2452 frame #9: 0x00007fffa009cb25 AppKit`-[NSView displayIfNeeded] + 1748 frame #10: 0x00007fffa009c437 AppKit`-[NSWindow displayIfNeeded] + 230 frame #11: 0x00007fffa07faf3f AppKit`___NSWindowGetDisplayCycleObserver_block_invoke.6228 + 277 frame #12: 0x00007fffa009bf15 AppKit`__37+[NSDisplayCycle currentDisplayCycle]_block_invoke + 454 frame #13: 0x00007fffa814aa96 QuartzCore`CA::Transaction::run_commit_handlers(CATransactionPhase) + 46 frame #14: 0x00007fffa8252800 QuartzCore`CA::Context::commit_transaction(CA::Transaction*) + 160 frame #15: 0x00007fffa8149631 QuartzCore`CA::Transaction::commit() + 475 frame #16: 0x00007fffa8149f92 QuartzCore`CA::Transaction::observer_callback(__CFRunLoopObserver*, unsigned long, void*) + 108 frame #17: 0x00007fffa243b397 CoreFoundation`__CFRUNLOOP_IS_CALLING_OUT_TO_AN_OBSERVER_CALLBACK_FUNCTION__ + 23 frame #18: 0x00007fffa243b307 CoreFoundation`__CFRunLoopDoObservers + 391 frame #19: 0x00007fffa241b996 CoreFoundation`CFRunLoopRunSpecific + 454 frame #20: 0x00007fffa19a7a5c HIToolbox`RunCurrentEventLoopInMode + 240 frame #21: 0x00007fffa19a7799 HIToolbox`ReceiveNextEventCommon + 184 frame #22: 0x00007fffa19a76c6 HIToolbox`_BlockUntilNextEventMatchingListInModeWithFilter + 71 frame #23: 0x00007fff9ff4d5b4 AppKit`_DPSNextEvent + 1120 frame #24: 0x00007fffa06c7d6b AppKit`-[NSApplication(NSEvent) _nextEventMatchingEventMask:untilDate:inMode:dequeue:] + 2789 frame #25: 0x00000001001b2daf Emacs`ns_send_appdefined(value=-1) + 143 at nsterm.m:3890 [opt] frame #26: 0x00007fffa2431a6c CoreFoundation`__CFNOTIFICATIONCENTER_IS_CALLING_OUT_TO_AN_OBSERVER__ + 12 frame #27: 0x00007fffa243196b CoreFoundation`_CFXRegistrationPost + 427 frame #28: 0x00007fffa24316d2 CoreFoundation`___CFXNotificationPost_block_invoke + 50 frame #29: 0x00007fffa23eed63 CoreFoundation`-[_CFXNotificationRegistrar find:object:observer:enumerator:] + 1827 frame #30: 0x00007fffa23edd9c CoreFoundation`_CFXNotificationPost + 604 frame #31: 0x00007fffa3e14a37 Foundation`-[NSNotificationCenter postNotificationName:object:userInfo:] + 66 frame #32: 0x00007fffa0019fc3 AppKit`-[NSWindow _setFrameCommon:display:stashSize:] + 3326 frame #33: 0x00007fffa00192b7 AppKit`-[NSWindow _setFrame:display:allowImplicitAnimation:stashSize:] + 222 frame #34: 0x00007fffa00191d2 AppKit`-[NSWindow setFrame:display:] + 67 frame #35: 0x00000001001bdfba Emacs`-[EmacsWindow setFrame:display:](self=<unavailable>, _cmd=<unavailable>, windowFrame=(origin = (x = 543, y = 405), size = (width = 595, height = 564)), displayViews=<unavailable>) + 74 at nsterm.m:7948 [opt] frame #36: 0x00007fffa02624f4 AppKit`-[NSWindow _didExitFullScreen:] + 226 frame #37: 0x00007fffa099073f AppKit`__123-[_NSWindowFullScreenTransition _performExitFullScreenModeForWindow:windowController:options:customWindows:doKitAnimation:]_block_invoke_2 + 390 frame #38: 0x00007fffa09904c5 AppKit`__123-[_NSWindowFullScreenTransition _performExitFullScreenModeForWindow:windowController:options:customWindows:doKitAnimation:]_block_invoke + 1191 frame #39: 0x00007fffa098ffbf AppKit`-[_NSWindowFullScreenTransition _performExitFullScreenModeForWindow:windowController:options:customWindows:doKitAnimation:] + 1616 frame #40: 0x00007fffa0991355 AppKit`-[_NSWindowFullScreenTransition exitFullScreenTransitionForWindow:options:] + 895 frame #41: 0x00007fffa0363776 AppKit`-[NSWindow(NSWindowTabbing) _doTabbedWindowCleanupForOrderOut] + 228 frame #42: 0x00007fffa01e44cd AppKit`__18-[NSWindow _close]_block_invoke + 82 frame #43: 0x00007fffa01e442c AppKit`-[NSWindow _close] + 365 frame #44: 0x00000001001b1394 Emacs`x_free_frame_resources(f=0x0000000103a1cc18) + 292 at nsterm.m:1656 [opt] frame #45: 0x00000001001b13d6 Emacs`x_destroy_window(f=0x0000000103a1cc18) + 22 at nsterm.m:1672 [opt] frame #46: 0x000000010001046c Emacs`delete_frame(frame=<unavailable>, force=<unavailable>) + 1260 at frame.c:1718 [opt] frame #47: 0x000000010013f168 Emacs`funcall_subr(subr=0x0000000100228e20, numargs=0, args=<unavailable>) + 248 at eval.c:2820 [opt] frame #48: 0x000000010013e75f Emacs`Ffuncall(nargs=<unavailable>, args=<unavailable>) + 735 at eval.c:2743 [opt] frame #49: 0x0000000100137ff6 Emacs`Ffuncall_interactively(nargs=<unavailable>, args=<unavailable>) + 70 at callint.c:252 [opt] frame #50: 0x000000010013e75f Emacs`Ffuncall(nargs=<unavailable>, args=<unavailable>) + 735 at eval.c:2743 [opt] frame #51: 0x00000001001395dd Emacs`Fcall_interactively(function=<unavailable>, record_flag=0, keys=<unavailable>) + 5581 at callint.c:843 [opt] frame #52: 0x000000010013f17c Emacs`funcall_subr(subr=0x000000010058c880, numargs=3, args=<unavailable>) + 268 at eval.c:2823 [opt] frame #53: 0x000000010013e75f Emacs`Ffuncall(nargs=<unavailable>, args=<unavailable>) + 735 at eval.c:2743 [opt] frame #54: 0x000000010017ae3a Emacs`exec_byte_code(bytestr=<unavailable>, vector=<unavailable>, maxdepth=<unavailable>, args_template=4102, nargs=<unavailable>, args=<unavailable>) + 1738 at bytecode.c:641 [opt] frame #55: 0x000000010013e700 Emacs`Ffuncall(nargs=<unavailable>, args=<unavailable>) + 640 at eval.c:2745 [opt] frame #56: 0x000000010013ee3d Emacs`call1(fn=<unavailable>, arg1=<unavailable>) + 45 at eval.c:2605 [opt] frame #57: 0x00000001000bfb17 Emacs`command_loop_1 + 1895 at keyboard.c:1484 [opt] frame #58: 0x000000010013cf67 Emacs`internal_condition_case(bfun=(Emacs`command_loop_1 at keyboard.c:1261), handlers=<unavailable>, hfun=(Emacs`cmd_error at keyboard.c:940)) + 87 at eval.c:1324 [opt] frame #59: 0x00000001000ce970 Emacs`command_loop_2(ignore=<unavailable>) + 48 at keyboard.c:1112 [opt] frame #60: 0x000000010013c82e Emacs`internal_catch(tag=<unavailable>, func=(Emacs`command_loop_2 at keyboard.c:1108), arg=0) + 78 at eval.c:1091 [opt] frame #61: 0x00000001000beaae Emacs`command_loop + 158 at keyboard.c:1091 [opt] frame #62: 0x00000001000be9bf Emacs`recursive_edit_1 + 111 at keyboard.c:697 [opt] frame #63: 0x00000001000bebf3 Emacs`Frecursive_edit + 227 at keyboard.c:768 [opt] frame #64: 0x00000001000bd7d8 Emacs`main(argc=0, argv=<unavailable>) + 6072 at emacs.c:1683 [opt] frame #65: 0x00007fffb7973255 libdyld.dylib`start + 1 ^ permalink raw reply [flat|nested] 21+ messages in thread
* bug#26323: 25.1; Closing frames (in fullscreen) under Mac OS cause immediate crash 2017-03-31 13:01 bug#26323: 25.1; Closing frames (in fullscreen) under Mac OS cause immediate crash Kevin Sjöberg 2017-03-31 19:13 ` Steve Perry @ 2017-06-17 16:58 ` Alan Third 2017-06-20 16:50 ` Stephen Perry 1 sibling, 1 reply; 21+ messages in thread From: Alan Third @ 2017-06-17 16:58 UTC (permalink / raw) To: Kevin Sjöberg; +Cc: Steve Perry, 26323-done kev.sjoberg@gmail.com (Kevin Sjöberg) writes: > Start Emacs (GUI) and fullscreen the current frame. Create a new frame > (C-x 5 2), followed by closing the frame (C-x 5 0). This cause Emacs to > crash immediately. This does only happen if both frames are in > fullscreen. > > This is not reproducible if the frames in question are not in fullscreen. I believe this is fixed in master. At least, I can't reproduce any more. I think the changes to allow undecorated frames, etc., did it. Let me know if you still get the crashes. -- Alan Third ^ permalink raw reply [flat|nested] 21+ messages in thread
* bug#26323: 25.1; Closing frames (in fullscreen) under Mac OS cause immediate crash 2017-06-17 16:58 ` Alan Third @ 2017-06-20 16:50 ` Stephen Perry 0 siblings, 0 replies; 21+ messages in thread From: Stephen Perry @ 2017-06-20 16:50 UTC (permalink / raw) To: Alan Third; +Cc: Kevin Sjöberg, 26323-done I’m no longer able to reproduce this problem in master. ^ permalink raw reply [flat|nested] 21+ messages in thread
* bug#26323: 25.1; Closing frames (in fullscreen) under Mac OS cause immediate crash @ 2018-03-16 0:54 Matthew Bauer 2018-03-16 10:47 ` Alan Third 0 siblings, 1 reply; 21+ messages in thread From: Matthew Bauer @ 2018-03-16 0:54 UTC (permalink / raw) To: alan; +Cc: emacs-devel Hi Alan, This is still an issue for me. Note that to reproduce you must have "tabbing" enabled through macOS: System Preferences -> Dock -> Prefer tabs when opening document -> Always Any idea what is going on? It's still happening in my 26.0.91 build, so I'm assuming it hasn't been fixed in master). ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: bug#26323: 25.1; Closing frames (in fullscreen) under Mac OS cause immediate crash 2018-03-16 0:54 Matthew Bauer @ 2018-03-16 10:47 ` Alan Third 2018-03-16 18:12 ` David Reitter 0 siblings, 1 reply; 21+ messages in thread From: Alan Third @ 2018-03-16 10:47 UTC (permalink / raw) To: Matthew Bauer; +Cc: emacs-devel On Thu, Mar 15, 2018 at 07:54:56PM -0500, Matthew Bauer wrote: > Hi Alan, > > This is still an issue for me. Note that to reproduce you must have > "tabbing" enabled through macOS: > > System Preferences -> Dock -> Prefer tabs when opening document -> Always > > Any idea what is going on? It's still happening in my 26.0.91 build, > so I'm assuming it hasn't been fixed in master). Hi, are you building your own Emacs or downloading it from somewhere else? -- Alan Third ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: bug#26323: 25.1; Closing frames (in fullscreen) under Mac OS cause immediate crash 2018-03-16 10:47 ` Alan Third @ 2018-03-16 18:12 ` David Reitter 2018-03-18 11:15 ` Alan Third 0 siblings, 1 reply; 21+ messages in thread From: David Reitter @ 2018-03-16 18:12 UTC (permalink / raw) To: Alan Third; +Cc: Matthew Bauer, emacs-devel On Mar 16, 2018, at 6:47 AM, Alan Third <alan@idiocy.org> wrote: > > Hi, are you building your own Emacs or downloading it from somewhere > else? I just reproduced Matthew’s bug, several times (relevant portion of stack trace below). Just open a few new frames (which is redirected to a tab), then close the frame. It reproduced in a mid-2016 build, and in a current build (based on the 25 branch). 10 libsystem_platform.dylib 0x00007fff61c3ff5a _sigtramp + 26 11 ??? 000000000000000000 0 + 0 12 org.gnu.Aquamacs 0x00000001001c5fa4 -[EmacsView drawRect:] + 84 13 com.apple.AppKit 0x00007fff37f3bc21 _NSViewDrawRect + 83 14 com.apple.AppKit 0x00007fff377d4b38 -[NSView _drawRect:clip:] + 1819 15 com.apple.AppKit 0x00007fff3781cf62 -[NSView _recursiveDisplayAllDirtyWithLockFocus:visRect:] + 1735 16 com.apple.AppKit 0x00007fff3781d42f -[NSView _recursiveDisplayAllDirtyWithLockFocus:visRect:] + 2964 17 com.apple.AppKit 0x00007fff3781d42f -[NSView _recursiveDisplayAllDirtyWithLockFocus:visRect:] + 2964 18 com.apple.AppKit 0x00007fff377d2a52 -[NSView _recursiveDisplayRectIfNeededIgnoringOpacity:isVisibleRect:rectIsVisibleRectForView:topView:] + 938 19 com.apple.AppKit 0x00007fff377d21db -[NSThemeFrame _recursiveDisplayRectIfNeededIgnoringOpacity:isVisibleRect:rectIsVisibleRectForView:topView:] + 327 20 com.apple.AppKit 0x00007fff37f3d1d8 -[NSView _oldDisplayRectIgnoringOpacity:isVisibleRect:rectIsVisibleRectForView:] + 2051 21 com.apple.AppKit 0x00007fff377d1261 -[NSView _displayRectIgnoringOpacity:isVisibleRect:rectIsVisibleRectForView:] + 253 22 com.apple.AppKit 0x00007fff377cd4b8 -[NSView displayIfNeeded] + 1581 23 com.apple.AppKit 0x00007fff37757dc1 -[NSThemeFrame handleSetFrameCommonRedisplay] + 281 24 com.apple.AppKit 0x00007fff3774fa1d -[NSWindow _setFrameCommon:display:stashSize:] + 4103 25 com.apple.AppKit 0x00007fff3774ea09 -[NSWindow _setFrame:display:allowImplicitAnimation:stashSize:] + 222 26 com.apple.AppKit 0x00007fff3784d42c -[NSWindow setFrame:display:animate:] + 647 27 org.gnu.Aquamacs 0x00000001001c834a -[EmacsWindow setFrame:display:animate:] + 74 28 com.apple.AppKit 0x00007fff37ee4d42 -[NSThemeFrame _growWindowReshapeContentAndToolbarView:withOldToolbarFrameSize:animate:] + 1371 29 com.apple.AppKit 0x00007fff37ee50a0 -[NSThemeFrame _reshapeContentAndToolbarView:withOldToolbarFrameSize:resizeWindow:animate:] + 494 30 com.apple.AppKit 0x00007fff3774c32c -[NSThemeFrame _toolbarFrameSizeChanged:oldSize:] + 66 31 com.apple.AppKit 0x00007fff3784ccb0 -[NSWindow _toolbarFrameSizeChanged:oldSize:] + 93 32 com.apple.AppKit 0x00007fff3772236a -[NSToolbarView _layoutDirtyItemViewersAndTileToolbar] + 5826 33 com.apple.AppKit 0x00007fff37713bfd -[NSToolbar _noteToolbarShowsBaselinePropertyChanged] + 27 34 com.apple.AppKit 0x00007fff37f02219 -[NSToolbar _setHideBaselineOverride:] + 96 35 com.apple.AppKit 0x00007fff37eeaff0 -[NSWindowStackController _removeTabBarAccessoryViewControllerForWindow:] + 271 36 com.apple.AppKit 0x00007fff37eebe52 -[NSWindowStackController removeWindow:] + 277 37 com.apple.AppKit 0x00007fff37a75cb5 -[NSWindow(NSWindowTabbing) _doTabbedWindowCleanupForOrderOut] + 97 38 com.apple.AppKit 0x00007fff37f5ef44 -[NSWindow _finishClosingWindow] + 73 39 com.apple.AppKit 0x00007fff378ff264 -[NSWindow _close] + 378 40 org.gnu.Aquamacs 0x00000001001b770d x_free_frame_resources + 301 41 org.gnu.Aquamacs 0x00000001001b7756 x_destroy_window + 22 42 org.gnu.Aquamacs 0x0000000100010250 delete_frame + 1440 ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: bug#26323: 25.1; Closing frames (in fullscreen) under Mac OS cause immediate crash 2018-03-16 18:12 ` David Reitter @ 2018-03-18 11:15 ` Alan Third 2018-03-18 11:17 ` David Reitter 2018-03-19 2:05 ` Matthew Bauer 0 siblings, 2 replies; 21+ messages in thread From: Alan Third @ 2018-03-18 11:15 UTC (permalink / raw) To: David Reitter; +Cc: Matthew Bauer, emacs-devel On Fri, Mar 16, 2018 at 02:12:32PM -0400, David Reitter wrote: > I just reproduced Matthew’s bug, several times (relevant portion of stack trace below). > Just open a few new frames (which is redirected to a tab), then close the frame. > > It reproduced in a mid-2016 build, and in a current build (based on the 25 branch). It was fixed after that. I can’t reproduce it in Emacs 26. I want to know how Matthew got his copy of Emacs as the code to turn off Sierra tab support is only included when built on Sierra+ or when using the right build options. As far as I’m aware emacsformacosx.com builds, for example, don’t include it yet. -- Alan Third ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: bug#26323: 25.1; Closing frames (in fullscreen) under Mac OS cause immediate crash 2018-03-18 11:15 ` Alan Third @ 2018-03-18 11:17 ` David Reitter 2018-03-18 11:30 ` Alan Third 2018-03-18 18:14 ` John Wiegley 2018-03-19 2:05 ` Matthew Bauer 1 sibling, 2 replies; 21+ messages in thread From: David Reitter @ 2018-03-18 11:17 UTC (permalink / raw) To: Alan Third; +Cc: Matthew Bauer, emacs-devel On Mar 18, 2018, at 7:15 AM, Alan Third <alan@idiocy.org> wrote: >> It reproduced in a mid-2016 build, and in a current build (based on the 25 branch). > > It was fixed after that. I can’t reproduce it in Emacs 26. Is this going to be backported to 25? > I want to know how Matthew got his copy of Emacs as the code to turn > off Sierra tab support is only included when built on Sierra+ or when > using the right build options. That suggests the “fix” is to turn off tab support - is that right? ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: bug#26323: 25.1; Closing frames (in fullscreen) under Mac OS cause immediate crash 2018-03-18 11:17 ` David Reitter @ 2018-03-18 11:30 ` Alan Third 2018-03-18 18:14 ` John Wiegley 1 sibling, 0 replies; 21+ messages in thread From: Alan Third @ 2018-03-18 11:30 UTC (permalink / raw) To: David Reitter; +Cc: Matthew Bauer, emacs-devel On Sun, Mar 18, 2018 at 07:17:34AM -0400, David Reitter wrote: > On Mar 18, 2018, at 7:15 AM, Alan Third <alan@idiocy.org> wrote: > > >> It reproduced in a mid-2016 build, and in a current build (based on the 25 branch). > > > > It was fixed after that. I can’t reproduce it in Emacs 26. > > Is this going to be backported to 25? No, I’m pretty sure it isn’t. > > I want to know how Matthew got his copy of Emacs as the code to turn > > off Sierra tab support is only included when built on Sierra+ or when > > using the right build options. > > That suggests the “fix” is to turn off tab support - is that right? I’m not sure, to be honest, but Matthew said he could only reproduce the problem with tab support on. I have tab support on in the OS and can’t reproduce it. The relevant code is: /* macOS Sierra automatically enables tabbed windows. We can't allow this to be enabled until it's available on a Free system. Currently it only happens by accident and is buggy anyway. */ #if defined (NS_IMPL_COCOA) \ && MAC_OS_X_VERSION_MAX_ALLOWED >= 101200 #if MAC_OS_X_VERSION_MIN_REQUIRED < 101200 if ([win respondsToSelector: @selector(setTabbingMode:)]) #endif [win setTabbingMode: NSWindowTabbingModeDisallowed]; #endif at the bottom of initFrameFromEmacs in nsterm.m. It’s possible we need to include similar code for fullscreen (I can’t remember if the fullscreen code uses initFrameFromEmacs), but it seems OK here. -- Alan Third ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: bug#26323: 25.1; Closing frames (in fullscreen) under Mac OS cause immediate crash 2018-03-18 11:17 ` David Reitter 2018-03-18 11:30 ` Alan Third @ 2018-03-18 18:14 ` John Wiegley 2018-03-18 20:14 ` Alan Third 1 sibling, 1 reply; 21+ messages in thread From: John Wiegley @ 2018-03-18 18:14 UTC (permalink / raw) To: David Reitter; +Cc: Alan Third, Matthew Bauer, emacs-devel >>>>> "DR" == David Reitter <david.reitter@gmail.com> writes: DR> On Mar 18, 2018, at 7:15 AM, Alan Third <alan@idiocy.org> wrote: >>> It reproduced in a mid-2016 build, and in a current build (based on the 25 >>> branch). >> >> It was fixed after that. I can’t reproduce it in Emacs 26. DR> Is this going to be backported to 25? When was this fixed? It happens to me in Emacs 26 every time. -- John Wiegley GPG fingerprint = 4710 CF98 AF9B 327B B80F http://newartisans.com 60E1 46C4 BD1A 7AC1 4BA2 ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: bug#26323: 25.1; Closing frames (in fullscreen) under Mac OS cause immediate crash 2018-03-18 18:14 ` John Wiegley @ 2018-03-18 20:14 ` Alan Third 2018-03-19 0:37 ` Nick Helm 0 siblings, 1 reply; 21+ messages in thread From: Alan Third @ 2018-03-18 20:14 UTC (permalink / raw) To: David Reitter, Matthew Bauer, emacs-devel On Sun, Mar 18, 2018 at 11:14:04AM -0700, John Wiegley wrote: > >>>>> "DR" == David Reitter <david.reitter@gmail.com> writes: > > DR> On Mar 18, 2018, at 7:15 AM, Alan Third <alan@idiocy.org> wrote: > >>> It reproduced in a mid-2016 build, and in a current build (based on the 25 > >>> branch). > >> > >> It was fixed after that. I can’t reproduce it in Emacs 26. > > DR> Is this going to be backported to 25? > > When was this fixed? It happens to me in Emacs 26 every time. I haven’t been able to replicate it since sometime around the middle of last year. Additionally there was a fix for macOS 10.13 installed in emacs-26 in October last year. I still can’t replicate it. If anyone is able to provide a backtrace for either emacs 26 or the master branch crashing, that would be helpful. -- Alan Third ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: bug#26323: 25.1; Closing frames (in fullscreen) under Mac OS cause immediate crash 2018-03-18 20:14 ` Alan Third @ 2018-03-19 0:37 ` Nick Helm 2018-03-19 12:29 ` Alan Third 0 siblings, 1 reply; 21+ messages in thread From: Nick Helm @ 2018-03-19 0:37 UTC (permalink / raw) To: Alan Third; +Cc: emacs-devel On Sun, 18 Mar 2018 at 20:14:16 +0000, Alan Third wrote: > If anyone is able to provide a backtrace for either emacs 26 or the > master branch crashing, that would be helpful. I can't reproduce this using a current build on macOS HS (either emacs-26 or master), but I can with a prebuilt download from emacsformacosx.com. The emacs-26 branch (dated 2018.01.23) and master (dated 2018.02.22) crash every time. I don't know what system these were built on. Here's a backtrace from 27.0.50, if it's useful: Thread 0 Crashed:: Dispatch queue: com.apple.main-thread 0 libsystem_kernel.dylib 0x00007fff7fb6fe3e __pthread_kill + 10 1 libsystem_pthread.dylib 0x00007fff7fcae150 pthread_kill + 333 2 libsystem_c.dylib 0x00007fff7fa7e8fe raise + 26 3 Emacs-x86_64-10_9 0x00000001000bdc11 terminate_due_to_signal + 161 4 Emacs-x86_64-10_9 0x00000001000da9c3 emacs_abort + 19 5 Emacs-x86_64-10_9 0x00000001001be94c ns_term_shutdown + 124 6 Emacs-x86_64-10_9 0x00000001000bddf5 shut_down_emacs + 261 7 Emacs-x86_64-10_9 0x00000001000bdbd6 terminate_due_to_signal + 102 8 Emacs-x86_64-10_9 0x00000001000dc2f6 deliver_fatal_thread_signal + 134 9 Emacs-x86_64-10_9 0x00000001000dd6d7 handle_sigsegv + 167 10 libsystem_platform.dylib 0x00007fff7fca1f5a _sigtramp + 26 11 ??? 000000000000000000 0 + 0 12 Emacs-x86_64-10_9 0x00000001001c8504 -[EmacsView drawRect:] + 84 13 com.apple.AppKit 0x00007fff55f9dc21 _NSViewDrawRect + 83 14 com.apple.AppKit 0x00007fff55836b38 -[NSView _drawRect:clip:] + 1819 15 com.apple.AppKit 0x00007fff5587ef62 -[NSView _recursiveDisplayAllDirtyWithLockFocus:visRect:] + 1735 16 com.apple.AppKit 0x00007fff5587f42f -[NSView _recursiveDisplayAllDirtyWithLockFocus:visRect:] + 2964 17 com.apple.AppKit 0x00007fff5587f42f -[NSView _recursiveDisplayAllDirtyWithLockFocus:visRect:] + 2964 18 com.apple.AppKit 0x00007fff55834a52 -[NSView _recursiveDisplayRectIfNeededIgnoringOpacity:isVisibleRect:rectIsVisibleRectForView:topView:] + 938 19 com.apple.AppKit 0x00007fff558341db -[NSThemeFrame _recursiveDisplayRectIfNeededIgnoringOpacity:isVisibleRect:rectIsVisibleRectForView:topView:] + 327 20 com.apple.AppKit 0x00007fff55f9f1d8 -[NSView _oldDisplayRectIgnoringOpacity:isVisibleRect:rectIsVisibleRectForView:] + 2051 21 com.apple.AppKit 0x00007fff55833261 -[NSView _displayRectIgnoringOpacity:isVisibleRect:rectIsVisibleRectForView:] + 253 22 com.apple.AppKit 0x00007fff5582f4b8 -[NSView displayIfNeeded] + 1581 23 com.apple.AppKit 0x00007fff557b9dc1 -[NSThemeFrame handleSetFrameCommonRedisplay] + 281 24 com.apple.AppKit 0x00007fff557b1a1d -[NSWindow _setFrameCommon:display:stashSize:] + 4103 25 com.apple.AppKit 0x00007fff557b0a09 -[NSWindow _setFrame:display:allowImplicitAnimation:stashSize:] + 222 26 com.apple.AppKit 0x00007fff557b0924 -[NSWindow setFrame:display:] + 67 27 Emacs-x86_64-10_9 0x00000001001ca17a -[EmacsWindow setFrame:display:] + 74 28 com.apple.AppKit 0x00007fff55d71cd2 -[_NSWindowExitFullScreenTransitionController setupWindowForAfterFullScreenExit] + 282 29 com.apple.AppKit 0x00007fff5605a90c -[_NSExitFullScreenTransitionController start] + 430 30 com.apple.AppKit 0x00007fff55ad7d63 -[NSWindow(NSWindowTabbing) _doTabbedWindowCleanupForOrderOut] + 271 31 com.apple.AppKit 0x00007fff55fc0f44 -[NSWindow _finishClosingWindow] + 73 32 com.apple.AppKit 0x00007fff55961264 -[NSWindow _close] + 378 33 Emacs-x86_64-10_9 0x00000001001bad9c x_free_frame_resources + 300 34 Emacs-x86_64-10_9 0x00000001001bae3a x_destroy_window + 106 35 Emacs-x86_64-10_9 0x000000010000f93f delete_frame + 1295 36 Emacs-x86_64-10_9 0x0000000100142ca3 funcall_subr + 83 37 Emacs-x86_64-10_9 0x0000000100142275 Ffuncall + 773 38 Emacs-x86_64-10_9 0x0000000100141bd1 Fapply + 145 39 Emacs-x86_64-10_9 0x000000010013e7a1 eval_sub + 2449 40 Emacs-x86_64-10_9 0x000000010013e98d Fif + 93 41 Emacs-x86_64-10_9 0x000000010013e3ca eval_sub + 1466 42 Emacs-x86_64-10_9 0x000000010014326d funcall_lambda + 989 43 Emacs-x86_64-10_9 0x0000000100142215 Ffuncall + 677 44 Emacs-x86_64-10_9 0x0000000100141bd1 Fapply + 145 45 Emacs-x86_64-10_9 0x0000000100142ca3 funcall_subr + 83 46 Emacs-x86_64-10_9 0x0000000100142275 Ffuncall + 773 47 Emacs-x86_64-10_9 0x000000010018359b exec_byte_code + 1771 48 Emacs-x86_64-10_9 0x0000000100142215 Ffuncall + 677 49 Emacs-x86_64-10_9 0x000000010013b8b6 Ffuncall_interactively + 70 50 Emacs-x86_64-10_9 0x0000000100142ca3 funcall_subr + 83 51 Emacs-x86_64-10_9 0x0000000100142275 Ffuncall + 773 52 Emacs-x86_64-10_9 0x000000010013d04b Fcall_interactively + 6011 53 Emacs-x86_64-10_9 0x0000000100142d92 funcall_subr + 322 54 Emacs-x86_64-10_9 0x0000000100142275 Ffuncall + 773 55 Emacs-x86_64-10_9 0x000000010018359b exec_byte_code + 1771 56 Emacs-x86_64-10_9 0x0000000100142215 Ffuncall + 677 57 Emacs-x86_64-10_9 0x000000010014297d call1 + 45 58 Emacs-x86_64-10_9 0x00000001000c1c1d command_loop_1 + 1981 59 Emacs-x86_64-10_9 0x0000000100140937 internal_condition_case + 87 60 Emacs-x86_64-10_9 0x00000001000d2460 command_loop_2 + 48 61 Emacs-x86_64-10_9 0x00000001001401ee internal_catch + 78 62 Emacs-x86_64-10_9 0x00000001000c0b1e command_loop + 158 63 Emacs-x86_64-10_9 0x00000001000c0a30 recursive_edit_1 + 112 64 Emacs-x86_64-10_9 0x00000001000c0c65 Frecursive_edit + 229 65 Emacs-x86_64-10_9 0x00000001000bf83a main + 6618 66 libdyld.dylib 0x00007fff7fa20115 start + 1 ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: bug#26323: 25.1; Closing frames (in fullscreen) under Mac OS cause immediate crash 2018-03-19 0:37 ` Nick Helm @ 2018-03-19 12:29 ` Alan Third 0 siblings, 0 replies; 21+ messages in thread From: Alan Third @ 2018-03-19 12:29 UTC (permalink / raw) To: Nick Helm; +Cc: emacs-devel On Mon, Mar 19, 2018 at 01:37:36PM +1300, Nick Helm wrote: > On Sun, 18 Mar 2018 at 20:14:16 +0000, Alan Third wrote: > > > If anyone is able to provide a backtrace for either emacs 26 or the > > master branch crashing, that would be helpful. > > I can't reproduce this using a current build on macOS HS (either emacs-26 or > master), but I can with a prebuilt download from emacsformacosx.com. The > emacs-26 branch (dated 2018.01.23) and master (dated 2018.02.22) crash > every time. I don't know what system these were built on. Thanks. I think this is because it’s built on 10.9. We added some code to support building across versions (actually because of this specific issue) but David hasn’t sorted it out yet. What was really confusing me was people building on 10.13 running into the same issue. It looks like it’s because they’re using Nix which apparently builds against the 10.10 SDK. -- Alan Third ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: bug#26323: 25.1; Closing frames (in fullscreen) under Mac OS cause immediate crash 2018-03-18 11:15 ` Alan Third 2018-03-18 11:17 ` David Reitter @ 2018-03-19 2:05 ` Matthew Bauer 2018-03-19 12:23 ` Alan Third 1 sibling, 1 reply; 21+ messages in thread From: Matthew Bauer @ 2018-03-19 2:05 UTC (permalink / raw) To: Alan Third; +Cc: emacs-devel Alan Third <alan@idiocy.org> writes: > It was fixed after that. I can’t reproduce it in Emacs 26. > > I want to know how Matthew got his copy of Emacs as the code to turn > off Sierra tab support is only included when built on Sierra+ or when > using the right build options. > > As far as I’m aware emacsformacosx.com builds, for example, don’t > include it yet. So I've been building from source with a checkout of https://git.savannah.gnu.org/git/emacs.git. The revision is 8d4500087f547e203cfba03f61dcbe641bf650de. I actually hadn't realized that Sierra's "tabbing" feature is disabled intentionally in Emacs. I had been using it since Sierra came out and it works fine except for the frame closing issue. This is obviously a little contentious in the Emacs world but I wonder if it could be supported. IMO this is a "window manager" feature similar to how lots of window managers will group multiple frames of Emacs. In no way is it really an "Emacs feature" that has to be disabled. A note on this that may be important: This was from John's Nix configuration script that is available on: https://github.com/jwiegley/nix-config/blob/e5649602dc89f944e0444a88d8526b19b965bccb/overlays/10-emacs.nix#L678-L698 This probably accounts for how John is having the same issue. Nix does some stuff to achieve "purity" but might be inadvertly introducing the issue. The SDK used in Nixpkgs is still at macOS 10.10 Yosemite. It could be causing the discrepency. Most likely the build from "emacsformacosx.com" is using older SDKs as well. ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: bug#26323: 25.1; Closing frames (in fullscreen) under Mac OS cause immediate crash 2018-03-19 2:05 ` Matthew Bauer @ 2018-03-19 12:23 ` Alan Third 2018-03-20 1:05 ` John Wiegley 0 siblings, 1 reply; 21+ messages in thread From: Alan Third @ 2018-03-19 12:23 UTC (permalink / raw) To: Matthew Bauer; +Cc: emacs-devel On Sun, Mar 18, 2018 at 09:05:06PM -0500, Matthew Bauer wrote: > > I actually hadn't realized that Sierra's "tabbing" feature is disabled > intentionally in Emacs. I had been using it since Sierra came out and it > works fine except for the frame closing issue. This is obviously a > little contentious in the Emacs world but I wonder if it could be > supported. IMO this is a "window manager" feature similar to how lots of > window managers will group multiple frames of Emacs. In no way is it > really an "Emacs feature" that has to be disabled. You could also argue that free OS’s support tab bar mode and the like, so this isn’t really unprecedented. It would need some work before it could be properly supported, though. Not least because it appears to cause crashes. > A note on this that may be important: This was from John's Nix > configuration script that is available on: > https://github.com/jwiegley/nix-config/blob/e5649602dc89f944e0444a88d8526b19b965bccb/overlays/10-emacs.nix#L678-L698 > > This probably accounts for how John is having the same issue. Nix does > some stuff to achieve "purity" but might be inadvertly introducing the > issue. The SDK used in Nixpkgs is still at macOS 10.10 Yosemite. It > could be causing the discrepency. Most likely the build from > "emacsformacosx.com" is using older SDKs as well. Yes, 10.10 doesn’t support the tabs command. emacsformacosx.com builds on 10.9 the last time I looked, so yes, that’s what’s going on there. Please try adding -DMAC_OS_X_VERSION_MAX_ALLOWED=101200 to CFLAGS. It should give you a compiler warning or two, but you can safely ignore them. -- Alan Third ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: bug#26323: 25.1; Closing frames (in fullscreen) under Mac OS cause immediate crash 2018-03-19 12:23 ` Alan Third @ 2018-03-20 1:05 ` John Wiegley 0 siblings, 0 replies; 21+ messages in thread From: John Wiegley @ 2018-03-20 1:05 UTC (permalink / raw) To: Alan Third; +Cc: Matthew Bauer, emacs-devel >>>>> "AT" == Alan Third <alan@idiocy.org> writes: AT> Yes, 10.10 doesn’t support the tabs command. emacsformacosx.com builds on AT> 10.9 the last time I looked, so yes, that’s what’s going on there. AT> Please try adding AT> -DMAC_OS_X_VERSION_MAX_ALLOWED=101200 AT> to CFLAGS. I can confirm that this resolves the issue for me. In fact, now each created frame gets its own space, and I can even have a non-fullscreen frame in my main space, with the other frames being their own spaces. And no more crashes when closing a fullscreen frame. Thank you! -- John Wiegley GPG fingerprint = 4710 CF98 AF9B 327B B80F http://newartisans.com 60E1 46C4 BD1A 7AC1 4BA2 ^ permalink raw reply [flat|nested] 21+ messages in thread
* bug#26323: 25.1; Closing frames (in fullscreen) under Mac OS cause immediate crash @ 2018-07-10 20:52 Noah Sussman 2018-07-12 20:51 ` Alan Third 2018-07-13 2:16 ` Radon Rosborough 0 siblings, 2 replies; 21+ messages in thread From: Noah Sussman @ 2018-07-10 20:52 UTC (permalink / raw) To: emacs-devel [-- Attachment #1: Type: text/plain, Size: 408 bytes --] Since this bug still exists in Homebrew as of July 2018, I thought I would share how I solved it on OS X Sierra v10.12.6 brew edit cask emacs This will open a text editor. Search for “def install” Paste the following line immediately below “def install”: ENV[“cflags"]="-DMAC_OS_X_VERSION_MAX_ALLOWED=101200” Close the editor and reinstall the cask: brew reinstall cask emacs [-- Attachment #2: Type: text/html, Size: 598 bytes --] ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: bug#26323: 25.1; Closing frames (in fullscreen) under Mac OS cause immediate crash 2018-07-10 20:52 Noah Sussman @ 2018-07-12 20:51 ` Alan Third 2018-07-13 2:16 ` Radon Rosborough 1 sibling, 0 replies; 21+ messages in thread From: Alan Third @ 2018-07-12 20:51 UTC (permalink / raw) To: Noah Sussman; +Cc: emacs-devel On Tue, Jul 10, 2018 at 04:52:29PM -0400, Noah Sussman wrote: > Since this bug still exists in Homebrew as of July 2018, I thought I would > share how I solved it on OS X Sierra v10.12.6 > > brew edit cask emacs > > This will open a text editor. Search for “def install” > > Paste the following line immediately below “def install”: > > ENV[“cflags"]="-DMAC_OS_X_VERSION_MAX_ALLOWED=101200” > > Close the editor and reinstall the cask: > > brew reinstall cask emacs Why is this an issue in homebrew? Does it use an old version of the XCode command line tools? -- Alan Third ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: bug#26323: 25.1; Closing frames (in fullscreen) under Mac OS cause immediate crash 2018-07-10 20:52 Noah Sussman 2018-07-12 20:51 ` Alan Third @ 2018-07-13 2:16 ` Radon Rosborough 2018-07-13 20:25 ` Noah Sussman 1 sibling, 1 reply; 21+ messages in thread From: Radon Rosborough @ 2018-07-13 2:16 UTC (permalink / raw) To: nsussman; +Cc: emacs-devel > brew edit cask emacs Do you perhaps mean 'brew cask edit' rather than 'brew edit cask'? I would assume yes, but 'cask' is also the name of a Homebrew formula relating to Emacs... :) ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: bug#26323: 25.1; Closing frames (in fullscreen) under Mac OS cause immediate crash 2018-07-13 2:16 ` Radon Rosborough @ 2018-07-13 20:25 ` Noah Sussman 0 siblings, 0 replies; 21+ messages in thread From: Noah Sussman @ 2018-07-13 20:25 UTC (permalink / raw) To: Radon Rosborough; +Cc: emacs-devel [-- Attachment #1: Type: text/plain, Size: 681 bytes --] On Thu, Jul 12, 2018 at 10:16 PM, Radon Rosborough <radon.neon@gmail.com> wrote: > > brew edit cask emacs > > Do you perhaps mean 'brew cask edit' rather than 'brew edit cask'? > The quoted command is the one I used. It may not be optimal or there may be a more idiomatic Homebrew way to do it, but I have looked at my .history file and here are all 3 commands I used to get Emacs to stop crashing when closing a fullscreen window: brew cask install emacs brew edit cask emacs # change the ctags as described above brew reinstall cask emacs I did try the other way round: brew cask edit emacs and it opens a different file, not the right file to put that ctags change in!!! [-- Attachment #2: Type: text/html, Size: 1225 bytes --] ^ permalink raw reply [flat|nested] 21+ messages in thread
end of thread, other threads:[~2018-07-13 20:25 UTC | newest] Thread overview: 21+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2017-03-31 13:01 bug#26323: 25.1; Closing frames (in fullscreen) under Mac OS cause immediate crash Kevin Sjöberg 2017-03-31 19:13 ` Steve Perry 2017-06-17 16:58 ` Alan Third 2017-06-20 16:50 ` Stephen Perry -- strict thread matches above, loose matches on Subject: below -- 2018-03-16 0:54 Matthew Bauer 2018-03-16 10:47 ` Alan Third 2018-03-16 18:12 ` David Reitter 2018-03-18 11:15 ` Alan Third 2018-03-18 11:17 ` David Reitter 2018-03-18 11:30 ` Alan Third 2018-03-18 18:14 ` John Wiegley 2018-03-18 20:14 ` Alan Third 2018-03-19 0:37 ` Nick Helm 2018-03-19 12:29 ` Alan Third 2018-03-19 2:05 ` Matthew Bauer 2018-03-19 12:23 ` Alan Third 2018-03-20 1:05 ` John Wiegley 2018-07-10 20:52 Noah Sussman 2018-07-12 20:51 ` Alan Third 2018-07-13 2:16 ` Radon Rosborough 2018-07-13 20:25 ` Noah Sussman
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.