fx_media_opened_file_count becomes -1 (0xFFFF FFFF) which in turn sends fx_file_open and other functions into endless loop

[jerrylogansquare]

There are no guards on this line of code. If fx_media_opened_file_count happens to be 0, it will become -1 (0xFFFF FFFF) https://github.com/eclipse-threadx/filex/blob/9023227ba4cf4e12d010daed121f5148b80403d9/common/src/fx_file_close.c#L136

In many functions, we have this common sequence of code below. When fx_media_opened_file_count is -1, the while loop will run indefinitely and the processor gets stuck, resulting in watchdog reset.

    /* Loop through the media's open files.  */
    open_count =  media_ptr -> fx_media_opened_file_count;
    file_ptr =    media_ptr -> fx_media_opened_file_list;
    while (open_count)

[fdesbiens]

Hi @jerrylogansquare.

Thank you for raising this issue. We will look into it.

[cypherbridge]

Patch this with conditional test

if (media_ptr -> fx_media_opened_file_count > 0) { media_ptr -> fx_media_opened_file_count--; }

[amgross]

Patch this with conditional test

if (media_ptr -> fx_media_opened_file_count > 0) { media_ptr -> fx_media_opened_file_count--; }

Shouldn't we return error in this case?

[cypherbridge]

The top of fx_file_close() checks for a validated file handle file_ptr -> fx_file_id != FX_FILE_ID then when its done closing invalidates it file_ptr -> fx_file_id = FX_FILE_CLOSED_ID; By inspection it would appear that entering this function with a valid file handle should not return until it closes the file and adjusts the file list. Otherwise the hazard would be possible file leak. It is not clear how a state is reached where fx_media_opened_file_count is zero, yet this function is entered with a valid file handle. Can you reproduce this condition, then inspect media_ptr -> fx_media_opened_file_list. Try to figure out how this state can occur. Also defensively code your application while (open_count > 0)