bug#23924: 25.1.50; Emacs NSInternalInconsistencyException on macos Sierra developer beta 2

bug#23924: 25.1.50; Emacs NSInternalInconsistencyException on macos Sierra developer beta 2

[Bob Halley]

I don't have a firm recipe to reproduce.  I do normal editing and then at some point
emacs crashes, usually after file open / close / save, or Control-G.

This is the backtrace, which seems to be unhappy about "nextEventMatchingMask should only be called from the Main Thread".  If there's anything else you'd like info on, or things you want me to try, let me know.  I disabled all of my packages, so AFAIK this is a core emacs issue.

Regards!

/Bob


Process:               Emacs [49531]
Path:                  /Applications/Emacs.app/Contents/MacOS/Emacs
Identifier:            org.gnu.Emacs
Version:               Version 25.1.50 (9.0)
Code Type:             X86-64 (Native)
Parent Process:        ??? [1]
Responsible:           Emacs [49531]
User ID:               501

Date/Time:             2016-07-08 17:05:24.573 -0700
OS Version:            Mac OS X 10.12 (16A239j)
Report Version:        12
Anonymous UUID:        98DA97D2-48E1-4657-356C-8847334D938F

Sleep/Wake UUID:       01CB8305-217D-4944-978A-AB157A426668

Time Awake Since Boot: 140000 seconds
Time Since Wake:       40000 seconds

System Integrity Protection: enabled

Crashed Thread:        1

Exception Type:        EXC_CRASH (SIGABRT)
Exception Codes:       0x0000000000000000, 0x0000000000000000
Exception Note:        EXC_CORPSE_NOTIFY

Application Specific Information:
*** Terminating app due to uncaught exception 'NSInternalInconsistencyException', reason: 'nextEventMatchingMask should only be called from the Main Thread!'
terminating with uncaught exception of type NSException
abort() called

Application Specific Backtrace 1:
0   CoreFoundation                      0x00007fffbccf41cb __exceptionPreprocess + 171
1   libobjc.A.dylib                     0x00007fffd078a8fa objc_exception_throw + 48
2   AppKit                              0x00007fffbb0a8a4d -[NSApplication(NSEvent) shouldBeTreatedAsInkEvent:] + 0
3   Emacs                               0x00000001001a8527 ns_send_appdefined + 103
4   Emacs                               0x00000001001ab4c7 -[EmacsApp fd_handler:] + 695
5   Foundation                          0x00007fffbe6ac00d __NSThread__start__ + 1243
6   libsystem_pthread.dylib             0x00007fffd1278c4f _pthread_body + 176
7   libsystem_pthread.dylib             0x00007fffd1278b9f _pthread_body + 0
8   libsystem_pthread.dylib             0x00007fffd12783d5 thread_start + 13

Thread 0:: Dispatch queue: com.apple.main-thread
0   libsystem_kernel.dylib        	0x00007fffd1191de6 __pthread_kill + 10
1   libsystem_pthread.dylib       	0x00007fffd127b92b pthread_kill + 90
2   libsystem_c.dylib             	0x00007fffd10a851f raise + 26
3   org.gnu.Emacs                 	0x00000001000ba869 terminate_due_to_signal + 153 (emacs.c:398)
4   org.gnu.Emacs                 	0x00000001000d71f3 emacs_abort + 19
5   org.gnu.Emacs                 	0x00000001001a9c8a ns_term_shutdown + 122
6   org.gnu.Emacs                 	0x00000001000baa35 shut_down_emacs + 261 (emacs.c:2056)
7   org.gnu.Emacs                 	0x00000001000ba836 terminate_due_to_signal + 102 (emacs.c:379)
8   org.gnu.Emacs                 	0x00000001000d8a9d deliver_fatal_signal + 125
9   libsystem_platform.dylib      	0x00007fffd126f01a _sigtramp + 26
10  ???                           	000000000000000000 0 + 0
11  org.gnu.Emacs                 	0x00000001000c6545 handle_interrupt + 757 (keyboard.c:10434)
12  org.gnu.Emacs                 	0x00000001000c13a8 gobble_input + 472 (.keyboard.h:475)
13  org.gnu.Emacs                 	0x00000001000c7db5 unblock_input + 69 (keyboard.c:7088)
14  org.gnu.Emacs                 	0x00000001001a8a85 ns_select + 981 (nsterm.m:4286)
15  org.gnu.Emacs                 	0x000000010017dada wait_reading_process_output + 2698 (process.c:5187)
16  org.gnu.Emacs                 	0x0000000100008ac5 sit_for + 261 (dispnew.c:5765)
17  org.gnu.Emacs                 	0x00000001000c3027 read_char + 5815 (keyboard.c:2714)
18  org.gnu.Emacs                 	0x00000001000bfad2 read_key_sequence + 2194 (.lisp.h:2616)
19  org.gnu.Emacs                 	0x00000001000be112 command_loop_1 + 1154 (keyboard.c:1365)
20  org.gnu.Emacs                 	0x0000000100137e46 internal_condition_case + 70 (eval.c:1312)
21  org.gnu.Emacs                 	0x00000001000cd2a0 command_loop_2 + 48 (keyboard.c:1107)
22  org.gnu.Emacs                 	0x0000000100137996 internal_catch + 54 (eval.c:1077)
23  org.gnu.Emacs                 	0x00000001000bd3ae command_loop + 158 (keyboard.c:1087)
24  org.gnu.Emacs                 	0x00000001000bd2c1 recursive_edit_1 + 113 (keyboard.c:693)
25  org.gnu.Emacs                 	0x00000001000bd4ea Frecursive_edit + 218 (keyboard.c:764)
26  org.gnu.Emacs                 	0x00000001000bc170 main + 5840 (emacs.c:1656)
27  libdyld.dylib                 	0x00007fffd1063255 start + 1

