Add CI coverage for the exported CLRMA `!analyze` path (dbgeng, out of command scope)

オープン
  • 何か問題がありますか？
#5,947 コメント 0 件 リアクション 0 件 担当者 0 名 GitHub で見る

メンテナーはふだん 1 日以内に返信

まだ誰も着手していません。

評価

難易度
5/5
見積もり時間
1週間以上
初心者へのやさしさ
35/100
issue の種類
機能追加
明瞭さ
おおむね明確
活発さ
静か
技術スタック
cpp
領域
devtools, testing-qa

調査の方向性

Microsoft.Diagnostics.DebugServices.UnitTests.csproj と ConfigFiles/Windows/Debugger.Tests.Config.txt を確認し、続いて issue #3111 と併せて ClrmaTests と BangAnalyzeTests を調査します。ext.dll に対応したデバッガーを有効にするか、native harness を使用して command scope なしで CLRMACreateInstance と AssociateClient を呼び出すかを評価します。CI が実際の out-of-command-scope パスを実行し、g_Ext*-null クラッシュをゲートできれば完了です。

索引モデルが issue の本文から書いたものです。

説明

Background

PR #5946 fixed a crash on the native (non-hosted) CLRMA path where the exported CLRMACreateInstance (invoked by dbgeng !analyze via ext!CLRMACreateCached) borrowed command-scoped g_Ext* debugger globals that are null outside a !command. Regression originated in #4667.

That PR added coverage that exercises the fixed native Target/DataTarget/Runtime object graph via !clrma under cdb with !SetHostRuntime -none. However, this does not reproduce the original crash, because the !clrma command runs in command scope (INIT_API_EXT() -> ExtQuery populates g_Ext* for the command's duration). The only trigger that runs outside command scope is dbgeng's !analyze, which we cannot exercise in CI today.

Why !analyze can't be tested in CI currently

  • No ext.dll in the test debugger package. The cdb-sos package (10.0.26100.1) used by the tests ships only dbgcore/dbgeng/dbghelp/DbgModel/symsrv - no ext.dll, so !analyze fails with "No export analyze found". DbgEngPath in Microsoft.Diagnostics.DebugServices.UnitTests.csproj points at this same package.
  • TestDbgEng harness is disabled. The <TestDbgEng>true</TestDbgEng> config blocks in ConfigFiles/Windows/Debugger.Tests.Config.txt are commented out (tracked by #3111), so ClrmaTests/BangAnalyzeTests (the only harness that issues !analyze) don't run in CI.

Ask

Add a test that drives CLRMA through the real out-of-command-scope entry point so the exact g_Ext*-null crash path is gated in CI. Options to evaluate:

  • Provide an ext.dll-capable debugger in the test assets (or a minimal harness) and re-enable a scoped TestDbgEng configuration (see #3111) so !analyze -v can run against a managed crash dump.
  • Alternatively, add a small native test harness that calls the exported CLRMACreateInstance + AssociateClient directly with no active command (mirroring ext!CLRMACreateCached), asserting no fault when the command-scoped globals are null.

References

  • Fix: #5946
  • Regression origin: #4667
  • Related disabled harness: #3111
主要言語
C++
スター
1.3k
フォーク
407
平均マージ
21時間 5分
マージ済み PR（30日）
78

環境構築

Codespaces で開く

このプロジェクトの開発コンテナを、あなたの GitHub アカウントでブラウザ上に起動します。

  • Dockerfile・Docker Compose ファイルなし
  • プルリクエストのテンプレートなし
  • コントリビューションガイドなし

はじめの一歩

  1. issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
  2. 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
  3. リポジトリをフォークし、ブランチを切って変更します。
  4. issue 番号を参照したプルリクエストを送ります。

dotnet/diagnostics のほかの issue

dotnet/diagnostics の issue をすべて見る

似ている issue

C++ の issue をもっと見る

新しい issue をメールで受け取る

初心者向けの GitHub issue を短くまとめたダイジェスト。