Hacktoberfest 2026: le issue che i maintainer hanno segnato per ottobre, aperte e adatte ai principianti. Sfoglia le issue Hacktoberfest

WASAPI: cached IMMDeviceEnumerator is created in one thread's STA and used after that thread exits

Aperta
  • Qualcosa non va?
#1,302 18 commenti 0 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 1 giorno

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
5/5
Tempo stimato
Più di una settimana
Idoneità per principianti
25/100
Tipo di issue
Bug
Chiarezza
Abbastanza chiara
Stato di attività
Tranquilla
Stack tecnologico
rust
Ambito
backend

Direzione di ricerca

Start with the ENUMERATOR initialization in src/host/wasapi/device.rs and COM lifetime handling in src/host/com.rs; then trace how default_device_monitor() stores the enumerator and how DefaultDeviceMonitor::drop unregisters its callback. Reproduce the failure with Windows tests run using --test-threads=1, then determine a lifetime strategy that covers both paths. Done means device enumeration and monitor cleanup remain safe after the creating thread exits.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

correctness host - wasapi platform - windows

Calling cpal's safe API on Windows can crash the process with STATUS_ACCESS_VIOLATION rather than returning an error.

Symptom

In a test binary run with --test-threads=1, a test that enumerates devices passes when run alone, but the process faults when other tests run in the same binary. The fault lands on an arbitrary later test and moves between runs. Two stacks from cdb, both faulting at +0x19d — the vtable read:

INVALID_POINTER_READ_c0000005
  windows::Win32::Media::Audio::IMMDeviceEnumerator::GetDefaultAudioEndpoint
  cpal::host::wasapi::device::default_device
  cpal::host::wasapi::device::default_input_device
  cpal::traits::HostTrait::default_input_device

INVALID_POINTER_READ_c0000005
  windows::Win32::Media::Audio::IMMDeviceEnumerator::EnumAudioEndpoints
  cpal::host::wasapi::device::Devices::new
  cpal::host::wasapi::impl$1::devices
  cpal::traits::HostTrait::input_devices

Observed on windows-latest GitHub Actions runners, cpal 0.17.3, and the same code is present on main.

Diagnosis

ENUMERATOR in src/host/wasapi/device.rs is a process-wide OnceLock<Enumerator>, created on whichever thread calls first, with unsafe impl Send + Sync. COM is initialised as COINIT_APARTMENTTHREADED through a thread-local in src/host/com.rs whose Drop calls CoUninitialize.

An STA belongs to the thread that created it. So once the first thread to touch cpal exits, the cached interface pointer is dangling, and every later caller reads a dead vtable. The comment at the initialisation site states the assumption that does not hold:

// COM initialization is thread local, but we only need to have COM initialized in the
// thread we create the objects in
com::com_initialized();

This is most visible where audio work happens on short-lived threads: whichever one touches cpal first owns the enumerator, and its exit breaks device access for the rest of the process.

Ruled out

  • CoCreateInstance failing is not a fit — that would panic at the .unwrap(), not fault at a vtable read.
  • Absent audio endpoints is not a fit either — that surfaces as an HRESULT from GetDefaultAudioEndpoint / EnumAudioEndpoints, not an invalid dereference.

Two affected paths

Making ENUMERATOR a thread_local fixes enumeration, but is not sufficient. default_device_monitor() clones the enumerator into DefaultDeviceMonitor, which is unsafe impl Send + Sync and stored in Stream. Its Drop calls UnregisterEndpointNotificationCallback, and carries this comment:

// Ensure COM is initialised on this thread before making COM calls. Drop can run on
// any thread (e.g. the audio run thread), which may not have called CoInitialize.

Initialising COM on the dropping thread does not help if the apartment that owns the object has gone. That path shares an apartment-bound pointer regardless of what the enumeration path does.

Possibly related earlier reports

#517, #539 and #596 all report this exit code and were closed as ASIO issues. #517 in particular describes "enumerate devices in another thread, after the thread returns, I get access violation", and its workaround was to spawn a thread and join it — which on the WASAPI path is precisely what destroys the apartment. It may be worth re-reading those with this in mind.

History

The cached enumerator dates to e8a0537 (Jun 2019). DefaultDeviceMonitor arrived with #1183 (May 2026), which widened the exposure to a second path.

Possible fixes

Listing these with tradeoffs rather than proposing one, since the ASIO and winit constraints are yours:

  • Per-thread enumerator (thread_local) — simple; fixes enumeration; leaves the monitor path.
  • No caching, create per call — same coverage as above; costs a CoCreateInstance per call.
  • A dedicated long-lived COM thread owning the enumerator and servicing calls — covers both paths, keeps STA, costs one parked thread.
  • Marshal via the Global Interface Table — canonical COM answer; the most machinery.
  • MTA — would solve it outright, but conflicts with the deliberate COINIT_APARTMENTTHREADED choice for ASIO and winit.

I have a branch with the per-thread change if it is useful as a starting point, but since it only closes the first path I have not opened it as a PR.

Open question

Does UnregisterEndpointNotificationCallback require the same IMMDeviceEnumerator instance that registered? The documentation reads that way. If so, it rules out "create a fresh enumerator at drop time" as a fix for the monitor path.

Minor, separate

CoCreateInstance(...).unwrap() in the enumerator initialiser lets a safe API abort the process on failure.

Lingua principale
Rust
Stelle
4k
Fork
554
Merge medio
2g 11h
PR unite (30g)
3

Preparare l'ambiente

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di RustAudio/cpal

Tutte le issue di RustAudio/cpal

Issue simili

Altre issue su Rust

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.