Thread 1 Crashed:
0   libsystem_kernel.dylib        	0x00007fffd1192272 __sigsuspend + 10
1   org.gnu.Emacs                 	0x00000001000d8b18 deliver_fatal_thread_signal + 120 (sysdep.c:1606)
2   libsystem_platform.dylib      	0x00007fffd126f01a _sigtramp + 26
3   ???                           	0x00000003d9a6a240 0 + 16536478272
4   libsystem_c.dylib             	0x00007fffd10f74dc abort + 129
5   libc++abi.dylib               	0x00007fffcfc5685a abort_message + 266
6   libc++abi.dylib               	0x00007fffcfc7bc4f default_terminate_handler() + 267
7   libobjc.A.dylib               	0x00007fffd078ca7e _objc_terminate() + 103
8   libc++abi.dylib               	0x00007fffcfc78d69 std::__terminate(void (*)()) + 8
9   libc++abi.dylib               	0x00007fffcfc787de __cxa_throw + 121
10  libobjc.A.dylib               	0x00007fffd078aa23 objc_exception_throw + 345
11  com.apple.AppKit              	0x00007fffbb0a8a4d -[NSApplication(NSEvent) _nextEventMatchingEventMask:untilDate:inMode:dequeue:] + 2499
12  org.gnu.Emacs                 	0x00000001001a8527 ns_send_appdefined + 103 (nsterm.m:3954)
13  org.gnu.Emacs                 	0x00000001001ab4c7 -[EmacsApp fd_handler:] + 695 (nsterm.m:5620)
14  com.apple.Foundation          	0x00007fffbe6ac00d __NSThread__start__ + 1243
15  libsystem_pthread.dylib       	0x00007fffd1278c4f _pthread_body + 176
16  libsystem_pthread.dylib       	0x00007fffd1278b9f _pthread_start + 274
17  libsystem_pthread.dylib       	0x00007fffd12783d5 thread_start + 13

Thread 2:: com.apple.NSEventThread
0   libsystem_kernel.dylib        	0x00007fffd118a4da mach_msg_trap + 10
1   libsystem_kernel.dylib        	0x00007fffd1189927 mach_msg + 55
2   com.apple.CoreFoundation      	0x00007fffbcc6c6e4 __CFRunLoopServiceMachPort + 212
3   com.apple.CoreFoundation      	0x00007fffbcc6bb61 __CFRunLoopRun + 1361
4   com.apple.CoreFoundation      	0x00007fffbcc6b3ad CFRunLoopRunSpecific + 285
5   com.apple.AppKit              	0x00007fffbaaeb0b4 _NSEventThread + 205
6   libsystem_pthread.dylib       	0x00007fffd1278c4f _pthread_body + 176
7   libsystem_pthread.dylib       	0x00007fffd1278b9f _pthread_start + 274
8   libsystem_pthread.dylib       	0x00007fffd12783d5 thread_start + 13

