Everybody knows about, that you have to be very keen about using unmanaged resources (like filestreams, sharepoint objects, sockets, etc), disposing them whenever it's important, etc. But do we know all situations, that you have to be careful not to leak memory or not to let an unmanaged resource to be collected by garbage collector (which should mean you were unaware about it being unreleased at the appropiate time)? I tried to collect most of the situations where you may leak an unmanaged object the way you even didn't think about.
Returning a ref value
Wow – returning a value may cause problems? But how? The sad thing – it's not that hard to create a situation when just returning a reference value can cause (curable) problems. Look at this situation:
We have two objects, both of them having unmanaged references to each other – let's name them Parent and Child. Let's state that both of them are backing up unmanaged resources as well. If I return the Child object from a call (let's say Child GetFirstChildForThisParent(guid), and it looks up the parent according to the guid given), the following is happening:
You get a child object, which you use for what reason you would like to use it – the problem arise at the end of your code snippet, when you want to dispose the object – you have to be very cautious when freeing it up. If it has a managed reference to the parent – you can grab it, and free it! Or not? No, you can't dispose it – what happens, if there are anything else in the memory from the parent – any other child, any other references that are hold, etc. So – where are we? Again at the reference counting world of COM arrived? Yes, this can be a solution as well, but what if you create a small class holding the parent and the child object together, and giving that as a result – and of course creating a new parent every time needed… That could work as well. So – this could be a solution, but this will create additional needs on the memory footprint and the number of unmanaged resources…
Iterating over a collection
Ok, what happens, if I iterate over a collecting? Collection iterating is done in two parts – first you get an iterator, than you get the values each by each by calling some property. So – in order not to leak the resources this time, try to reuse the collection from the original object in the iterator, and the main point – plan how you are going to manage the values you are giving from the list. A small problem would arise with this approach – you are not able to modify the collection easily while you are iterating over it, it's not easy anytime, but the unmanaged resources you are holding are going to drive you nuts 🙂
Yielding
Ok, yielding – it's a very good thing, but do we know exactly what is happening? State machine created, calls are stopped by early returns, etc. It's one of the most useful creations in .NET, but – if you followed the previous paragraphs carefully, you already should know what is the problem – you don't have the right control over the creation of unmanaged resources and linkage between them… So, as for the others, you can use this useful tool as well, but you have to be very careful at most of the cases… 🙁
