CrossOver Bug Report — intermittent `c000001d` abort in winecoreaudio audio-unit init

# CrossOver Bug Report — intermittent `c000001d` abort in winecoreaudio audio-unit init (Apple Silicon / macOS 26)

## Summary

A 32-bit Windows game (GTA: San Andreas + SA-MP/open.mp) intermittently aborts
the whole process (CRT `abort()`, exit code 3) the moment its audio engine
creates a render audio unit. The crash is an **illegal instruction
(`EXCEPTION_ILLEGAL_INSTRUCTION`, `c000001d`) raised inside the native macOS
CoreAudio/AudioToolbox shared-cache code** that `winecoreaudio.drv` calls into,
which Wine's `mmdevapi` then turns into `assert(!status)` →
`_wassert(..., "mmdevapi_private.h", 120)` → `abort()`.

It is **intermittent and timing-dependent**: with the exact same machine,
output device, and negotiated audio format, the same launch succeeds roughly
half the time and aborts the other half. Running Wine with verbose `WINEDEBUG`
logging (which slows execution) makes it succeed far more often, which is the
classic signature of a race / timing-sensitive fault in the emulated CoreAudio
path rather than a format- or device-specific bug.

## Environment

| | |
|---|---|
| CrossOver | 26.1.0.39808 |
| macOS | 26.5 (build 25F71) — "Tahoe" |
| Hardware | Apple M1 (arm64) |
| Bottle Windows version | (Rockstar Games Launcher bottle) |
| Game process | 32-bit (i386) — uses `i386-windows/winecoreaudio.drv` |
| App | GTA: San Andreas + SA-MP 0.3.7-R5 / open.mp client |
| Audio driver | `HKCU\Software\Wine\Drivers\Audio = coreaudio` |
| Default output device | USB EarPods, 44100 Hz, stereo |

The crash reproduces with both built-in speakers and external USB/Bluetooth
output devices, so it is **not** specific to the built-in audio device.

## The fault

The faulting instruction is at a **fixed shared-cache address inside Apple's
audio frameworks**:

```
handle_syscall_fault code=c000001d flags=0 addr=0x7ff81253a0ed ip=7ff81253a0ed tid=0a14
  rax=0000000217cf3060 rbx=00007ff84611d9a0 rcx=ffffffffffffefa0 rdx=0000000000001040
  rsi=0000000217cf2000 rdi=00007ff84611d9a0 rbp=00000001000ff830 rsp=00000001000ff830
   r8=0000000000000000  r9=0000000000000000 r10=0000000000002081 r11=00000000000007fb
  r12=0000000000001040 r13=0000000217cf2000 r14=0000600001d9c5c0 r15=00007ff84611d840
handle_syscall_fault returning to user mode ip=000000007bdf1287 ret=c000001d
err:msvcrt:_wassert (L"!status",L"../../wine/dlls/mmdevapi/mmdevapi_private.h",120)
```

Observations about the register state at the fault:

- `ip = 0x7ff81253a0ed` is in the dyld **shared cache** (Apple system library
  region), i.e. native CoreAudio/AudioToolbox code, **not** Wine code.
- `rsi/r13 = 0x217cf2000` and `rdi/rbx = 0x7ff84611d9a0` look like source and
  destination buffer pointers; `rdx = r12 = 0x1040` (4160) looks like a byte
  count. This is consistent with a **vectorized (SIMD/AVX) buffer-processing /
  resampling instruction** in Apple's audio code that the emulation layer fails
  to execute on this particular invocation.
- `ret = c000001d` confirms the kernel/host delivered an illegal-instruction
  signal, which Wine surfaced as `EXCEPTION_ILLEGAL_INSTRUCTION`.

The `assert(!status)` then fires in `mmdevapi_private.h:120`, the SEH unwind
propagates as a `c0000005` through the game's own DLL frames, and the CRT calls
`abort()`.

## Call sequence immediately before the fault

