"System.InvalidProgramException : Common Language Runtime detected an invalid program." when running some tests

[saxonww]

I'm seeing errors similar to this one since 2.0.0-ci-20180325225037:

Failed   Product.MacroService.Tests.Concept.ConceptServiceTests.GetPersonConceptSummaryTest
Error Message:
 System.InvalidProgramException : Common Language Runtime detected an invalid program.
Stack Trace:
   at Product.MacroService.Concept.Services.ConceptService.<>c.<CalculateConceptFields>b__4_0(Part p)
   at System.Linq.Enumerable.WhereListIterator`1.ToList()
   at System.Linq.Enumerable.ToList[TSource](IEnumerable`1 source)
   at Product.MacroService.Concept.Services.ConceptService.CalculateImmunizationFields(PersonConceptSummary summary)
   at Product.MacroService.Concept.Services.ConceptService.<GetPersonConceptSummary>d__3.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
   at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
   at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
   at System.Runtime.CompilerServices.TaskAwaiter`1.GetResult()
   at Product.MacroService.Tests.Concept.ConceptServiceTests.<GetPersonConceptSummaryTest>d__4.MoveNext() in /mnt/c/git/product/macroservice/test/Product.MacroService.Tests/Concept/ConceptServiceTests.cs:line 71
--- End of stack trace from previous location where exception was thrown ---
   at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()

I'm not sure if it helps, but every failure is with something working with System.Collections.Generic.List or System.Linq.Enumerable.

My development environment is Windows 10/WSL with an up-to-date Ubuntu 16.04 installation. I'm using .NET Core 2.0.0.

[saxonww]

@bhugot I can't share the actual code generating this but I can try to come up with a reproduction.

[bhugot]

would be very helpfull

[saxonww]

I tried to write a new minimal test case based on one of our failing tests, but I could not get it to fail. So, I've taken one of our internal solutions, pared it down, and made some naming modifications. It's probably not as small as it could be but it does reproduce a failing test. See saxonww/minicover-failure for the project.

I can build this project in VS2017 and run the test with no errors. I can run dotnet test on the test project with no errors. But if I run dotnet test while instrumenting with minicover, I get a CLR failure.

Note that I don't think this code would actually work, it just compiles and the test completes successfully (or not). The original project does work and produces output that is in active use; the exception and stack trace are the same in the original vs. this altered version so hopefully it's a good indicator for what's going on with minicover.

[bhugot]

Hello thanks for sharing, your problem was fixed with the last version

[abakumov-v]

Hi! I have the same problem in my CI-pipeline (I assume that this is due to the fact that the command dotnet test was launched with minicover instumenting because without minicover instrumenting the dotnet test command completed without errors) with version 2.0.0-ci-20180329054201, but if I use the Minicover version 2.0.0-ci-20180328123752 then tests ran without this error and code coverage analysis was finished successfully.

[saxonww]

@bhugot I've verified that all of our tests work with 2.0.0-ci-20180329054201. Thanks for looking at this!

[lucaslorentz]

@Valeriy1991
Is there any chance you inverted the versions on your comment above?
Version 20180329054201 should be the good one and 20180328123752 is the one with issue.

[SapientGuardian]

I also am experiencing this issue with 20180329054201, but NOT with 20180328123752. I can't share the code under test, sorry.

[raftAtGit]

I have the same issue for both versions. After some digging, I noticed this only happens if I provide --configuration release setting to dotnet build. with --configuration debug, or with no configuration setting at all, it works okay.

Also another weird issue is, the coverage report differs for different dotnet versions. 2.1.4 and 2.1.101 respectively. The same files are listed with same number of lines but number of covered lines are quite different.

Edit: Different coverage reports are not caused by different dotnet versions. On a regular Ubuntu 16.04 both versions create the same result. But somehow, on Microsoft provided VSTS build agent Docker container (also Ubuntu 16.04) the results are different with dotnet 2.1.101.

[lucaslorentz]

@saxonww @Valeriy1991 @SapientGuardian
Can you please check if you have same issue with version 2.0.0-ci-20180517205544?

[SapientGuardian]

I do not have the issue with 2.0.0-ci-20180517205544