Memory leak example?

[code?]

Is there any way I can do a tiny memory leak application, to see what it would do? Just wondering for experimental reasons.

[wildfrog]

You could keep on adding elements to some kind of collection (List, Dictionary etc.).

- petter

[TheCPUWizard]

You could keep on adding elements to some kind of collection (List, Dictionary etc.).

- petter

How would that generate a leak????

[DeepT]

The classic memory leak in C# come from event handlers.

Take some core object that never goes away for the life of the application. Then take some other object which instanced for a while and then it is supposed to go away.

The Other object subscribes to an event on the core object. Now the core object has a reference to this other object in its event handler. You go along and empty your collection of objects thinking the GC will clean everything up. However, those objects never get cleaned up, because Core object's event has a reference to it.

The fix for this is simply to unsubscribe to the event, thus removing the reference.

[TheCPUWizard]

The classic memory leak in C# come from event handlers.

Take some core object that never goes away for the life of the application. Then take some other object which instanced for a while and then it is supposed to go away.

The Other object subscribes to an event on the core object. Now the core object has a reference to this other object in its event handler. You go along and empty your collection of objects thinking the GC will clean everything up. However, those objects never get cleaned up, because Core object's event has a reference to it.

The fix for this is simply to unsubscribe to the event, thus removing the reference.

This is a VERY common problem. I find it in about 80% of .NET applications I am called in on.

Technically this is not a leak, as:

1) The object is still referencable (ie the event will continue to call it)
2) The object will be properly destroyed (albiet at program termination).

One common solution it to use the "Weak Event Model". However this does add some overhead on each invokation of the event.

A less common but [IMHO] better solution is the "Owned Delegate Model". In this model there is a bidirectional tie between the (wrapper for the) delegate and the recieving object.

MANUALLY unsubscribing works, but it is soo easy to miss

[DeepT]

In a manged language it is a close to a memory leak as you can get. If you (not CPUWizard, but people in general) wanted to be super-anal about it, you would simply say memory leaks are impossible and strike the word from the C# lexicon.

Now you could go on about unmanaged code, but we are talking about managed code, C#, not COM interoperability or DLLs written in C++ that can leak.

[DeepT]

A less common but [IMHO] better solution is the "Owned Delegate Model". In this model there is a bidirectional tie between the (wrapper for the) delegate and the recieving object.

An example of this would be great.

[TheCPUWizard]

An example of this would be great.

A "working" example would be too big to post here (might be time for an article ), but The concept is simple....

(This code is typed in RAW and for conceptual purposes only...)

    public class OwnedDelegates : List<OwnedDelegate>
    {
        public static OwnedDelegates Global = new OwnedDelegates();
        public void Register(OwnedDelegate item)
        {
            Add(item);
        }

        public void Unregister(OwnedDelegate item)
        {
            Remove(item);
        }


        public void ReleaseAll(object owner)
        {
            List<OwnedDelegate> killList = new List<OwnedDelegate>();
            foreach (OwnedDelegate item in this)
            {
                if (item.IsOwnedBy(owner))
                {
                    item.Invalidate();
                    killList.Add(item);
                }
            }
            foreach (OwnedDelegate item in killList)
            {
                Remove(item);
            }
        }
    }

    public abstract class OwnedDelegate
    {
        public abstract void Invalidate();
        public abstract bool IsOwnedBy(Object owner);
        public abstract bool IsAlive { get; }
    }

    public class OwnedDelegate<EVENT_TYPE> : OwnedDelegate
        where EVENT_TYPE : EventArgs
    {
        public static EventHandler<EVENT_TYPE> Create(EventHandler<EVENT_TYPE> handler)
        {
            OwnedDelegate<EVENT_TYPE> instance = new OwnedDelegate<EVENT_TYPE>(handler);
            OwnedDelegates.Global.Register(instance);
            return instance.Delegate;
        }

        public override bool IsOwnedBy(Object owner)
        {

            if (IsAlive)
                return ReferenceEquals(m_Owner.Target, owner);
            else
                return false;
        }

         public override bool IsAlive
        {
            get { return (m_Owner != null) && (m_Owner.IsAlive); }
         }

        public override void Invalidate()
        {
            m_RealHandler = null;
            m_Owner = null;
            OwnedDelegates.Global.Unregister(this);
        }

        private OwnedDelegate(EventHandler<EVENT_TYPE> handler)
        {
            m_Owner = new WeakReference(handler.Target);
            m_RealHandler = handler;
            m_MyHandler += OwnedDelegate_Handler;
        }

        public EventHandler<EVENT_TYPE> Delegate
        {
            get { return m_MyHandler; }
        }

        void OwnedDelegate_Handler(object sender, EVENT_TYPE e)
        {
            if (m_RealHandler != null)
                m_RealHandler(sender, e);
        }

        private WeakReference m_Owner;
        private event EventHandler<EVENT_TYPE> m_MyHandler;
        private EventHandler<EVENT_TYPE> m_RealHandler;
    }

[Mutant_Fruit]

Just keep calling:

System.Runtime.InteropServices.Marshal.AllocHGlobal(10000);

and don't free the returned pointer.

[DeepT]

That will take a couple of read-throughs, or maybe find a book. Or you can create an article on it.

[DeepT]

Just keep calling:

System.Runtime.InteropServices.Marshal.AllocHGlobal(10000);

and don't free the returned pointer.

That is cheating and doesn't count. Once you leave the managed side of things, you are "out of bounds".

I can come up with better one then that

public void Loop() { Loop();}

[TheCPUWizard]

DeepT ---- Just found out you do not have PM's enabled....please contact me.

DO NOT REPLY directly on forum to this particular reply. It will be deleted once contact is made.

[Mutant_Fruit]

A stack overflow isn't a memory leak :P

You can't create a memory leak in C# unless you are exploiting a bug in the framework or are using unmanaged code.

Pure safe C# cannot leak.

[DeepT]

I will define a memory leak for C#:

A leak is when your program consumes more and more memory and you have no idea why.

[TheCPUWizard]

I will define a memory leak for C#:

A leak is when your program consumes more and more memory and you have no idea why.

One can not simply make up definitions for a word...unless...

I hereby define "fun" as "Send large sums of money to the CPUWizard". I want EVERYBODY th have FUN!!!!!

A leak is characterized by two qualities.

1) The resource is not referencable
2) The resource will not be properly "cleaned up".

Unless these two conditions come into play, it is NOT a leak!!!!!!

Improper Object Lifetime Management is a completely different topic. "Excessive" memory usage is one symptom of this.

Two ironic points:

1) EXPLICITLY calling GC.Collect can actually induce increased memory usage.

2) .NET really does not have "garbage collection" for most objects (objects with 85,000 or more bytes of direct allocation are the exception). On the other hand native C++ almost ALWAYS has "garbage collection".