System.Diagnostics.Process.Tests failure on net10.0-linux-Debug-arm64-Mono_Minijit_Debug

[am11]

trafficstars

Build Information

Build: https://dev.azure.com/dnceng-public/cbb18261-c48f-4abb-8651-8cdcb5474649/_build/results?buildId=893020 Build error leg or test failing: System.Diagnostics.Tests.ProcessTests.TestGetProcessById Pull request: https://github.com/dotnet/runtime/pull/110198

Error Message

Fill the error message using step by step known issues guidance.

{
  "ErrorMessage": ["Expected: \".NET Long Runni\"","System.Diagnostics.Tests.ProcessTests.TestGetProcessById"],
  "BuildRetry": false,
  "ExcludeConsoleLog": false
}

Known issue validation

Build: :mag_right: https://dev.azure.com/dnceng-public/public/_build/results?buildId=893020 Error message validated: [Expected: ".NET Long Runni" System.Diagnostics.Tests.ProcessTests.TestGetProcessById] Result validation: :white_check_mark: Known issue matched with the provided build. Validation performed at: 12/12/2024 6:55:46 PM UTC

Report

Summary

24-Hour Hit Count	7-Day Hit Count	1-Month Count
0	0	0

Report

Build	Definition	Test	Pull Request
1061262	dotnet/runtime	System.Diagnostics.Tests.ProcessTests.TestGetProcessById	dotnet/runtime#116353

Summary

24-Hour Hit Count	7-Day Hit Count	1-Month Count
0	0	1

[jkotas]

Expected: ".NET Long Runni" is very generic pattern that can match number of unrelated issues. I have updated it to be make it more specific.

[mdh1418]

This looks like a dupe of https://github.com/dotnet/runtime/issues/107821. It seems odd that the expected name is ".NET Long Runni", do we really expect the process started by CreateDefaultProcess to have that name (which looks like that name stems from a long running task being trimmed https://github.com/dotnet/runtime/blob/1d69684de8801d500e12de8efd86e7ecfa5ed168/src/libraries/System.Private.CoreLib/src/System/Threading/Tasks/ThreadPoolTaskScheduler.cs#L51) instead of dotnet?

All other instances of .NET Long Runni in other issues seem to be some problem with hangs/futex-internal.c when looking at callstacks in https://github.com/dotnet/runtime/issues/92070, https://github.com/dotnet/runtime/issues/90019, https://github.com/dotnet/runtime/issues/105808, and maybe even https://github.com/dotnet/runtime/issues/109630 and https://github.com/dotnet/runtime/issues/106595 might have the same underlying issue.

[dotnet-policy-service[bot]]

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

[jeffhandley]

Assigned to @adamsitnik for triage

[adamsitnik]

Triage: it seems that reading a process name on Linux makes some of our tests flaky (#109630, #110643, #111460).

@jkotas has suggested in https://github.com/dotnet/runtime/issues/111460#issuecomment-2608999432 that we maybe reading it too soon. I am going to try to add a simple retry mechanism to see if it helps.

[jeffschwMSFT]

removing blocking-clean-ci has it has not failed in 30 days

24-Hour Hit Count	7-Day Hit Count	1-Month Count
0	0	0

[jeffhandley]

Closing as it has continued not to have recent hits

[jkotas]

Closing as it has continued not to have recent hits

It was hit a few days ago in #117743

Build	Definition	Test	Pull Request
1097369	dotnet/runtime	System.Diagnostics.Tests.ProcessTests.TestCheckChildProcessUserAndGroupIds	dotnet/runtime#117743

Summary

24-Hour Hit Count	7-Day Hit Count	1-Month Count
0	1	1