mind_the_gap
Mon May 05 12:47:45 CDT 2008
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
On 5 Mai, 15:42, "Chris Tacke, eMVP" <ctacke.at.opennetcf.dot.com>
wrote:
> An IntPtr isn't inherently unsafe. =A0It's an unsigned 32-bit value type,
> nothing more. =A0In fact it's not even really needed - you can just as eas=
ily
> 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. =A0Whe=
n
> 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 hav=
e
> a leak - memory that was allocated and can never be released. =A0This is w=
hat
> a Finalizer is for. =A0If 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 finaliz=
ed
> *before* you want it to (and that's the point of the blog entry you refer
> to). =A0There are a few solutions to it. =A0First is to try to analyze you=
r code
> to prevent these scope-loss situations that might trigger a finalizer befo=
re
> you actually want it to happen. =A0The second is to use a replication of t=
he
> SafeHandle, such as this:
http://opennetcf.com/library/sdf/html/f5377fa7-0e=
df-c277-baa0-d9df287...
>
> --
>
> Chris Tacke, Embedded MVP
> OpenNETCF Consulting
> Giving back to the embedded community
http://community.OpenNETCF.com
>
> "mind_the_gap" <2voo...@gmx.de> wrote in message
>
> news:9d174437-3bfe-4d5a-9e60-ae843ed162af@y38g2000hsy.googlegroups.com...
>
>
>
> > 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