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?