Thread 3:
0   libsystem_pthread.dylib       	0x00007fffd12783b8 start_wqthread + 0
1   ???                           	0x00007fffd6217990 0 + 140736785906064

Thread 4:
0   libsystem_kernel.dylib        	0x00007fffd11924f2 __workq_kernreturn + 10
1   libsystem_pthread.dylib       	0x00007fffd127896a _pthread_wqthread + 1427
2   libsystem_pthread.dylib       	0x00007fffd12783c5 start_wqthread + 13

Thread 5:
0   libsystem_pthread.dylib       	0x00007fffd12783b8 start_wqthread + 0
1   ???                           	0x0000700000880b80 0 + 123145311226752

Thread 6:
0   libsystem_kernel.dylib        	0x00007fffd11924f2 __workq_kernreturn + 10
1   libsystem_pthread.dylib       	0x00007fffd127896a _pthread_wqthread + 1427
2   libsystem_pthread.dylib       	0x00007fffd12783c5 start_wqthread + 13

Thread 7:
0   libsystem_kernel.dylib        	0x00007fffd11924f2 __workq_kernreturn + 10
1   libsystem_pthread.dylib       	0x00007fffd127896a _pthread_wqthread + 1427
2   libsystem_pthread.dylib       	0x00007fffd12783c5 start_wqthread + 13

Thread 8:
0   libsystem_kernel.dylib        	0x00007fffd11924f2 __workq_kernreturn + 10
1   libsystem_pthread.dylib       	0x00007fffd127896a _pthread_wqthread + 1427
2   libsystem_pthread.dylib       	0x00007fffd12783c5 start_wqthread + 13

Thread 9:
0   libsystem_pthread.dylib       	0x00007fffd12783b8 start_wqthread + 0
1   ???                           	0x0000700000b92b30 0 + 123145314446128



In GNU Emacs 25.1.50.1 (x86_64-apple-darwin16.0.0, NS appkit-1490.23 Version 10.12 (Build 16A239j))
 of 2016-07-08 built on bark.local
Repository revision: bdda4855c635ecf4135e23321bdba023e9ae65c9
Windowing system distributor 'Apple', version 10.3.1490
Recent messages:
Loading /Users/halley/.emacs.d/customize.el (source)...
Loading grep...done
Loading /Users/halley/.emacs.d/customize.el (source)...done
For information about GNU Emacs and the GNU system, type C-h C-a.
Making completion list...

Configured using:
 'configure --without-x --with-ns -with-wide-int
 LIBXML2_CFLAGS=-I/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.11.sdk/usr/include/libxml2'

Configured features:
NOTIFY ACL LIBXML2 ZLIB TOOLKIT_SCROLL_BARS NS

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

Major mode: Lisp Interaction

Minor modes in effect:
  delete-selection-mode: t
  tooltip-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
  blink-cursor-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  line-number-mode: t
  transient-mark-mode: t

Load-path shadows:
None found.

Features:
(shadow sort mail-extr emacsbug message puny dired dired-loaddefs
format-spec rfc822 mml mml-sec epa derived epg gnus-util rmail
rmail-loaddefs mm-decode mm-bodies mm-encode mail-parse rfc2231
mailabbrev gmm-utils mailheader sendmail rfc2047 rfc2045 ietf-drums
mm-util mail-prsvr mail-utils finder-inf package epg-config url-handlers
url-parse auth-source cl-seq eieio eieio-core cl-macs eieio-loaddefs
password-cache url-vars seq byte-opt gv bytecomp byte-compile cl-extra
help-mode easymenu cconv rth-light-theme grep compile comint ansi-color
ring cus-start cus-load rfc cc-styles cc-align cc-engine cc-vars cc-defs
server edmacro kmacro cl-loaddefs pcase cl-lib rth-funcs delsel
time-date mule-util tooltip eldoc electric uniquify ediff-hook vc-hooks
lisp-float-type mwheel term/ns-win 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
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 charscript 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 multi-tty make-network-process emacs)

Memory information:
((conses 16 246188 9032)
 (symbols 48 25001 0)
 (miscs 40 48 227)
 (strings 32 29820 7752)
 (string-bytes 1 999974)
 (vectors 16 38590)
 (vector-slots 8 711067 2705)
 (floats 8 218 51)
 (intervals 56 227 0)
 (buffers 976 12))

