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

VS 2015 freeze with F# projects, F# cleanup disabled, and Visual F# Power Tools installed #227

Closed
JanWosnitza opened this Issue Mar 9, 2016 · 24 comments

Comments

Projects
None yet
2 participants
@JanWosnitza

JanWosnitza commented Mar 9, 2016

Of course, it a the VS template doesn't trigger it. Would be to easy ;) So invested some time and here is the (mean) report:

Steps to reproduce

  1. Create a new Solution with a stock F# console application
  2. Add a new code file (the default "File1.fs" is ok), leave it as is
  3. Add another new code file (again, the default "File2.fs" is ok)
  4. Close VS
  5. Reopen the solution
  6. Open menu "CodeMaid" -> freeze

I also noticed:

  • the freeze is not a complete lock, but lasts for ~30sec
  • while freezed the cpu is idling and no memory is allocated
  • doesn't happen with only "File1.cs"
  • the freeze only happens the first time after VS lunch
  • it happens when right clicking an opened *.fs editors tab, too. (not with CodeMaid being disabled)

I tried to debug VS and pause when VS is freezed, but had no luck with seeing a callstack.

If you're not able to reproduce it on your behalf, repeat steps 3 to 6. Looking forward to read about your luck/results.

Cheers Jan

Jan Wosnitza
When I have an F# project opened and I open the "CodeMaid" menu from the VS main-menu band, VS freezes immediately.

But it's not a big deal to not click the button ;)

Cheers Jan

Facts:

  • VS2015 Community Edition
  • CodeMaid v0.9.0

Steve Cadwallader
Sorry to hear it, and I have been unable to reproduce it with a stock F# console application.

If you can file an issue on GitHub (https://github.com/codecadwallader/codemaid/issues) we can look into it more. Some interesting information to have would be the document that is open and active when you encounter the issue. One of the menu items does report the file name (i.e. "Cleanup Program.fs") so it would be interesting to know if the issue occurs when no documents are open or only when certain documents are active.

@codecadwallader codecadwallader self-assigned this Mar 9, 2016

@codecadwallader

This comment has been minimized.

Owner

codecadwallader commented Mar 9, 2016

Thanks for reporting the issue with all the clear details, very well stated. :)

Unfortunately I still haven't been able to reproduce it (cycled up to File4.fs). I'll try again at a different time on another machine to see if I can't get a better idea what might be causing it.

It may be helpful to provide your CodeMaid settings as well as a list of any other extensions you may be running. I can't think of any in particular that I would expect to cause a difference in what we're seeing, but always good to know to try and explain any differences between systems.

@JanWosnitza

This comment has been minimized.

JanWosnitza commented Mar 16, 2016

My extensions are:

CodeMaid export:

<?xml version="1.0" encoding="utf-8"?>
<configuration>
    <configSections>
        <sectionGroup name="userSettings" type="System.Configuration.UserSettingsGroup, System, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" >
            <section name="SteveCadwallader.CodeMaid.Properties.Settings" type="System.Configuration.ClientSettingsSection, System, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" />
        </sectionGroup>
    </configSections>
    <userSettings>
        <SteveCadwallader.CodeMaid.Properties.Settings>
            <setting name="Cleaning_AutoCleanupOnFileSave" serializeAs="String">
                <value>True</value>
            </setting>
            <setting name="Cleaning_InsertExplicitAccessModifiersOnStructs"
                serializeAs="String">
                <value>False</value>
            </setting>
            <setting name="Cleaning_InsertExplicitAccessModifiersOnMethods"
                serializeAs="String">
                <value>False</value>
            </setting>
            <setting name="Cleaning_InsertExplicitAccessModifiersOnProperties"
                serializeAs="String">
                <value>False</value>
            </setting>
            <setting name="Cleaning_InsertExplicitAccessModifiersOnClasses"
                serializeAs="String">
                <value>False</value>
            </setting>
            <setting name="Cleaning_InsertExplicitAccessModifiersOnDelegates"
                serializeAs="String">
                <value>False</value>
            </setting>
            <setting name="Cleaning_InsertExplicitAccessModifiersOnEnumerations"
                serializeAs="String">
                <value>False</value>
            </setting>
            <setting name="Cleaning_InsertExplicitAccessModifiersOnEvents"
                serializeAs="String">
                <value>False</value>
            </setting>
            <setting name="Cleaning_InsertExplicitAccessModifiersOnInterfaces"
                serializeAs="String">
                <value>False</value>
            </setting>
            <setting name="Cleaning_InsertExplicitAccessModifiersOnFields"
                serializeAs="String">
                <value>False</value>
            </setting>
            <setting name="Cleaning_InsertBlankLinePaddingBeforeUsingStatementBlocks"
                serializeAs="String">
                <value>False</value>
            </setting>
            <setting name="Cleaning_InsertBlankLinePaddingAfterUsingStatementBlocks"
                serializeAs="String">
                <value>False</value>
            </setting>
            <setting name="Cleaning_IncludeFSharp" serializeAs="String">
                <value>False</value>
            </setting>
            <setting name="General_CacheFiles" serializeAs="String">
                <value>True</value>
            </setting>
        </SteveCadwallader.CodeMaid.Properties.Settings>
    </userSettings>
