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

System.Runtime.CompilerServices leaks memory (in coreclr helloMVC scenario) #2887

KKhurin opened this Issue May 19, 2015 · 7 comments


None yet
7 participants
Copy link

KKhurin commented May 19, 2015

To repro run requests against coreclr hosted helloMVC:

Here are the leaked objects:

00007ff8a7e984f0    13250       424000 Microsoft.CSharp.RuntimeBinder.Semantics.SYMTBL+Key
00007ff8a7e96648     4013       449456 Microsoft.CSharp.RuntimeBinder.Semantics.EXPRCALL
00007ff8a7e94c70     4014       481680 Microsoft.CSharp.RuntimeBinder.Semantics.EXPRMEMGRP
00007ff8a7e96100     7002       616176 Microsoft.CSharp.RuntimeBinder.Semantics.Scope
00007ff8a7e958d8     7002       672192 Microsoft.CSharp.RuntimeBinder.Semantics.AggregateDeclaration
00007ff8a8970ca0        1      1048600 Microsoft.CodeAnalysis.CSharp.Syntax.InternalSyntax.SyntaxNodeCache+Entry[]
00007ff8a896b5b0        1      1048600 Roslyn.Utilities.TextKeyedCache`1+SharedEntry[[Microsoft.CodeAnalysis.CSharp.Syntax.InternalSyntax.SyntaxToken, Microsoft.CodeAnalysis.CSharp]][]
00007ff8a896b1a8        1      1048600 Roslyn.Utilities.TextKeyedCache`1+SharedEntry[[Microsoft.CodeAnalysis.CSharp.Syntax.InternalSyntax.SyntaxTrivia, Microsoft.CodeAnalysis.CSharp]][]
00007ff8a7e95ee0    13006      1144528 Microsoft.CSharp.RuntimeBinder.Semantics.LocalVariableSymbol

And here is the typical root:

0:025> !gcroot 0000005b5336ee00
    00000057d2be23f8 (pinned handle)
    -> 0000005bd2f31450 System.Object[]
    -> 00000057d2f64d40 System.Runtime.CompilerServices.CallSite`1[[System.Func`4[[System.Runtime.CompilerServices.CallSite, System.Dynamic.Runtime],[System.Object, mscorlib],[System.String, mscorlib],[System.Object, mscorlib]], mscorlib]]
    -> 00000057d2f55e30 Microsoft.CSharp.RuntimeBinder.CSharpSetMemberBinder
    -> 00000057d2f55ed8 Microsoft.CSharp.RuntimeBinder.RuntimeBinder
    -> 00000057d2f631f8 Microsoft.CSharp.RuntimeBinder.SymbolTable
    -> 00000057d2f5a960 Microsoft.CSharp.RuntimeBinder.Semantics.SYMTBL
    -> 00000057d2f5a978 System.Collections.Generic.Dictionary`2[[Microsoft.CSharp.RuntimeBinder.Semantics.SYMTBL+Key, Microsoft.CSharp],[Microsoft.CSharp.RuntimeBinder.Semantics.Symbol, Microsoft.CSharp]]
    -> 0000005bd2f8bd48 System.Collections.Generic.Dictionary`2+Entry[[Microsoft.CSharp.RuntimeBinder.Semantics.SYMTBL+Key, Microsoft.CSharp],[Microsoft.CSharp.RuntimeBinder.Semantics.Symbol, Microsoft.CSharp]][]
    -> 0000005b5336eeb0 Microsoft.CSharp.RuntimeBinder.Semantics.SYMTBL+Key
    -> 0000005b5336ee00 Microsoft.CSharp.RuntimeBinder.Semantics.Scope

@VSadov VSadov self-assigned this May 21, 2015


This comment has been minimized.

Copy link

VSadov commented May 21, 2015

I think this is currently intended behavior of C# runtime binder. Some binding productions are cached and retained indefinitely.
There should be a natural limit on how many of these will be created.

Is the issue just about observing the caching or it does result in a measurable negative impact in a particular scenario?


This comment has been minimized.

Copy link

KKhurin commented May 22, 2015

The binder list grows unboundly...
@rynowak is this intended use of the runtime builder?


This comment has been minimized.

Copy link

rynowak commented May 22, 2015

There's not enough information there to really tell what code is generating this.

My guess is that this is coming from callsites in Razor code that access ViewBag. This is a very typical Razor pattern, and virtually all user sites will have this kind of code. Can you try to repro after removing all calls to `ViewBag from the layout page and the view?

This isn't a solution, but it will help us narrow down the cause.


This comment has been minimized.

Copy link

VSadov commented May 26, 2015

Since this cannot be fixed with a compiler change. Suggesting Resolution-External.

@VSadov VSadov removed their assignment May 26, 2015

@gafter gafter added Area-External and removed Area-Compilers labels May 27, 2015


This comment has been minimized.

Copy link

gafter commented Mar 24, 2016

@VSadov Where should reports against the runtime binder go?


This comment has been minimized.

Copy link

VSadov commented Mar 24, 2016

@jinujoseph jinujoseph added this to the Unknown milestone Jul 23, 2018


This comment has been minimized.

Copy link

vbguyny commented Aug 9, 2018

Any update on this issue? My company is in the process of rewriting 20 year old VB6 code to C# however we still need to maintain backward compatible by invoking COM methods from C#. The bug indicated in this thread is causing our application to crash due to "out of memory" exceptions.

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