Re: AccessPoint accessPoint in currentAdapter.PreferredAccessPoints Memory Leak

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.

".net CF'er" <jderu...@xxxxxxxxx> wrote in message

news:0efca325-ad8b-4a59-ad71-4ea3e509eaba@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
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

".net CF'er" <jderu...@xxxxxxxxx> wrote in message

news:13a2a82a-8620-475f-8fd6-3c3d48b9c204@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

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.?
.

Relevant Pages

  • Re: Fibre Channel Array Troubles.
    ... Subject: Fibre Channel Array Troubles. ... two hbas and I ran diagnostics today and it ... ent0 Available 1L-08 10/100 Mbps Ethernet PCI Adapter II ... ide0 Available 1G-19 ATA/IDE Controller Device ...
    (AIX-L)
  • Block sizes for Tru64 5.1Bv4
    ... We supplied an external 5TB array ... SCSI HBA is the KZPEA-DB U160 Dual Channel adapter. ... fine in the SRM (6 logicals on our external raid array) ... entities other than the intended recipient is prohibited. ...
    (comp.unix.tru64)
  • Problems with 2G HBA
    ... Adapter, and 3510FC Array. ... I installed all the necessary patches, ...
    (SunManagers)
  • Arena 8600 array on Ultra320 adapter
    ... or using a PCI Dual Channel Ultra2 SCSI Adapter ... PCI-X Dual Channel Ultra 320 SCSI adapter in an IBM ... I have tried a different but identical array, ...
    (comp.unix.aix)
Loading