Skip to content

Race condition leads to files in a wrong directory #69

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
sschneideribs opened this issue May 6, 2025 · 0 comments
Open

Race condition leads to files in a wrong directory #69

sschneideribs opened this issue May 6, 2025 · 0 comments
Labels
bug Something isn't working

Comments

@sschneideribs
Copy link

sschneideribs commented May 6, 2025

Greetings,

We are using ThreadX in combination with FileX, and we are making FileX calls from multiple threads, as FileX is advertised as being thread-safe when used with ThreadX. Recently, we encountered an issue where a call to fx_file_create created a file in the root directory instead of the specified subdirectory, even though the subdirectory did exist.

After an extensive debugging session, we discovered that a race condition between threads was overwriting the path name, leading to the behavior described. Here's how the issue can be reproduced:

  1. Create a subdirectory, for example: /Alarms/
  2. Create a file within that subdirectory: /Alarms/0001_alarm.json
  3. While fx_file_create is searching for an existing file name inside _fx_directory_search, call another FileX function that modifies the media directory name, such as fx_directory_local_path_set.
  4. As a result, the file 0001_alarm.json ends up being created in the root directory instead of /Alarms/.

The race condition is easier to trigger when many files exist in the same directory, since the search takes longer, increasing the likelihood of the conflict. The root of the problem appears to be that FX_PROTECT is called too late. It needs to be invoked at the very beginning—before the media directory entry name is nulled.

I have observed that several other functions may be susceptible to the same behavior. As a temporary workaround, we have wrapped all FileX function calls that are not properly protected with an additional mutex.

Some additional information:
Our logic is functioning correctly—there is no issue in the application code. Additionally, FileX does not return any errors, as we are very meticulous in checking return values. The described behavior only occurs when specific timing conditions between different threads are met.

@sschneideribs sschneideribs added the bug Something isn't working label May 6, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

No branches or pull requests

1 participant