FreeRTOS+FAT memory leakage ?

Hi all, I am using FreeRTOS version 9.0.0 and FreeRTOS+FAT version 160919 to work with SD card and USB flash drive on LPC1788. During testing I noticed that if unplug any connected drive and then plug in again it causes lost 40 bytes from the FreeRTOS heap. The research showed that: In function FFCreateIOManger (file ffioman.c) structure pxIOManager allocated by ffconfigMALLOC (line 141), then at line 156 allocated EventGroup (those 40 bytes) and its handle is stored in the structure pxIOManager. Next, in function FFDeleteIOManager structure pxIOManager freed by ffconfigFREE, but previously allocated EventGroup is not freed before it and EventGroup handler is lost. So at the next time you call FFCreateIOManger will create a new EventGroup. It means heap memory leakage by 40 bytes in every reconnect the drive. It seems that in function FF_DeleteIOManager need to freed EventGroup and make it before freed a structure pxIOManager. Is that right?

FreeRTOS+FAT memory leakage ?

Thanks for the information – will get fixed.

FreeRTOS+FAT memory leakage ?

Thank you! When can we expect new release? The last one was more then year ago…

FreeRTOS+FAT memory leakage ?

The latest +TCP code, which has evolved a bit since the same release you are referring to, is now in the main FreeRTOS SVN repository accessible via SourceForge – with the intent of having it in the main release next time. We may (?) do the same with the fat code, not sure.

FreeRTOS+FAT memory leakage ?

When can we expect new release? The last one was more then year ago…
That’s a good sign, there were very few changes since one year ago 🙂 But I will prepare a new release, either in the form of a patch, or on sourceforge. I will come back to this. Thanks.

FreeRTOS+FAT memory leakage ?

Ок, thanks, will wait with impatience!

FreeRTOS+FAT memory leakage ?

Hi Sergey, in order not to let you wait: please find attached a patch since 2016 Sep 19. This is a quick release, not an official one. Regards, Hein

FreeRTOS+FAT memory leakage ?

A summary of the changes made in the above 0001-Changes-since-160919.patch for FreeRTOS+FAT. Note that all changes are intended to be downward compatible. ● FF_FileSize() can only handle sizes up to 2GB because it returns a signed value. ~~~ Old : int32t FFFileSize( FFFILE *pxFile ) New : FFErrort FFGetFileSize( FFFILE *pxFile, uint32t *pulSize ) ~~~ The old function is still there. The function ff_filelength() (in ff_stdio.c) already returned an unsigned value size_t. It will now also call FF_GetFileSize() to obtain the size. If it returns 0ul, then stdioGET_ERRNO() can be called to see if there was an error. ● FF_ExtendFile() always immediately called FF_FlushCache() which is sometimes not desirable. This will now be configurable with ffconfigFILE_EXTEND_FLUSHES_BUFFERS, default defined as 1: ~~~ #if( ffconfigFILEEXTENDFLUSHESBUFFERS != 0 ) { FFError_t xTempError;
    xTempError = FF_FlushCache( pxIOManager );
    if( FF_isERR( xError ) == pdFALSE )
    {
        xError = xTempError;
    }
}
#endif    /* ffconfigFILE_EXTEND_FLUSHES_BUFFERS */
~~~ Some users don’t like this automatic flushing of FAT sectors. In stead they want to call FF_FlushCache() them selves, or wait until FF_fclose() is being called, which will call FF_FlushCache(). ● FF_Seek() (from ff_file.c) and ff_fseek() (from ff_stdio.c) did not work properly on files larger that 2GB. The offset parameter of ff_fseek() is a signed 32-bit long:
int ff_fseek( FF_FILE *pxStream, long lOffset, int iWhence )
With this patch :
iWhence = FF_SEEK_SET : lOffset is interpreted as a `uint32_t`
iWhence = FF_SEEK_CUR : lOffset is interpreted as a a signed offset
iWhence = FF_SEEK_END : lOffset must be <= 0
FF_Partition() : Make sure that ulHiddenSectors is at least 1 ● FF_CreateIOManger() would call FF_CreateEvents(), event if pxIOManager equals NULL When it fails to create a pxIOManager, it should not proceed to create the event group. ● FF_DeleteIOManager() caused a memory leak, the field pxIOManager->xEventGroup was not deleted ● FF_FlushCache() now has a use hook See comments in ff_ioman.h Some users want to perform special actions each time when the +FAT data buffers have been flushed to disk. ● FF_Mount() : The field pxPartition->pcVolumeLabel didn’t get zero-terminated ● FF_IncreaseFreeClusters() could get blocked under certain circumstances It was trying to take a lock that was already taken. ● ff_sys.c completely tested and updated This module was rewritten and tested with frequent calls to FF_FS_Add(() and FF_FS_Remove() in a random order. ff_sys.c makes the mapping between the so-called I/O managers and the (virtual) maps where they get mounted. Hein Tibosch

FreeRTOS+FAT memory leakage ?

Hi, Hein! Great thanks for patch!