Open nnpcYvIVl opened 5 years ago
@nnpcYvIVl Do you have a repro project that I can try this on?
@mavasani Sorry, no repro at the moment.
I am in the process of upgrading our NuGet package from 2.9.3 to 2.9.4 and also have discovered that after upgrading the C# compiler hangs. But this doesn't apply to all our .csproj projects, some work fine and everthing is working oke with 2.9.3. C# version = 3.2.1-beta4-19408-03 (2fc6a049)
I am now upgrading project for project to see when the problems occurs.
Update: I have brought the problem down to 1 project. Any tips on how to log which .cs file / line is being processed?
@vbaderks If you are able to capture a heap dump, then the thread which has the analyzer name DoNotPassLiteralsAsLocalizedParameters
should contain the symbol and the name of the current method being analyzed.
Hi @mavasani,
When I run msbuild on the project it always hangs. When I attach Visual Studio to the VBCCompiler.exe process I don't see a thread with the name DoNotPassLiteralsAsLocalizedParameters. On my system there are 3 managed threads (Main Thread and 2 Workers threads). The thread that is in a loop and processing CPU cycles is just called "Worker Thread". The call stack does however looks like the one above.
I tried to add a VBCCompiler.ini file to get better debug info, but at this moment I can only see the call stack but no variables (with VS 2019 as debugger) which could help to understand which method is being analyzed.
I just updated to "v2.9.5-beta1.final", the "hang" I was seeing has been resolved with this version.
My project still hangs with v2.9.5-beta1.final.
I am experiencing the same issue in a project using versions 2.9.3 or 2.9.6 (latest). VBCSCompiler maxes out CPU and memory. Even after canceling build and closing Visual Studio, VBCSCompiler continues to run and has to be force quit (see screenshots).
Disabling CA1303 in GlobalSuppressions.vb and/or .editorconfig has no effect; I have to create a ruleset file with <Rule Id="CA1303" Action="None" />
in order to proceed. FYI, my project has >3100 violations of CA1303.
During build:
After canceling build and closing Visual Studio:
@guitarzan Would you be able to provide a repro that we can use to investigate?
Disabling CA1303 in GlobalSuppressions.vb and/or .editorconfig has no effect; I have to create a ruleset file with
in order to proceed. FYI, my project has >3100 violations of CA1303.
We are hoping to fix the .editorconfig suppression to prevent running the analyzer in 16.4, so the performance characteristics would be identical when disabled in .editorconfig file or ruleset.
@guitarzan Would you be able to provide a repro that we can use to investigate?
Sorry, no repro. It's only one very large project that has this problem, and I can't tell where the problem originates. If you have steps I could follow, I'm willing to help if I can.
@guitarzan are you still experiencing the issue with the latest version?
Same problem here, I can reproduce the behaviour with dotnet-cli (ubuntu & windows) and Visual Studio. A project with this behaviour can be found at https://github.com/Codeuctivity/Open-Xml-PowerTools/blob/vNext/OpenXmlPowerTools/OpenXmlPowerTools.csproj
This may not be a conclusive test since I'm now running VS in Parallels on an older Mac, and even a normal build seems to max out the CPU for a while, but I just tried removing the rule disabling CA1303 from my ruleset file and had the same issue -- build never finished & VBCSCompiler continued to run after canceling build and closing VS.
I'm currently on VS 16.5.2 and version 2.9.8 of the analyzers (latest stable).
FYI, still an issue on VS 16.7.2 and Microsoft.CodeAnalysis.FxCopAnalyzers 3.3.0.
By the way, not sure if this makes a difference, but my project is on .NET Framework 4.5.2. I just noticed the OP mentioned Microsoft.NetCore.Analyzers.
@stesee I am having some trouble reproducing the issue with the project you have pointed to. Whether or not I enable the CA1303
rule I can't see any difference. What are you doing to be able to reproduce the issue?
@Evangelink : Microsoft.CodeAnalysis.FxCopAnalyzers was disabled after hanging issues in https://github.com/Codeuctivity/Open-Xml-PowerTools/blob/master/OpenXmlPowerTools/OpenXmlPowerTools.csproj
I validated that the issue is still there with "Microsoft.CodeAnalysis.FxCopAnalyzers" Version="3.3.0" and VS 16.7.5
Thanks, I didn't see that this project was excluding the analyzer.
I have done various run and I cannot reproduce the build hanging but I confirm that by enabling the fxcop analyzers on OpenXmlPowerTools
project we move from around 40s of build time to 2m40s but the build does finish properly. For the record there is nearly 4500 issues.
I have also tried to re-enable the nullable option and there is still no hanging problem with the build.
Lastly, I have tried to disable the rule CA1303 in the .editorconfig file and it doesn't seem to be affecting much the build time so if there is a rule slowing down the process it shouldn't be this one.
You are right. The build is not hanging, it is just unexpected slow. My slow pet project dev machine went from 4:34 to 22:59 build time after enabling Microsoft.CodeAnalysis.FxCopAnalyzers 3.3.0. I also took a second look at Microsoft.CodeAnalysis.FxCopAnalyzers 2.9.8 and killed the build after 60+ minutes.
@nnpcYvIVl can you upgrade Microsoft.CodeAnalysis.FxCopAnalyzers and prove that your build isn't just realy realy slow?
I agree that the build becomes really slow but when looking at the number of issues found I don't really know if that's so bad (@sharwell any opinion?).
@stesee I would personally disable most of the rules that are reporting a lot of issues and slowly enable them (i.e. do a PR enabling rule X and fixing or skipping the issues found by rule X then repeat with rule Y). Because when you are seeing a lot of issues you tend to somehow get used to them and so not to do the required changes which means you are better of without the analyzers. When living in the noise we get used to it and start ignoring it.
Yes, that code needs a big portion of love. I am not sure if I have that much love (time) to spare. Great that 3.3.0 produces any output at least I could work on.
I will investigate this issue, this is likely due to the fact that this rule runs with inter procedural data flow analysis.
In a build pipeline I run analyzers from Microsoft.NetCore.Analyzers.dll. One particular solution always hangs, when I capture a memory dump it is stuck in CA1303 DoNotPassLiteralsAsLocalizedParameters.
I am using version 2.9.4. See attached stacktrace.