Re: memory leak

Chris,

Thanks for posting this info - I'm glad I found the problem, I definitely
learned from the info the CF team came back with. Having said that:

1. Is it just my natural "Defensive Coding" nature or does anyone else find
this really really scarey? For example, it seems as though, since MSFT have
already said that they will fix this problem, that we're going to have to
check for and code for specific CF versions. Secondly, performance is
dependant on which constructor gets used?!? Thirdly, exception handling and
GC behavior is dependant on which constructor gets used. So now we're left
to do our own memory management and we have no idea how our performance
will/may take a hit when users change to a new CF.

2. Chris, do you know if the information you posted is specific for CF 1,
CF 2, or both? (I have seen the same (incorrect) behavior on both)

3. When do they plan on fixing it? How do they plan on fixing it? How
will their fix impact an application's performance?

4. What other classes in CF (or Full) exhibit such odd (and incorrect)
behavior? Do the CF Team know of any that might jump up and bite us like
Bitmap did to me?

5. Why did they do it like this?

6. When will I run out of video RAM? i.e. I'm assuming that I could still
have lots of 'free memory', yet a "new Bitmap (w, h)" call will fail when
video RAM is exhausted. This will throw an OOM exception (perhaps
ArgumentException on Full Framework) when I have a ton of virtual memory
left because it may be allocating memory in the 'dedicated video ram'.

This is more than an implementation bug, this is a fundamental design flaw
in the CF (and Full Framework which is fixed in its latest version) and one
which goes against the fundamental nature of VM/GC notion. Again, I love
what the CF Team have given us, but IMHO this is a serious failure of the
design, implementation, and testing of .NET at Microsoft.

As always, comments please and correct me if I'm wrong.

Again for the record, I love C#, CF, etc etc etc, but I call it as I see it.

Hilton



"<ctacke/>" <ctacke[@]opennetcf[dot]com> wrote in message
news:%23QEqDjhxGHA.1872@xxxxxxxxxxxxxxxxxxxxxxx
And here's what I found out:

http://blog.opennetcf.org/ctacke/PermaLink,guid,987041fc-2e13-4bab-930a-f79021225b74.aspx


--
Chris Tacke
OpenNETCF Consulting
Managed Code in the Embedded World
www.opennetcf.com
--


"Hilton" <nospam@xxxxxxxxxx> wrote in message
news:F3dFg.16148$o27.9790@xxxxxxxxxxxxxxxxxxxxxxxxxxxxx
That's not fair, you can't say "the behavior is not as simple as either
of us originally thought" and not tell me. :) Just kidding. Seriously
though, I'd love to find out more about this issue because everything
we've seen, it seems like the VM doesn't garbage collect before throwing
an OOM on .NET 1.1 and CF. On a scale of 1 to 10, that's pretty serious.
Again, I'm hoping I'm wrong and it is something simple.

Anything to add here or blog?

Thanks,

Hilton


"<ctacke/>" <ctacke[@]opennetcf[dot]com> wrote in message
news:%23K$Iel%23vGHA.1436@xxxxxxxxxxxxxxxxxxxxxxx
Just FYI I'm running some tests on this and talking with the CF team
about what I'm seeing - the behavior is not as simple as either of us
originally thought. Once I have some definitive info I'll blog it.


--
Chris Tacke
OpenNETCF Consulting
www.opennetcf.com
--



"Hilton" <nospam@xxxxxxxxxx> wrote in message
news:Xa_Dg.6860$1f6.2623@xxxxxxxxxxxxxxxxxxxxxxxxxxxxx
I find it interesting that the exceptions are different too (desktop
versus CF).

Ilya or anyone else from MSFT want to jump in here???

Hilton


"<ctacke/>" <ctacke_AT_OpenNETCF_com> wrote in message
news:%23Rq%23Sw5vGHA.3392@xxxxxxxxxxxxxxxxxxxxxxx
Sounds like an OOM on a bitmap allocation isn't triggering a GC like
it should. If that's the case, it's certainly a bug.

-Chris


