AccessPoint accessPoint in currentAdapter.PreferredAccessPointsMemory Leak

  • Thread starter Thread starter .net CF'er
  • Start date Start date
N

.net CF'er

Hello All, I think I have narrowed a memory leak down to this code. I
am using OpenNETCF.Net Version 2.1.
As you can see, I am really doing nothing in the following code accept
getting the current adapters preferredAccessPoint collection. I plan
on digging into this code this weekend/next week but wanted to throw
it out on the forum in hopes others have a solution. The pattern
appears to be a 200K drop in available virtual every ~ 15 calls to the
function that runs the code below. A perfmon diff shows no
accumulations of objects in managed code. It will run until the exe
eats up all 32MB.

// Add other preferred access points
foreach (AccessPoint accessPoint in
currentAdapter.PreferredAccessPoints)
{
if (!results.ContainsKey
(accessPoint.Name))
{
try
{
results.Add
(accessPoint.Name,null);
}
catch { }
}
}

I did a quick search on this and only found the following from Chris
T. The difference is this guy was using NetCF ver 1.4 and the 2.1
version I am using does not have a reference to ndisAccess and the
class is only 229 lines. it does have a RefreshList function with no
need to close any Handles.
-----------

There is a leak in AccessPointCollection, near line 329 in RefreshList
().
You need to add the following:

FileEx.CloseHandle( ndisAccess );


before leaving that method.

I'm unable to find anything else actually leaking. All of the managed
arrays, I would think, should be getting freed when the garbage
collector
decides that it's time. There's very little, if any, unmanaged memory
allocated when that series of steps is performed, so there isn't a lot
of
room for things to get lost.
-------------
 
Have you tried anything newer? We're already at version 2.3, and we made a
lot of changes and did a lot of fixes around WiFi in the 2.3 release.


--

Chris Tacke, Embedded MVP
OpenNETCF Consulting
Giving back to the embedded community
http://community.OpenNETCF.com
 
Have you tried anything newer?  We're already at version 2.3, and we made a
lot of changes and did a lot of fixes around WiFi in the 2.3 release.

--

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












- Show quoted text -

Prelim results is that it acts the same between 2.3 and 2.1, still
seems to be dropping in 200K buckets.

I will know more tomorrow.
 
Are you, by any chance, not disposing of something, an AccessPoint or an
Adapter, when you're done with it? That sounds like a case where a large
structure that one of those classes allocated to get SSID information might
not get thrown away unless you call Dispose(), Close() or something of that
nature, possibly because you are storing things in an array for later use or
something.

Paul T.

Have you tried anything newer? We're already at version 2.3, and we made a
lot of changes and did a lot of fixes around WiFi in the 2.3 release.

--

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












- Show quoted text -

Prelim results is that it acts the same between 2.3 and 2.1, still
seems to be dropping in 200K buckets.

I will know more tomorrow.
 
Are you, by any chance, not disposing of something, an AccessPoint or an
Adapter, when you're done with it?  That sounds like a case where a large
structure that one of those classes allocated to get SSID information might
not get thrown away unless you call Dispose(), Close() or something of that
nature, possibly because you are storing things in an array for later useor
something.

Paul T.






Prelim results is that it acts the same between 2.3 and 2.1, still
seems to be dropping in 200K buckets.

I will know more tomorrow.- Hide quoted text -

- Show quoted text -

Hello Paul,
I am using INetworkInterface, WirelessZeroConfigNetworkInterface, and
NetworkInformation.AccessPoint and do not see a close or dispose
function on any of them.?
 
OK, it appears to me that there may a missing deallocation for the raw data
portion of the INTF_ENTRY struct in the AccessPointCollection methods for
the allocation near line 173. I think that Chris would have to identify and
apply a fix.

Paul T.

Are you, by any chance, not disposing of something, an AccessPoint or an
Adapter, when you're done with it? That sounds like a case where a large
structure that one of those classes allocated to get SSID information
might
not get thrown away unless you call Dispose(), Close() or something of
that
nature, possibly because you are storing things in an array for later use
or
something.

