The resource is not that large, less than 2k. But I need to manipulate it and eventually send it through the comport.
Something happens inside the Comport code that generates the OOM. The function takes a string parameter (data), converts it to a byte array and sends it to an instance of SerialPort (sp). The .Length of the data string is 1989
Note the following code and Debug.GC(false) outputs.
// 15228
sp.DiscardOutBuffer();
// 12300 ???
byte[] buffer = StrToByteArray(data);
// 10332
sp.Write(buffer, 0, buffer.Length); -- it blows up here.
So I am guessing that some data handling is going on in the SerialPort object that requires more memory that is available.
If I reduce the data parameter to 1000 bytes, it never crashes, ever.
I should mention that I am using GHI sdk v1.08 from 8/2010.
rgelb, That’s a really old version of the SDK. Have you tried this on the current version to see if this is perhaps a problem that has been fixed? If you can’t test it for some reason, please post your StrToByteArray() also and I’ll test it. Also, please use code tags when posting code.
public static byte[] StrToByteArray(string str)
{
System.Text.UTF8Encoding encoding = new System.Text.UTF8Encoding();
return encoding.GetBytes(str);
}
But that is not where it blows up. In fact it works exactly as I would have expected. Before the call, there was 12300 bytes available, after the call 10332, because it converted a string of length 1998 to a byte array.
The problem is in SerialPort.Write and possibly in SerialPort.DiscardOutBuffer methods.
I’ll give it a shot with a later version of the SDK (was really trying to avoid it).
That will take a little longer to setup. Gotta get to bed tonight. I’ll try to recreate that situation tomorrow. In the meantime, you might try using a loop with the offset and length parameters to write out 1K at a time?