bug#23924: 25.1.50; Emacs NSInternalInconsistencyException on macos Sierra developer beta 2

[Alan Third]

On Fri, Jul 08, 2016 at 05:20:37PM -0700, Bob Halley wrote:
> I don't have a firm recipe to reproduce. I do normal editing and
> then at some point emacs crashes, usually after file open / close /
> save, or Control-G.
> 
> This is the backtrace, which seems to be unhappy about
> "nextEventMatchingMask should only be called from the Main Thread".
> If there's anything else you'd like info on, or things you want me
> to try, let me know. I disabled all of my packages, so AFAIK this is
> a core emacs issue.

Hi Bob, thanks for reporting this.

I recently made a small change to input handling in the master branch
that may be related to this. Is there any chance you could give it a
go?
-- 
Alan Third

bug#23924: 25.1.50; Emacs NSInternalInconsistencyException on macos Sierra developer beta 2

[Bob Halley]

> On Jul 10, 2016, at 03:10, Alan Third <alan@idiocy.org> wrote:
> 
> On Fri, Jul 08, 2016 at 05:20:37PM -0700, Bob Halley wrote:
>> I don't have a firm recipe to reproduce. I do normal editing and
>> then at some point emacs crashes, usually after file open / close /
>> save, or Control-G.
>> 
>> This is the backtrace, which seems to be unhappy about
>> "nextEventMatchingMask should only be called from the Main Thread".
>> If there's anything else you'd like info on, or things you want me
>> to try, let me know. I disabled all of my packages, so AFAIK this is
>> a core emacs issue.
> 
> Hi Bob, thanks for reporting this.
> 
> I recently made a small change to input handling in the master branch
> that may be related to this. Is there any chance you could give it a
> go?

Do you mean ee7bc988603ca16e6ef37fbbc377d82db37954c0, "Prevent NS event loop being re-entered (bug#11049)"?  If so, I had that in my build before i filed the report.  I was hopeful when I saw it but it didn't help, alas.  The only thing from you I see that is new since my last build is removing the app nap setting.

Regards,

/Bob

bug#23924: 25.1.50; Emacs NSInternalInconsistencyException on macos Sierra developer beta 2

[Alan Third]