```
coreaudio:unix_get_mix_format Got channel layout: {tag: 0x0, bitmap: 0x0, num_descs: 2}
coreaudio:dump_adesc final: mSampleRate:      44100.000000
coreaudio:dump_adesc final: mBytesPerPacket:  8
coreaudio:dump_adesc final: mFramesPerPacket: 1
coreaudio:dump_adesc final: mBytesPerFrame:   8
coreaudio:dump_adesc final: mChannelsPerFrame: 2
coreaudio:dump_adesc final: mBitsPerChannel:  32          <-- 32-bit float, 44.1 kHz, stereo
   ... 18 ms later ...
seh:handle_syscall_fault code=c000001d ... ip=7ff81253a0ed  <-- illegal instruction in native CoreAudio
msvcrt:_wassert (L"!status", mmdevapi_private.h, 120)       <-- Wine asserts, process aborts
```

The fault happens during the **creation/initialization of the render audio
unit** (right after `unix_get_mix_format` produced the 32-bit-float descriptor),
**before** `unix_set_volumes` runs.

## Why we believe it is a race, not a format/device bug

We captured a **successful** session and a **crashing** session from the same
machine minutes apart, with identical hardware and audio config:

| | Successful run (exit 0) | Crashing run (exit 3) |
|---|---|---|
| Output device | EarPods (USB, 44100) | EarPods (USB, 44100) — identical |
| Negotiated format | 44100 / 32-bit float / stereo | 44100 / 32-bit float / stereo — identical |
| `unix_get_mix_format` adesc | same values | same values |
| Outcome | audio unit created, game runs | `c000001d` in CoreAudio → abort |

The successful run even builds the audio unit **twice** (initial + a
re-negotiation ~3 s later) and survives both. The only material difference is
**timing** — and verbose `WINEDEBUG` logging (which adds latency around the
audio-unit init) dramatically reduces the crash rate. This strongly points to a
**non-deterministic fault in the emulated execution of Apple's CoreAudio SIMD
code** under specific buffer/timing conditions.

## Reproduction

1. macOS 26.x on Apple Silicon, CrossOver 26.1.
2. Install GTA: San Andreas + SA-MP/open.mp in a bottle; `Drivers\Audio =
   coreaudio`.
3. Launch the game and connect to a server (audio unit gets created on first
   sound playback) — this usually succeeds.
4. Disconnect and reconnect (forces the audio engine to tear down and
   re-create the render audio unit). This re-rolls the dice; it aborts with
   exit code 3 a large fraction of the time.

Running with `WINEDEBUG=+coreaudio,+mmdevapi,+seh` makes step 4 succeed much
more often, confirming the timing sensitivity.

## What does NOT work around it

- Forcing `HKCU\Software\Wine\DirectSound` to `HardwareAcceleration=Emulation`,
  `DefaultSampleRate=48000`, `DefaultBitsPerSample=16` — the game's audio still
  goes through `mmdevapi`/`coreaudio` and negotiates 44100/32-bit float anyway.
- Switching the default output device (built-in speakers → USB EarPods →
  Bluetooth) — the fault is device-independent.
- Setting a different nominal sample rate on the device.

## What would help

- A fix in `winecoreaudio.drv` (or the emulation layer) so the native CoreAudio
  buffer-processing call at the audio-unit-init path cannot raise an illegal
  instruction under emulation, or is retried/guarded.
- Alternatively, having `mmdevapi` treat this CoreAudio failure as a recoverable
  error (return a failing `HRESULT` to the caller) instead of `assert(!status)`
  → `abort()`, so a single audio-init hiccup does not kill the entire game
  process.

## Attached logs

Full `WINEDEBUG=+timestamp,+pid,+seh,+unwind,+process,+module,+loaddll,+threadname,+mmdevapi,+coreaudio,err+all,fixme+all`
session logs (one successful, one crashing) are available on request. The
crashing session's relevant excerpt is reproduced above.