</configuration>
@codecadwallader

This comment has been minimized.

Owner

codecadwallader commented Mar 17, 2016

I've attempted it on a second machine with your solution settings included, and I'm still not seeing any unexpected latency. I have been using later CodeMaid betas and the now official release of v0.9.1 that just happened tonight. There aren't any deliberate fixes for this issue present so I wouldn't expect it to provide any difference in behavior, but it would be good to upgrade as a sanity check.

A couple ideas:

  1. I noticed you actually have F# cleanup disabled above. Was it always that way, or just something you were experimenting with? Is the behavior any different if you toggle that setting?
  2. When Visual Studio starts up, there is a little latency as different IDE services come online. If you are launching a solution directly from file explorer and expecting the entire IDE to be immediately responsive, I find that's usually not the case. However that's not limited to CodeMaid - that would really apply to accessing any menu. A quick way to rule that out is to give Visual Studio a minute to fully load where it's clearly sitting idle and other menus are accessible before hitting CodeMaid. Since you were looking at CPU and other metrics I highly doubt this is the case, but including it just in case.

A couple other things to test if you haven't already:

  1. Please close all files before closing Visual Studio to see if the behavior is any different.
  2. Please try a different type of project to see if the behavior is any different (e.g. C#).
  3. Please try having a different type of file (e.g. the App.config) as the only open document to see if the behavior is any different.

Thanks for working with me on this, I hope to get to the bottom of it.

@codecadwallader codecadwallader removed their assignment Mar 20, 2016

@codecadwallader codecadwallader added the bug label Mar 20, 2016

@JanWosnitza

This comment has been minimized.

JanWosnitza commented Mar 21, 2016

Since you mentioned it: if F# cleanup is enabled, the freeze is gone.

@ideas:

  1. I don't think I have touched it, but not sure about it..
  2. It really doesn't matter, when I open the menu. It even stalls if VS ran the whole day. Or if I start VS without solution, open CodeMaid menu, load the (F#) solution and then again open CodeMaid menu -> freeze.

@couple other tings:

  1. If I open the solution without any files opened, it will freeze for a second or two when adding the first or second file I open (which is not the case if other files were opened already), but the menu-freeze is gone.
  2. Doesn't happen with an C# project (auto cleanup enabled or disabled)
  3. Sry if I wasn't clear enough about it, but it doesn't happen with only one file open (this is why me reproducing steps included adding some files). And: doesn't freeze with 2 .fs files and two .config files opened on startup. When opening more .fs files until the freeze occurs, it still freezes if I close the .config files.

Again for clarification: Since the freeze only happens the first time, I always restart VS after opening/closing a file and then click on the CodeMaid-menu.

@JanWosnitza

This comment has been minimized.

JanWosnitza commented Mar 21, 2016

I downloaded CodeMaid's newest master, built it and loaded my F# project within the test VS, freeze gone. F# cleanup was disabled.

@codecadwallader

This comment has been minimized.

Owner

codecadwallader commented Mar 21, 2016

Thanks for the additional information. We created a new CI channel over the weekend.. do you want to try that as well and see if it's gone there as well (i.e. not through debugging)? http://vsixgallery.com/extension/4c82e17d-927e-42d2-8460-b473ac7df316/

@JanWosnitza

This comment has been minimized.

JanWosnitza commented Mar 22, 2016

I installed the new version, and the freeze is still happening there. AND I tried to disable some PlugIns and the freeze disappears as soon as "Visual F# Power Tools" is disabled. So I opened the CodeMaid solution again, installed "Visual F# Power Tools" in Test-VS and ... Why, hello there. It's freeezing. Callstack is:

  • [External Code]
  • CodeMaid.Helpers.DocumentExtensions.GetCodeLanguage(EnvDTE.Document document) Line 17
  • CodeMaid.Logic.Cleaning.CodeCleanupAvailabilityLogic.IsDocumentLanguageIncludedByOptions(EnvDTE.Document document) Line 190
  • CodeMaid.Logic.Cleaning.CodeCleanupAvailabilityLogic.CanCleanup(EnvDTE.Document document, bool allowUserPrompts) Line 88
  • CodeMaid.Integration.Commands.CleanupOpenCodeCommand.get_OpenCleanableDocuments.AnonymousMethod__12_0(EnvDTE.Document x) Line 77
  • [External Code]
  • CodeMaid.Integration.Commands.CleanupOpenCodeCommand.OnBeforeQueryStatus() Line 39
  • CodeMaid.Integration.Commands.BaseCommand.BaseCommand_BeforeQueryStatus(object sender, System.EventArgs e) Line 49
  • [External Code]

..when trying to get the value of EnvDTE.Document.Language. And as it looks like, it doesn't matter which document it tries to get the language from. Also froze on "Microsoft.Common.CurrentVersion.targets" when doing:

  1. start VS
  2. pause debugging on freeze
  3. remember file name (local var), where freeze happens
  4. restart VS
  5. close the file where the freeze happened before
  6. now freezing when trying to get language of "Microsoft.Common.CurrentVersion.targets" (which is not opened)
@JanWosnitza

This comment has been minimized.

JanWosnitza commented Mar 22, 2016

And now a "ContextSwitchDealock ocurred":

Managed Debugging Assistant 'ContextSwitchDeadlock' has detected a problem in 'C:\Program Files (x86)\Microsoft Visual Studio 14.0\Common7\IDE\devenv.exe'.

Additional information: The CLR has been unable to transition from COM context 0x9a9240 to COM context 0x9a9188 for 60 seconds. The thread that owns the destination context/apartment is most likely either doing a non pumping wait or processing a very long running operation without pumping Windows messages. This situation generally has a negative performance impact and may even lead to the application becoming non responsive or memory usage accumulating continually over time. To avoid this problem, all single threaded apartment (STA) threads should use pumping wait primitives (such as CoWaitForMultipleHandles) and routinely pump messages during long running operations.

while still "waiting" for Document.Language's value in the "Main Thread".

@codecadwallader

This comment has been minimized.

Owner

codecadwallader commented Mar 22, 2016

Very interesting. The ContextSwitchDeadlock is something I see from time to time in many different places when debugging VS, particularly on exit, so I think that's a bit of a red herring that can be ignored.

The Visual F# Power Tools are open source too. It could be interesting to debug it with CodeMaid installed and see if there's anything in their call stack that's occurring. The EnvDTE call is the VS API, but perhaps they have overridden something specifically with the document registrations.

@codecadwallader

This comment has been minimized.

Owner

codecadwallader commented Mar 23, 2016

I installed Visual F# Power Tools and re-ran through the original repro steps, but unfortunately still did not see the issue.

My best guess is that something is happening during loading of the packages. CodeMaid loads during Visual Studio startup (code link) while Visual F# Power Tools loads a little later (code link). It would be interesting to know if the lag is coinciding with the load of Visual F# Power Tools, which perhaps CodeMaid is triggering when it requests the details for an F# document. Is there a menu in Visual F# that you can access before going to the CodeMaid menu?

@JanWosnitza

This comment has been minimized.

JanWosnitza commented Mar 24, 2016

I tried to compile and debug the Visual F# Power Tools, but didn't succeed so far (it's launching VS and stuff but the plugin is broken). Maybe because I'm using VS2015 instead of VS2013 (which is mentioned on it's github-page).

@ triggering the load: I don't think CodeMaid is triggering the load, because the VF#PT should load immediately with the F# files.

@ VF#PT settings: You try to use the same settings that I have:
Go To: Tools->Options->F# Power Tools->General:
Check everything BUT:

  • Source code formatting
  • Folder organization
  • FSharpLint integration
@JanWosnitza

This comment has been minimized.

JanWosnitza commented Mar 25, 2016

I reproduced the bug on my PC at home:

  1. Start VS 2015 Community Edition via the Developer Commandline with "devenv.exe /rootsuffix CodeMaid"
  2. Menu: Tools->Extensions and Updates
  3. Install VF#PT and CodeMaid
  4. Close Vs and restart ("devenv.exe /rootsuffix CodeMaid")
  5. Create FSharp project + solution, add empty files: File1.cs to File4.cs
  6. Close Vs and restart ("devenv.exe /rootsuffix CodeMaid")
  7. Load soltuion created on 5
  8. Click "CodeMaid" on menu
  9. Freeze

I haven't touched the VF#PT or CodeMaid settings. CodeMaid's "Options->File Types->F#" was unchecked.

@codecadwallader

This comment has been minimized.

Owner

codecadwallader commented Mar 25, 2016

Ok, thanks for the updated steps. I'm away this weekend but will try them out again next week.

@codecadwallader codecadwallader self-assigned this Apr 4, 2016

@codecadwallader

This comment has been minimized.

Owner

codecadwallader commented Apr 5, 2016

Reproduced! Investigating..

@codecadwallader

This comment has been minimized.

Owner

codecadwallader commented Apr 5, 2016

  1. Confirmed that with Visual F# Power Tools disabled, the issue does not seem to occur.
  2. Confirmed that with F# enabled within CodeMaid (default setting), the issue does not seem to occur.
@codecadwallader

This comment has been minimized.

Owner

codecadwallader commented Apr 5, 2016

Using the debugger, it looks like the following two threads are deadlocking each other:

  • FSharpVSPowerTools.Logic.dll!FSharpVSPowerTools.ProjectSystem.VSUtils.DTE.GetProjectItem
  • SteveCadwallader.CodeMaid.dll!SteveCadwallader.CodeMaid.Helpers.DocumentExtensions.GetCodeLanguage(EnvDTE.Document document) Line 17

Both of these are making calls into the VS API to get more information about the active document. The VS API we're both using is COM based.. so multi-threading deadlocks and other issues are not uncommon.

@codecadwallader

This comment has been minimized.

Owner

codecadwallader commented Apr 5, 2016

I believe this is specifically tied to the CleanupOpenCodeCommand, which searches all open documents and determines if any of them are candidates for cleanup. As soon as it finds one document that is a candidate, it should(tm) stop searching the other documents and enable the "Cleanup Open Code" command. When the F# setting in CodeMaid is enabled, it can stop analyzing files with the first one. When the F# setting in CodeMaid is disabled, it has to process all of the files trying to find a match before concluding at the end that none of the files are candidates.

I confirmed this by overriding the command to always be enabled, and indeed the hang seemed to disappear.

@codecadwallader

This comment has been minimized.

Owner

codecadwallader commented Apr 5, 2016

Additionally confirmed by right clicking on the document tab header, which also exposes the CleanupOpenCodeCommand and also exhibits the issue.

@codecadwallader

This comment has been minimized.

Owner

codecadwallader commented Apr 5, 2016

I'll need to chew on possible resolutions.. a few ideas:

  1. Contact Visual F# Power Tools team to see if there's anything on their side they can suggest/address.
  2. Change our CleanupOpenCodeCommand to always be enabled, and wait until execution time to evaluate if there actually are any files we can process. This would be a deviation from the CleanupSelectedCodeCommand (used in Solution Explorer) which also enables/disabled the command based on the affected items The CleanupSelectedCodeCommand does not appear to be affected by the bug as it works with ProjectItem's (vs. Document's).
  3. Change the CleanupOpenCodeCommand to work against ProjectItem's. That would lose a little bit of capability we gain with open documents (e.g. cleaning files external to the solution).

