Join GitHub today
GitHub is home to over 50 million developers working together to host and review code, manage projects, and build software together.Sign up
C# compiler crashes with NullReferenceException in Microsoft.CodeAnalysis.CompilationOptions.get_Errors() #12993
Version Used: Visual Studio 2015 Update 3, C# compilier
Steps to Reproduce:
Try to build a project via TFS build agent
Expected Behavior: Compilation of C# files
From the log file created on the build machine:
I applied Update 3 about two weeks ago, to my two build machines. One of them started failing like this after a day or two. I disabled it because the other seemed fine, so I wouldn't have to investigate immediately.
Then the other machine failed after a week. I tried doing a Visual Studio repair (with the installer) on the first machine. After that it seemed to work. I did the same on the second machine and it also worked. So both seemed okay.
This morning the first build I started on the first machine has failed with same stack trace. I'm running a build on the second machine and it's working fine (the build completes without any errors in our code or yours!)
It's very odd because once a given machine has failed once, it then no longer works, although a repair install fixes it temporarily.
As the problem occurs in parsing the command line arguments, I've compared the args passed in a build that succeeds with one that fails, on the same project. They were identical:
If I open a command prompt on the build machine, logged in under the account that our TFS services use, and pass the same arguments to the exact same csc.exe:
Then it succeeds and produces output. So problem only occurs when build is started by TFS build controller.
@danielearwicker would it be possible for you to get a dump of the process when it throws that exception?
We've looked at the code and it simply doesn't seem possible that it could throw a NRE at that location. All of the code definitely assigns non-null values to the variables involved. It's a bit perplexing. A dump would give us some insight here and likely point out what we are missing.
@danielearwicker been looking at the dump. One thing that stands out in the disassembly is that a profiler is running on the machine. Specifically TypeMock. It is definitely inserting itself into the assembly of the function that is crashing.
There are instances in the past where we've seen profilers cause errors like this in our code. Can you disable
It seems likely this is the cause of the crash. The code in question here is really straight forward:
In short there is really no way that it should ever hit this error. Seems much more likely to be a result of TypeMock.
Excellent, thanks for this tip-off, will try today.
EDIT Have deleted the installed TypeMock stuff and it doesn't appear to be necessary to build successfully. Will take a few more builds before I feel confident it's resolved but this certainly seems like the "smoking gun".
Having looked at the module list in the crash dump I can see the TypeMock assemblies are loaded - this looks like a step too far in "clever" behaviour IMO, especially given this outcome. Is there a legit way to get 3rd party code into
In any case this was the first I've become aware it was being used here, and I think I'm going to just rip it out ASAP.