Memoryleak - garbage collector / WinCe 5.0 / CF 2.0

  • Thread starter Thread starter Chriz
  • Start date Start date
C

Chriz

Hello,

I´m programming a C# application on Windows CE 5.0 and CF 2.0.
This application should run permanently (24h/7days). I realized that the
garbage collector (gc) does not free all the allocated memory. Thus after a
while (a few days) an OutOfMemory-exception occurs.

I wrote a small test application:
In a function I created a form (Form frm = new Form();) which is shown by
ShowDialog(). I figured out that after closing this form and leaving the
function, some memory fragments won´t be freed by the gc (>= 4KB).
This behavior occurs when member variables (lists, bitmaps,...) are declared
in this created form. If I declare this member variables within a function
(stack) the memory will be totally freed.

As I can see there is a bug in Visual Studio 2005. The object ‘components‘
is created, but never used by the designer. The overridden dispose-function
in the designer.cs frees all the objects in the componets-object but – as I
said – this object is never beeing used.

I customized all overrides of dispose() in the designer.cs:

/// <summary>
/// Clean up any resources being used.
/// </summary>
/// <param name="disposing">true if managed resources should be disposed;
otherwise, false.</param>
protected override void Dispose(bool disposing)
{
if (disposing && this.Controls != null)
{
this.components = new System.ComponentModel.Container();
foreach (Control o in this.Controls)
components.Add(o);
components.Dispose();
}
base.Dispose(disposing);
}

Now, most of the memory is freed but periodically there still remain some
fragments in the memory (>=4KB up to 64KB (?)).

I also noticed that running this application on a desktop pc with the “big“
:NET framework – no memoryloak persists!


Has anyone noticed the same behaviour and/or found a solution for it?

Does anyone have experience with applications running round the clock on
Windows CE / CF 2.0?

Are there bugs in the gc on compact framework?


Thanks for your help, best regards Chris
 
Yes, we have applications that run 24/7 with CF 2.0 (written in Studio 05,
but I don't think that matters) and have not seen any leak. I doubt there
is a problem with the GC, my bet is that there's a problem in your code with
some object not having all of its resources freed. Keep in mind that
calling GC.Collect does *not* implicitly release memory back to the OS.
That happens only during compaction.


--

Chris Tacke, Embedded MVP
OpenNETCF Consulting
Giving back to the embedded community
http://community.OpenNETCF.com
 
Hi.
I have an app that leaks managed bytes over time similar to what is
described on a CE 5.0, .NET CF 2.0 SP1 system. It will leak to exhaustion
in about 9 hours in a certain configuration.

With no code changes except to target .NET CF 3.5 in my application, the
leak goes away.

It also does not leak on .NET FF on XP.

I wish I had a simple reproduction, but I do not (3rd party code is involved
with the reproduction). However, I'd be interested to hear:

1) Is there a known fix to a GC mem leak issue in .NETCF 3.5 over .NETCF
2.0?
2) If there is, can someone provide a link to where to read about it?
3) If not, is there an explanation for seeing the same code leak and not
leak on the 3 platforms I describe above?

My method for seeing the leak is looking at the 'Managed Bytes In Use After
GC' counter in RPM (on CE). On XP I can use the System.GC.GetTotalMemory
call.

In all cases, the memory number bounces up and down maybe +/- 20K and up to
+/- 1MB. But in the leak case, the average number climbs from about 2.7MB
to ~19MB when I finally see an OutOfMemory exception and sometimes
MissingMethodException (presumably becuase there's no memory to place JITted
code that has been pitched!).

Thanks for any help that anyone can provide!

Regards,
Wil
 
I'm not sure.

I assume this means building with a .NETCF 2.0 target, then running on a CE
platform that only has .NET CF 3.5?

If so, this will take me a while to answer, as part of my problem is getting
a good nk.bin build with .NETCF 3.5. (The nk.bin that I do build with the
..NETCF 3.5 component complains when I run a program that targets .NETCF 3.5
that not all of the pieces for .NET are present.)

Right now, I'm relying on VS2008 deploying .NETCF 3.5 to even test that the
memory leak is gone.

So, I guess I need to build an nk.bin that omits .NETCF 2.0 (and 3.5), then
deploy 3.5 with VS. Then run my program that was built targeting 2.0 to try
out what you're suggesting?

Does that all sound right?

Or can this be done with a manifest file?

Thanks,
Wil
 
Chris,
Using the following config file seems to do the trick for getting 3.5
loaded with code built targeting 2.0:

<configuration>
<startup>
<supportedRuntime version="v3.5.0"/>
</startup>
</configuration>

I can verify this by looking at CE Remote Process viewer, and seeing
mscoree3_5.dll loaded as opposed to mscoree2_0.dll with the presence of the
..config file.

Watching the 'Managed Bytes In Use After GC' counter, it appears the memory
usage stays relatively constant over time in what was problem case.

So, the answer to your question is: No - I don't see the memory issue when
running with 3.5 after targeting 2.0 at build time.
If I go back to 2.0 on the same bits (remove the .config file) and run
again, I see the memory issue return.

Does this answer indicate something about where the problem lies?

Thanks for your help.

- Wil
 
Seeing as whatever the issue is, it appears to be fixed in 3.5, the support
case I should open is on my issue around not being able to get a good nk.bin
with .NETCF 3.5 in it. :-) (Correct me if I'm wrong, but I'm guessing MS
won't bother to fix a bug in 2.0 when it is already fixed in 3.5.)

Thanks again for you suggestions.

- Wil
 
Back
Top