I have a basic data logger reading from serial ports and logging to an SD card running on a FEZ Rhino and every now and then I see messages like the following:
Failed allocation for 173 blocks, 2076 bytes
I think most of the time the message appears just after debug output from a garbage collection.
Is this a message from the garbage collector or is it from the FAT file system?
GC: 3msec 51720 bytes used, 12660 bytes available
Type 0F (STRING ): 4644 bytes
Type 11 (CLASS ): 8208 bytes
Type 12 (VALUETYPE ): 60 bytes
Type 13 (SZARRAY ): 1704 bytes
Type 15 (FREEBLOCK ): 12660 bytes
Type 17 (ASSEMBLY ): 14460 bytes
Type 18 (WEAKCLASS ): 48 bytes
Type 19 (REFLECTION ): 24 bytes
Type 1B (DELEGATE_HEAD ): 612 bytes
Type 1C (DELEGATELIST_HEAD ): 48 bytes
Type 1D (OBJECT_TO_EVENT ): 264 bytes
Type 1E (BINARY_BLOB_HEAD ): 15828 bytes
Type 1F (THREAD ): 1152 bytes
Type 20 (SUBTHREAD ): 144 bytes
Type 21 (STACK_FRAME ): 1776 bytes
Type 22 (TIMER_HEAD ): 72 bytes
Type 23 (LOCK_HEAD ): 60 bytes
Type 24 (LOCK_OWNER_HEAD ): 24 bytes
Type 27 (FINALIZER_HEAD ): 1080 bytes
Type 31 (IO_PORT ): 360 bytes
Type 34 (APPDOMAIN_HEAD ): 72 bytes
Type 36 (APPDOMAIN_ASSEMBLY ): 1080 bytes
Failed allocation for 89 blocks, 1068 bytes
That text is definetely from the GC. It says GC took 3 secs. It might be forcing the GC to try to clean up because the alloc failed though.
My suggestion is that you have to watch how much memory is being consumed and how the GC output changes over time (for instance is binary_blob_head the part that grows) - there are other threads here on mis-handled serial ports and memory leaks, so it’s going to be a code issue sorry.
@ Sean
This can also happen when the available memory is fragmented, due to many small allocations. When it tries to allocate a larger, contiguous block it fails, if the GC hasn’t just run.
Check for areas of code where small allocations occur and try to “tame” them, perhaps by using static buffers with the appropriate size. As mentioned above, the serial port can be a real problem at high baud rates.
After initial setup during which I allocate some fixed size static buffers before entering the loop which reads from the incoming serial port and writes out to the SD card and to a couple of other serial ports I make no allocations during the loop.
And just before entering my logging loop I call Debug.GC(true).
When I see these messages the GC message mentions there being roughly 12-20KB free every time.
What I forgot to mention, although I did make reference to the FAT file system, is that I mostly see these messages when using File.Copy() to copy files from the SD card to an inserted USB memory stick.
Which is why I thought the messages may be related to file system blocks.