Skip to content

Csc/Vbc Tasks should log stderr as error#27349

Merged
jcouv merged 2 commits intodotnet:masterfrom
jcouv:csc-logging
Jun 4, 2018
Merged

Csc/Vbc Tasks should log stderr as error#27349
jcouv merged 2 commits intodotnet:masterfrom
jcouv:csc-logging

Conversation

@jcouv
Copy link
Copy Markdown
Member

@jcouv jcouv commented Jun 1, 2018

@nguerrera Would you have some tips for setting up a CLI with a custom-build version of Roslyn, so that I can validate the fix?

Customer scenario

If you build a CLI project that causes the compiler to crash (for instance, stackoverflow on a very deep fluent expression, or any other crash), you get an error code, but not error message or stacktrace.

Bugs this fixes

Fixes #27248
Fixes dotnet/msbuild#3054

Workarounds, if any

It is possible to recover the details of the failure with the following steps;

  1. run the problematic build command, but add the option for binary logging /bl (for example, dotnet build /bl)
  2. assuming this reproduced the issue, open the msbuild.binlog file with the binary log viewer.
  3. the log viewer should show the failed Csc task (as shown below)
  4. you can view and copy the command-line arguments to a text file repro.rsp, removing the first two chunks (the first one for "dotnet.exe" and the second one for "csc.dll")
  5. re-use those two chunks to run dotnet.exe csc.dll @repro.rsp
  6. this should repro, but also print out the compiler diagnostics

image

Risk

Performance impact

Low. We're just setting an option for how the MSBuild ToolTask reports on outputs to stderr. The compiler doesn't normally output to stderr.

Is this a regression from a previous update?

No.

How was the bug found?

Reported by customers.

Tagging @rainersigwald @jaredpar

@jcouv jcouv added this to the 15.8 milestone Jun 1, 2018
@jcouv jcouv self-assigned this Jun 1, 2018
@jcouv jcouv requested a review from a team as a code owner June 1, 2018 18:47
@jaredpar
Copy link
Copy Markdown
Member

jaredpar commented Jun 1, 2018

Need to override the StandardErrorLoggingImportance property as well

        /// <summary>
        /// Standard error output should be considered of high importance so that it shows up in even 
        /// minimal logs. This is how unhandled exception information is output by the runtime.
        /// </summary>
        protected override MessageImportance StandardErrorLoggingImportance => MessageImportance.High;

public ManagedCompiler()
{
TaskResources = ErrorString.ResourceManager;
LogStandardErrorAsError = true;
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

We should add a comment on why we are doing this. There isn't a great way to test this so need to have a comment justifying the change else deleting it will seem to be a fine change as it doesn't break CI

@nguerrera
Copy link
Copy Markdown
Contributor

@nguerrera Would you have some tips for setting up a CLI with a custom-build version of Roslyn, so that I can validate the fix?

I think the easiest thing would be to produce the Microsoft.NET.Compiler.Core nupkg with your change and test using RTM CLI and a package ref to your nupkg.

For a more out-of-the-box-like test, you could also download the zip https://www.microsoft.com/net/download/thank-you/dotnet-sdk-2.1.300-windows-x86-binaries and replace the sdk\2.1.300\Roslyn directory with your bits.

@jaredpar
Copy link
Copy Markdown
Member

jaredpar commented Jun 1, 2018

@jcouv I validated this change locally. Here is the steps I took to validating.

  1. In roslyn enlistment ran: powershell -noprofile -executionPolicy RemoteSigned -file build\scripts\build.ps1 -bootstrap -buildcoreclr. That puts a valid MSBuild layout into "E:\code\roslyn\Binaries\Bootstrap\Microsoft.NETCore.Compilers\42.42.42.42\tools"
  2. Created a Net Core app project that had the stack overflow case.
  3. In the sample code directory
    1. Ran dotnet build and verified no stack printed
    2. Ran dotnet build /p:RoslynTargetsPath=E:\code\roslyn\Binaries\Bootstrap\Microsoft.NETCore.Compilers\42.42.42.42\tools and verified the stack trace was printed

@jcouv
Copy link
Copy Markdown
Member Author

jcouv commented Jun 1, 2018

@jaredpar If I understood correctly, Rainer's comment (see linked issue) indicated that only one of the fixes should be sufficient. I'll test and confirm.

Copy link
Copy Markdown
Member

@rainersigwald rainersigwald left a comment

Choose a reason for hiding this comment

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

You shouldn't need to also up the priority: error is always higher-than-high-pri.

Copy link
Copy Markdown
Member

@agocke agocke left a comment

Choose a reason for hiding this comment

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

LGTM aside from comment

@jcouv
Copy link
Copy Markdown
Member Author

jcouv commented Jun 2, 2018

Verified the fix using Jared's instructions. Now, the error is printed out (including the very long stacktrace in the overflow scenario).

c:\...\Microsoft.CSharp.Core.targets(52,5): error : FailFast: [C:\repos\overflow\overflow.csproj]
c:\...\Microsoft.CSharp.Core.targets(52,5): error : System.InsufficientExecutionStackException: Insufficient stack to continue executing the program safely. This can happen from having too many functions on the call stack or function on the stack using too much stack space. [C:\repos\overflow\overflow.csproj]
c:\...\Microsoft.CSharp.Core.targets(52,5): error :    at System.Runtime.CompilerServices.RuntimeHelpers.EnsureSufficientExecutionStack() [C:\repos\overflow\overflow.csproj]
c:\...\Microsoft.CSharp.Core.targets(52,5): error :    at System.Runtime.CompilerServices.RuntimeHelpers.EnsureSufficientExecutionStack() [C:\repos\overflow\overflow.csproj]
c:\...\Microsoft.CSharp.Core.targets(52,5): error :    at Microsoft.CodeAnalysis.StackGuard.EnsureSufficientExecutionStack(Int32 recursionDepth) [C:\repos\overflow\overflow.csproj]
[... the stack for the overflow follows ...]

@jcouv
Copy link
Copy Markdown
Member Author

jcouv commented Jun 2, 2018

@jaredpar for second sign-off and for ask-mode approval for 15.8. Thanks

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.

MSBuild should preserve stacktraces when ToolTask exe throws an exception Crash message not reported, only error code

5 participants