Paul T.






Prelim results is that it acts the same between 2.3 and 2.1, still
seems to be dropping in 200K buckets.

I will know more tomorrow.- Hide quoted text -

- Show quoted text -

Hello Paul,
I am using INetworkInterface, WirelessZeroConfigNetworkInterface, and
NetworkInformation.AccessPoint and do not see a close or dispose
function on any of them.?
 
And, unfortunately, I'm leaving on vacation in an hour, so the earliest it's
going to happen on my end would be August.


--

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


"Paul G. Tobey [eMVP]" <p space tobey no spam AT no instrument no spam DOT
com> wrote in message news:%[email protected]...
 
Hmmm. Well, I'll try to take a look at it and at least suggest a fix for
the interim in the field. If .net CFer has the code, that should allow
things to be fixed for now, at least.

Enjoy the vacation!
Paul T.

Chris Tacke said:
And, unfortunately, I'm leaving on vacation in an hour, so the earliest
it's going to happen on my end would be August.


--

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


"Paul G. Tobey [eMVP]" <p space tobey no spam AT no instrument no spam DOT
com> wrote in message news:%[email protected]...
OK, it appears to me that there may a missing deallocation for the raw
data portion of the INTF_ENTRY struct in the AccessPointCollection
methods for the allocation near line 173. I think that Chris would have
to identify and apply a fix.

Paul T.



Hello Paul,
I am using INetworkInterface, WirelessZeroConfigNetworkInterface, and
NetworkInformation.AccessPoint and do not see a close or dispose
function on any of them.?
 
There are actually a few places where INTF_ENTRY structures are allocated
but not Dispose-ed. I'll give a list and you can try to find them and fix
them:

1. NetworkInformation.AccessPointCollection near line 234 there should be a
call to ie.Dispose().

2. NetworkInformation.WirelessZeroConfigNetworkInterface near line 102, in
the if ( retVal > 0 ) case, entry.Dispose() needs to be called, as it is in
the other case.

3. NetworkInformation.WirelessZeroConfigNetworkInterface near line 117, in
the if (WZC.QueryAdapter(this.Name, out entry) == 0) case, there are
actually two bugs. You need to add a line like this:

// PGT: Need to check the state of the flag to determine
// what to return.
bool ret = ((entry.dwCtlFlags & (uint)INTF_FLAGS.INTF_FALLBACK) != 0);

followed by one like this:

// PGT: Need to free it!
entry.Dispose();

That's what I've spotted so far. The rest of the INTF_ENTRY uses, at least,
seem to be handled correctly. I'm leaving a little program running for a
while to see if there are any other obvious leaks.

Paul T.

"Paul G. Tobey [eMVP]" <p space tobey no spam AT no instrument no spam DOT
com> wrote in message news:%[email protected]...
Hmmm. Well, I'll try to take a look at it and at least suggest a fix for
the interim in the field. If .net CFer has the code, that should allow
things to be fixed for now, at least.

Enjoy the vacation!
Paul T.

Chris Tacke said:
And, unfortunately, I'm leaving on vacation in an hour, so the earliest
it's going to happen on my end would be August.


--

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


"Paul G. Tobey [eMVP]" <p space tobey no spam AT no instrument no spam
DOT com> wrote in message news:%[email protected]...
OK, it appears to me that there may a missing deallocation for the raw
data portion of the INTF_ENTRY struct in the AccessPointCollection
methods for the allocation near line 173. I think that Chris would have
to identify and apply a fix.

Paul T.

On Jul 15, 4:13 pm, "Paul G. Tobey [eMVP]" <p space tobey no spam AT
no instrument no spam DOT com> wrote:
Are you, by any chance, not disposing of something, an AccessPoint or
an
Adapter, when you're done with it? That sounds like a case where a
large
structure that one of those classes allocated to get SSID information
might
not get thrown away unless you call Dispose(), Close() or something of
that
nature, possibly because you are storing things in an array for later
use or
something.

Paul T.


On Jul 11, 10:48 pm, "Chris Tacke, MVP" <ctacke.at.opennetcf.dot.com>
wrote:





