The most common managed code memory leaks I had the pleasure to locate were almost always objects which had a method registered to a static event. For some reason a lot of developer think, that these are weakly referenced. By now I know what to search for, but since these are also often some kind of lambda expression, their origin is often very difficult to locate.
Very good explanation, thank you so much for this. One question, you talked about gcroot command in video position 32.31 but i can't see that commend, can you explain what command you typed to get the location in actual source code?
Is the GC aware of constructions like object A is holding a ref to object B and B is holding a reference to A, but no one else references A or B. Would it collect those objects at some point or not?
Yes, it's one of the tasks of GC to clean up cyclic references. In .NET this done by creating a graph that contains all the objects that are reachable from the roots(static fields, local variables on a thread's stack, CPU registers, GC handles and etc.) and releasing all memory allocated for objects, unreachable from the application's roots.
its cool that it works on windows but on my macos i have wierd behavior.. so running clrstack gives something like failed to find runtime module (libcoreclr.dylib). thats on .net 6.0 app build with rider using the arm sdk
Very helpful ! very happy to see diagnosing memory leaks subject in action into the .NET community
The most common managed code memory leaks I had the pleasure to locate were almost always objects which had a method registered to a static event. For some reason a lot of developer think, that these are weakly referenced. By now I know what to search for, but since these are also often some kind of lambda expression, their origin is often very difficult to locate.
Excellent video! Very informative and well presented. We need more showcases of this type of tool.
Very good explanation, thank you so much for this. One question, you talked about gcroot command in video position 32.31 but i can't see that commend, can you explain what command you typed to get the location in actual source code?
I've never heard 2 guys so open about when they take a dump
This was such an incredibly informative video.. thanks a LOT
By any chance you got an update about the OutOfMemoryException not tearing down process?
Great video. How can we get a creation stack trace. Which method created the instance. Thanks!
Is the GC aware of constructions like object A is holding a ref to object B and B is holding a reference to A, but no one else references A or B. Would it collect those objects at some point or not?
Yes, it's one of the tasks of GC to clean up cyclic references. In .NET this done by creating a graph that contains all the objects that are reachable from the roots(static fields, local variables on a thread's stack, CPU registers, GC handles and etc.) and releasing all memory allocated for objects, unreachable from the application's roots.
Useless if you don't use the enterprise VS :( we don't have debug managed memory option when we open the dump file
I noticed that too. You can use dotnet-gcdump instead and open that in VS. Should be the same commands etc just add the gc part.
Very good. Thanks
Very helpful thank you
I have VS 2022 Community and I cannot find Actions > Debug managed memory after I open the dump file. Is it available for my version of VS?
Only in Enterprise it seems.
I could help but laugh at 16:31
😂 r/nocontext
😂
@@vincidixit 😬
its cool that it works on windows but on my macos i have wierd behavior..
so running clrstack gives something like failed to find runtime module (libcoreclr.dylib). thats on .net 6.0 app build with rider using the arm sdk