More OutOfMemoryException Problems

[Guest]

I am getting another OutOfMemory problem which seams a little strange.

I have only tested in debug as yet, so this may be significant, but
basically I have a big app, which uses one form and adds and remove controls
on the form to make up to about 50 different forms according to
configuration. I have used one form to make sure things are both fast and
efficient with memory and this fundamentally works well.
I have found that I am getting an OutOfMemoryException sometimes when I am
creating controls to polace on the form.
I have looked into the Garbage Collector (GC) a bit so I checked on memory
GetTotalMemory and it said 4.7Mb, which is about what I would expect. I am
using a 128Mb XDAIIs, and I have about 60Mb free for programs and 30Mb free
for storage.

Should I be getting this message.
Does GC.GetTotalMemory reflect the Total Memory Used, or does it not include
fragmentation, work differently with DLLs or anything.
I have also read some stuff about 64Kb methods causing OOM Exceptions, but
that doesnt mean anything to me.
I have also read about the Systems Out Of Memory Dialog, but I think this is
a myth, as I have never seen one.

I am sure that I can drop a load of stuff behind me if I want, but I was
hoping to leave that until the next version. MVPs - Help me move to VS2005 by
nailing this issue.
Thanks in advance.

 

[Guest]

Once again I must reinterate that in CE, having X MB or "free memory"
doesn't mean you app has that much available. There is a 32MB process
limit, and fragmentation and unmanaged DLL allocations on 64k boundaries can
seriously decrease the "availability" of memory. I highly recommend 2
things:

1. Read Boling's paper on advanced memory management in CE (MSDN)
2. Dispose of *anything* that has a Dispose method exposed as soon as
possible in your code.

-Chris

 

[Chris Botha]

An idea may be to re-use the controls instead of creating them every time.
So have something like a TextBoxManager, it has an ArrayList containing
textboxes, ask it for a textbox when you need one, if one exists in the list
it gives it else it creates a new one. When you remove a control from the
form give it back. Do the same for other controls.

 

[Guest]

A control manager is something I have considered. However I felt that the
management of all that might create more problems than it solves, but I like
it anyway.

Do you think that this will reduce the fragmentation? If I am not creating
asdn disposing of the controls, will this reduce the fragmentation of the
heap. A cause of 75% memory wastage if the earlier reply is accurate.

Thanks very much both of you.

 

[Chris Botha]

If creating/disposing the controls causes the problem then this will fix it.
I am not sure if fragmentation is your problem, but if creating/disposing
controls causes fragmentation then this will reduce fragmentation.

 

[Chris Tacke, eMVP]

You can test the fragmentation theory by manually calling a GC.Collect. Not
usually recommended, but it'll definitely let you know.

--
Chris Tacke
Co-founder
OpenNETCF.org
Are you using the SDF? Let's do a case study.
Email us at d c s @ o p e n n e t c f . c o m
http://www.opennetcf.org/donate

 

[Guest]

I am already running GC.Collect. This then dovetails with GC.GetTotalMemory,
which typically returns around 4Mb. In addition around the same time as I get
the OOutOfMemroyException, I seam to be also getting an
InvalidOperationException on a collection that I use to move a set of
controls around. I say 'about' as it is about the 40th 'form' (set of
controls) that I display.

I assume that the GC will do a better job of defragmentation than 85%, and
therefore a nothing problem must be there. I might have as many as 1000
control objects in various arrays and collections by this time. Could this be
a limitation.

Would I be correct in assuming that with 1000 controls sitting around in
collections and arrays, I would expect to be using mor than 4Mb of memory? If
so then the GC is reporting incorrectly, and I need to create some sort of
broker. Fine I can do that (begrudgingly).

If 1000 controls and 4Mb might sound realistic then it might be about right,
and then I need to chase up what bit of memory is running out. Could it be
some graphics memory or DLL memory. I dont know how all this fits together,
how I could check this or if an OutOfMemoryException might be thwe upshot.

I look forward to your responses.

 

[Guest]

I am completely lost. GC.GetTotalMemory tells me one thing. The
Settings...System...Memory tells me something else. Neither reflect anything
like 32Mb. The system is telling nothing. I am beginning to think that I have
something wrong with my set up here or something.
I am now not getting OutOfMemoryExceptions. The app is now just disappearing
with a little ActiveSync Beep-Boop to tell me that the connection has gone,
VS then telling me its lost its connection.
I am amzed that nobody can tell of accurate way of telling how much memory
is being used by an application and frustrated that I simply dont know where
to go.
A bit of a rant - sorry.
Can anybody suggest anything (dont send me in Bolings direction, as his
document although interesting doesnt shed any light on my situation).

 

[Guest]

His doc does shed a lot of light on it. Now you're probably seeing the PPC
memory manage shutting you down becasue you've used enough memory to pass
its cleanup trigger point. This can be avoided by trapping it's call with
an IMessageFilter.

Another thing that has to be considered is fragmentation. If you have 10MB
free, but it's all in small 4k blocks all over, then you ask for 8k or
contiguous memory, you'll still get a failure.

I think the Toolhelp APIs might give you some info. There are some quick
wrappers in the SDF for using them:

www.opennetcf.org/sdf

-Chris