Have you tried anything newer? We're already at version 2.3, and we
made a
lot of changes and did a lot of fixes around WiFi in the 2.3 release.

--

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



Hello All, I think I have narrowed a memory leak down to this code.
I
am using OpenNETCF.Net Version 2.1.
As you can see, I am really doing nothing in the following code
accept
getting the current adapters preferredAccessPoint collection. I
plan
on digging into this code this weekend/next week but wanted to
throw
it out on the forum in hopes others have a solution. The pattern
appears to be a 200K drop in available virtual every ~ 15 calls to
the
function that runs the code below. A perfmon diff shows no
accumulations of objects in managed code. It will run until the exe
eats up all 32MB.

// Add other preferred access points
foreach (AccessPoint accessPoint in
currentAdapter.PreferredAccessPoints)
{
if (!results.ContainsKey
(accessPoint.Name))
{
try
{
results.Add
(accessPoint.Name,null);
}
catch { }
}
}

I did a quick search on this and only found the following from
Chris
T. The difference is this guy was using NetCF ver 1.4 and the 2.1
version I am using does not have a reference to ndisAccess and the
class is only 229 lines. it does have a RefreshList function with
no
need to close any Handles.
-----------

There is a leak in AccessPointCollection, near line 329 in
RefreshList
().
You need to add the following:

FileEx.CloseHandle( ndisAccess );

before leaving that method.

I'm unable to find anything else actually leaking. All of the
managed
arrays, I would think, should be getting freed when the garbage
collector
decides that it's time. There's very little, if any, unmanaged
memory
allocated when that series of steps is performed, so there isn't a
lot
of
room for things to get lost.
-------------- Hide quoted text -

- Show quoted text -

Prelim results is that it acts the same between 2.3 and 2.1, still
seems to be dropping in 200K buckets.

I will know more tomorrow.- Hide quoted text -

- Show quoted text -

Hello Paul,
I am using INetworkInterface, WirelessZeroConfigNetworkInterface, and
NetworkInformation.AccessPoint and do not see a close or dispose
function on any of them.?
 
Hmmm.  Well, I'll try to take a look at it and at least suggest a fix for
the interim in the field.  If .net CFer has the code, that should allow
things to be fixed for now, at least.

Enjoy the vacation!
Paul T.

"Chris Tacke, MVP" <ctacke.at.opennetcf.dot.com> wrote in message

And, unfortunately, I'm leaving on vacation in an hour, so the earliest
it's going to happen on my end would be August.

Chris Tacke, Embedded MVP
OpenNETCF Consulting
Giving back to the embedded community
http://community.OpenNETCF.com
"Paul G. Tobey [eMVP]" <p space tobey no spam AT no instrument no spam DOT
com> wrote in messagenews:%[email protected]...
OK, it appears to me that there may a missing deallocation for the raw
data portion of the INTF_ENTRY struct in the AccessPointCollection
methods for the allocation near line 173.  I think that Chris would have
to identify and apply a fix.
Paul T.
On Jul 15, 4:13 pm, "Paul G. Tobey [eMVP]" <p space tobey no spam AT
no instrument no spam DOT com> wrote:
Are you, by any chance, not disposing of something, an AccessPoint oran
Adapter, when you're done with it? That sounds like a case where a large
structure that one of those classes allocated to get SSID information
might
not get thrown away unless you call Dispose(), Close() or something of
that
nature, possibly because you are storing things in an array for later
use or
something.
Paul T.
On Jul 11, 10:48 pm, "Chris Tacke, MVP" <ctacke.at.opennetcf.dot.com>
wrote:
Have you tried anything newer? We're already at version 2.3, and we
made a
lot of changes and did a lot of fixes around WiFi in the 2.3 release.
--
Chris Tacke, Embedded MVP
OpenNETCF Consulting
Giving back to the embedded communityhttp://community.OpenNETCF.com

