AXSpeech Thread Crash SEGV_ACCERR

Do you have a full Apple crash report for this problem? If so, please post it here, using the process described in Posting a Crash Report.

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

I encountered the same issue. Have you resolved it?

Speaking for myself only, I need a proper crash report before I can offer any insight into this. If you can post one here, using the instructions I linked to above, I’d be happy to take a look.

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

Thank you very much. This issue has been troubling me for months. My app frequently uses TTS, and the crash report has been attached. If you need more detailed information, please contact me. Additionally, I suspect it is a thread safety issue. I have tried making some calls on the main thread, but it hasn’t worked. I have also attached the code separately as an attachment.

Thanks for those crash reports.

Are you able to find a JSON crash report (.ips) for this? If so, please post it, because it may allow me to learn more about the issue.

In the absence of that then, yeah, at first blush this is looks like an Apple problem rather than a problem with your code. Consider the crashing thread from your first crash report:

Thread 22 name:
Thread 22 Crashed:
0  CoreFoundation          … __CFCheckCFInfoPACSignature + 4 (CFRuntime.c:559)
1  CoreFoundation          … CFRunLoopSourceSignal + 28 (CFRunLoop.c:4312)
2  Foundation              … performQueueDequeue + 484 (NSThread.m:1063)
3  Foundation              … __NSThreadPerformPerform + 88 (NSThread.m:1077)
4  CoreFoundation          … __CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE0_PERFORM_FUNCTION__ + 28 (CFRunLoop.c:1970)
5  CoreFoundation          … __CFRunLoopDoSource0 + 172 (CFRunLoop.c:2014)
6  CoreFoundation          … __CFRunLoopDoSources0 + 332 (CFRunLoop.c:2059)
7  CoreFoundation          … __CFRunLoopRun + 840 (CFRunLoop.c:2969)
8  CoreFoundation          … CFRunLoopRunSpecific + 572 (CFRunLoop.c:3434)
9  Foundation              … -[NSRunLoop(NSRunLoop) runMode:beforeDate:] + 212 (NSRunLoop.m:375)
10 TextToSpeech            … -[TTSSpeechThread main] + 308 (TTSSpeechThread.m:63)
11 Foundation              … __NSThread__start__ + 732 (NSThread.m:991)
12 libsystem_pthread.dylib … _pthread_start + 136 (pthread.c:931)
13 libsystem_pthread.dylib … thread_start + 8 (:-1)

Frame 10 is interesting. It indicates that the text-to-speech subsystem has an NSThread subclass that it uses for… well… something. Frames 9 through 5 indicate that this thread is running a run loop. Frames 4 through 0 indicate that the run loop is handling a run loop source, which is then crashing in frame 0 due to a PAC check. Typically this means that something has got corrupted.

Now, frame 3 is super interesting. This suggests that the run loop source is actually the result of Foundation’s thread perform feature, for example, a call to the perform(_:on:with:waitUntilDone:)) method. This gels with my understanding of how this thread works, that is, text-to-speech serialises work on that thread via perform(_:on:with:waitUntilDone:).

So, there are a couple of possibilities here:

• There’s a logic bug within the text-to-speech subsystem.
• There’s some sort of general memory corruption bug, and the text-to-speech subsystem is an innocent bystander.

I suspect it’s actually the first one, because this forums thread suggests that this issue is affecting multiple apps. However, that’s just a guess. Memory management issues are notoriously tricky.

If you run your app under the standard memory debugging tools, does it help make this issue more reproducible?

Oh, one last thing: All of those crash reports are from iOS 18 and earlier. Have you seen this reported on iOS 26?

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

Thank you very much for your time. The issue is still unresolved. I tried using the Instruments memory tool and enabled malloc scribble, but unfortunately, the crash has not been reproduced yet. By the way, there is a crash on the iOS 26 system, and the crash stacks for iOS 26, 18, and 17 are the same as the ones I sent earlier. I noticed that on systems below iOS 17, the crash stack has changed to a different form, and the crash occurs in [AXSpeechThread main] (in libAXSpeechManager.dylib). I have attached the crashes for iOS 26 and iOS 16. Could you please provide guidance?

Those crash reports didn’t come through intact )-:

To summarise the points I made earlier:

• To look into this in more detail I need a complete Apple crash report.
• Ideally a JSON crash report (.ips).
• Ideally one from an app with no third-party crash reporters [1].

See Posting a Crash Report for advice on how to post such a crash report.

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

[1] See Implementing Your Own Crash Reporter for an explanation as to why third-party crash reporters are a problem.