Simple problem: Why does this cause a massive memory leak?

[VJ]

Re: Simple problem: Why does this cause a massive memory leak?

Ok maybe I was not clear on what I said. The IDisposablie if for a .NET
Object not for COM. If the COM has a problem very true you fix it there..,
but any time you use Unmanaged code and reference in a .NET app, please wrap
it in a object with IDisposiable implementation and make sure you call
..Dispose() after done with the .NET object that has implemented the COM.

http://www.microsoft.com/mspress/books/sampchap/5028.aspx

Also in addition to what David, said when using Native API Code in .NET make
sure they will have permissions to run, see below link what i mean.

http://msdn2.microsoft.com/en-us/library/ms182161(VS.80).aspx

All this helps you make your .NET app work well with native code, but again
if the native code has issues, have to fix it there.

VJ

"David Browne" <davidbaxterbro wne no potted meat@hotmail.co mwrote in
message news:O%23O%23wR ZaHHA.4508@TK2M SFTNGP03.phx.gb l...

>
>
"Simon" <simon@nothanks .comwrote in message
news:OcNlsUYaHH A.2076@TK2MSFTN GP04.phx.gbl...

>Hi VJ
>>
>Thanks for your reply.
>>
>I'm not sure how to "implement IDisposable" on these objects as they
>don't have any such method. The COM objects are part of a third party
>programming API that I have no control over.
>>
>How do I get rid of them if they dont have a Dispose() method or any
>obvious equivelant?
>>

>
Yeah, that's nonsense. If the COM component really has a memory leak, you
would need to fix it in the COM component.
>
However, often .NET code using COM components have poor memory performance
because the Runtime Callable Wrappers that .NET uses to wrap the COM
interface pointers will not destroy the COM component until they are
finalized. This can cause lots of memory problems, although it's not
technically a leak. As a best practice, anytime you are using a COM
component from .NET, explicitly call
System.Runtime. InteropServices .Marshal.Releas eComObject when you are done
with the COM component. This will immediately decrement the reference
count on the COM component and should clean up any unmanaged memory
associated with the component.
>
David
>
>

[VJ]

Re: Simple problem: Why does this cause a massive memory leak?

Simon one more thing. If your COM object has methods to clean up itself
those have to be called. Just saying, I am sure you are already doing this.
See my recent post, this is where IDisposible is used which .NET and the GC
call after object is released, so you can do all cleaning.

VJ

"Simon" <simon@nothanks .comwrote in message
news:e9lQDhZaHH A.348@TK2MSFTNG P02.phx.gbl...

Hi Guys,
>
Thanks for your help so far.
>
I have a couple of questions I'm hoping someone could help me with.
>
1. If I have a method that creates and uses some COM objects, will the
resources that those COM objects were using be fair game for release as
soon as they go out of scope? Or do I have to do something to get rid of
them?
>
2. Dave mentioned calling
System.Runtime. InteropServices .Marshal.Releas eComObject. I had found a
reference to this when googling, but discounted it because the official
documentation said that it should only be used for testing purposes.
Something about the behaviour being undefined under certain operating
conditions. Should I use this?
>
Surely there must be a well known way of getting rid of COM gubbins once
I'm done with it. It sure isn't happening automatically though....
>
Thanks all
>
Simon

[Cor Ligthert [MVP]]

Re: Simple problem: Why does this cause a massive memory leak?

Simon,

I mean before it is created.

GPSPositionTabl eAdapter da = new GPSPositionTabl eAdapter();
tblGSPositions. Clear();
'At least the table which will be replaces loses now his rows, and I hope
its references.
'Be aware that not the same table is used again, only the references is
replaced by another one with
'your sentence bellow. If there are references to the existing those will
stay as long as the program lives.
GPSPositionTabl e tblGPSPositions = new GPSPositionTabl e();

Cor

"Simon" <simon@nothanks .comschreef in bericht
news:eR1yskVaHH A.208@TK2MSFTNG P05.phx.gbl...

Hi Cor,
>
Thanks for your reply. I havent had a chance to try what you're suggesting
as the code is on another machine, but I can't see why it would work...
>
PerformOperatio n is called say, 100 times and each time the datatable and
data adapter et al should go completely out of scope and therefore be fair
game for the GC.
>
If I call Clear on the data table just after it's create as you suggest,
I'd be calling clear on a completely new instance with nothing in it...
>
Am I perhaps misunderstandin g something?
>
Many thanks
>
Simon

[David Browne]

Re: Simple problem: Why does this cause a massive memory leak?



"Simon" <simon@nothanks .comwrote in message
news:e9lQDhZaHH A.348@TK2MSFTNG P02.phx.gbl...

Hi Guys,
>
Thanks for your help so far.
>
I have a couple of questions I'm hoping someone could help me with.
>
1. If I have a method that creates and uses some COM objects, will the
resources that those COM objects were using be fair game for release as
soon as they go out of scope? Or do I have to do something to get rid of
them?

Yes, they might get cleaned up any time after the COM object goes out of
scope. But normally the Runtime Callable Wrapper must be Garbage-Collected
before the COM object can clean itself up. There's no way to tell when that
will happen. System.Runtime. InteropServices .Marshal.Releas eComObject should
destroy the COM object immediately.

>
2. Dave mentioned calling
System.Runtime. InteropServices .Marshal.Releas eComObject. I had found a
reference to this when googling, but discounted it because the official
documentation said that it should only be used for testing purposes.
Something about the behaviour being undefined under certain operating
conditions. Should I use this?

The official docs say nothing of the kind.

Marshal.Release ComObject Method
....
This method is used to explicitly control the lifetime of a COM object used
from managed code. You should use this method to free the underlying COM
object that holds references to resources in a timely manner or when objects
must be freed in a specific order.

