Bug: gilrs gamepad init panics with thread exhaustion on macOS (WouldBlock)

[amiable-dev]

Bug Report

Summary

The Tauri GUI crashes on startup with repeated panics from gilrs-core when it fails to spawn a thread for gamepad initialization on macOS. The panic cascade exhausts the thread pool and terminates with a trace trap (SIGTRAP).

Stack Trace

thread 'tokio-runtime-worker' panicked at
  gilrs-core-0.5.15/src/platform/macos/gamepad.rs:81:14:
  failed to spawn thread: Os { code: 35, kind: WouldBlock,
  message: "Resource temporarily unavailable" }

The same panic fires repeatedly across multiple tokio runtime worker threads (observed on at least 2 distinct thread IDs: 32198892, 32198888), suggesting the gamepad initialization is retried on panic without backoff.

Root Cause Analysis

gilrs-core 0.5.15 on macOS spawns an OS thread (via std::thread::spawn) during Gilrs::new() for IOKit gamepad monitoring. When the process is near the thread limit (macOS default: ~2048 threads), the spawn fails with EAGAIN (errno 35 / WouldBlock). The gilrs code at gamepad.rs:81 calls .expect() on the thread spawn result, converting the error into a panic.

Contributing factors:

1. Gilrs::new() is called from a tokio runtime worker — if panics are caught and retried, each retry consumes a worker thread, creating a cascade
2. No gamepad is connected, but gilrs still spawns a monitoring thread
3. The Tauri app may already be near thread limits from CoreMIDI watcher + tokio runtime + WebView threads

Reproduction

cargo run -p conductor-gui
# Process exits with: [1] 45123 trace trap  cargo run -p conductor-gui

Observed on macOS (Darwin 25.2.0). No gamepad connected.

Expected Behavior

Gamepad initialization should fail gracefully when thread spawning is unavailable, logging a warning and disabling gamepad support for the session rather than panicking.

Proposed Fix

1. Wrap Gilrs::new() in catch_unwind in GamepadDeviceManager::new() or InputManager initialization — if gilrs panics, log a warning and set InputMode::MidiOnly
2. Guard against retry cascade — if gamepad init fails, do not retry on the same session
3. Consider lazy gamepad init — only initialize gilrs when InputMode::GamepadOnly or InputMode::Both is configured, not unconditionally
4. Upstream: gilrs-core should return Result instead of panicking on thread spawn failure (consider filing upstream issue on gilrs-rs/gilrs)

Environment

• OS: macOS (Darwin 25.2.0)
• gilrs-core: 0.5.15
• Rust runtime: tokio async
• Conductor version: v4.26.71+
• Gamepad connected: No

Labels

Bug, gamepad, macOS, panic