Quality RTOS & Embedded Software

 Real time embedded FreeRTOS RSS feed 
Quick Start Supported MCUs PDF Books Trace Tools Ecosystem TCP & FAT




Loading

FreeRTOS+FAT memory leakage ?

Posted by maketych on November 8, 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 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 ?

Posted by rtel on November 8, 2017

Thanks for the information - will get fixed.


FreeRTOS+FAT memory leakage ?

Posted by maketych on November 9, 2017

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


FreeRTOS+FAT memory leakage ?

Posted by rtel on November 9, 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.


FreeRTOS+FAT memory leakage ?

Posted by heinbali01 on November 9, 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 :-)

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 ?

Posted by maketych on November 13, 2017

Ок, thanks, will wait with impatience!


FreeRTOS+FAT memory leakage ?

Posted by heinbali01 on 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

Attachments


FreeRTOS+FAT memory leakage ?

Posted by heinbali01 on 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 : 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 ?

Posted by maketych on November 13, 2017

Hi, Hein!

Great thanks for patch!


[ Back to the top ]    [ About FreeRTOS ]    [ Sitemap ]    [ ]




Copyright (C) Amazon Web Services, Inc. or its affiliates. All rights reserved.

Latest News

FreeRTOS kernel V10 is available for immediate download. Now MIT licensed.


FreeRTOS Partners

ARM Connected RTOS partner for all ARM microcontroller cores

IAR Partner

Microchip Premier RTOS Partner

RTOS partner of NXP for all NXP ARM microcontrollers

STMicro RTOS partner supporting ARM7, ARM Cortex-M3, ARM Cortex-M4 and ARM Cortex-M0

Texas Instruments MCU Developer Network RTOS partner for ARM and MSP430 microcontrollers

OpenRTOS and SafeRTOS