Open ZhiqiangTao opened 3 years ago
I couldn't figure out the best area label to add to this issue. If you have write-permissions please help me learn by adding exactly one area label.
env:
Tagging subscribers to this area: @dotnet/gc See info in area-owners.md if you want to be subscribed.
Author: | ZhiqiangTao |
---|---|
Assignees: | - |
Labels: | `area-GC-coreclr`, `untriaged` |
Milestone: | - |
are all the objects of type System.Func2[[System.Object, System.Private.CoreLib],[System.Object, System.Private.CoreLib]]
? Have you tried using dumpheap
to check what all objects are alive?
I highly recommend PerfView for this analysis. It does a much better job than !gcroot
at showing the shortest weighted path to root.
reference to :https://github.com/dotnet/efcore/issues/24841
It's probably impossible for someone else to figure it out for you without the source code. The reference tree generated by those tools will contain mostly unrelated info and useful items needs to be digged out.
Since there is a lot of Func, do you use lambda in your code? C# compiler is known to generate code that leads to potential memory leaks if you keep closures alive. Specifically, if you create 2 closures in a same block, they will usually hold unnecessary references to objects that are used only in each other's body. So if you keep one of them alive and something used in either one of them (or both) won't be collected.
The code here is part of MVC'a code base. It's the cache that stores thunks for invoking action methods.
mycode sample just like below: any fault in there? Could you help me point out what's the problem :) @davidfowl @acaly
I'm not sure the above has anything to do with your code. How many controller actions do you have?
@ZhiqiangTao The second image shows a closure created capturing a variable. The other two don't create closure but the returned task will hold reference to the closure. To trigger the C# bug I mentioned, you need to:
The first one you probably need to check every single methods of your project. For the second, MVC framework shouldn't be storing anything permanently if you follow the scoped service pattern. It may happen if you created something yourself or store something (e.g., a Task for an async method that captures a closure variable) to static fields.
recently, I meet an issue as you can see, the gen2 is very large(about 120m) smaller than LOH, so I think there are many objects migrate from gen0 ->gen1-to gen2, then I use gcroot and gcwhere to inspect some objects , but i found that most of them are handled by below:
who can help me analyze the cause of that the small object(about 40btye) not released in gen0. thanks in advanced!