Hello All, I think I have narrowed a memory leak down to this code.
I
am using OpenNETCF.Net Version 2.1.
As you can see, I am really doing nothing in the following code
accept
getting the current adapters preferredAccessPoint collection. I plan
on digging into this code this weekend/next week but wanted to throw
it out on the forum in hopes others have a solution. The pattern
appears to be a 200K drop in available virtual every ~ 15 calls to
the
function that runs the code below. A perfmon diff shows no
accumulations of objects in managed code. It will run until the exe
eats up all 32MB.
// Add other preferred access points
foreach (AccessPoint accessPoint in
currentAdapter.PreferredAccessPoints)
{
if (!results.ContainsKey
(accessPoint.Name))
{
try
{
results.Add
(accessPoint.Name,null);
}
catch { }
}
}
I did a quick search on this and only found the following from Chris
T. The difference is this guy was using NetCF ver 1.4 and the 2.1
version I am using does not have a reference to ndisAccess and the
class is only 229 lines. it does have a RefreshList function withno
need to close any Handles.
-----------
There is a leak in AccessPointCollection, near line 329 in
RefreshList
().
You need to add the following:
FileEx.CloseHandle( ndisAccess );
before leaving that method.
I'm unable to find anything else actually leaking. All of the
managed
arrays, I would think, should be getting freed when the garbage
collector
decides that it's time. There's very little, if any, unmanaged
memory
allocated when that series of steps is performed, so there isn't a
lot
of
room for things to get lost.
-------------- Hide quoted text -
- Show quoted text -
Prelim results is that it acts the same between 2.3 and 2.1, still
seems to be dropping in 200K buckets.
I will know more tomorrow.- Hide quoted text -
- Show quoted text -
Hello Paul,
I am using INetworkInterface, WirelessZeroConfigNetworkInterface, and
NetworkInformation.AccessPoint and do not see a close or dispose
function on any of them.?- Hide quoted text -

- Show quoted text -

It looks like the RAW_DATA struct is not being disposed in all the
places it is being used. Going to look at 2.1.
 
There are actually a few places where INTF_ENTRY structures are allocated
but not Dispose-ed.  I'll give a list and you can try to find them and fix
them:

1. NetworkInformation.AccessPointCollection near line 234 there should bea
call to ie.Dispose().

2. NetworkInformation.WirelessZeroConfigNetworkInterface near line 102, in
the if ( retVal > 0 ) case, entry.Dispose() needs to be called, as it is in
the other case.

3. NetworkInformation.WirelessZeroConfigNetworkInterface near line 117, in
the if (WZC.QueryAdapter(this.Name, out entry) == 0) case, there are
actually two bugs.  You need to add a line like this:

// PGT: Need to check the state of the flag to determine
// what to return.
bool ret = ((entry.dwCtlFlags & (uint)INTF_FLAGS.INTF_FALLBACK) != 0);

followed by one like this:

// PGT: Need to free it!
entry.Dispose();

That's what I've spotted so far.  The rest of the INTF_ENTRY uses, at least,
seem to be handled correctly.  I'm leaving a little program running fora
while to see if there are any other obvious leaks.

Paul T.

"Paul G. Tobey [eMVP]" <p space tobey no spam AT no instrument no spam DOT



com> wrote in messagenews:%[email protected]...
Hmmm.  Well, I'll try to take a look at it and at least suggest a fixfor
the interim in the field.  If .net CFer has the code, that should allow
things to be fixed for now, at least.
Enjoy the vacation!
Paul T.
Chris Tacke said:
And, unfortunately, I'm leaving on vacation in an hour, so the earliest
it's going to happen on my end would be August.
--
Chris Tacke, Embedded MVP
OpenNETCF Consulting
Giving back to the embedded community
http://community.OpenNETCF.com
"Paul G. Tobey [eMVP]" <p space tobey no spam AT no instrument no spam
DOT com> wrote in messageOK, it appears to me that there may a missing deallocation for the raw
data portion of the INTF_ENTRY struct in the AccessPointCollection
methods for the allocation near line 173.  I think that Chris wouldhave
to identify and apply a fix.
Paul T.
On Jul 15, 4:13 pm, "Paul G. Tobey [eMVP]" <p space tobey no spam AT
no instrument no spam DOT com> wrote:
Are you, by any chance, not disposing of something, an AccessPoint or
an
Adapter, when you're done with it? That sounds like a case where a
large
structure that one of those classes allocated to get SSID information
might
not get thrown away unless you call Dispose(), Close() or something of
that
nature, possibly because you are storing things in an array for later
use or
something.
Paul T.
On Jul 11, 10:48 pm, "Chris Tacke, MVP" <ctacke.at.opennetcf.dot.com>
wrote:
Have you tried anything newer? We're already at version 2.3, and we
made a
lot of changes and did a lot of fixes around WiFi in the 2.3 release.
--
Chris Tacke, Embedded MVP
OpenNETCF Consulting
Giving back to the embedded communityhttp://community.OpenNETCF.com

