Are IntPtr also potentially unsafe in case of exceptions in .NetCF orNeed of SafeHandle?

  • Thread starter Thread starter mind_the_gap
  • Start date Start date
M

mind_the_gap

Hi,

i recently red a blog entry (http://blogs.msdn.com/bclteam/archive/
2005/03/16/396900.aspx) which stated that the use of IntPtr's holding
a reference to unmanaged resources could be dangerous in case of
object finalization and exceptions.
As I understood it the handle finalizer thread (it seems that there is
one and I can not change this) could run the objects finalizer, maybe
clean up the unmanaged resources (I do this in finanizers) and make
the IntPtr invalid. All this could happen while one is actually in a
unmanaged method and could lead to problems.

Since I use a lot of P/Invoke calls and do stuff on the unamanged side
I looked for solutions. A solution is the use of SafeHandles -
unfortunately this class/interface is not available in .Net CF. So
can't this problem occur in the compact framework or do I have to use
another solution (of which I do not know)?

It seems that this issue is critical if one uses P/Invokes in objects
that are not kept outside the local scope and in case of exceptions.

What do you think about this?

Thank you in advance,
Tom
 
An IntPtr isn't inherently unsafe. It's an unsigned 32-bit value type,
nothing more. In fact it's not even really needed - you can just as easily
use an int or uint in its place and everything works the same (though you'll
need some casts due to the language's type safety).

What becomes "unsafe" are people's use of native objects, especially when
they don't fully consider or fully understand how they are treated. When
you make a native allocation from managed code by P/Invoking, it becomes
your responsibility to track and managed the memory from that allocation.
This is done by it virtual address, which is stored in that IntPtr.

If the object that created your native allocation goes out of scop and the
GC collects it, the GC knows nothing of that native allocation and you have
a leak - memory that was allocated and can never be released. This is what
a Finalizer is for. If you're making native allocations and don't know how
to use a Finalizer, you're in trouble.

Now there are some rare cases where a resource reference might get finalized
*before* you want it to (and that's the point of the blog entry you refer
to). There are a few solutions to it. First is to try to analyze your code
to prevent these scope-loss situations that might trigger a finalizer before
you actually want it to happen. The second is to use a replication of the
SafeHandle, such as this:
http://opennetcf.com/library/sdf/html/f5377fa7-0edf-c277-baa0-d9df287e2aed.htm



--

Chris Tacke, Embedded MVP
OpenNETCF Consulting
Giving back to the embedded community
http://community.OpenNETCF.com
 
Chris,

thanks for your answer. I am aware of what is the blog posting about
and that the main reoson for memory leaks is the wrong handling and
maybe unawareness of how things work. I just thought that the GC
in .Net CF has maybe another behaviour in executing Finalizers/
Destructors than its big brother does.
Anyway, thanks for your explaination and the link to the SafeHandle (I
guess it is basically a container for the IntPtr and a reference to
the owning object).

bye,
Tom
 
Back
Top