iOS: deadlock (0x8BADF00D watchdog) with iosVoiceProcessing=true — handleEngineConfigurationChange isInUse vs AVAudioEngine dealloc dispatch_sync (nightly)
メンテナーはふだん 1 日以内に返信
まだ誰も着手していません。
評価
- 難易度
- 4/5
- 見積もり時間
- 3〜5日
- 初心者へのやさしさ
- 25/100
- issue の種類
- バグ
- 明瞭さ
- 明確に書かれている
- 活発さ
- 停滞
- 技術スタック
- cpp, ios, react-native
調査の方向性
PR #1290 と、クラッシュスタックに示されている AudioEngine のメソッド、特に rebuildAudioEngine、destroyAudioEnginePreservingSessionDeactivationState:、setAudioEngine: から始めてください。iosVoiceProcessing を有効にした状態で recorder と AudioContext のシーケンスを再現し、その後、メインスレッドの watchdog のデッドロックが発生しなくなったこと、またそのスタックが再現可能なリグレッションケースでカバーされていることを確認してください。
索引モデルが issue の本文から書いたものです。
説明
Summary
With new AudioRecorder({ iosVoiceProcessing: true }) on the current nightly, the app deadlocks on the main thread as soon as playback starts through an AudioContext, and iOS kills it with watchdog code 0x8BADF00D ("scene-update watchdog transgression … is stuck (deadlock)").
The crash report shows a lock-order inversion between the engine-configuration-change handler and the engine rebuild. PR #1290 ("fix(ios): engine-worker deadlock") moves the isInUse check inside the main-queue block, which is exactly the ordering in this trace — this issue is filed so that PR has something to close, and to add a reproducible stack.
Environment
react-native-audio-api1.0.0-nightly-1966b4a-20260918(audio-api-nightlydist-tag)- React Native 0.86.3, Expo SDK 57 (dev-client build, new architecture)
- iOS 26.6.2, iPhone 13 Pro (iPhone14,2), Xcode 27.0 (27A266a)
- Does not reproduce on
0.13.4(which has noiosVoiceProcessingoption) with the same JS.
Repro
AudioManager.setAudioSessionOptions({
iosCategory: "playAndRecord",
iosMode: "voiceChat",
iosOptions: ["defaultToSpeaker", "allowBluetoothHFP"],
});
await AudioManager.setAudioSessionActivity(true);
const rec = new AudioRecorder({ iosVoiceProcessing: true, androidInputPreset: "voiceCommunication" });
rec.onAudioReady({ sampleRate: 16000, bufferLength: 640, channelCount: 1 }, (ev) => {
/* Float32 → Int16 → WebSocket */
});
await rec.start(); // → {"status":"success"}
// Later, when the first remote PCM chunk arrives:
const ctx = new AudioContext({ sampleRate: 24000 });
const buf = ctx.createBuffer(1, samples, 24000);
// ... copyToChannel, createBufferSource, start()
Sequence observed: recorder starts fine → first TTS chunk arrives → AudioContext is created and a buffer scheduled → UI freezes → ~10 s later the watchdog kills the process.
Voice-processing IO changes the IO unit configuration, so AVAudioEngineConfigurationChangeNotification fires while the engine is being (re)built.
Crash report (excerpt)
Termination: FRONTBOARD 0x8BADF00D — scene-update watchdog transgression: app<me.duoai.mobilepoc> is stuck (deadlock)
Thread 0 (main, triggered):
libsystem_kernel kevent_id
libdispatch _dispatch_kq_poll
libdispatch _dispatch_event_loop_wait_for_ownership
libdispatch __DISPATCH_WAIT_FOR_QUEUE__
libdispatch _dispatch_sync_f_slow
AVFAudio -[AVAudioEngine dealloc]
app -[AudioEngine setAudioEngine:]
app -[AudioEngine destroyAudioEnginePreservingSessionDeactivationState:]
app -[AudioEngine rebuildAudioEngine]
app -[AudioEngine rebuildAudioEngineAndResumeIfNeeded]
app -[AudioEngine restartAudioEngine]
app __61-[SystemNotificationManager handleEngineConfigurationChange:]_block_invoke
libdispatch _dispatch_main_queue_drain
Thread "engine":
libsystem_kernel __psynch_mutexwait
libc++ std::recursive_mutex::lock()
app std::scoped_lock<std::recursive_mutex>::scoped_lock
app -[AudioEngine isInUse]
app -[SystemNotificationManager handleEngineConfigurationChange:]
CoreFoundation __CFNOTIFICATIONCENTER_IS_CALLING_OUT_TO_AN_OBSERVER__
Foundation -[NSNotificationCenter postNotificationName:object:userInfo:]
AVFAudio AVAudioEngineImpl::IOUnitConfigurationChanged() block
libdispatch _dispatch_source_invoke / _dispatch_lane_serial_drain
Main holds the engine recursive_mutex and dispatch_syncs onto the engine queue from -[AVAudioEngine dealloc]; the engine queue is blocked in isInUse waiting for that same mutex.
Full .ips available on request.
- 主要言語
- C++
- スター
- 848
- フォーク
- 95
- 平均マージ
- 3日 19時間
- マージ済み PR（30日）
- 30
環境構築
- Dockerfile・Docker Compose ファイルなし
- プルリクエストのテンプレートあり
- コントリビューションガイドを読む
はじめの一歩
- issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
- 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
- リポジトリをフォークし、ブランチを切って変更します。
- issue 番号を参照したプルリクエストを送ります。
software-mansion/react-native-audio-api のほかの issue
-
android bug
難易度 2/5 1〜3時間 初心者へのやさしさ 82/100
software-mansion/react-native-audio-api#1273 · コメント 5 件 ·
メンテナーはふだん 1 日以内に返信
-
bug
難易度 2/5 1〜3時間 初心者へのやさしさ 78/100
software-mansion/react-native-audio-api#1238 ·
メンテナーはふだん 1 日以内に返信
-
難易度 4/5 3〜5日 初心者へのやさしさ 25/100
software-mansion/react-native-audio-api#1350 ·
メンテナーはふだん 1 日以内に返信
-
難易度 4/5 3〜5日 初心者へのやさしさ 38/100
software-mansion/react-native-audio-api#1340 · コメント 1 件 ·
メンテナーはふだん 1 日以内に返信
-
難易度 4/5 3〜5日 初心者へのやさしさ 48/100
software-mansion/react-native-audio-api#1339 ·
メンテナーはふだん 1 日以内に返信
software-mansion/react-native-audio-api の issue をすべて見る
似ている issue
-
accessibility good first issue hacktoberfest help wanted
難易度 2/5 1〜3時間 初心者へのやさしさ 74/100
OpenChemistry/avogadrolibs#3184 ·
メンテナーはふだん 1 日以内に返信
-
難易度 2/5 1〜3時間 初心者へのやさしさ 68/100
Tracktion/tracktion_engine#475 ·
メンテナーはふだん 1 日以内に返信
-
難易度 2/5 1〜3時間 初心者へのやさしさ 72/100
redis/memtier_benchmark#732 ·
メンテナーはふだん 1 日以内に返信
-
binding:web core docs p3
難易度 2/5 1〜3時間 初心者へのやさしさ 85/100
RunanywhereAI/runanywhere-sdks#1123 ·
メンテナーはふだん 1 日以内に返信
-
ai_p3 comp-data-types
難易度 2/5 1〜3時間 初心者へのやさしさ 74/100
ClickHouse/ClickHouse#126316 ·
メンテナーはふだん 1 日以内に返信