Hello All, I think I have narrowed a memory leak down to this code.
I
am using OpenNETCF.Net Version 2.1.
As you can see, I am really doing nothing in the following code
accept
getting the current adapters preferredAccessPoint collection. I
plan
on digging into this code this weekend/next week but wanted to
throw
it out on the forum in hopes others have a solution. The pattern
appears to be a 200K drop in available virtual every ~ 15 calls to
the
function that runs the code below. A perfmon diff shows no
accumulations of objects in managed code. It will run until the exe
eats up all 32MB.
// Add other preferred access points
foreach (AccessPoint accessPoint in
currentAdapter.PreferredAccessPoints)
{
if (!results.ContainsKey
(accessPoint.Name))
{
try
{
results.Add
(accessPoint.Name,null);
}
catch { }
}
}
I did a quick search on this and only found the following from
Chris
T. The difference is this guy was using NetCF ver 1.4 and the 2.1
version I am using does not have a reference to ndisAccess and the
class is only 229 lines. it does have a RefreshList function with
no
need to close any Handles.
-----------
There is a leak in AccessPointCollection, near line 329 in
RefreshList
().
You need to add the following:
FileEx.CloseHandle( ndisAccess );
before leaving that method.
I'm unable to find anything else actually leaking. All of the
managed
arrays, I would think, should be getting freed when the garbage
collector
decides that it's time. There's very little, if any, unmanaged
memory
allocated when that series of steps is performed, so there isn'ta
lot
of
room for things to get lost.
-------------- Hide quoted text -
- Show quoted text -
Prelim results is that it acts the same between 2.3 and 2.1, still
seems to be dropping in 200K buckets.
I will know more tomorrow.- Hide quoted text -
- Show quoted text -
Hello Paul,
I am using INetworkInterface, WirelessZeroConfigNetworkInterface, and
NetworkInformation.AccessPoint and do not see a close or dispose
function on any of them.?- Hide quoted text -

- Show quoted text -


Example: in WLANConfigurationList constructor
RAW_DATA data is set as a class variable and never disposed.
 
Yep. Please report all of these things, including the ones that I
identified, to OpenNETCF so that Chris will have the list. Obviously, a
global effort needs to be made to find everywhere RAW_DATA is used and make
sure that all of the instances are freed in one way or another.

Paul T.

There are actually a few places where INTF_ENTRY structures are allocated
but not Dispose-ed. I'll give a list and you can try to find them and fix
them:

1. NetworkInformation.AccessPointCollection near line 234 there should be
a
call to ie.Dispose().

2. NetworkInformation.WirelessZeroConfigNetworkInterface near line 102, in
the if ( retVal > 0 ) case, entry.Dispose() needs to be called, as it is
in
the other case.

3. NetworkInformation.WirelessZeroConfigNetworkInterface near line 117, in
the if (WZC.QueryAdapter(this.Name, out entry) == 0) case, there are
actually two bugs. You need to add a line like this:

// PGT: Need to check the state of the flag to determine
// what to return.
bool ret = ((entry.dwCtlFlags & (uint)INTF_FLAGS.INTF_FALLBACK) != 0);

followed by one like this:

// PGT: Need to free it!
entry.Dispose();

