macOS 26 – NSSound/CoreAudio causes SIGILL crash in caulk allocator

Question

Created 2w

Replies 7

Boosts 0

Views 1k

Participants 4

Hi everyone, We are the engineering team behind an enterprise communications application for macOS. We are experiencing a critical crash on macOS 26 that did not occur on any previous macOS version. We are seeking clarification from Apple engineers or anyone who may have insight into this behaviour.

Environment Architecturex86_64macOS26.4.1 (25E253)HardwareMac15,13 (MacBook Pro)ExceptionSIGILL / ILL_ILLOPCCrashed ThreadThread 0 (Main Thread)TriggerPlaying a notification sound via NSSound during an incoming call

Crash Stack 0 caulk
consolidating_free_map::maybe_create_free_node + 119 ← SIGILL

1 caulk
tiered_allocator + 1469

2 caulk
exported_resource::do_allocate + 15

3 AudioToolboxCore
EABLImpl::create + 204

4 CoreAudio
AUNotQuiteSoSimpleTimeFactory + 33267

8 AudioToolboxCore
AudioUnitInitialize + 189

9 AudioToolbox
XAudioUnit::Initialize + 19

10 AudioToolbox
MESubmixGraph::initialize + 125

11 AudioToolbox
MESubmixGraph::connectInputChannel + 1172

12 AudioToolbox
MEDeviceStreamClient::AddRunningClient + 509

15 AudioToolbox
AudioQueueObject::StartRunning + 194

16 AudioToolbox
AudioQueueObject::Start + 1447

22 AudioToolbox
AQ::API::V2Impl::AudioQueueStartWithFlags + 805

23 AVFAudio
AVAudioPlayerCpp::playQueue + 354

24 AVFAudio
AVAudioPlayerCpp::DoAction + 134

25 AVFAudio
-[AVAudioPlayer play] + 26

26 AppKit
-[NSSound play] + 100

27 Our App
-[AudioHelper tryToStartSound:ofType:] + 569

28 Our App
block_invoke + 59

Behaviour Difference Between macOS Versions The exact same code path that triggers this crash on macOS 26 works without any issue on macOS 14 and macOS 15 — no crash, no warning, no log output of any kind. The crash occurs inside Apple's private caulk memory allocator during CoreAudio audio engine initialisation, triggered by a call to [NSSound play]. The SIGILL / ILL_ILLOPC at maybe_create_free_node + 119 suggests a hard ud2 trap — an intentional abort guard inserted at compile time. This strongly suggests that something changed in macOS 26 within NSSound / CoreAudio / caulk that causes this code path to fail in a way it previously did not.

Questions We have the following specific questions:

Was there a deliberate threading policy change in NSSound / CoreAudio in macOS 26?

Is the SIGILL in caulk::consolidating_free_map::maybe_create_free_node an intentional thread-affinity assertion introduced in macOS 26?

Are there any other NSSound / AVAudioPlayer / AudioQueue APIs that have similarly tightened their requirements in macOS 26 that we should be aware of?

Is there a migration guide, release note, or WWDC session that covers CoreAudio changes in macOS 26 that we may have missed?

Has anyone else in the developer community encountered a similar SIGILL crash in caulk on macOS 26 during audio playback?

Answered by sbhagat in 886219022

Hello DTS Engineer,

Please find attached whole log ,

crash.crash

Code Implementation where it is crashing

Boost

Answer 1

DTS Engineer OP

Apple

2w

To learn more about this I need to see a full Apple crash report. Please post one, per the advice in Posting a Crash Report.

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

0

Answer 2

sbhagat OP

2w

Accepted Answer

Hello DTS Engineer,

Please find attached whole log ,

crash.crash

Code Implementation where it is crashing

0

Answer 3

DTS Engineer OP

Apple

1w

You are correct that:

This is memory management code.
It’s trapped due to a failed assert.

Consider this:

(lldb) disas -a 0x00007ff821039082
caulk`caulk::alloc::consolidating_free_map<caulk::alloc::page_allocator, 10485760ul>::maybe_create_free_node:
    …
    0x7ff8210390a1 <+31>:  js     0x7ff8210390f9 ; <+119>
    …
    0x7ff8210390bb <+57>:  js     0x7ff8210390f9 ; <+119>
    …
    0x7ff8210390f9 <+119>: ud2    
    0x7ff8210390fb <+121>: nop

As you can see, the instruction at +119 is a ud2, which is the canonical trap instruction for Intel code. There are two ways to get there, which isn’t as helpful as it could be, but the difference doesn’t really matter because both traps are associated with various invariant failures.

How reproducible is this? Are you debugging it based on reports coming in from the field? Or can you reproduce it in your office?

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

0

Answer 4

greengreengreen OP

5d

I have reports from one user of our software with the exact same issue with macOS 26.4.1 We call [NSSound play] on a background thread in our app since ~ 2012. Maybe it should now be called on main thread ? However we have not had reports from other users, so I have asked them if they are using a different Audio Output to the Mac Built-in output. As maybe that is the difference. I have attached the crash log.

crash.txt

0

Answer 5

DTS Engineer OP

Apple

4d

So, lemme see if I understand this correctly:

You have one user who’s consistently experienced this crash on macOS 26.
You’ve not received reports of it from other users.
You can’t reproduce it yourself.

Is that right?

Has that users seen it on all versions of macOS 26? Or just macOS 26.4?

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

0

Answer 6

Yanziyi OP

1d

I've encountered the same issue on both macOS 26.4 and macOS 26.5. The crash report is attached.

crash.txt

0

Answer 7

DTS Engineer OP

Apple

1h

I've encountered the same issue

OK. Then I have the same question for you: How reproducible is it?

We’ve definitely seen bug reports about this. The conclusion is that, yeah, something is corrupting memory. It’s hard to be sure what that is, but we’ve made some changes to the OS to help debug it (r. 170652193). However, those changes are not yet in any released or seeded version of macOS.

If you’re hitting this, try running your app under the standard memory debugging tools. Those tools aim to turn hard-to-reproduce memory management issues into reproducible ones, and if they do that in this case then that’ll be a significant step in the direction of a fix.

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

0