FreeRTOS+FAT memory leakage ?

maketych wrote on Wednesday, November 08, 2017:

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 FF_CreateIOManger (file ff_ioman.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 FF_DeleteIOManager 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 FF_CreateIOManger 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?

rtel wrote on Wednesday, November 08, 2017:

Thanks for the information - will get fixed.

maketych wrote on Thursday, November 09, 2017:

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

rtel wrote on Thursday, November 09, 2017:

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.

heinbali01 wrote on Thursday, November 09, 2017:

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 :slight_smile:

But I will prepare a new release, either in the form of a patch, or on sourceforge.
I will come back to this.
Thanks.

maketych wrote on Monday, November 13, 2017:

Ок, thanks, will wait with impatience!

heinbali01 wrote on Monday, November 13, 2017:

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

heinbali01 wrote on Monday, November 13, 2017:

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 : int32_t FF_FileSize( FF_FILE *pxFile )
New : FF_Error_t FF_GetFileSize( FF_FILE *pxFile, uint32_t *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( ffconfigFILE_EXTEND_FLUSHES_BUFFERS != 0 )
    {
    FF_Error_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

maketych wrote on Monday, November 13, 2017:

Hi, Hein!

Great thanks for patch!