http://msdn2.microsoft.com/en-us/library/system.runtime.interopservices.marshal.releasecomobject.aspx

And yes, you should use this method to free the underlying COM object that
holds references to resources in a timely manner.

David

[Miha Markic [MVP C#]]

Re: Simple problem: Why does this cause a massive memory leak?

Cor,

There are two issues with your solution:
1. It won't compile as you are accessing a variable before its declaration
2. It doesn't matter whether you invoke Clear or not as reference goes out
of the scope anyway.

--
Miha Markic [MVP C#, INETA Country Leader for Slovenia]
RightHand .NET consulting & development www.rthand.com
Blog: http://cs.rthand.com/blogs/blog_with_righthand/

"Cor Ligthert [MVP]" <notmyfirstname @planet.nlwrote in message
news:uENB05aaHH A.4692@TK2MSFTN GP04.phx.gbl...

Simon,
>
I mean before it is created.
>
GPSPositionTabl eAdapter da = new GPSPositionTabl eAdapter();
tblGSPositions. Clear();
'At least the table which will be replaces loses now his rows, and I hope
its references.
'Be aware that not the same table is used again, only the references is
replaced by another one with
'your sentence bellow. If there are references to the existing those will
stay as long as the program lives.
GPSPositionTabl e tblGPSPositions = new GPSPositionTabl e();
>
Cor
>
"Simon" <simon@nothanks .comschreef in bericht
news:eR1yskVaHH A.208@TK2MSFTNG P05.phx.gbl...

>Hi Cor,
>>
>Thanks for your reply. I havent had a chance to try what you're
>suggesting as the code is on another machine, but I can't see why it
>would work...
>>
>PerformOperati on is called say, 100 times and each time the datatable and
>data adapter et al should go completely out of scope and therefore be
>fair game for the GC.
>>
>If I call Clear on the data table just after it's create as you suggest,
>I'd be calling clear on a completely new instance with nothing in it...
>>
>Am I perhaps misunderstandin g something?
>>
>Many thanks
>>
>Simon

>
>

[Simon Harvey]

Re: Simple problem: Why does this cause a massive memory leak?

Miha Markic [MVP C#] wrote:

Cor,
>
There are two issues with your solution:
1. It won't compile as you are accessing a variable before its declaration
2. It doesn't matter whether you invoke Clear or not as reference goes
out of the scope anyway.
>

Yeah - I've got to agree with that assesment I'm afraid. Unless I'm
being particularly thick, the code as suggested wouldnt even compile -

// Won't compile
tblGSPositions. Clear();
GPSPositionTabl e tblGPSPositions = new GPSPositionTabl e();

Thanks

Simon

[Cor Ligthert [MVP]]

Re: Simple problem: Why does this cause a massive memory leak?

Miha,

I agree with you that I missed the declaration part and this one won't go,
however the idea was that often the problem is that the old object stays,
because although it goes out of scope, holds or has references to it.

Maybe will this go with the declaration global. I trying this with the
shortes code I can think about.

cor

Cor,
>
There are two issues with your solution:
1. It won't compile as you are accessing a variable before its declaration
2. It doesn't matter whether you invoke Clear or not as reference goes out
of the scope anyway.
>
--
Miha Markic [MVP C#, INETA Country Leader for Slovenia]
RightHand .NET consulting & development www.rthand.com
Blog: http://cs.rthand.com/blogs/blog_with_righthand/
>
"Cor Ligthert [MVP]" <notmyfirstname @planet.nlwrote in message
news:uENB05aaHH A.4692@TK2MSFTN GP04.phx.gbl...

>Simon,
>>
>I mean before it is created.
>>
>GPSPositionTab leAdapter da = new GPSPositionTabl eAdapter();
>tblGSPositions .Clear();
>'At least the table which will be replaces loses now his rows, and I hope
>its references.
>'Be aware that not the same table is used again, only the references is
>replaced by another one with
>'your sentence bellow. If there are references to the existing those will
>stay as long as the program lives.
>GPSPositionTab le tblGPSPositions = new GPSPositionTabl e();
>>
>Cor
>>
>"Simon" <simon@nothanks .comschreef in bericht
>news:eR1yskVaH HA.208@TK2MSFTN GP05.phx.gbl...

>>Hi Cor,
>>>
>>Thanks for your reply. I havent had a chance to try what you're
>>suggesting as the code is on another machine, but I can't see why it
>>would work...
>>>
>>PerformOperat ion is called say, 100 times and each time the datatable
>>and data adapter et al should go completely out of scope and therefore
>>be fair game for the GC.
>>>
>>If I call Clear on the data table just after it's create as you suggest,
>>I'd be calling clear on a completely new instance with nothing in it...
>>>
>>Am I perhaps misunderstandin g something?
>>>
>>Many thanks
>>>
>>Simon

>>
>>

>

[Miha Markic [MVP C#]]

Re: Simple problem: Why does this cause a massive memory leak?


"Cor Ligthert [MVP]" <notmyfirstname @planet.nlwrote in message
news:OdZj2BlaHH A.5108@TK2MSFTN GP03.phx.gbl...

Miha,
>
I agree with you that I missed the declaration part and this one won't go,
however the idea was that often the problem is that the old object stays,
because although it goes out of scope, holds or has references to it.

If something is holding the reference (lets say parent) to instance you want
get rid of then you have to make sure to either
a) drop that reference
b) make sure every reference to parent is dropped
so the graph isn't referenced from outside.
Either way Clear would not help.

--
Miha Markic [MVP C#, INETA Country Leader for Slovenia]
RightHand .NET consulting & development www.rthand.com
Blog: http://cs.rthand.com/blogs/blog_with_righthand/