"Hilton" <nospam@xxxxxxxxxx> wrote in message
news:gOTDg.688$q63.333@xxxxxxxxxxxxxxxxxxxxxxxxxxxxx
Chris,

I did some more testing. Using CF 2.0 makes no difference - still
throws exception. Adding GC.Collect() causes the memory to drop, app
keeps running both on desktop and PPC. So, the OOM is not causing a
GC.Collect() because that would cause the OOM condition to go away,
the "new" to then succeed etc. Looks like they fixed this on the
desktop in a later version of the .NET Framework according to Doug's
post. I'm still running 1.1.4322.2032.

Chris, do you agree? (given that my findings stated above are
correct)

Hilton


"<ctacke/>" <ctacke_AT_OpenNETCF_com> wrote in message
news:edV$yhzvGHA.4688@xxxxxxxxxxxxxxxxxxxxxxx
I don't have Studio on this machine. What happens if you put a
GC.Collect in the exception handler, then allow it to continue?

-Chris




"Hilton" <nospam@xxxxxxxxxx> wrote in message
news:f9PDg.9744$FN2.6734@xxxxxxxxxxxxxxxxxxxxxxxxxxxxx
Chris,

I agree there is a misunderstanding of the fundamentals. Run the
short program below and see for yourself. On the Pocket PC, the
device runs out of memory and throws an OutOfmemoryException; one
the desktop, it used all 2GB that was free when it started and
threw a "System.ArgumentException: Invalid parameter used" on the
"new Bitmap" line.

Now do you still agree that the GC will cleanup Bitmap objects?
Sorry Chirs, it doesn't happen as you say cause the "new Bitmap"
code below that *does not keep a reference to each bitmap* ran out
of memory.

Hilton
----------------------------
Create a form, add a timer with the code:
this.timer = new Timer ();
this.timer.Interval = 250;
this.timer.Tick += new EventHandler(timer_Tick);
this.timer.Enabled = true;

then add this method:

private void timer_Tick(object sender, EventArgs ea)
{
bool error = false;

this.timer.Enabled = false;

try
{
this.bmp = new Bitmap (1024, 1024);

this.Text = DateTime.Now.ToLongTimeString();
}
catch (Exception e)
{
error = true;

using (System.IO.StreamWriter sw = new
System.IO.StreamWriter ("exp.txt"))
{
sw.WriteLine (e.ToString());
}

this.Text = "Exception";
}
this.timer.Enabled = !error;
}
---------------

"<ctacke/>" <ctacke[@]opennetcf[dot]com> wrote in message
news:esCAJeyvGHA.1772@xxxxxxxxxxxxxxxxxxxxxxx
I think there's still a misundestanding of the fundamentals.

Dispose is not a required call - it is optional. Your application
knows better than anything else when you are done with resources,
and at that point, you can call Dispose to let the GC know that
you are done with those resources. These classes are written so
that during that call, managed resources are released.

If you don't call Dispose, that's fine. When the GC goes to
collect, it will walk the roots. It will see that the Bitmap has
no references, and it will then run Dispose on it for you and move
it to the Finalizer queue. On the _next_ GC cycle, the actual
Bitmap will be released. This all happens automatically, without
your intervention. It just happens late - when the GC is
collecting - likely because you're low on resources.

Calling Dispose is simply a good idea because it allows the
release of system resources when the app is done with them rather
than waiting for the system to GC.

For more info, take a look at my presentation from MEDC:
http://blog.opennetcf.org/ctacke/PermaLink,guid,e806d34b-a8d8-45e8-9de8-bec58818fafe.aspx


--
Chris Tacke
OpenNETCF Consulting
www.opennetcf.com
--




"Hilton" <nospam@xxxxxxxxxx> wrote in message
news:0lMDg.8207$9T3.540@xxxxxxxxxxxxxxxxxxxxxxxxxxxxx
Chris,

This has come up before, so no use beating a dead horse (I'm the
guilty one here since I first mentioned it), but here are some
points which hopefully helps to explain my comments:

