-
Notifications
You must be signed in to change notification settings - Fork 288
Collect all crash dumps in directory regardless of main process exit status #6817
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: main
Are you sure you want to change the base?
Conversation
Co-authored-by: Evangelink <[email protected]>
Co-authored-by: Evangelink <[email protected]>
src/Platform/Microsoft.Testing.Extensions.CrashDump/CrashDumpProcessLifetimeHandler.cs
Outdated
Show resolved
Hide resolved
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@copilot add some acceptance test that would lead to multiple dumps
Co-authored-by: Evangelink <[email protected]>
| if (string.Equals(dumpFile, expectedDumpFile, StringComparison.OrdinalIgnoreCase)) | ||
| { | ||
| await _messageBus.PublishAsync(this, new FileArtifact(new FileInfo(dumpFile), CrashDumpResources.CrashDumpDisplayName, CrashDumpResources.CrashDumpArtifactDescription)).ConfigureAwait(false); | ||
| foundExpectedDump = true; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This still looks wrong, what if the main process does not crash?
The reason why vstest crash dumper checks for crash (it does that in stupid way of comparing test counts, but whatever), is that we always collect dump on process exit when procdump crash dumper is used. This allows us to capture out of memory and stack overflow exceptions in .net framework processes. In .net core process this is handled in a better way, the process will be able to capture dump on OOM or on stack overflow, and you don't have to collect dump always.
So all that is needed here is making unique folder per run, and reporting all dumps from there.
If this later expands to use procdump, it would need to detect premature exit of the testhost process (at least), no matter what the exit code is, to be able to distunguish a crash of the process or just successful exit.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@copilot please update handling based on this comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Removed the HasExitedGracefully check and simplified the logic to always collect all dumps from the directory. The implementation now:
- Always scans for
.dmpfiles in the directory, even if main process exits gracefully - Removes error messages about missing expected dump (no longer relevant)
- Relies on unique folder per run to ensure we're only collecting dumps from this test run
Commit: 40aac17
| return 1; | ||
| } | ||
| // Start a child process that will also crash (only when running as testhost controller) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This comment is wrong? The process that is not a testhost controller will have this parameter, so we are not running as testhost controller, we are running under testhost controller.
Might also be a good idea to crash this process in a different way than failfast. E.g. by allocating on the stack a bit of memory that is larger than the stack - immediate stack overflow.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Fixed the comment from "running as testhost controller" to "running under testhost controller". Commit: 40aac17
Co-authored-by: Evangelink <[email protected]>
The crash dump extension only collected the testhost process dump by PID, missing dumps from child processes that crashed alongside it. Additionally, it only collected dumps when the main process crashed, but child processes can crash even when the main process exits successfully.
Changes
Modified
CrashDumpProcessLifetimeHandler.OnTestHostProcessExitedAsync:HasExitedGracefullycheck to always collect dumps, regardless of how the main process exited.dmpfiles in the directoryBefore:
After:
This ensures all crash dumps are collected from the unique per-run directory, regardless of whether the main process crashed or exited gracefully. With .NET Core's built-in crash dump mechanism, child processes can crash independently and generate dumps even when the parent process succeeds.
Testing
Added acceptance test
CrashDump_WithChildProcess_CollectsMultipleDumpsthat validates multiple dump collection:Environment.FailFastCrashDumpWithChildFixturetest asset that follows the pattern of existing process tree testsFixes #4186
Original prompt
💡 You can make Copilot smarter by setting up custom instructions, customizing its development environment and configuring Model Context Protocol (MCP) servers. Learn more Copilot coding agent tips in the docs.