Isolate SOS hosting from other debugger extensions that use managed code
メンテナーはふだん 1 日以内に返信
評価
- 難易度
- 5/5
- 見積もり時間
- 1週間以上
- 初心者へのやさしさ
- 25/100
調査の方向性
Start by tracing native SOS initialization and managed hosting in the SOS code, then inspect how debugger interfaces and callbacks are registered. The issue identifies dependency isolation, existing CoreCLR handling, Windows AppDomain boundaries, and initialization rollback as connected design constraints. Done means SOS can initialize alongside another managed debugger extension without dependency conflicts or unusable partial state.
索引モデルが issue の本文から書いたものです。
説明
Description
SOS should work when another WinDbg or LLDB extension that uses managed code has already started a runtime or loaded different dependency versions. This concerns independently loaded debugger extensions, not optional SOS extensions.
Current issues on main:
- CoreCLR dependency conflicts: SOS infrastructure loads into Default, sharing assembly bindings with other managed debugger extensions. Incompatible dependencies loaded first can prevent initialization or break commands.
ExtensionLoadContextisolates optional SOS extensions, not SOS infrastructure. - Existing-runtime handling: SOS selects a runtime and calls
coreclr_initializewithout explicitly handling an already-active CoreCLR. Its TPA/probing setup cannot be assumed to replace the existing host's configuration or make SOS assemblies discoverable there. - Framework/AppDomain isolation: SOS runs in the default AppDomain. Its failed-bind resolver cannot override incompatible bindings that already succeeded. A dedicated AppDomain could isolate dependencies, but managed objects cannot simply be shared across domains without marshaling/remoting. A native COM-compatible boundary can avoid remoting, provided the domain remains alive while the debugger retains interface pointers or callbacks. Unloading it would invalidate those pointers. AppDomain isolation also cannot replace the underlying CLR version.
- Incomplete initialization recovery: Initialization publishes native pointers, the initialized flag, and managed singleton state before registration succeeds, without complete rollback. Failures can leave partial state and block reconfiguration. Windows may also fall back to Framework after CoreCLR initialization fails.
Configuration
Native SOS hosting in WinDbg or LLDB. The Framework/AppDomain path applies to supported Windows configurations.
Regression?
Not established.
Other information
N/A
- 主要言語
- C++
- スター
- 1.3k
- フォーク
- 407
- 平均マージ
- 21時間 5分
- マージ済み PR（30日）
- 78
環境構築
このプロジェクトの開発コンテナを、あなたの GitHub アカウントでブラウザ上に起動します。
- Dockerfile・Docker Compose ファイルなし
- プルリクエストのテンプレートなし
- コントリビューションガイドなし
はじめの一歩
- issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
- 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
- リポジトリをフォークし、ブランチを切って変更します。
- issue 番号を参照したプルリクエストを送ります。
dotnet/diagnostics のほかの issue
-
Fix StackAndOtherTests.script line number verification for .NET 11 and Windows x64再び着手できるかも このイシューのプルリクエストはマージされずにクローズされました。 オープン
難易度 2/5 1〜3時間 初心者へのやさしさ 65/100
dotnet/diagnostics#5884 · コメント 2 件 ·
メンテナーはふだん 1 日以内に返信
-
難易度 4/5 3〜5日 初心者へのやさしさ 25/100
dotnet/diagnostics#6225 ·
メンテナーはふだん 1 日以内に返信
-
難易度 4/5 3〜5日 初心者へのやさしさ 48/100
dotnet/diagnostics#6213 ·
メンテナーはふだん 1 日以内に返信
-
Known Build Error
難易度 4/5 3〜5日 初心者へのやさしさ 49/100
dotnet/diagnostics#6190 ·
メンテナーはふだん 1 日以内に返信
-
enhancement sos tracking
難易度 4/5 3〜5日 初心者へのやさしさ 25/100
dotnet/diagnostics#6130 ·
メンテナーはふだん 1 日以内に返信
dotnet/diagnostics の issue をすべて見る
似ている issue
-
難易度 2/5 1〜3時間 初心者へのやさしさ 76/100
AutoHotkey/AutoHotkey#380 ·
-
documentation
難易度 1/5 1〜3時間 初心者へのやさしさ 84/100
メンテナーはふだん 1 日以内に返信
-
難易度 2/5 1〜3時間 初心者へのやさしさ 69/100
grumpycoders/pcsx-redux#2667 ·
-
GCC 15.2: -Wcast-qual warning - cast discards const qualifier from pointer target type (H5trace.c)オープン
難易度 2/5 1〜3時間 初心者へのやさしさ 73/100
メンテナーはふだん 1 日以内に返信
-
難易度 2/5 1〜3時間 初心者へのやさしさ 88/100
google/tensorstore#305 ·