@codecadwallader codecadwallader added this to the v10.1 milestone Apr 5, 2016

@codecadwallader codecadwallader changed the title from VS 2015 freeze with F# projects to VS 2015 freeze with F# projects, F# cleanup disabled, and Visual F# Power Tools installed Apr 5, 2016

@codecadwallader

This comment has been minimized.

Owner

codecadwallader commented Apr 5, 2016

Four: Enable F# cleanup ;)

@codecadwallader

This comment has been minimized.

Owner

codecadwallader commented Apr 7, 2016

As referenced in #255, we may go with option 2 above where we make more of our commands always enabled instead of repeatedly, dynamically checking if they should be enabled. Pending confirmation on that other issue that it is still needed.

codecadwallader added a commit that referenced this issue Apr 9, 2016

#227 #255 #268: Change commands that have expensive availability chec…
…ks to remain enabled, deferring availability checks to execution time.
@codecadwallader

This comment has been minimized.

Owner

codecadwallader commented Apr 9, 2016

I've changed several of the commands that have expensive availability checks to remain enabled and defer availability checks to execution time. I think this may resolve the issue you have been seeing. Can you please test the latest CI build (10.0.81 or higher) available here: http://vsixgallery.com/extension/4c82e17d-927e-42d2-8460-b473ac7df316/

@JanWosnitza

This comment has been minimized.

JanWosnitza commented Apr 11, 2016

  1. Install newest CodeMaid-build: done
  2. Check CodeMaid-Filestypes: F#=unchecked: confirmed
  3. Confirm no programmer freezing bugs are around: success
  4. Happily take sweater off, since risk of getting freezed again is small: roll eyes
  5. Perform bad/awkward joke: ...

Nice job! 👍

@codecadwallader

This comment has been minimized.

Owner

codecadwallader commented Apr 11, 2016

  1. Get cup of ☕️: done
  2. Check GitHub notifications: success
  3. Apply ice to humorous burn: soothing

Thanks for making me smile in the morning, and all your help hunting this one down. 👍

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment