It’s probably worth filing a bug about that. Please post your bug number, just for the record. I created FB13454498. First, I recommend against using Dispatch global concurrent queues, as explained in Avoid Dispatch Global Concurrent Queues. Thank you. While the second WWDC link on the linked page correctly leads to a video, the first link (WWDC 2015 Session 718 Building Responsive and Efficient Apps with GCD) leads to a list of videos where that video cannot be found. Does it still exist? Second, synchronously dispatching to the main queue is a concern because it can block the current thread for long periods of time. I know, but that thread needs access to a resource possibly occupied by the main thread before being able to continue with its work. I think you’d be much better off investing in Swift concurrency. I'm still supporting macOS 10.13, while Swift concurrency is only available on macOS 10.15.

I forgot to mention that I'm doing this from a background thread: DispatchQueue.global().async { DispatchQueue.main.async { [self] in asd() // no warning or error } DispatchQueue.main.sync { [self] in asd() // warning: Call to method 'asd' in closure requires explicit use of 'self' to make capture semantics explicit; this is an error in Swift 6 } }

Shouldn't you be using self?.asd() in the closure for weak self? Not necessarily. One could use guard let self = self else { return } to avoid using self?. each time. But I don't need to use weak self in this case.

You could test this. I manually caused an infinite recursion at the same location as the other crash report and I got a crash report with 511 frames. Frames numbered 9 to 510 are all the same, and since 510 is the last one, it looks like it's cut off. Otherwise the frames look very similar to the crash report downloaded by Xcode. Thread 4 Crashed:: Dispatch queue: com.apple.root.user-initiated-qos 0 CoreFoundation 0x1837f5084 __CFStringEncodeByteStream + 76 1 Foundation 0x184901558 -[NSString(NSStringOtherEncodings) getBytes:maxLength:usedLength:encoding:options:range:remainingRange:] + 260 2 libswiftCore.dylib 0x1931cf194 _NSStringCopyBytes(_:encoding:into:) + 124 3 libswiftCore.dylib 0x1931d67f0 _StringGuts._foreignCopyUTF8(into:) + 80 4 libswiftCore.dylib 0x1931d7bc8 _StringGuts._foreignConvertedToSmall() + 68 5 libswiftCore.dylib 0x1931d7b44 _StringGuts.append(_:) + 1232 6 libswiftCore.dylib 0x19316ba80 String.write<A>(to:) + 56 7 libswiftCore.dylib 0x19300bef0 DefaultStringInterpolation.appendInterpolation<A>(_:) + 72 8 MyApp 0x1000e4538 String.appendingPathComponent(_:) + 924 (PathAdditions.swift:75) 9 MyApp 0x100119138 Snapshot.renameFile(_:to:) + 696 (Snapshot+Modify.swift:135) 10 MyApp 0x10011915c Snapshot.renameFile(_:to:) + 732 (Snapshot+Modify.swift:135) ... 510 MyApp 0x10011915c Snapshot.renameFile(_:to:) + 732 (Snapshot+Modify.swift:135) And it's also the same exception type: Exception Type: EXC_BAD_ACCESS (SIGBUS) Exception Codes: KERN_PROTECTION_FAILURE at 0x0000000170027fd8 Exception Codes: 0x0000000000000002, 0x0000000170027fd8 Termination Reason: Namespace SIGNAL, Code 10 Bus error: 10 Terminating Process: exc handler [66786] VM Region Info: 0x170027fd8 is in 0x170024000-0x170028000; bytes after start: 16344 bytes before end: 39 REGION TYPE START - END [ VSIZE] PRT/MAX SHRMOD REGION DETAIL Stack 16ff9c000-170024000 [ 544K] rw-/rwx SM=PRV thread 3 ---> STACK GUARD 170024000-170028000 [ 16K] ---/rwx SM=NUL ... for thread 4 Stack 170028000-1700b0000 [ 544K] rw-/rwx SM=PRV thread 4 I guess we solved the mystery? Probably the backtrace got cut off along the way between the user and my Xcode instance. Thank you very much for your help!

I recommend that you update your bug with information about your specific use case. Thanks, updated it. It's an app that scans user-selected directories, such as Macintosh HD, and shows the contents as a graph.

Thank you very much for your insights. How did thread 1 get started? You're right, I didn't notice that the stacktrace looks strange. The code in thread 1 is called from inside NSFileCoordinator.coordinate(readingItemAt:options:writingItemAt:options:error:byAccessor:), which in turn is called inside DispatchQueue.global(qos: .userInitiated).async, with some other of my code before and after each of these calls. What’s up with the symbolication? I'm not sure I understand why the double line 135 seems unlikely. I can confirm that in this case it's a recursive method call. Could it be that the program somehow went into infinite recursion, explaining why the thread's origin is cut off?

Thanks, attached the full crash report. crash.txt

The privilege to access other apps containers falls into that third group. Thanks for confirming. Personally, I think it's quite annoying that it gets shown each time, and the reason why I noticed this in the first place was that users of my app where asking me why the alert is shown each time they scan the disk, given that one is used to seeing this kind of alert only once. I have filed FB13410100 in case you're interested.

How is your app signed? A problem with the signature might prevent the OS from "remembering" that permission has been granted before. Thanks for the suggestion, but I don't think there's any problem with the signature. All other warnings (Calendar, Reminders, etc.) only get shown once, but this one gets shown each time. I think it only started appearing since macOS 14 Sonoma.

While I was writing my earlier answer I just got 10 new flows from 0.0.0.0 to 192.168.1.1 by /sbin/ping: socketType = SOCK_RAW, socketFamily = AF_INET, socketProtocol = IPPROTO_ICMP.

Sorry for my late reply, again I wasn't notified of your response despite watching this thread. Yes, they are NEFilterSocketFlow. I just got 2 outbound flows from local :: to remote ff02::2 (both port 0) by /usr/libexec/configd: socketType = SOCK_RAW, socketFamily = AF_INET6, socketProtocol = IPPROTO_ICMPV6.

In this case look at the local and remote ports, is everything the same here for the flows or are they different? I can now confirm that local host and port, and remote host and port are the same. The process path is always /usr/sbin/mDNSResponder.

Does this only happen when data starts moving on the flow? Isn't handleNewFlow(_:) called only when data starts moving? I couldn't find any mention of a different behaviour in the documentation.

The intended function to use when you specify the .cursorUpdate option on your tracking area is cursorUpdate(with:): Thanks, that really seems to solve the issue with the sample code I provided above. I guess updating the cursor once in cursorUpdate(with:) makes macOS aware that there is a custom cursor so it doesn't try to reset it continuously, as opposed to "force" setting it in mouseMoved(with:). The problem now is that I was really looking for a way to set a custom cursor whenever the mouse moves, because in my custom view there can be many hotspots that should change the mouse cursor, and I guess adding hundreds of tracking areas is not ideal... or is it? These hotspots also change very frequently. It seems like calculating and creating all individual tracking areas is very inefficient, as opposed to dynamically finding out what the cursor should be depending on the mouse cursor's position (particularly since in my case this can be done with some simple calculations).

Did you remove the container app using Finder? Yes.