-
Notifications
You must be signed in to change notification settings - Fork 4.7k
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
Process.Start() failure should include path #46417
Conversation
Tagging subscribers to this area: @eiriktsarpalis Issue DetailsThis PR fixes #39928
|
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.
@batzen big thanks for your PR! I've left some comments, please address them and take a look at the failing tests (let me know if you need some help in getting some information from CI logs).
Could you also remove the empty file (src/installer/snaps/dotnet-sdk/dotnet-runtime
) ?
src/libraries/System.Diagnostics.Process/src/System/Diagnostics/Process.cs
Outdated
Show resolved
Hide resolved
src/libraries/System.Diagnostics.Process/src/System/Diagnostics/Process.Unix.cs
Outdated
Show resolved
Hide resolved
@@ -185,6 +185,9 @@ | |||
<data name="InvalidApplication" xml:space="preserve"> | |||
<value>The specified executable is not a valid application for this OS platform.</value> | |||
</data> | |||
<data name="FailedToStartFileDirectory" xml:space="preserve"> | |||
<value>Failed to start '{0}' with working directory '{1}'. {2}</value> |
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.
It's just an opinion (and I can see that it was a suggestion in the original issue #39928 (comment)), but I think that it would be better to append the missing information to the existing exception message. Especially if we want to add it for all throwing cases (not just when the file is not found)
<value>Failed to start '{0}' with working directory '{1}'. {2}</value> | |
<value>{2} (the file name was '{0}', the working directory '{1}').</value> |
So we would have:
- The system cannot find the file specified
+ The system cannot find the file specified (the file name was 'abc.exe', the working directory 'C:\xyz').
Instead of:
- The system cannot find the file specified
+ Failed to start 'abc.exe' with working directory 'C:\xyz'. The system cannot find the file specified
cc @danmosemsft who proposed the initial version
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.
How about "{0} (file: '{1}', working directory: '{2}')." then?
Given that "file name" is not always appropriate as it could also be an absolute/relative path to some exe.
Even file is not always the right term/word as it could also be "ftp://something" or "https://something", but "file" sounds better than "file name" here.
Or should we stick with "file name" as the property is also called "FileName"?
Are there native errors that could produce an empty message?
In that case the original proposed message would still make sense whereas the new one would look awkward.
- Failed to start 'abc.exe' with working directory 'C:\xyz'.
+ (the file name was 'abc.exe', the working directory 'C:\xyz').
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.
How about "{0} (file: '{1}', working directory: '{2}')." then?
Sounds good to me!
Are there native errors that could produce an empty message?
This is a very good question. From what I can see in the source code, there is no such possibility for Windows:
runtime/src/libraries/Common/src/Interop/Windows/Kernel32/Interop.FormatMessage.cs
Line 74 in 144cac3
return string.Format("Unknown error (0x{0:x})", errorCode); |
And on Unix we end up calling strerror_r
:
byte* message = StrErrorR(platformErrno, buffer, maxBufferLength); |
return StrErrorR(platformErrno, buffer, bufferSize); |
and the docs for it says that it also returns unknow error message for such cases:
The strerror(), strerror_l(), and the GNU-specific strerror_r()
functions return the appropriate error description string, or an
"Unknown error nnn" message if the error number is unknown.
So I think that we can assume that it's never empty.
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.
With respect to the message, my only thought is whether exceptions might occur that wouldn't suggest we were trying to start a process. Eg., System is not in a good state (the file name was 'abc.exe', the working directory 'C:\xyz').
(I made this up - but OS sometimes give strange errors). If you don't have the callstack, only the message, it is not clear what is going on. This problem already exists of course - but that was my reasoning for the "failed to start" text.
But this is @adamsitnik call.
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.
After some manual testing, such as where the filename
provided is a directory, the message, "No such file or directory (file: '/home`, working directory: '/home')" seems confusing to me. I agree with the previous comments that having "failed to start" at the beginning is a better experience; the second part of the message is the underlying error.
In that spirit, I'll go with "An error occurred trying to start process '{0}' with working directory '{1}'. {2}".
src/libraries/System.Diagnostics.Process/src/System/Diagnostics/Process.Windows.cs
Show resolved
Hide resolved
@adamsitnik I just had a look at the failing tests when running on unix. I don't know why it's done this way and what happens in Do you have any idea on how i should proceed here? |
@adamsitnik I guess you missed my results and the question about the failing Linux tests. Would be nice if you could have a look. ;-) |
…s/Process.cs Co-authored-by: Adam Sitnik <[email protected]>
…s/Process.Unix.cs Co-authored-by: Adam Sitnik <[email protected]>
@adamsitnik Tests are now working on unix and i just rebased again. |
That message format seems good to me. @adamsitnik -- could you take a look at the previous comment when you get a chance please? |
Ping on this, @adamsitnik. 😄 |
ForkAndExecProcess(originalFilename, filename, argv, envp, cwd, | ||
startInfo.RedirectStandardInput, startInfo.RedirectStandardOutput, startInfo.RedirectStandardError, | ||
setCredentials, userId, groupId, groups, | ||
out stdinFd, out stdoutFd, out stderrFd, usesTerminal); |
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.
Too many parameters! Maybe pass startInfo
?
ForkAndExecProcess(startInfo, filename, argv, envp, cwd,
setCredentials, userId, groupId, groups,
out stdinFd, out stdoutFd, out stderrFd, usesTerminal);
@adamsitnik It looks like this PR is still awaiting your re-review. Note this comment too. |
@batzen You're right; we let you down here. We failed to prioritize this and also failed to set expectations that we wouldn't be able to prioritize it until other work was completed. This isn't how we want to treat contributors and I'm glad you called us out on it. Thank you for letting us know how this was affecting you and I'm sorry.
That sounds like the right approach to me. I hope it's OK with you, but I'd like to update your branch with the latest from main, resolve the conflicts, and take a closer look at this. I'll comment back within the next couple of days with the intention of getting this merged by Monday or Tuesday of next week so that this fix can make .NET 6 Preview 7. |
@jeffhandley Thanks for your kind response. According to the changes that could/should be made in |
Thank you, @batzen. I'll push some changes to your branch to get it caught up and then I'll check in again once I look more closely into |
I'm going to split the difference on this. I'm changing I'm doing some manual testing on both Ubuntu and Windows with these changes now; I expect to have this ready for re-review tomorrow. |
Test failures:
|
@batzen @stephentoub This is ready for re-review. |
LGTM |
src/libraries/System.Diagnostics.Process/src/System/Diagnostics/Process.Unix.cs
Outdated
Show resolved
Hide resolved
src/libraries/System.Diagnostics.Process/src/System/Diagnostics/Process.Unix.cs
Outdated
Show resolved
Hide resolved
src/libraries/System.Diagnostics.Process/src/System/Diagnostics/Process.Unix.cs
Outdated
Show resolved
Hide resolved
src/libraries/System.Diagnostics.Process/src/System/Diagnostics/Process.Win32.cs
Show resolved
Hide resolved
Co-authored-by: Stephen Toub <[email protected]>
Hello @jeffhandley! Because this pull request has the p.s. you can customize the way I help with merging this pull request, such as holding this pull request until a specific person approves. Simply @mention me (
|
Failures aren't showing up here for some reason (but are likely all unrelated) |
System.IO.FileSystem.Net5Compat.Tests failed on Android with:
Isolated storage tests failed on Android with
System.Security.Cryptography.Xml tests failed with
Oh, now I see that this is staging and can be ignored. But I'll leave this here for reference. cc @steveisok |
I realize now (1) failures in azdo are in staging and can be ignored (2) failure above should be ignored as it's staging also, but since it's a timeout it's not due to limitations. |
@batzen thank you for the contribution here. It should go out in .NET 6 preview 7 in about a month. I second @jeffhandley comments that we aim to be more responsive on PR's and generally we are I think. I do hope you will continue to contribute and either Jeff or myself will pay special attention to any future PR you offer to make sure we do better. |
Thanks for checking the tests and merging this, @danmoseley. @batzen, this will be included in Preview 7. Thanks again for the contribution and for the feedback and help! |
This PR fixes #39928