6

I have a memory leak and traced it to this field inside CLR:

Microsoft.CSharp.RuntimeBinder.RuntimeBinder.s_instance.m_semanticChecker.globalSymbolContext.GlobalSymbols.tableGlobal.dictionary

It can be viewed in debugger using this specification:

((Microsoft.CSharp.RuntimeBinder.Semantics.LangCompiler)(Microsoft.CSharp.RuntimeBinder.RuntimeBinder.s_instance.m_semanticChecker)).globalSymbolContext.GlobalSymbols.tableGlobal.dictionary

During execution of application, this dictionary indefinitely grows.

Any ideas, what exactly this field is used for, and why it can grow?

UPD there is no dynamic creation of types, at least in my code

user626528
  • 13,999
  • 30
  • 78
  • 146
  • Are you creating types dynamically? – Oded Jan 06 '12 at 12:28
  • 5
    Not all forms of memory consumption are leaks. How big is your 'leak', how do you measure? – H H Jan 06 '12 at 12:29
  • This leak is infinite. More application runs, bigger this table grows, until application eats all gigabytes of RAM – user626528 Jan 06 '12 at 12:33
  • 4
    You need to provide more information about your own code - how does the binder get invoked by your code? At what point? – Oded Jan 06 '12 at 12:59
  • My code doesn't call binder. It must be called indirectly from somewhere. – user626528 Jan 06 '12 at 13:02
  • 7
    This is buried deep inside the plumbing that makes the *dynamic* keyword work. Not necessarily in your own code. It is impossible to diagnose without a project that exhibit this problem. Even then a diagnostic is hard to come by, this code is super secret. Best thing to do is to start a support case with Microsoft. They'll need your project so they can repro the problem. Make sure it is easy to run, the smaller the better. – Hans Passant Jan 06 '12 at 13:21
  • Have you tried running a proper memory profiler to see when and what type of allocations happen when your code is running? I would like to recommend dotTrace (I DO NOT work for Jet Brains and I am not affiliated with them in any way). I use it in a project recently and found that I suffered from Large Object Heap fragmentation (not sure this is your case though). Just give it a go. – Yannis Feb 07 '12 at 12:17
  • @Yannis, don't answer if you didn't read or didn't understand the question. – user626528 Feb 10 '12 at 06:25

1 Answers1

4

The best answer I've found so far:
The problem happens somewhere around Excel VSTO Range.Style property (it uses dynamic data type).
Every time this piece of code

range.Style == null

runs, it makes the binder consume some more memory.
But if I rewrite this code like this

(Style)range.Style == null

then the problem disappears.

UPD reported this to Microsoft https://connect.microsoft.com/VisualStudio/feedback/details/861770/memory-leak-when-using-excel-add-in-api#tabs

user626528
  • 13,999
  • 30
  • 78
  • 146