On Sun, Jul 10, 2016 at 09:06:22AM -0700, Bob Halley wrote:
> 
> > On Jul 10, 2016, at 03:10, Alan Third <alan@idiocy.org> wrote:
> > 
> > I recently made a small change to input handling in the master branch
> > that may be related to this. Is there any chance you could give it a
> > go?
> 
> Do you mean ee7bc988603ca16e6ef37fbbc377d82db37954c0, "Prevent NS
> event loop being re-entered (bug#11049)"? If so, I had that in my
> build before i filed the report. I was hopeful when I saw it but it
> didn't help, alas. The only thing from you I see that is new since
> my last build is removing the app nap setting.

Yep, that's the one.

OK, the next step is to rebuild with NSTRACE enabled. If you look near
the top of nsterm.h there is a #DEFINE commented out for NSTRACE. If
you uncomment it Emacs will output information about what it's doing
and then we can see the last thing that happened before the error.

If that doesn't get us anywhere you may need to rebuild with debugging
stuff enabled and try it in lldb or gdb.
-- 
Alan Third

bug#23924: 25.1.50; Emacs NSInternalInconsistencyException on macos Sierra developer beta 2

[Bob Halley]

> Yep, that's the one.
> 
> OK, the next step is to rebuild with NSTRACE enabled. If you look near
> the top of nsterm.h there is a #DEFINE commented out for NSTRACE. If
> you uncomment it Emacs will output information about what it's doing
> and then we can see the last thing that happened before the error.
> 
> If that doesn't get us anywhere you may need to rebuild with debugging
> stuff enabled and try it in lldb or gdb.

OK, will try that and report back!

bug#23924: 25.1.50; Emacs NSInternalInconsistencyException on macos Sierra developer beta 2

[Bob Halley]

So far it's the usual "turn on tracing, problem stops being easily replicated" thing.  I hate timing bugs.  I'll trace all day tomorrow while working and see if we get lucky and it happens again.

bug#23924: 25.1.50; Emacs NSInternalInconsistencyException on macos Sierra developer beta 2

[Bob Halley]

If I disable the invocation of nextEventMatchingMask:untilDate:inMode:dequeue at nsterm.m:3950, the problem stops.  And indeed, this is the method that is called in the traceback that is causing the assertion to fire.  Since this appears to be a workaround for events getting eaten, however, this doesn't seem to be a good fix.

Is it a bad thing to just always set send_appdefined=YES?  The code appears to be trying to suppress appdefined events in some cases, but it's not clear to me what happens if we stop trying to send only one.  Naively I'd think "why not, so the run loop gets stopped twice, it's a little extra work" but I don't know this code and am not familiar with the macOS API :)

bug#23924: 25.1.50; Emacs NSInternalInconsistencyException on macos Sierra developer beta 2

[Bob Halley]

> Is it a bad thing to just always set send_appdefined=YES?  The code appears to be trying to suppress appdefined events in some cases, but it's not clear to me what happens if we stop trying to send only one.  Naively I'd think "why not, so the run loop gets stopped twice, it's a little extra work" but I don't know this code and am not familiar with the macOS API :)

FWIW, I made my emacs just always have send_appdefined=YES and nothing obviously bad has happened so far.

bug#23924: [PATCH] Only check for AppDefined events in OS X 10.10 (bug#23924)

[Alan Third]

* src/nsterm.m (ns_send_appdefined): Limit bugfix for bug#18993 to OS X
10.10.
---
 src/nsterm.m | 25 +++++++++++++++----------
 1 file changed, 15 insertions(+), 10 deletions(-)

diff --git a/src/nsterm.m b/src/nsterm.m
index a6160ed..a7e2649 100644
--- a/src/nsterm.m
+++ b/src/nsterm.m
@@ -3942,16 +3942,21 @@ overwriting cursor (usually when cursor on a tab) */
        this moment.  */
 
 #ifdef NS_IMPL_COCOA
-  if (! send_appdefined)
-    {
-      /* OSX 10.10.1 swallows the AppDefined event we are sending ourselves
-         in certain situations (rapid incoming events).
-         So check if we have one, if not add one.  */
-      NSEvent *appev = [NSApp nextEventMatchingMask:NSApplicationDefinedMask
-                                          untilDate:[NSDate distantPast]
-                                             inMode:NSDefaultRunLoopMode
-                                            dequeue:NO];
-      if (! appev) send_appdefined = YES;
+  if ([[NSProcessInfo processInfo] respondsToSelector:@selector(operatingSystemVersion)])
+    {
+      NSOperatingSystemVersion v = [[NSProcessInfo processInfo] operatingSystemVersion];
+
+      if (! send_appdefined && v.majorVersion == 10 && v.minorVersion == 10)
+        {
+          /* OSX 10.10.1 swallows the AppDefined event we are sending ourselves
+             in certain situations (rapid incoming events).
+             So check if we have one, if not add one.  */
+          NSEvent *appev = [NSApp nextEventMatchingMask:NSApplicationDefinedMask
+                                              untilDate:[NSDate distantPast]
+                                                 inMode:NSDefaultRunLoopMode
+                                                dequeue:NO];
+          if (! appev) send_appdefined = YES;
+        }
     }
 #endif
 
-- 
Hi Bob, can you try applying this patch? The fix was originally put in
place for bug#18993 which seems to be specific to OS X 10.10 (or at
least, I can't replicate it here in 10.11) so I've limited the fix to
that specific version and completely removed it for everything else.

Hopefully it's not going to break everything, but it seems OK here.
-- 
Alan Third

bug#23924: [PATCH] Only check for AppDefined events in OS X 10.10 (bug#23924)

[Bob Halley]

Seems to work for me!  No troubles!

/Bob

bug#23924: [PATCH] Only check for AppDefined events in OS X 10.10 (bug#23924)

[Alan Third]

On Wed, Jul 13, 2016 at 04:08:12PM -0700, Bob Halley wrote:
> Seems to work for me!  No troubles!

I was hoping someone using OS X 10.10 might have chimed in, but it's
not looking likely, so unless anyone objects I'll commit this to
master in a day or two.

It may be neccessary to commit it to Emacs 25 as it the bug breaks
Emacs on the next version of OS X, which should be out later this
year.
-- 
Alan Third

bug#23924: [PATCH] Only check for AppDefined events in OS X 10.10 (bug#23924)

[Bob Halley]

I have a concern about this patch now, as this morning my emacs, running with it, simply froze and was unresponsive to any input.  This sounds like the description of 18993.

I didn't have any trouble when I made emacs just always send an appdefined event instead of trying to figure out whether it might have one sent already.  Is this known to be bad somehow?

bug#23924: [PATCH] Only check for AppDefined events in OS X 10.10 (bug#23924)

[Alan Third]

On Wed, Jul 20, 2016 at 11:35:33AM -0700, Bob Halley wrote:
> I have a concern about this patch now, as this morning my emacs,
> running with it, simply froze and was unresponsive to any input.
> This sounds like the description of 18993.

I guess it’s back to the drawing board. :(

> I didn't have any trouble when I made emacs just always send an
> appdefined event instead of trying to figure out whether it might
> have one sent already. Is this known to be bad somehow?

Well, it seems to me that it could delay processing of input events in
certain circumstances. It maybe wouldn’t be a big deal, but I don’t
know for certain.
-- 
Alan Third

bug#23924: [PATCH] Post AppDefined events from the main thread ONLY (bug#23934)

[Alan Third]

* src/nsterm.h: Make nextappdefined var not just GNUStep.
* src/nsterm.c (ns_send_appdefined, sendFromMainThread): Remove GNUStep
---
 src/nsterm.h | 2 +-
 src/nsterm.m | 5 +----
 2 files changed, 2 insertions(+), 5 deletions(-)

diff --git a/src/nsterm.h b/src/nsterm.h
index 862ff2e..3d8b1a1 100644
--- a/src/nsterm.h
+++ b/src/nsterm.h
@@ -380,9 +380,9 @@ char const * nstrace_fullscreen_type_name (int);
 #endif
 #ifdef NS_IMPL_GNUSTEP
   BOOL applicationDidFinishLaunchingCalled;
+#endif
 @public
   int nextappdefined;
-#endif
 }
 - (void)logNotification: (NSNotification *)notification;
 - (void)antialiasThresholdDidChange:(NSNotification *)notification;
diff --git a/src/nsterm.m b/src/nsterm.m
index 8da2ffe..dcc1e87 100644
--- a/src/nsterm.m
+++ b/src/nsterm.m
@@ -3927,8 +3927,8 @@ overwriting cursor (usually when cursor on a tab) */
 {
   NSTRACE_WHEN (NSTRACE_GROUP_EVENTS, "ns_send_appdefined(%d)", value);
 
-#ifdef NS_IMPL_GNUSTEP
   // GNUstep needs postEvent to happen on the main thread.
+  // Cocoa needs nextEventMatchingMask to happen on the main thread too.
   if (! [[NSThread currentThread] isMainThread])
     {
       EmacsApp *app = (EmacsApp *)NSApp;
@@ -3938,7 +3938,6 @@ overwriting cursor (usually when cursor on a tab) */
                          waitUntilDone:YES];
       return;
     }
-#endif
 
   /* Only post this event if we haven't already posted one.  This will end
        the [NXApp run] main loop after having processed all events queued at
@@ -5551,12 +5550,10 @@ - (void)timeout_handler: (NSTimer *)timedEntry
   ns_send_appdefined (-2);
 }
 
-#ifdef NS_IMPL_GNUSTEP
 - (void)sendFromMainThread:(id)unused
 {
   ns_send_appdefined (nextappdefined);
 }
-#endif
 
 - (void)fd_handler:(id)unused
 /* --------------------------------------------------------------------------
-- 

Hi Bob, can you try this patch instead.

Rather than remove the check, I’m now trying to force it to run in the
main thread, since that’s what your original error was complaining
about.

I’ve tried looking for more information on this bug in 10.10, and am
drawing a blank. I’m beginning to suspect it’s a bug in Emacs’s event
handling code rather than OS X.

-- 
Alan Third

bug#23924: [PATCH] Post AppDefined events from the main thread ONLY (bug#23934)

[Bob Halley]

So far, so good!

bug#23924: [PATCH] Post AppDefined events from the main thread ONLY (bug#23934)

[Bob Halley]

Still good!

bug#23924: [PATCH] Post AppDefined events from the main thread ONLY (bug#23934)

[Alan Third]

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

Thanks. I think this one should do.

On 22 Jul 2016 10:10 p.m., "Bob Halley" <halley@play-bow.org> wrote:

> Still good!
>
>

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