ConvolverNode: SIGSEGV in Convolver::process caused by a race in ThreadPool::wait()
メンテナーはふだん 1 日以内に返信
まだ誰も着手していません。
評価
- 難易度
- 4/5
- 見積もり時間
- 3〜5日
- 初心者へのやさしさ
- 48/100
- issue の種類
- バグ
- 明瞭さ
- 明確に書かれている
- 活発さ
- 活発
- 技術スタック
- android, cpp, react-native
調査の方向性
Start with common/cpp/audioapi/utils/ThreadPool.hpp, focusing on schedule() and wait(), then trace the captured processingBuffer references in ConvolverNode::processNode. Reproduce with the issue’s standalone harness and widened scheduling window. Done means wait() does not return before all tasks in the current batch complete, with a regression test covering the race and no dangling buffer access.
索引モデルが issue の本文から書いたものです。
説明
Description
We got a native crash in production (Android, arm64) inside Convolver::process:
#00 libc.so (__memcpy_aarch64_simd+232)
#01 libreact-native-audio-api.so (audioapi::Convolver::process(audioapi::AlignedAudioArray<64ul> const&, audioapi::AlignedAudioArray<64ul>&)+112)
#02 libreact-native-audio-api.so (audioapi::move_only_function<void ()>::callable_impl<... audioapi::ThreadPool::schedule<audioapi::ConvolverNode::performConvolution(std::shared_ptr<audioapi::AlignedAudioBuffer<64ul>> const&)::$_1 ...>::operator()())
#03 libreact-native-audio-api.so (audioapi::ThreadPool::workerThreadFunc(...)+220)
#04 libreact-native-audio-api.so (std::__thread_proxy ...)
#05 libc.so (__pthread_start)
It has happened once so far. I think it comes from a race in ThreadPool::wait() (common/cpp/audioapi/utils/ThreadPool.hpp). The code is the same in 0.13.2, 0.13.6 and on main as of today.
The interleaving:
- Quantum N: the audio thread schedules the convolver tasks. All of them finish before the audio thread reaches
wait(). The last worker has donetasksScheduled.fetch_sub(count is now 0), but it gets preempted beforewaitingForTasks.store(false)/notify_one(). - The audio thread calls
wait(): it storestrue, seestasksScheduled == 0, storesfalseand returns. That is correct for quantum N. - Quantum N+1: the audio thread schedules new tasks (count > 0), calls
wait(), storestrueand blocks inwaitingForTasks.wait(true). - The worker from step 1 resumes and runs
store(false)+notify_one().wait()returns while the tasks from quantum N+1 are still pending or running.
After that, ConvolverNode::processNode returns early. The scheduled lambdas capture processingBuffer by reference ([&, i] in the mono branch, &processingBuffer in the stereo branch). That is a const std::shared_ptr<DSPAudioBuffer>& bound to a local in AudioNode::processAudio, so once the frame is gone the worker reads a dangling reference. Convolver::process then copies from it (_inputBuffer->copy(input, ...)), which matches the memcpy frame at process+112.
Steps to reproduce
The race window is a few instructions wide, so it does not show up in normal use. I reproduced it with a standalone harness that compiles ThreadPool.hpp as is, on macOS with clang++ -std=c++20.
- Stock header: with fast tasks, 2,000,000 quanta give 0 early returns. The window is too small to hit by chance.
- Widened window: I put a 2.5 ms sleep between
fetch_subreaching 0 andstore(false)on 1 in 7 tasks. I also delay the scheduling thread for 3 ms beforewait()on every third quantum, which simulates the audio thread being preempted. The sleep only stands in for a preempted worker and does not change the logic. In this setup,wait()returned with 0/2 tasks done in 142 of 3,000 quanta. - With the fix below: the same widened setup gives 0 early returns.
Harness (the check after wait() is the only assertion):
#include <audioapi/utils/ThreadPool.hpp>
#include <atomic>
#include <chrono>
#include <cstdio>
#include <thread>
int main() {
audioapi::ThreadPool pool(4);
std::atomic<int> done{0};
long early = 0;
for (long q = 0; q < 3000; ++q) {
done.store(0);
for (int i = 0; i < 2; ++i)
pool.schedule([&done] {
std::this_thread::sleep_for(std::chrono::microseconds(1000));
done.fetch_add(1);
});
if (q % 3 == 0) std::this_thread::sleep_for(std::chrono::microseconds(3000)); // scheduler preempted
pool.wait();
if (done.load() != 2) { ++early; while (done.load() != 2) {} }
}
std::printf("early_returns=%ld\n", early);
}
For the widened run, add this inside the bound task's if (left == 0) branch, before store(false):
if (counter++ % 7 == 0) std::this_thread::sleep_for(std::chrono::microseconds(2500));
Suggested fix: wait on the counter itself, so a late wake-up from a previous batch can't release the waiter:
// in schedule()'s bound task, after f(...)
if (cntrl->tasksScheduled.fetch_sub(1, std::memory_order_acq_rel) == 1) {
cntrl->tasksScheduled.notify_all();
}
void wait() {
size_t pending;
while ((pending = controlBlock_->tasksScheduled.load(std::memory_order_acquire)) != 0) {
controlBlock_->tasksScheduled.wait(pending, std::memory_order_acquire);
}
}
With this, waitingForTasks is no longer needed. As a second safeguard, performConvolution could capture processingBuffer by value (it's a shared_ptr), so a task that outlives processNode doesn't read a dead stack slot.
Snack or a link to a repository
No public repo. The harness above is self-contained and needs only ThreadPool.hpp, SpscChannel.hpp, MoveOnlyFunction.hpp and core/utils/Constants.h on the include path.
React Native Audio API version
0.13.2 (code is unchanged in 0.13.6 and on main)
React Native version
0.86.2 (Expo SDK 57)
Platforms
Android
Architecture
New Architecture (bridgeless)
Build type
Release
Device
Real device
Device model
Android 16 (API 36), arm64
Acknowledgements
Yes, I searched the existing issues first.
- 主要言語
- 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 日以内に返信
-
Channel negotiation drops buffer swaps when several graph changes land in one render quantum対応中かも このイシューにリンクされたプルリクエストがオープン中、またはマージ済みです。 オープンbug
難易度 4/5 3〜5日 初心者へのやさしさ 48/100
software-mansion/react-native-audio-api#1332 · コメント 4 件 ·
メンテナーはふだん 1 日以内に返信
software-mansion/react-native-audio-api の issue をすべて見る
似ている issue
-
Mac mini M6 (16 GB): Q2_0 streaming works - measured 11.7->27.2 tok/s + arena fix for sub-32 GB Macsオープン
難易度 2/5 1〜3時間 初心者へのやさしさ 68/100
メンテナーはふだん 1 日以内に返信
-
champion good first issue remake source/qq
難易度 2/5 1〜3時間 初心者へのやさしさ 65/100
metasequoiaime/msime-windows#1025 ·
メンテナーはふだん 1 日以内に返信
-
backlog bug
難易度 2/5 1〜3時間 初心者へのやさしさ 75/100
EchoTools/nevr-runtime#653 ·
メンテナーはふだん 1 日以内に返信
-
`--fail-require-skip` never fires: run_tests.py searches stdout, but the unittest binary writes the skip summary to stderr対応中かも このイシューにリンクされたプルリクエストがオープン中、またはマージ済みです。 オープン
難易度 2/5 1〜3時間 初心者へのやさしさ 72/100
メンテナーはふだん 1 日以内に返信
-
難易度 2/5 1〜3時間 初心者へのやさしさ 75/100
InfiniTimeOrg/InfiniTime#2492 ·