The out of memory could be caused if you get an offset in your data stream that causes the STM library to use a random byte for the size (which often results in trying to read a really big message size). If you roughly know the size of your data it's a good idea to modify the library and put in an upper bound on the message size that throws an error if it get's the wrong size.
Of course that begs the question of what is causing you to get that offset in the first place. It could be a few things, but I think given your situation it's likely you are overflowing one of the buffers at some point, most likely the write buffer on the RT target. Different targets behave differently when that happens, I know that VxWorks throws an error and that Windows doesn't. I'm not sure if I ever tested it for Pharlap, but my guess would be that it behaves more like Windows.
My suggestion would be to try sending smaller chunks of data, perhaps sending each cluster in the array separately rather than sending the entire array at once. Assuming the clusters are already reasonably large that shouldn't affect your streaming performance much.
You may also need to increase the speed of the reader if it turns out you are overflowing the write buffers. The best way to do this is probably to take a close look at your data structure and decide if it's the best way of streaming the data. An array of large clusters with variable sized strings is going to be hammering your memory manager on both sides, and you probably end up doing a lot of indexing and unbundling/rebundling, which can be expensive.
E-Mail this Page