It could be interesting to know what is the hardware target. I mean if your application runs on USBizi, 10/12kb of free mem can be normal depending on your code, but if your code runs on EMX, 10/12kb left is probably due to a strong memory leakage in your code.
This can be the reason. There’s not a lot of RAM memory on such platform. Be sure to Dispose unusefull object before dealing with filesystem. You should also try to move this part of code at an early stage of your algorithm. If you don’t run other part that can be memory consumming does your code could work?
As Eric said, this depends on how big is your file. Even if your code does not seem to be heavy, some of the assembly reference can be very memory consumming. On a previous target (USBisy), loading the all the assembly for our application didn’t let us enough free mem to run the application.10/12kb can be enough in a lot of cases but in other such as the one you mention may be not.
You are doing it right, just use the buffer of smallest possible size when needed.
Try also to avoid as much as possible string (even for Debug.Print purpose). There’s also some bugs in netmf such as HashTable that is growing undefinitely till crashing the platform.
The problem is somewhere else than just streamreader code… There’s something that eats memory (double check the assembly references, the use of string and so on…)
Oh my, is there a known issue tracker with this information? I swear the memory management on my Panda is awful. I have to keep way too much memory free to keep it from crashing. I strongly believe something is wrong @ a fundamental level.
New version of .NET MF has some memory management fixes i think so I’m waiting to test it (we need to wait for GHI to update the premium libs). This problem is more often seen on small devices like Panda.
Baz, I am glad you posted this because I asked myself “Didn’t I try this with no luck??”
I dealt with this issue a month or so back. I had more than enough free memory but StreamReader was not happy regardless. I ended up using FileStream (with a small buffer) only and don’t use stream reader at all.
Streamreader allocates a buffer of about 4k up front before reading anything. The problem is it needs 4k of contiguous space… One large block with no fragmentation. This is ususually not available by the time you open it and it seems to allocate inside the Read method.
Try and create a streamreader very early in the program and read something immediately and see if makes a difference.
I have also just used Filestream.Read in the end.
There used to be a StreamReaderEx on die code site. Have a look if you can find it.