That's what I've spotted so far. The rest of the INTF_ENTRY uses, at
least,
seem to be handled correctly. I'm leaving a little program running for a
while to see if there are any other obvious leaks.

Paul T.

"Paul G. Tobey [eMVP]" <p space tobey no spam AT no instrument no spam DOT



com> wrote in messagenews:%[email protected]...
Hmmm. Well, I'll try to take a look at it and at least suggest a fix for
the interim in the field. If .net CFer has the code, that should allow
things to be fixed for now, at least.
Enjoy the vacation!
Paul T.
Chris Tacke said:
And, unfortunately, I'm leaving on vacation in an hour, so the earliest
it's going to happen on my end would be August.
--
Chris Tacke, Embedded MVP
OpenNETCF Consulting
Giving back to the embedded community
http://community.OpenNETCF.com
"Paul G. Tobey [eMVP]" <p space tobey no spam AT no instrument no spam
DOT com> wrote in messageOK, it appears to me that there may a missing deallocation for the raw
data portion of the INTF_ENTRY struct in the AccessPointCollection
methods for the allocation near line 173. I think that Chris would
have
to identify and apply a fix.
Paul T.
On Jul 15, 4:13 pm, "Paul G. Tobey [eMVP]" <p space tobey no spam AT
no instrument no spam DOT com> wrote:
Are you, by any chance, not disposing of something, an AccessPoint or
an
Adapter, when you're done with it? That sounds like a case where a
large
structure that one of those classes allocated to get SSID information
might
not get thrown away unless you call Dispose(), Close() or something
of
that
nature, possibly because you are storing things in an array for later
use or
something.
Paul T.
On Jul 11, 10:48 pm, "Chris Tacke, MVP" <ctacke.at.opennetcf.dot.com>
wrote:
Have you tried anything newer? We're already at version 2.3, and we
made a
lot of changes and did a lot of fixes around WiFi in the 2.3
release.
--
Chris Tacke, Embedded MVP
OpenNETCF Consulting
Giving back to the embedded communityhttp://community.OpenNETCF.com

Hello All, I think I have narrowed a memory leak down to this
code.
I
am using OpenNETCF.Net Version 2.1.
As you can see, I am really doing nothing in the following code
accept
getting the current adapters preferredAccessPoint collection. I
plan
on digging into this code this weekend/next week but wanted to
throw
it out on the forum in hopes others have a solution. The pattern
appears to be a 200K drop in available virtual every ~ 15 calls
to
the
function that runs the code below. A perfmon diff shows no
accumulations of objects in managed code. It will run until the
exe
eats up all 32MB.
// Add other preferred access points
foreach (AccessPoint accessPoint in
currentAdapter.PreferredAccessPoints)
{
if (!results.ContainsKey
(accessPoint.Name))
{
try
{
results.Add
(accessPoint.Name,null);
}
catch { }
}
}
I did a quick search on this and only found the following from
Chris
T. The difference is this guy was using NetCF ver 1.4 and the 2.1
version I am using does not have a reference to ndisAccess and
the
class is only 229 lines. it does have a RefreshList function with
no
need to close any Handles.
-----------
There is a leak in AccessPointCollection, near line 329 in
RefreshList
().
You need to add the following:
FileEx.CloseHandle( ndisAccess );
before leaving that method.
I'm unable to find anything else actually leaking. All of the
managed
arrays, I would think, should be getting freed when the garbage
collector
decides that it's time. There's very little, if any, unmanaged
memory
allocated when that series of steps is performed, so there isn't
a
lot
of
room for things to get lost.
-------------- Hide quoted text -
- Show quoted text -
Prelim results is that it acts the same between 2.3 and 2.1, still
seems to be dropping in 200K buckets.
I will know more tomorrow.- Hide quoted text -
- Show quoted text -
Hello Paul,
I am using INetworkInterface, WirelessZeroConfigNetworkInterface, and
NetworkInformation.AccessPoint and do not see a close or dispose
function on any of them.?- Hide quoted text -

- Show quoted text -


Example: in WLANConfigurationList constructor
RAW_DATA data is set as a class variable and never disposed.
 
Back
Top