Skip to content
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.

Sign up for GitHub

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

Jump to bottom

Visual F# Tools leak memory while reloading solutions #106

Closed
KevinRansom opened this issue Jan 26, 2015 · 8 comments
Closed

Visual F# Tools leak memory while reloading solutions #106

KevinRansom opened this issue Jan 26, 2015 · 8 comments
Labels
Bug
Milestone
F# 4.0 Update 1

Comments

@KevinRansom
Copy link
Member

Scenario:
◾Disable VFPT in VS if it is installed
◾Open VFPT solution (https://github.com/fsprojects/VisualFSharpPowerTools), VS occupies ~ 300MB RAM
◾Repeat the following steps 15 times: (1) Switch to a new git branch (2) Reload the solution (3) Rebuild the solution
◾VS now occupies ~ 1.7 GB RAM

Context:
We are hunting down memory leaks in Visual F# Power Tools. It turned out FSharp.Compiler.Service (FCS) leaked memories when Xaml type providers (FsXaml) didn't dispose resources correctly. These bugs have been fixed in FCS and FsXaml. See the discussion at fsharp/fsharp-compiler-docs#158.

After bug fixing, there are still memory leaks. I think Visual F# Tools has the same issue where type providers are in use. We did profile using PerfView without enabling VFPT. Here is a diff of two snapshots where we reload and rebuild solutions twice.

https://cloud.githubusercontent.com/assets/941060/3277997/c56876ec-f39f-11e3-8042-4840c6cffffd.png

https://cloud.githubusercontent.com/assets/941060/3278000/13a16d6e-f3a0-11e3-97cd-b994b8086d8e.png

Configuration:

  • Visual Studio 2013
  • Windows 7
  • A recent build of Visual F# Tools 3.1.1

I believe the fix should be similar to that of FCS. Here are relevant commits:
fsharp/fsharp-compiler-docs@a325df2
fsharp/fsharp-compiler-docs@4e7c8bc

Let me know if you need more information.
@latkin latkin added the Bug label Jan 26, 2015
@dsyme
Copy link
Contributor

dsyme commented Apr 30, 2015

We should apply the linked fix to VF# Tools.

@dsyme dsyme added this to the VS 2015 milestone Apr 30, 2015
@forki
Copy link
Contributor

forki commented Apr 30, 2015

/cc @quasilord

@forki
Copy link
Contributor

forki commented May 3, 2015

We should apply the linked fix to VF# Tools.

I tried to do this, but there are more commits involved.

@dsyme dsyme added the pri-1 label May 9, 2015
@dsyme dsyme self-assigned this May 12, 2015
@dsyme dsyme mentioned this issue May 31, 2015
Closed
dsyme added a commit that referenced this issue Jun 3, 2015
@dsyme @latkin
Fix memory leak: not disposing even subscriptions to invalidation events
64c4ea6 
partially addresses #106
closes #477

commit 5505b71
Author: Don Syme <donsyme@fastmail.fm>
Date:   Sun May 31 16:48:05 2015 +1000

    fix tests for invalidation handlers

commit 0871018
Author: Don Syme <donsyme@fastmail.fm>
Date:   Sun May 31 16:35:47 2015 +1000

    add diagnostic counters to signature

commit e8afa9c
Author: Don Syme <donsyme@fastmail.fm>
Date:   Sun May 31 15:07:35 2015 +1000

    Fix memory leak: not disposing even subscriptions to invalidation events
@latkin latkin removed the fix ready label Jun 3, 2015
@latkin
Copy link
Contributor

latkin commented Jun 10, 2015

This was partially addressed by recent fix from @dsyme, but it looks like we still leak a bunch on reload. I've left it open to keep tracking remaining leaks.

Moving out of VS 2015 milestone, though.

@latkin latkin modified the milestones: vNext, VS 2015 Jun 10, 2015
@dsyme
Copy link
Contributor

dsyme commented Jun 10, 2015

@latkin AFAIK a well written type provider shouldn't leak on reload. What repro steps should I follow to check this out (I'm ok with this being vNext)

@dsyme dsyme added pri-3 and removed pri-1 labels Jun 10, 2015
@latkin
Copy link
Contributor

latkin commented Jun 10, 2015

Sorry, I was not specific enough. I trust that the type provider leak in particular is now fixed, but the general problem indicated by the title of the bug ("Visual F# Tools leak memory while reloading solutions") is not.

@dsyme
Copy link
Contributor

dsyme commented Jun 10, 2015

OK, got it, thanks

@latkin latkin removed this from the vNext milestone Aug 4, 2015
@dsyme
Copy link
Contributor

dsyme commented Aug 14, 2015

Re memory leaks - I noticed another case where the Fsharp.Compiler.Service code is correctly disconnecting a callback when a prjoect is unloaded, see https://github.com/fsharp/FSharp.Compiler.Service/blob/0c37365691e5568adfc357fc915eed645b45481d/src/fsharp/CompileOps.fs#L4093.

dsyme added a commit to dsyme/fsharp that referenced this issue Aug 14, 2015
@dsyme
Second half of fix to dotnet#106
adebe18
@dsyme dsyme mentioned this issue Aug 14, 2015
Closed
@dsyme dsyme closed this as completed in 225b990 Sep 16, 2015
@latkin latkin added the fixed label Sep 16, 2015
@latkin latkin added this to the F# 4.0 Update 1 milestone Sep 16, 2015
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
Bug
Projects
None yet
Milestone
F# 4.0 Update 1
Development

No branches or pull requests
4 participants
@forki @KevinRansom @latkin @dsyme