One of our apps does most of its work in an NSOperation subclass, and most of the work involves sending hundreds of AppleScripts to InDesign. We only send them on the main thread via:
dispatch_sync(dispatch_get_main_queue(), ^{
[self _runAppleScriptWithDict:infoDict];
});
Since upgrading from an old MacBook Pro running 10.10.x and whatever Xcode it could handle to a fairly new one running 10.13..6 and Xcode 10.1, I've been seeing a lot of problems when debugging, stopping at breakpoints, then either stepping or continuing when the next line involves sending an AppleScript on the main thread. The main thread looks like:
#0 | 0x00007fff54fefaee in __psynch_rw_wrlock () |
#1 | 0x0000000100e109a9 in _pthread_rwlock_lock_wait () |
#2 | 0x0000000100e108f0 in _pthread_rwlock_lock_slow () |
#3 | 0x00000001005ff39d in enter_stack_in_backtrace_uniquing_table () |
#4 | 0x00000001005fb92e in gcd_queue_item_enqueue_hook () |
#5 | 0x0000000100dbe085 in _dispatch_introspection_queue_item_enqueue_hook () |
#6 | 0x0000000100da5794 in _dispatch_root_queue_push_override () |
#7 | 0x00007fff2f051399 in __NSOQSchedule () |
#8 | 0x00007fff2f080190 in __addOperations () |
#9 | 0x00007fff2b0212f4 in NSPersistentUIEncodingQueueFinishEnqueued () |
#10 | 0x00007fff2af92511 in -[NSPersistentUIManager flushAllChanges] () |
#11 | 0x00007fff2ad6446c in __48-[NSPersistentUIFlushScheduler initWithHandler:]_block_invoke_2 () |
#12 | 0x0000000100d8ed8f in _dispatch_client_callout () |
#13 | 0x0000000100da33d2 in _dispatch_continuation_pop () |
#14 | 0x0000000100d9148f in _dispatch_source_invoke () |
#15 | 0x0000000100d9b053 in _dispatch_main_queue_callback_4CF () |
#16 | 0x00007fff2cfabb39 in __CFRUNLOOP_IS_SERVICING_THE_MAIN_DISPATCH_QUEUE__ () |
#17 | 0x00007fff2cf6dcda in __CFRunLoopRun () |
#18 | 0x00007fff2cf6d033 in CFRunLoopRunSpecific () |
#19 | 0x00007fff2c257d96 in RunCurrentEventLoopInMode () |
#20 | 0x00007fff2c257b06 in ReceiveNextEventCommon () |
#21 | 0x00007fff2c257884 in _BlockUntilNextEventMatchingListInModeWithFilter () |
#22 | 0x00007fff2a507a73 in _DPSNextEvent () |
#23 | 0x00007fff2ac9de34 in -[NSApplication(NSEvent) _nextEventMatchingEventMask:untilDate:inMode:dequeue:] () |
#24 | 0x00007fff2a4fc885 in -[NSApplication run] () |
#25 | 0x00007fff2a4cba72 in NSApplicationMain () |
#26 | 0x00000001000018c2 in main at /Users/rr219379/gitdepot/MMAutomation/main.m:13 |
#27 | 0x00007fff54e9f015 in start () |
And the top of our worker thread looks like:
#0 | 0x00007fff54ff015a in __ulock_wait () |
#1 | 0x0000000100d9fe92 in _dispatch_ulock_wait () |
#2 | 0x0000000100d9ff83 in _dispatch_thread_event_wait_slow () |
#3 | 0x0000000100da7604 in _dispatch_sync_wait () |
#4 | 0x000000010097b954 in -[AppleScriptHelper runAppleScript:withSubstitutionValues:] at /Users/rr219379/gitdepot/RRDFramework/AppleScriptHelper.m:135 |
#5 | 0x00000001009f823a in -[InDesignHelper _runAppleScript:withSubstitutionValues:forDocID:] at /Users/rr219379/gitdepot/RRDFramework/InDesignHelper.m:4152 |
I've normalized all our main thread calling to use dispatch_sync (running AppleScripts only uses that one) or dispatch_async instead of a mix of those and performSelectorOnMainThread:withObject: after reading a blog post about race conditions and such when both are used. That didn't magically fix it. It never happens when just running normally, only after stopping at a breakpoint, and not every time.
I've played with all the debugging options in Xcode, the sanitizers and such. No luck. Any other ideas? It's highly annoying to spend a lot of time debugging, almost getting to the root of a problem, and then having to kill it and start all over because Xcode or the OS is hosing up the main thread locking stuff.