Skip to content

Fix flaky signal handler test on mono on Linux#125969

Merged
mrek-msft merged 2 commits intodotnet:mainfrom
mrek-msft:dev/mrek/meh-sigquit-mono-fail
Mar 24, 2026
Merged

Fix flaky signal handler test on mono on Linux#125969
mrek-msft merged 2 commits intodotnet:mainfrom
mrek-msft:dev/mrek/meh-sigquit-mono-fail

Conversation

@mrek-msft
Copy link
Copy Markdown
Member

Fix #125953

Issue was that in mono case, two signals were send, SIGQUIT, then SIGTERM. If remote process was fast enough, SIGQUIT printed thread dump on stdout and StandardOutput.EndOfStream check in parent failed afterwards.

Copilot AI review requested due to automatic review settings March 23, 2026 15:54
@mrek-msft mrek-msft requested review from adamsitnik and jkotas March 23, 2026 15:54
@dotnet-policy-service
Copy link
Copy Markdown
Contributor

Tagging subscribers to this area: @dotnet/area-system-diagnostics-process
See info in area-owners.md if you want to be subscribed.

Copy link
Copy Markdown
Contributor

Copilot AI left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Pull request overview

Fixes a flaky System.Diagnostics.Process signal-handling test on Linux when running under the Mono interpreter, where SIGQUIT can emit a thread dump to stdout and break the parent process’ StandardOutput.EndOfStream assertion.

Changes:

  • Updates SignalHandler_CanDisposeInHandler to terminate the remote process with SIGTERM (instead of a second SIGQUIT) when running on Mono + non-Windows.
  • Adds a comment explaining Mono’s SIGQUIT behavior that caused the flake.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

ProcessTests.SignalHandler_CanDisposeInHandler fails on linux on mono interpreter

3 participants