1. If ALL objects were required to be disposed, would that be a
design bug? Of course it would, it is .NET with a garbage
collector.
2. Then why do we have to dispose Bitmap? Because MS took a
short-cut. Note that MS have already said that they will *fix*
this problem.
3. Another bad choice IMHO was to put Bitmap in System.Drawing -
that is the wrong place since you don't only draw with Bitmap and
a Bitmap image should not be directly associated with UI. It
should be in System.Image or something similar. Here is an
example in pseudo-C#: Imagine you wanted to convert all BMP files
to PNG files using a command line EXE. It should simply be "using
System.Image; foreach BMPFile in directory { new Bitmap
(BMPFile).SaveAs (PNG); }" but instead we have to include
System.Drawing (UI stuff), plus we need to do our own memory
management (the code above would have a huge memory leak).
4. FWIW: I think Dispose should be an optional call, not a
mandatory call required to prevent a memory leak.
5. There are other things like why they called it SortedList
instead of SortedMap etc... (unrelated to Bitmap)

Bottom line, I love C#, work with it day in and day out,
absolutely darn amazing on Pocket PCs etc, so don't think for a
second I'm bashing the C# language, the .NET team, or Microsoft.
Just sometimes, bad design decisions get made (*IHMO*).

Hilton


"<ctacke/>" <ctacke[@]opennetcf[dot]com> wrote in message
news:eWyovzwvGHA.3372@xxxxxxxxxxxxxxxxxxxxxxx
The same has to be done on the full framework, and again, it's
not a bug.

-Chris


"Hilton" <nospam@xxxxxxxxxx> wrote in message
news:gvJDg.12218$gY6.3863@xxxxxxxxxxxxxxxxxxxxxxxxxxxxx
I bet you're doing something like "xyz.Image = new Bitmap
(...)" - right? If so, there is a bug in the CF
design/implementation (IMHO) that forces you to do your own
memory management; i.e. for every "new Bitmap ()" you do, you'll
need to do a "Dispose()" on that bitmap when you're done with it
(aka malloc and free).

Let us know if that helps,

Hilton


"raju" <ponnurajs@xxxxxxxxx> wrote in message
news:1155390117.643466.283160@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
Hai

In my device application (windows ce application using
vb.net), i
am having nearly 25 forms. Moving from one form to another
form, just i
am hide the first form and show the second form.

Each form I am having some picturebox, putting images for
that
picturebox using imagelist.

My application works very well. But, if the application
running
contineously for 1 or 2 hours, i am getting error such as "low
memory".


when i checked the memory, it will automatically
increasing when
the application is in running. First initial time, it occupies
22 mb
and it increasing upto 32 to 35 mb.

What is the reason for this? and how to correct this
memory
problem.

Regards
Raju.



























.

Relevant Pages

  • Re: memory leak
    ... explicit GC and it worked just as it should - memory climbed up to near 2GB ... Now do you still agree that the GC will cleanup Bitmap objects? ... Dispose is not a required call - it is optional. ... those resources. ...
    (microsoft.public.dotnet.framework.compactframework)
  • Re: memory leak
    ... I am pretty diligent when it comes to disposing unmanaged resources. ... If an OOM occurs when attempting to create a bitmap from a binary ... making it appear that the device has more available memory. ... Dispose is not a required call - it is optional. ...
    (microsoft.public.dotnet.framework.compactframework)
  • Re: memory leak
    ... Adding GC.Collectcauses the memory to drop, ... Now do you still agree that the GC will cleanup Bitmap objects? ... Dispose is not a required call - it is optional. ... those resources. ...
    (microsoft.public.dotnet.framework.compactframework)
  • Re: memory leak
    ... explicit GC and it worked just as it should - memory climbed up to near ... Now do you still agree that the GC will cleanup Bitmap objects? ... Dispose is not a required call - it is optional. ... those resources. ...
    (microsoft.public.dotnet.framework.compactframework)
  • Re: memory leak
    ... explicit GC and it worked just as it should - memory climbed up to near ... Now do you still agree that the GC will cleanup Bitmap objects? ... Dispose is not a required call - it is optional. ... done with those resources. ...
    (microsoft.public.dotnet.framework.compactframework)