Build task is crashing on ETA and VSI runs

[heejaechang]

C:\Users\dotnet-bot.nuget\packages\Microsoft.Net.Compilers\1.2.0-beta-20151211-01\tools\Microsoft.CSharp.Core.targets(67,5): error MSB3883: Unexpected exception: [d:\j\workspace\roslyn-internal_prtest_win_dbg_unit32\Open\src\Features\Core\Portable\Features.csproj]
10:53:14 C:\Users\dotnet-bot.nuget\packages\Microsoft.Net.Compilers\1.2.0-beta-20151211-01\tools\Microsoft.CSharp.Core.targets(67,5): error : System.NullReferenceException: Object reference not set to an instance of an object. [d:\j\workspace\roslyn-internal_prtest_win_dbg_unit32\Open\src\Features\Core\Portable\Features.csproj]

http://dotnet-ci.cloudapp.net/job/roslyn-internal_prtest_win_dbg_unit32/404/consoleFull#56248540979494335-f7bd-47d0-8771-8661e00c2db2

[heejaechang]

10:53:15 C:\Users\dotnet-bot.nuget\packages\Microsoft.Net.Compilers\1.2.0-beta-20151211-01\tools\Microsoft.CSharp.Core.targets(67,5): error : at Microsoft.CodeAnalysis.BuildTasks.ManagedCompiler.ExecuteTool(String pathToTool, String responseFileCommands, String commandLineCommands) [d:\j\workspace\roslyn-internal_prtest_win_dbg_unit32\Open\src\Features\Core\Portable\Features.csproj]
10:53:16 CSharpCodeAnalysis -> d:\j\workspace\roslyn-

[davkean]

We hit this again, @jaredpar can you get someone to have a look at this?

[davkean]

And again: http://dotnet-ci.cloudapp.net/job/roslyn-internal_prtest_win_vsi_p2/89/consoleFull#-132868381679494335-f7bd-47d0-8771-8661e00c2db2

[davkean]

And again here: http://dotnet-ci.cloudapp.net/job/dotnet_roslyn_prtest_win_vsi_p0/111/consoleFull#59593570779494335-f7bd-47d0-8771-8661e00c2db2

[TyOverby]

The following projects are failing:

• 404
  • Features
  • Features
• 89
  • BasicWorkspace
  • BasicWorkspace
• 111
  • CodeAnalysisTest
  • CodeAnalysisTest

Notice that each failure happens twice for each build. @davkean: did you find out why this is built twice?

[davkean]

We suspect that the toolset update introduced this: #7444.

[TyOverby]

I am currently attempting to reproduce the issue with PDBs present. This way, hopefully we can get line-number info as well as (maybe) a call stack.

[davkean]

How did we go with this?

[TyOverby]

It hasn't failed in the two days since I've tried to repro...

[davkean]

We hit this again: #7782

[amcasey]

http://dotnet-ci.cloudapp.net/view/roslyn/job/roslyn_prtest_win_dbg_unit64/2549/
http://dotnet-ci.cloudapp.net/view/roslyn/job/roslyn_prtest_win_dbg_unit64/2550/
http://dotnet-ci.cloudapp.net/view/roslyn/job/roslyn_prtest_win_dbg_unit32/2581/

[davkean]

Only the middle one, http://dotnet-ci.cloudapp.net/view/roslyn/job/roslyn_prtest_win_dbg_unit64/2550/, looks related.

[agocke]

I think I see the problem: https://github.com/dotnet/roslyn/blob/master/src/Compilers/Core/MSBuildTask/Shared/ManagedCompiler.cs#L389

NRE if responseTask is null.

https://github.com/dotnet/roslyn/blob/master/src/Compilers/Shared/DesktopBuildClient.cs#L160

Looks like that should be return Task.FromResult<BuildResponse>(null)

[agocke]

Making a PR now.

[davkean]

Damnit, nice one. We've been trying find the cause for ages. We couldn't get a consistent repro.

[agocke]

Jared actually fixed a case in e0d04ad but just missed this one.

[amcasey]

Should we have an analyzer that detects constant null returns from non-async task-returning methods?

[agocke]

@amcasey I could see a good reason for returning null, rather than boxing a null in a task. I just happened to choose the "no-null" approach.

[TyOverby]

@agocke What is your example scenario? I've always thought of Task as being a prime example of "this is a reference type, but seriously shouldn't ever be null".

[agocke]

@TyOverby Someone with a task-returning method which is often going to be "empty" and they don't want to incur an extra allocation. In theory the Task.FromResult(..) could be cached, but I'm not willing to say that's uniformly better.

[jaredpar]

@agocke good catch.

How were you able to debug this? Or did you just find this via code inspection?

[agocke]

@jaredpar Code inspection