C#: Care about Event Memory Leaks with Delegate.GetInvocationList()

home
c#
view story

13 Kicks

C#: Care about Event Memory Leaks with Delegate.GetInvocationList()(weblogs.sqlteam.com)

submitted by spirit1(3160) 4 years, 7 months ago

Subscribed events are one of the most common reasons of memory leaks in .Net. This means that if you have an object that has an event and there are other object that are subscribed to that event, the original object won't be properly disposed until all events are unsubscribed since an event is a strong reference.

2 comments |category: C# |Views: 421
Tweet

tags: MemoryLeak Delegate .net2.0 C# Patterns another

Everyones tags:

Your Tags:

Please login or signup.

Add a live kick counter to your blog >> liveImage

You can even customize the image by choosing your own colors, and then clicking the button below to update the preview and the html code:

"Kick It" text
"Kick It" background
kick count text
kick count background
border

Simply copy and paste this HTML into your blog post.

Users who kicked this story:

More who kicked this story...

Comments:

posted by jesse(100) 4 years, 7 months ago 0

Sigh...seems like every year or so some (otherwise smart) developer with a blog is fooled into thinking that "magical delegates" must be creating memory leaks with all those circular references because, well, circular references *must* be bad, right? Also like this guy, most people who write on the subject of delegate circular references almost always show you how to avoid the problem with a weird (and often wrong) finalizer to add to all your forms (that should be your first warning that they're just plain wrong), and they NEVER bother to include code demonstrating how the finalizers of the suspect classes aren't running after a forced GC, because, well, they don't actually know what's going on under the hood of .NET to begin with. Somehow they either never learned--or just totally forgot--that the GC in .NET finalizes circular-referenced objects, and that it's trivial to write code showing this is true. What they usually do wrong is forget to entirely dereference their forms, and then go wondering why they aren't being finalized after someone presses the "close" button.

If you take a minute to learn that delegates aren't magical, and what a typesafe function pointer actually is, you'll quickly understand that it's like any other reference in .NET, and the normal GC rules apply. The only way the form in the author's example wouldn't be GC'd once it is closed is if he keeps another reference to the form instance in a field or collection. Just because the form isn't being displayed doesn't mean it's dereferenced yet! Since the form's delegates still contain pointers to methods on the handling classes, neither the form nor the handling classes are finalized until the form is truly dereferenced! In this single case, the "memory leak" isn't GC-related at all--it's "bad programmer"-related.

posted by spirit1(3160) 4 years, 7 months ago 0

true. i was proven wrong and i'm thankfull for it. for me this is a good thing since i've learned a new thing. and that's always good, right? :))
if i'm not mistaken my example would have to be reversed.
for the leak to occur the form should have to be subscribed to an event on the original class that owns the form.
since then closing the form wouldn't magicaly unsubscribe the event subscribtion to the original class from where you called form.Show().
correct?

Most Active Users

What's this?