-
Notifications
You must be signed in to change notification settings - Fork 4.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Code coverage of System.Private.CoreLib is broken #51058
Comments
I couldn't figure out the best area label to add to this issue. If you have write-permissions please help me learn by adding exactly one area label. |
Tagging subscribers to this area: @dotnet/runtime-infrastructure Issue DetailsAccording to the directions, running a test suite like System.Runtime.Tests should be able to get coverage of the code in corelib via /p:Coverage=true /p:TestRuntime=true, but while doing so does add CoreLib to the command-line, the resulting code coverage report is empty. cc: @ViktorHofer
|
This has broken enough times, ideally we'd protect it with an outerloop test (just as we should protect launch and build in VS). As far as I know we have no existing example of a test that does a build, but presumably we can assume dotnet is on the path (at least we do in the build) |
For Helix executions of CoreCLR tests Simon added provisions for passing dotnet path around for the purpose of running Crossgen2, please see here: Line 909 in 94641d8
I guess it shouldn't be that hard to introduce a similar logic to library tests. |
Marking as 6.0 and as a bug. Will look into this as soon as I have some cycles. Assigning to myself. |
@danmoseley, is there someone who can look at this in Viktor's absence? |
@ericstj owns our infra backlog. |
CoreLib code coverage measurement is broken because the following negative path is hit during coverlet's
Coverlet fails to find the generated The options that I see are:
FWIW this was easy to debug by building coverlet myself, adding a I hope that helps :) |
Thanks.
Fixing that (#64534) helps but does not solve the problem. Everything in corelib still shows as 0%. |
I believe the remaining issue is that the instrumented IL code is at the wrong place:
This is from the ildasm my instrumented System.Private.CoreLib assembly. The code indicates that the processExit branch is hit and the EDIT: The code responsible for injecting the UnloadModule method can be found here: https://github.com/coverlet-coverage/coverlet/blob/df968b862687aeb9ac86ae47938da04d95c10452/src/coverlet.core/Instrumentation/Instrumenter.cs#L303. |
@sharwell, seems that change came from coverlet-coverage/coverlet@96b1594. Can you take a look? |
Yes that was it. If I change internal static void OnProcessExit()
{
AssemblyLoadContext.OnProcessExit();
if (EventSource.IsSupported)
{
EventListener.DisposeOnShutdown();
}
- ProcessExit?.Invoke(AppDomain.CurrentDomain, EventArgs.Empty);
+ // Don't optimize this code path to inline the != null check via the ?. operator as otherwise
+ // coverlet can't inject the UnloadModule instrumentation code path and CoreLib's coverage results will be empty.
+ if (ProcessExit != null)
+ {
+ ProcessExit.Invoke(AppDomain.CurrentDomain, EventArgs.Empty);
+ }
}
|
There is one more remaining issue which unfortunately needs to be fixed in coverlet itself: coverlet-coverage/coverlet#1285. If I fix that locally and apply the AppContext.ProcessExit workaround from above I finally get code coverage results for CoreLib:
Unfortunately I don't have any more time to help out here but I think that all the information needed is now on the table. |
Should this better be fixed in Coverlet too? |
Presumably this broke when we picked up the previous coverlet 1.7.2? If we ensure we always verify corelib coverage before updating our coverlet version, we should at least be protected against coverlet breaks, presumably? Incidentally apparently this workaround can be removed now. |
Yes 😄. cc: @sharwell, @MarcoRossignoli |
Thanks for getting to it, Viktor. |
I'll take a look asap(weekend I think). Thanks @ViktorHofer 🙇 |
I did a pair of fixes for the issues above, can someone with more "knowledge" and a ready runtime env(build etc...) give it a try before official release? I'm a bit rusty at the moment. https://github.com/coverlet-coverage/coverlet/blob/master/Documentation/ConsumeNightlyBuild.md Will be shipped at midnight. |
Thanks, @MarcoRossignoli.
That's on the nightly feed. What about official builds? |
I do manual deploy for official build. I did one a few days ago 1/30...so the only difference between 3.1.1 and 3.1.2 will be this fix...for this reason I'd like to know before the release if it's working to avoid to ship an useful bugged version. I've fired manual dogfood release the version with the fix is |
Tried it:
|
interesting...pls can you send here command list to build/run coverage, so I can go by my own |
Apply stephentoub@009a5af to your dotnet/runtime repo clone. |
thx I'll be back asap(I have my suspect). |
Release 3.1.2 is out you can give it a try. |
According to the directions, running a test suite like System.Runtime.Tests should be able to get coverage of the code in corelib via /p:Coverage=true /p:TestRuntime=true, but while doing so does add CoreLib to the command-line, the resulting code coverage report is empty.
cc: @ViktorHofer
The text was updated successfully, but these errors were encountered: