Closed ssuraci closed 2 weeks ago
I've just discovered a simple "workaround": if the source file that triggers the bug contains a syntax error (eg: mispelled field name), the error is obviously marked in red in vscode and omnisharp/intellisense works perfectly.
Same situation for me on the exact same config except for the OS (Mac OS X 10.15.6) and VSCode (1.42.1).
Steps to reproduce with a very simple program:
omnisharp-bug.csproj
:
<Project Sdk="Microsoft.NET.Sdk">
<PropertyGroup>
<OutputType>Exe</OutputType>
<TargetFramework>netcoreapp3.1</TargetFramework>
<RootNamespace>omnisharp_bug</RootNamespace>
</PropertyGroup>
<ItemGroup>
<PackageReference Include="Automapper" Version="10.0.0" />
</ItemGroup>
</Project>
Program.cs
:
using System;
namespace omnisharp_bug
{
class TestModel
{
public string field1 { get; set; }
public string field2 { get; set; }
public string field3 { get; set; }
public string field4 { get; set; }
public string field5 { get; set; }
public string field6 { get; set; }
public string field7 { get; set; }
public string field8 { get; set; }
public string field9 { get; set; }
public string field10 { get; set; }
}
class TestDto
{
public string field1 { get; set; }
public string field2 { get; set; }
public string field3 { get; set; }
public string field4 { get; set; }
public string field5 { get; set; }
public string field6 { get; set; }
public string field7 { get; set; }
public string field8 { get; set; }
public string field9 { get; set; }
public string field10 { get; set; }
}
public class MapperProfile : AutoMapper.Profile
{
public MapperProfile()
{
}
public void MapTest()
{
CreateMap<TestModel, TestDto>()
.ForMember(dest => dest.field1, opt => opt.MapFrom(src => src.field1))
.ForMember(dest => dest.field2, opt => opt.MapFrom(src => src.field2))
.ForMember(dest => dest.field3, opt => opt.MapFrom(src => src.field3))
.ForMember(dest => dest.field4, opt => opt.MapFrom(src => src.field4))
.ForMember(dest => dest.field5, opt => opt.MapFrom(src => src.field5))
.ForMember(dest => dest.field6, opt => opt.MapFrom(src => src.field6))
.ForMember(dest => dest.field7, opt => opt.MapFrom(src => src.field7))
.ForMember(dest => dest.field8, opt => opt.MapFrom(src => src.field8))
.ForMember(dest => dest.field9, opt => opt.MapFrom(src => src.field9))
// to trigger the bug:
// 1. wait for OmniSharp to initialize
// 2. delete "field10" in src and press ctrl+space for autocompletion (in case 2/3 times if needed)
// 3. mono process goes 100% CPU, completion does not work and vscode becomes unusable
.ForMember(dest => dest.field10, opt => opt.MapFrom(src => src.field10))
;
CreateMap<TestDto, TestModel>()
.ForMember(dest => dest.field1, opt => opt.MapFrom(src => src.field1))
.ForMember(dest => dest.field2, opt => opt.MapFrom(src => src.field2))
.ForMember(dest => dest.field3, opt => opt.MapFrom(src => src.field3))
.ForMember(dest => dest.field4, opt => opt.MapFrom(src => src.field4))
.ForMember(dest => dest.field5, opt => opt.MapFrom(src => src.field5))
.ForMember(dest => dest.field6, opt => opt.MapFrom(src => src.field6))
.ForMember(dest => dest.field7, opt => opt.MapFrom(src => src.field7))
.ForMember(dest => dest.field8, opt => opt.MapFrom(src => src.field8))
.ForMember(dest => dest.field9, opt => opt.MapFrom(src => src.field9))
.ForMember(dest => dest.field10, opt => opt.MapFrom(src => src.field10))
;
}
class Program
{
static void Main(string[] args)
{
Console.WriteLine("Hello World!");
}
}
}
If you mark the folder that Automapper is generating as generated code into I would expect this to no longer repo.
[SomeFileOrFolder]
generated_code = true
If you mark the folder that Automapper is generating as generated code into I would expect this to no longer repo.
[SomeFileOrFolder] generated_code = true
AFAIK Automapper
does not generate code for mapping.
@JoeRobich @jmarolf at least the stack trace suggests a Roslyn bug, we should be able to isolate it into a repro without OmniSharp
This bug gets triggered with any source file that uses non trivial lambda expressions (eg: EntityFrameworkCore
DbContext
), not only Automapper
.
Some updates regarding this issue:
v1.23.3-beta4
CodeLens
in extension option
- a working (so far) workaround is to disable
CodeLens
in extension option
That is an interesting bit of additional information. We only surface reference count and testing commands via the CodeLens. In this case I would suspect finding references to be the expensive operation. In the past we have excluded finding references for certain methods, such as object.ToString, since they are implemented by virtually everything and occur frequently in code. I wonder if there is another method or set of methods that we should exclude for performance.
I wonder if there is another method or set of methods that we should exclude for performance.
As mentioned above, the issue arises in source files where there is heavy use of lambda expressions. I think it would be nice to have an option to disable CodeLens
selectively on those files.
- a working (so far) workaround is to disable
CodeLens
in extension option
Sadly if the source file is complex, the bug arises even with CodeLens
disabled.
Hope it will be fixed soon as, at least for me, makes vscode almost unusable for most C# development.
The workaround didn't work for me. I had to avoid creating new mapping with more than 5 lines approx. Otherwise, I must restart my VSCode every 5min 😞
@plsgard Today I've:
dotnet
to version 3.1.9-1
on Ubuntu dotnet
version 2.2.1
omnisharp-vscode
to version 1.23.2
(in version 1.23.3
intellisense does not work at all, see #4114 )thereafter the bug seems resolved (so far ...)
@plsgard Today I've:
- upgraded
dotnet
to version3.1.9-1
on Ubuntu- removed
dotnet
version2.2.1
- downgraded
omnisharp-vscode
to version1.23.2
(in version1.23.3
intellisense does not work at all, see #4114 )thereafter the bug seems resolved (so far ...)
Nope, the bug is still here, sometimes does not get triggered but usually is ... Sadly I'll have to switch to Visual Studio as VS Code is pratically unusable for me ...
Still a problem with 1.37.15. It's related to complex (nested?) lambda expression, not code lens.
This issue makes VSCode unusable for moderate to large projects. I've had to switch to Rider.
Closing due to lack of activity.
Issue Description
Omnisharp intellisense stops working and Omnisharp process CPU gets stuck at 100% idenfinitely.
Steps to Reproduce
It happens when OmniSharp analyzes complex
AutoMapper
profiles. If needed I could try to create a minimal project to reproduce it; the code I'm actually working on and that causes the bug is large and is not opensource.Expected Behavior
Omnisharp intellisense should work as usual
Actual Behavior
Intellisense freezes, CPU for OmniSharp exe process goes 100% indefinitely, vscode becomes unusable and must be restarted.
Logs
Thread dump for stuck threads is the following:
and
OmniSharp log
Environment information
VSCode version: 1.49.0 C# Extension: 1.23.2
Mono Information
OmniSharp using built-in monoDotnet Information
.NET Core SDK (reflecting any global.json): Version: 3.1.402 Commit: 9b5de826fd Runtime Environment: OS Name: ubuntu OS Version: 16.04 OS Platform: Linux RID: ubuntu.16.04-x64 Base Path: /usr/share/dotnet/sdk/3.1.402/ Host (useful for support): Version: 3.1.8 Commit: 9c1330dedd .NET Core SDKs installed: 2.2.402 [/usr/share/dotnet/sdk] 3.1.402 [/usr/share/dotnet/sdk] .NET Core runtimes installed: Microsoft.AspNetCore.All 2.2.8 [/usr/share/dotnet/shared/Microsoft.AspNetCore.All] Microsoft.AspNetCore.App 2.2.8 [/usr/share/dotnet/shared/Microsoft.AspNetCore.App] Microsoft.AspNetCore.App 3.1.8 [/usr/share/dotnet/shared/Microsoft.AspNetCore.App] Microsoft.NETCore.App 2.2.8 [/usr/share/dotnet/shared/Microsoft.NETCore.App] Microsoft.NETCore.App 3.1.8 [/usr/share/dotnet/shared/Microsoft.NETCore.App] To install additional .NET Core runtimes or SDKs: https://aka.ms/dotnet-downloadVisual Studio Code Extensions
|Extension|Author|Version| |---|---|---| |angular-schematics|cyrilletuzi|4.3.0| |Angular2|johnpapa|9.1.2| |auto-using|Fudge|0.7.15| |autoimport|steoates|1.5.3| |beautify|HookyQR|1.5.0| |cql|LawrenceGrant|0.8.7| |csharp|ms-dotnettools|1.23.2| |csharp-to-typescript|adrianwilczynski|1.12.1| |csharp2ts|rafaelsalguero|0.0.24| |csharpfixformat|Leopotam|0.0.84| |debugger-for-chrome|msjsdiag|4.12.10| |devicetree|plorefice|0.1.1| |dotnet-test-explorer|formulahendry|0.7.4| |gc-excelviewer|GrapeCity|3.0.40| |git-graph|mhutchie|1.26.0| |gitflow|vector-of-bool|1.2.1| |githistory|donjayamanne|0.6.9| |gitlens|eamodio|10.2.2| |java|redhat|0.67.0| |markdown-all-in-one|yzhang|3.3.0| |nbpreviewer|jithurjacob|1.2.2| |ng-template|Angular|0.1001.0| |pdf|tomoki1207|1.1.0| |php-debug|felixfbecker|1.13.0| |powershell|ms-vscode|2020.6.0| |prettify-json|mohsen1|0.0.3| |python|ms-python|2020.8.109390| |rainbow-csv|mechatroner|1.7.1| |remote-ssh|ms-vscode-remote|0.55.0| |remote-ssh-edit|ms-vscode-remote|0.55.0| |saml-extension|mcastany|0.0.10| |sqltools|mtxr|0.23.0| |svg|jock|1.3.10| |svgeditor|henoc|2.9.0| |team|ms-vsts|1.161.0| |velocity|sodatea|0.2.0| |vs-code-xml-format|fabianlauer|0.1.5| |vscode-boot-dev-pack|Pivotal|0.0.8| |vscode-cassandra|kdcro101|0.3.6| |vscode-concourse|Pivotal|1.22.0| |vscode-eslint|dbaeumer|2.1.8| |vscode-icons|vscode-icons-team|10.2.0| |vscode-intelephense-client|bmewburn|1.5.4| |vscode-java-debug|vscjava|0.28.0| |vscode-java-dependency|vscjava|0.13.0| |vscode-java-pack|vscjava|0.10.0| |vscode-java-test|vscjava|0.24.2| |vscode-language-pack-it|MS-CEINTL|1.49.1| |vscode-lombok|GabrielBB|1.0.1| |vscode-manifest-yaml|Pivotal|1.22.0| |vscode-maven|vscjava|0.24.2| |vscode-spring-boot|Pivotal|1.22.0| |vscode-spring-boot-dashboard|vscjava|0.1.10| |vscode-spring-initializr|vscjava|0.5.0| |vscode-sqlite|alexcvzz|0.9.0| |vscode-tomcat|adashen|0.11.3| |vscode-typescript-tslint-plugin|ms-vscode|1.2.3| |vscode-xml|redhat|0.13.0| |vscodeintellicode|VisualStudioExptTeam|1.2.10|;