Limit compiler server pipe name length#24265
Merged
agocke merged 2 commits intodotnet:dev15.6.xfrom Jan 18, 2018
Merged
Conversation
On MacOS pipes are implemented using Unix domain sockets. Unix domain sockets must have a valid file path for their endpoint. The best place is in the temp folder. Unfortunately, domain sockets on Unix also have a very small path length limit of 104 characters. In addition, Mac temp paths can be very long since they include randomly generated characters from the OS. In total, this means that Roslyn has barely 50 characters worth of space for its pipe identifiers. This change cuts down on the bytes of the SHA256 hash used. This shouldn't affect the security of the pipe, since the hash isn't used as a security boundary, but should fit the pipe name into the length limitations.
jaredpar
approved these changes
Jan 16, 2018
Member
Author
|
cc @MeiChin-Tsai for ask-mode approval |
Member
Author
|
@dotnet/roslyn-compiler Can I get one more review on this PR please? |
|
approved. thx. |
Member
Author
|
ping @dotnet/roslyn-compiler for a 15.6 bug review |
cston
approved these changes
Jan 18, 2018
333fred
added a commit
to 333fred/roslyn
that referenced
this pull request
Jan 19, 2018
…g-text * dotnet/dev15.6.x: Fix symbol completion after 'in' (dotnet#24335) use PascalCase for const name Limit compiler server pipe name length (dotnet#24265) Test ConvertedType on LHS of deconstruction-assignment (dotnet#24158) remove unused usings use .editorconfig files address more comments address code review comments move newly added text into resource file add text and hyperlink to C# code style page
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
4 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Customer scenario
The current scenario: on Mac sometimes the compiler server can be left
spinning in an exception loop and non-responsive and the build silently
falls back to slower csc/vbc operation.
On MacOS pipes are implemented using Unix domain sockets. Unix domain
sockets must have a valid file path for their endpoint. The best place
is in the temp folder. Unfortunately, domain sockets on Unix also have a
very small path length limit of 104 characters. In addition, Mac temp
paths can be very long since they include randomly generated characters
from the OS. In total, this means that Roslyn has barely 50 characters
worth of space for its pipe identifiers.
This change cuts down on the bytes of the SHA256 hash used. This shouldn't
affect the security of the pipe, since the hash isn't used as a security boundary,
but should fit the pipe name into the length limitations.
Bugs this fixes
Fixes #24137
Workarounds, if any
On Mac, for your
dotnet buildprocess, set your TMP environment variable to a short path, like/tmp.Risk
Low. The path name itself is not semantically meaningful to Roslyn.
Performance impact
This is a perf fix. Should improve perf quite a lot (> 100% in my test).
Is this a regression from a previous update?
No.
Root cause analysis
This is a bug in a new feature that is caused by an OS peculiarity that only sometimes occurs
based on the user ID and randomized path generated by MacOS for the current session.
How was the bug found?
First found by a developer when trying to repro a different bug, then customer reported.