-
Notifications
You must be signed in to change notification settings - Fork 4.9k
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
Redirecting stdout/stderr of a process throws exception with .NET 5 preview.6 on WSL1 #40727
Comments
Tagging subscribers to this area: @eiriktsarpalis |
(It would also be good to understand what's different about the repro vs the Process tests we have, and augment the process tests accordingly.) |
The code in PowerShell is the normal operations to start a process, you can find the code here. I think the WSL1 environment is the key factor in play for this issue. I also ran into troubles building PowerShell with .NET 5 preview.6 SDK in WSL1, and it was reporting the same exception:
I reported this in the '.NET First Party Outreach' channel. I was told it worked in WSL2 and a workaround was to use Speaking of WSL1 and WSL2, are .NET 5 (including SDK) and near-future .NET versions going to continue supporting WSL1? |
We'll take a look at this before the end of the week. |
The same issue seems to impact dotnet sdk too:
|
This reproduces the error: using System.Diagnostics;
namespace consoleapp
{
class Program
{
static void Main()
{
var psi = new ProcessStartInfo("ls");
psi.RedirectStandardOutput = true;
Process.Start(psi);
}
}
} |
So, after running this on the debugger, it looks like the root cause is in the SystemNative_GetSocketType function which does not set an address family in this case. Ultimately that results in this check not being satisfied, so none of the I'm not sure what the best approach might be to fix the problem. Perhaps @dotnet/ncl could weigh in on this. Note that dotnet/runtime on WSL1 is mostly broken because of this bug. If trying to debug, you might want to check out the original commit c44dc40 that introduced the regression, since it relies on a bootstrapping sdk that doesn't suffer from the bug. |
Does it fail with specific error or does it just stay unknown? I'm wondering if we can somehow detect this specific condition and do some damage control. |
It succeeds without populating the address family. Same for protocol type. |
Addressed by #40851 |
Description
This was reported in PowerShell repo (PowerShell/PowerShell#13407), and it turns out to be a .NET 5 issue on Ubuntu 18.04 with WSL1.
Repro
On Ubuntu 18.04 with WSL1, run the following in PowerShell 7.1.0-preview.5 (using .NET 5 preview.6)
The exception is:
Configuration
Regression?
Yes, it doesn't repro with PowerShell 7.1.0-preview.3, which is on top of .NET 5 preview.4.
That means the issue was a regression introduced after .NET 5 preview.4.
The text was updated successfully, but these errors were encountered: