Crash creating and using OSLCompiler instances in mutliple threads
メンテナーはふだん 1 日以内に返信
まだ誰も着手していません。
評価
- 難易度
- 5/5
- 見積もり時間
- 1週間以上
- 初心者へのやさしさ
- 35/100
- issue の種類
- バグ
- 明瞭さ
- おおむね明確
- 活発さ
- 停滞
- 技術スタック
- cpp
調査の方向性
ファイルもテストも指定されていません。まず、レポートで説明されている SymbolTable::delete_syms() と共有される TypeSpec::struct_list() から始め、その後、OSLCompiler と ShadingSystem によるそれらの使用箇所を追跡してください。並行インスタンスの所有権または同期に関する合意済みの設計があり、クラッシュが防止されることの証拠が得られれば完了です。
索引モデルが issue の本文から書いたものです。
説明
Problem
In the Cycles renderer we are getting crashes doing different renders in different threads, each creating their own OSLCompiler instances. From #654 it appears that this is supposed to work.
I think I understand the cause and am willing to contribute a fix, but looking for advice on the best way to solve this.
What happens is that OSLCompiler ends up calling this in its destructor:
void
SymbolTable::delete_syms()
{
for (auto& sym : m_allsyms)
delete sym;
m_allsyms.clear();
TypeSpec::struct_list().clear();
}
This TypeSpec::struct_list() is a global variable used by OSLCompiler, and also ShadingSystem. So fully clearing it here is not safe.
I can think of a few solutions:
- Never clear this list and accept the memory usage.
ShadingSystemdoes not clear it as far as I can tell, so you already have this when not compiling shaders. - Add reference counting to only clear this list when there are zero classes using it. This also involves adding mutex protection in a bunch of places.
- Add a struct list per
OSLCompilerandShadingSystem, instead of making it global.
Solution (3) seems like the best to me, does that seem reasonable? Or is there some performance reason that this should be reused.
Versions
- OSL branch/version: master branch, 6b6637e
- OS: Ubuntu Linux
- C++ compiler: Clang
- 主要言語
- C++
- スター
- 2.3k
- フォーク
- 415
- 平均マージ
- 2日 14時間
- マージ済み PR（30日）
- 13
環境構築
はじめの一歩
- issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
- 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
- リポジトリをフォークし、ブランチを切って変更します。
- issue 番号を参照したプルリクエストを送ります。
AcademySoftwareFoundation/OpenShadingLanguage のほかの issue
-
build / testing / port / CI
難易度 2/5 1〜3時間 初心者へのやさしさ 68/100
AcademySoftwareFoundation/OpenShadingLanguage#2148 · コメント 5 件 ·
メンテナーはふだん 1 日以内に返信
-
難易度 2/5 1〜3時間 初心者へのやさしさ 68/100
AcademySoftwareFoundation/OpenShadingLanguage#2109 · リアクション 1 件 ·
メンテナーはふだん 1 日以内に返信
-
難易度 5/5 1週間以上 初心者へのやさしさ 38/100
AcademySoftwareFoundation/OpenShadingLanguage#2175 ·
メンテナーはふだん 1 日以内に返信
-
難易度 5/5 1週間以上 初心者へのやさしさ 25/100
AcademySoftwareFoundation/OpenShadingLanguage#2146 ·
メンテナーはふだん 1 日以内に返信
-
難易度 4/5 3〜5日 初心者へのやさしさ 45/100
AcademySoftwareFoundation/OpenShadingLanguage#2135 ·
メンテナーはふだん 1 日以内に返信
AcademySoftwareFoundation/OpenShadingLanguage の issue をすべて見る
似ている issue
-
bug
難易度 1/5 1〜3時間 初心者へのやさしさ 88/100
isl-org/Open3D#7585 · コメント 1 件 ·
メンテナーはふだん 2 日以内に返信
-
Unconfirmed bug
難易度 1/5 1時間未満 初心者へのやさしさ 88/100
luanti-org/luanti#17605 · コメント 1 件 ·
メンテナーはふだん 2 日以内に返信
-
area: config area: firmware priority: P2 - medium size: S type: bug
難易度 2/5 1〜3時間 初心者へのやさしさ 76/100
Mizithra/ActiveTerrain#16 ·
-
難易度 2/5 1〜3時間 初心者へのやさしさ 84/100
grumpycoders/pcsx-redux#2171 ·
メンテナーはふだん 1 日以内に返信
-
難易度 2/5 1〜3時間 初心者へのやさしさ 70/100
メンテナーはふだん 2 日以内に返信