XProtect makes app hang when running an AppleScript

Consider this:

Exception Type:    EXC_BREAKPOINT (SIGTRAP)
Exception Codes:   0x0000000000000001, 0x0000000102c799bc

This typically means that the app trapped, that is, it detected an internal error and deliberately crashed. For example, if you force unwrap an option that’s nil, you’ll trap like this.

Now look at the backtrace:

Thread 1 Crashed::  Dispatch queue: com.apple.root.utility-qos
0 DIM                     … 0x102c6c000 + 55740
1 DIM                     … 0x102c6c000 + 128212
2 libdispatch.dylib       … _dispatch_call_block_and_release + 32
3 libdispatch.dylib       … _dispatch_client_callout + 16
4 libdispatch.dylib       …  + 32
5 libdispatch.dylib       … _dispatch_root_queue_drain + 736
6 libdispatch.dylib       … _dispatch_worker_thread2 + 180
7 libsystem_pthread.dylib … _pthread_wqthread + 232
8 libsystem_pthread.dylib … start_wqthread + 8

frames 8 through 2 are Dispatch (GCD) machinery. Frame 1 is your code, which calls frame 0, which trapped. To learn more about this you need to symbolicate frames 1 and 0. See Adding identifiable symbol names to a crash report.

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

That's what I did. It resolved to a line which tried to use the object to access the AppleScript. Before Apple's change, it could not reach that code.

I create the object which loads AppleScriptObjC/script on the .userInteractive queue. I then dispatch back to the main queue. There I test if the object is nil or if there is a problem calling the script. If so, I display error sheet and quit. Otherwise, UserDefaults is loaded and startup finishes accordingly. These tests to check if AppleScriptObjC/script correctly loaded failed to work.

Messy, but worked for over five years, until now.

btw, the picture of the Devices and Simulations is out-of-date along with the instructions. I did cli.

You have the crash report, GitHub has the actual source for that version in Releases. Uploaded .dSYM also. (https://github.com/com-entonos/Desktop-Icon-Manager/releases/tag/4.5.1)

Appreciate the interest,

GitHub has the actual source for that version in Releases

OK. I downloaded the app, the .dSYM, and the source code and took a look.

First, the crash report has this:

Binary Images:
       0x102c6c000 -        0x102c9ffff DIM arm64  <3e247524da7930099f63cd12ace4ab0e> …/DIM

I used dwarfdump to confirm that I have the right .dSYM:

% dwarfdump --uuid DIM.app/Contents/MacOS/DIM
UUID: 7A4DAC69-55A2-3D1B-B9E0-6A14AB2D5EEA (x86_64) DIM.app/Contents/MacOS/DIM
UUID: 3E247524-DA79-3009-9F63-CD12ACE4AB0E (arm64) DIM.app/Contents/MacOS/DIM

I then symbolicated those frames:

% atos -l 0x102c6c000 -o DIM.app.dSYM 0x102c799bc 0x102c8b4d4
closure #1 in ViewController.restore(_:) (in DIM) (ViewController.swift:207)
thunk for @escaping @callee_guaranteed () -> () (in DIM) + 28

Plugging that into the backtrace, I get this:

Thread 1 Crashed::  Dispatch queue: com.apple.root.utility-qos
0 DIM                     … 0x102c6c000 + 55740 closure #1 in ViewController.restore(_:) (in DIM) (ViewController.swift:207)
1 DIM                     … 0x102c6c000 + 128212 thunk for @escaping @callee_guaranteed () -> () (in DIM) + 28
2 libdispatch.dylib       … _dispatch_call_block_and_release + 32
3 libdispatch.dylib       … _dispatch_client_callout + 16
4 libdispatch.dylib       …  + 32
5 libdispatch.dylib       … _dispatch_root_queue_drain + 736
6 libdispatch.dylib       … _dispatch_worker_thread2 + 180
7 libsystem_pthread.dylib … _pthread_wqthread + 232
8 libsystem_pthread.dylib … start_wqthread + 8

I then loaded the app up in LLDB:

% lldb DIM.app
(lldb) target create "DIM.app"
Current executable set to '/Users/quinn/Desktop/DesktopIconManager4.5.1/DIM.app' (arm64).

and looked at the actual crashing address:

(lldb) disas -s 0x100000000+55740
DIM`Swift runtime failure: Unexpectedly found nil while unwrapping an Optional value:
DIM[0x10000d9bc] <+1288>: brk    #0x1

Note The crash report shows that 55740 is the offset from the start of the image to the crashing instruction. LLDB loads the main image at 0x100000000, that is, after the 4 GiB page zero segment. By adding these together we get the crashing address for the LLDB context.

The brk is a trap instruction for 64-bit Apple silicon code. When Swift inserts such a trap, it tries to put it at a unique address and add a symbol for that address that indicates the type of trap. Hence the nice output from LLDB.

Now let’s look at the source address indicated by the symbolication, line 207 of ViewController.swift:

203 // restore from arrangement given by name
204 func restore(_ name: String) {
205     updateUI("Restoring Icon Positions...")
206     DispatchQueue.global(qos: .utility).async { [unowned self] in
207         self.setSet(set: self.arrangements[name]!)
208         self.dim!.numOnDesktop = 0
            …
213     }
214 }

It seems most likely that self.arrangements[name] is nil [1]. This confirms my earlier assertion that this is an issue with your code rather than the system-level issue that bwill was bumping in to.

Looking further into the code, I bumped into some serious concurrency holes. You access self.arrangements from both the the main thread (via the timer scheduled in refreshTimer()) and a Dispatch global concurrent queue (via the code shown above). The Swift concurrency model considers this undefined behavior. Honestly, you’re lucky that you crashed so ‘cleanly’; concurrency bugs are often much harder to find.

I recommend that you take a step back, look at the big picture of the concurrency within this app, decide on a plan, and implement that. And if were in your shoes I’d enable the Swift 6 language mode, whereupon the compiler will help you avoid issues like this.

Oh, and I also recommend that you not use Dispatch global concurrent queues. See Avoid Dispatch Global Concurrent Queues has the full story on that front.

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

[1] It wouldn’t surprise me if the actual issue was that self.dim was nil, but self.dim has the same concurrency issues as self.arrangements.

Thank you. Particularly for the step-by-step, very informative.

The algorithm should have insured arrangements[name] is not nil well before func restore was called (therefore no test to confirm).

Appreciate your time and efforts- never fun looking at another's code. Also understand your concerns about concurrency. They are valid.