Memory allocation problem with Fez Panda II

Hello,

I have a memory problem on my Fez Panda II. I am using .NET Micro Framework 4.1.

I have 270 bytes of data and 270 bytes of semicolons to parse that data. To parse string to obtain the actual data I’m using:

someStr.Split(new char[] {';'}); 

I got the following exception message with GC message:

GC: 3msec 42864 bytes used, 21516 bytes available
Type 0F (STRING ): 1764 bytes
Type 11 (CLASS ): 5064 bytes
Type 12 (VALUETYPE ): 84 bytes
Type 13 (SZARRAY ): 4680 bytes
Type 15 (FREEBLOCK ): 21516 bytes
Type 17 (ASSEMBLY ): 14628 bytes
Type 18 (WEAKCLASS ): 48 bytes
Type 19 (REFLECTION ): 24 bytes
Type 1B (DELEGATE_HEAD ): 612 bytes
Type 1C (DELEGATELIST_HEAD ): 144 bytes
Type 1D (OBJECT_TO_EVENT ): 144 bytes
Type 1E (BINARY_BLOB_HEAD ): 5928 bytes
Type 1F (THREAD ): 2688 bytes
Type 20 (SUBTHREAD ): 336 bytes
Type 21 (STACK_FRAME ): 3924 bytes
Type 23 (LOCK_HEAD ): 60 bytes
Type 24 (LOCK_OWNER_HEAD ): 24 bytes
Type 27 (FINALIZER_HEAD ): 264 bytes
Type 31 (IO_PORT ): 216 bytes
Type 34 (APPDOMAIN_HEAD ): 72 bytes
Type 36 (APPDOMAIN_ASSEMBLY ): 2160 bytes
Failed allocation for 165 blocks, 1980 bytes

#### Exception System.OutOfMemoryException - CLR_E_OUT_OF_MEMORY (8) ####
#### Message: 
#### System.String::Split [IP: 0000] ####
#### HangerController.XMLIOHandler::getDeviceQrCodes [IP: 0143] ####
#### HangerController.DataFetcherSender::fetchAndSendData [IP: 0135] ####
#### HangerController.TCPServerProcessor::TCPListenerThread [IP: 0171] ####

A first chance exception of type ‘System.OutOfMemoryException’ occurred in mscorlib.dll
An unhandled exception of type ‘System.OutOfMemoryException’ occurred in mscorlib.dll

Here I didn’t understand why there is a memory allocation problem for 1980 bytes from 21516 bytes available. Is there a mistake with my mind?

Moreover if I force Garbage Collector to run:


Debug.GC(true);
someStr.Split(new char[] {';'});

There is no memory allocation problem.

So what is the problem?

Thank in advance.

Fragmentation is one thing I can think of.

Forcing GC before is a good practice!

Yes, fragmentation is your problem. GC forced compaction and then the memory allocation could be found in a contiguous chunk. When you have lots of string churn you can get into this situation too easily, and using string split in your scenario is actually quite hard on memory (have you thought about dealing with chars instead?)

Hi enienws,

This is a limitation of .NET Micro Framework 4.1 and earlier. One workaround is to call Debug.GC(true) before any operations that need a large chunk of memory.

Based on initial testing, this has been fixed in .NET Micro Framework 4.2.

Chris

thank you so much all for your replies

The problem is we will never see 4.2 on the Panda.

never is a long time… there’s the OpenUSBizi project that will likely move USBizi into the 4.2 and beyond world