Coverage buffer that loses its initialization byte is reported as a passing run with an empty report (line-rate="1")
まだ誰も着手していません。
評価
- 難易度
- 4/5
- 見積もり時間
- 3〜5日
- 初心者へのやさしさ
- 52/100
- issue の種類
- バグ
- 明瞭さ
- おおむね明確
- 活発さ
- 活発
- 技術スタック
- csharp
- 領域
- testing-qa, tooling
調査の方向性
Start by tracing SharedMemoryStream.IsInitialized() through the collector path described in the issue, including the guards around AddPackage, AddStream, and PopulateCoverageStatus. Reproduce the offset-0 corruption using the harness and results linked from issue #232. Done means an uninitialized module buffer is made visible as an anomaly rather than producing a passing empty report that satisfies coverage thresholds.
索引モデルが issue の本文から書いたものです。
説明
Package: Microsoft.Testing.Extensions.CodeCoverage 18.11.2 (the latest at the time of writing)
Runtime: .NET 8 and .NET 10 hosts, Linux x64, xunit.v3 3.2.2 on Microsoft.Testing.Platform
Context: split out of #232, which 18.11.2 fixed. The harness and full results are in this comment.
Summary
If a module's coverage buffer loses its initialization byte, the run is reported as Passed! and the cobertura report is 178 bytes, with line-rate="1" over an empty <packages />. A coverage threshold passes it, so the data loss goes unnoticed.
Cause
The byte at offset 0 of the buffer is read by SharedMemoryStream.IsInitialized(). It gates whether a module enters the report at all: if (logStream.IsInitialized()) guards AddPackage, AddStream and PopulateCoverageStatus. Truncating the buffer zeroes that byte, and the host's flush writes only the indices where a probe fired, so index 0 is never restored.
Two runs isolate it to that byte, rather than to the data loss itself:
| what was done to the buffer | cobertura |
|---|---|
| write a single zero byte to offset 0; file length and all 1,356 probe bytes left intact | 178 bytes, line-rate="1" |
truncate to 0, re-extend to the original length, then set offset 0 back to 1 |
337,297 bytes, line-rate="0.027" |
The direction matters. When the flag survives, the report shows a low rate that honestly reflects the destroyed data, and any coverage threshold catches it. When the flag is lost, the report shows a perfect rate over zero lines, which every threshold passes.
Suggestion
The collector created the buffer and handed it to the host, so a module whose buffer comes back uninitialized is an anomaly it can detect, not a normal skip. Logging a warning at that point, or failing the coverage step, would make this loss visible.
- 主要言語
- C#
- スター
- 125
- フォーク
- 17
- 平均マージ
- 1時間 15分
- マージ済み PR（30日）
- 2
環境構築
このプロジェクトには開発コンテナ、Dockerfile、コントリビューションガイドがありません。まず README を読み、一般的な手順ははじめてのコントリビューションガイドを参照してください。
はじめの一歩
- issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
- 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
- リポジトリをフォークし、ブランチを切って変更します。
- issue 番号を参照したプルリクエストを送ります。
microsoft/codecoverage のほかの issue
-
難易度 5/5 1週間以上 初心者へのやさしさ 10/100
microsoft/codecoverage#255 ·
-
難易度 3/5 1〜2日 初心者へのやさしさ 22/100
microsoft/codecoverage#254 ·
-
難易度 4/5 3〜5日 初心者へのやさしさ 45/100
microsoft/codecoverage#253 · リアクション 1 件 ·
-
難易度 3/5 1〜2日 初心者へのやさしさ 65/100
microsoft/codecoverage#252 ·
-
難易度 4/5 3〜5日 初心者へのやさしさ 35/100
microsoft/codecoverage#249 · コメント 1 件 · リアクション 1 件 ·
microsoft/codecoverage の issue をすべて見る
似ている issue
-
再現済み 要トリアージ 誤判定
難易度 2/5 1〜3時間 初心者へのやさしさ 72/100
yksr-melt/Meltype#421 · コメント 1 件 ·
メンテナーはふだん 1 日以内に返信
-
難易度 2/5 1〜3時間 初心者へのやさしさ 64/100
Facepunch/sbox-public#12063 · コメント 1 件 ·
メンテナーはふだん 2 日以内に返信
-
documentation
難易度 2/5 1〜3時間 初心者へのやさしさ 84/100
facioquo/stock-indicators-dotnet#2316 · コメント 1 件 ·
メンテナーはふだん 1 日以内に返信
-
難易度 2/5 1〜3時間 初心者へのやさしさ 62/100
lostindark/DriverStoreExplorer#477 ·
メンテナーはふだん 1 日以内に返信
-
bug
難易度 2/5 1〜3時間 初心者へのやさしさ 72/100
eriknihlen/OpenAC#219 ·
メンテナーはふだん 1 日以内に返信