Use Mini dump in CrashDump child-crash test to fix macOS Debug timeout#8483
Use Mini dump in CrashDump child-crash test to fix macOS Debug timeout#8483Evangelink wants to merge 3 commits into
Conversation
There was a problem hiding this comment.
Pull request overview
This PR addresses a macOS Debug CI timeout in the Microsoft.Testing.Platform CrashDump acceptance test by switching the test scenario to request Mini dumps, avoiding multi-GB Full dump creation delays that can exceed the test’s 60s child-process wait.
Changes:
- Update
CrashDump_TesthostAndChildBothCrash_CollectsAllDumpsto pass--crashdump-type Miniand document the macOS Debug timeout root cause. - Simplify a filename-collision loop in TRX artifact copying logic.
- Refactor HTML report target framework moniker selection into a single null-coalescing expression.
Show a summary per file
| File | Description |
|---|---|
| test/IntegrationTests/Microsoft.Testing.Platform.Acceptance.IntegrationTests/CrashDumpTests.cs | Requests Mini crash dumps in the child-crash scenario to prevent macOS Debug timeouts and improve test reliability. |
| src/Platform/Microsoft.Testing.Extensions.TrxReport/TrxReportEngine.Artifacts.cs | Simplifies the destination-exists retry loop while preserving behavior. |
| src/Platform/Microsoft.Testing.Extensions.HtmlReport/HtmlReportEngine.cs | Refactors GetTargetFrameworkMoniker for equivalent, more concise logic. |
Copilot's findings
- Files reviewed: 3/3 changed files
- Comments generated: 0
Evangelink
left a comment
There was a problem hiding this comment.
✅ 8/8 applicable dimensions clean — no findings.
Reviewed dimensions:
- ✅ Algorithmic Correctness — Both refactorings are semantically identical to original code
- ✅ Threading & Concurrency — No new race conditions introduced (existing TOCTOU preserved)
- ✅ Performance & Allocations — No hot-path changes, refactorings have no performance impact
- ✅ Code Structure & Simplification — Excellent use of null-coalescing and while-condition extraction
- ✅ Test Completeness & Coverage — No new code paths require coverage
- ✅ Flakiness Patterns — Fix directly addresses root cause (timeout on macOS Debug Full dumps)
- ✅ Naming & Conventions — Consistent with codebase style
- ✅ Documentation Accuracy — New comment accurately explains WHY and mechanism
Skipped dimensions (not applicable): Security, Public API, Cross-TFM, Resource Management, Defensive Coding, Localization, Test Isolation, Assertion Quality, Data-Driven Coverage, Analyzer Quality, IPC Wire, Build Infrastructure, Scope Discipline.
Summary: This PR combines a targeted test fix (switching to --crashdump-type Mini to prevent macOS Debug timeouts) with two clean refactorings (null-coalescing chain, while-condition extraction). All changes preserve exact semantics. The test fix is well-documented and addresses the root cause identified in the PR description.
Generated by Expert Code Review (on open) for issue #8483 · ● 12.6M
On macOS Debug builds, createdump writes a multi-GB Full dump that can take 3+ minutes per process. The test parent waits only 60s on its spawned child via WaitForExit, so on macOS Debug the wait times out, the parent kills the child mid-dump, and only the parent's dump is left on disk — failing the HasCount(2) assertion. Switch the test to '--crashdump-type Mini'. The DbgMiniDumpType env var set by CrashDumpEnvironmentVariableProvider is inherited by the spawned child, so both processes write small/fast Mini dumps and complete well within the 60s window. The test only validates that both dumps are collected and reported as artifacts — dump format is irrelevant for this scenario. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
221c058 to
b76ac8e
Compare
|
@copilot resolve the merge conflicts in this pull request |
…ashdump-macos-debug-timeout # Conflicts: # test/IntegrationTests/Microsoft.Testing.Platform.Acceptance.IntegrationTests/CrashDumpTests.cs Co-authored-by: Evangelink <11340282+Evangelink@users.noreply.github.com>
Merged |
Fixes the consistent failure of CrashDump_TesthostAndChildBothCrash_CollectsAllDumps on macOS Debug builds.
Root cause
The default crash dump type is
Full. On macOS Debug builds the runtime'screatedumpwrites a multi-GB Full dump that can take several minutes per process. A representative failure log shows the parent's dump being a 5.6 GB file written in 198857ms (~3.3 minutes):The test parent only waits 60s on its spawned child via
child.WaitForExit(60_000). On macOS Debug:FailFasts and createdump starts writing its (huge) dump.child.Kill()and throws, interrupting the in-progress child dump ([createdump] Writing dump FAILED).Assert.HasCount(2, dumpFiles)fails (actual: 1).Other configurations aren't impacted because Full dumps complete far faster on Windows/Linux and on Release builds.
Fix
Pass
--crashdump-type Miniin this specific test. TheDbgMiniDumpTypeenv var set byCrashDumpEnvironmentVariableProvideris inherited by the spawned child process, so both processes write small/fast Mini dumps that comfortably finish within the 60s window.The test only validates that both dumps are collected and reported as artifacts — it doesn't care about dump contents — so Mini is semantically equivalent for this scenario.