locked
Linq-To-Sql memory leaking RRS feed

  • Question

  • Hi,

    I'm looking at the exactly the same problem as described here: https://social.msdn.microsoft.com/Forums/en-US/2e52addf-1283-45ee-b987-09a111262de3/dlinq-and-memory-leaking

    Windows Service application keeps hoarding up memory slowly and the root cause seems to be SQLNew etc. objects being rooted in LocalDataStore. The application is .Net Framework 4.5.2 project that uses Linq-To-Sql to access the database. 

    What adds those SQLNew etc. instances to the local store and is there a way of releasing them? The last question in the previous post was from 2013 where someone asked about this in 4.0 runtime but it was left unanswered.

    Best Regards, Pate Blomqvist

    Wednesday, September 11, 2019 10:26 AM

All replies

  • Hi PBlomqvist,

    Thank you for posting here.

    >>Windows Service application keeps hoarding up memory slowly and the root cause seems to be SQLNew etc. objects being rooted in LocalDataStore.

    Could you provide more information about 'SQLNew' and 'LocalDataStore' ? It will help us to analyze your problem.

    Besides, I have found a reference.

    How do I avoid a memory leak with LINQ-To-SQL?

    Hope it can help you.

    Best Regards,

    Xingyu Zhao


    MSDN Community Support
    Please remember to click "Mark as Answer" the responses that resolved your issue, and to click "Unmark as Answer" if not. This can be beneficial to other community members reading this thread. If you have any compliments or complaints to MSDN Support, feel free to contact MSDNFSF@microsoft.com.

    Thursday, September 12, 2019 5:33 AM
  • Hi,

    I profile the application with dotMemory and compare two snapshots. Number of SQLNew instances in memory keeps increasing and if I look at the memory retention paths it seems that they are being kept alive by the LocalDataStore. Basically the same thing that is described in the thread I linked in the original post.

    Basically it says that: "I think I found why the data context and the Customer entity instance wasn't being collected by the GC. Taking a snapshot, in ANTS Profiler, after the GC.Collect(), i found that the customer instance is referenced from a System.Linq.Expressions.ConstantExpression instance. The ConstantExpression instance is referenced from a SqlColumnRef instance. The SqlColumnRef is referenced from a SqlClientArray instance (it's inside a List<T> on the SqlClientArray instance). The SqlClientArray instance is referenced from a ObjectReaderCompiler.ReaderFactoryCache.CacheInfo instance. The CacheInfo instance is referenced from a ObjectReaderCompiler.ReaderFactoryCache (it's inside a LinkedList<T> on the ReaderFactoryCache instance). The ReaderFactoryCache instance is inside a object[] array. And this object[] array is inside a LocalDataStore instance. This LocalDataStore instance is inside an ArrayList instance which is inside a LocalDataStoreMgr instance. The LocalDataStoreMgr instance is inside a LocalDataStoreSlot instance. This LocalDataStoreSlot instance is only referenced from a static object[] array wich ANTS profiler says that is allocated by the CLR initialization. In other words, the Customer instance cannot be released from memory because the dlinq engine stored it indirectly in a LocalDataStoreSlot on the thread. Since the Customer instance points to the data context, it isn't released too."

    I also found the link you did and it is not relevant here as I already dispose of all of the connections that are being made. Somehow it seems that the query parameters get stored into LocalDataStore and keep accumulating more and more memory. 

    In the original thread, this was takein into account in 2.0 runtime but someone commented that it has re-appeared in 4.0 runtime in 2013. 

    Best Regards, Pate Blomqvist

    Thursday, September 12, 2019 6:39 AM
  • Hi PBlomqvist,

    Thanks for your feedback.

    Is the similar problem solved in the 3.5 runtime? If so, I suggest you report a problem in Developer Community for more help.

    Thank you for your understanding and support.

    Best Regrads,

    Xingyu Zhao


    MSDN Community Support
    Please remember to click "Mark as Answer" the responses that resolved your issue, and to click "Unmark as Answer" if not. This can be beneficial to other community members reading this thread. If you have any compliments or complaints to MSDN Support, feel free to contact MSDNFSF@microsoft.com.

    Thursday, September 12, 2019 8:28 AM