Out Of Memory Exception when using StringBuilder

  • Thread starter Thread starter Patino
  • Start date Start date
P

Patino

I have a NET CF application running on Mobile 5. The app tries to read
a very BIG file (almost 3 Mb) and store its content in a string. I use
StreamReader to read the file, and stringbuilder to build the string.
However, at some time during this process I get the error:

at System.PInvoke.EE.FastAllocateString()
at System.String.GetStringForStringBuilder()
at System.String.GetStringForStringBuilder()
at System.Text.StringBuilder.GetNewString()
at System.Text.StringBuilder.Append()
at MyProgram.XMLUtils.xmlToString()
: : :

I've been trying to walk through the code when running this one, but
somewhere when the Capacity of my string reaches 117158 the code
freezes.

I need to build that string so that my CF app can upload that string
to a web service application.

Now, the application runs fine (without errors) some times; other
times it crashes with the OutOfMemoryException, on both cases using
the exact same data. The only difference is that: it crashes when the
app has been running for a while in the PDA. It does not crash if a
start a new session of the app and go straight to create that string
to send to the web service.

Any ideas on how I can fix this?

Oh yes, I have added the lines:
GC.Collect();
GC.WaitForPendingFinalizers();
when I instanciate the form that creates this string......and still
the thing crashes.

:-(
 
How about doing the transfer in packets? Trying to do the entire thing in
one shot is a bit insane for the reason you're seeing and others.
 
There are a lot of things that can wrong transferring a 3MB file from a
device. How about you use HttpWebRequest to upload the file asynchronuosly
and when complete have a WebService call pick up the file and work with it.

Passing a 3MB file via a WebService call is going to kill any interface
responsivness, and is way too dependent on a good connection.
 
Thanks for your reply. We are going to break the file into smaller
chunks as you suggest. We also realized that running our app with such
a big input file was taking more than 20MB of memory to run. The
typical input file for our app with files of < 200Kb uses 2 or 3 MB of
memory to run, a big difference in performance. It is just that once
in a while some user decides to uplaod these big input files.
 
Thanks for your reply. We are going to break the file into smaller
chunks as you suggest. We also realized that running our app with such
a big input file was taking more than 20MB of memory to run. The
typical input file for our app with files of < 200Kb uses 2 or 3 MB of
memory to run, a big difference in performance. It is just that once
in a while some user decides to uplaod these big input files.
 
Back
Top