-
Notifications
You must be signed in to change notification settings - Fork 1.6k
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
input: non-thread-safe access around mem_buf_status #3854
Comments
This issue is stale because it has been open 30 days with no activity. Remove stale label or comment or this will be closed in 5 days. |
Not stale. |
This issue is stale because it has been open 30 days with no activity. Remove stale label or comment or this will be closed in 5 days. |
Not stale. |
This issue is stale because it has been open 30 days with no activity. Remove stale label or comment or this will be closed in 5 days. |
Not stale. |
This issue is stale because it has been open 30 days with no activity. Remove stale label or comment or this will be closed in 5 days. |
Not stale. |
This issue is stale because it has been open 90 days with no activity. Remove stale label or comment or this will be closed in 5 days. Maintainers can add the |
Not stale. |
both logics/code mentioned above runs in the same thread. There is no threaded input plugins "yet" |
This issue is stale because it has been open 90 days with no activity. Remove stale label or comment or this will be closed in 5 days. Maintainers can add the |
This issue was closed because it has been stalled for 5 days with no activity. |
The
mem_buf_status
field ofstruct flb_input_instance
is read and written across two threads without synchronization.For example, it gets read in one thread here:
fluent-bit/src/flb_input_chunk.c
Lines 887 to 892 in 5d51473
and gets written by another thread here:
fluent-bit/src/flb_input.c
Lines 873 to 883 in 5d51473
From what I understand, this kind of access might not work as expected if each thread is running on a different CPU, so it does need to be fixed.
One possible solution is to protect that field with a pthread mutex. Another is to use
atomic_int
or similar, but it sounds like that's not portable. A third is to mark the field asvolatile
, but that may not necessarily fully resolve the issue.This race condition was detected by the thread sanitizer while running the filter_grep unit tests.
The text was updated successfully, but these errors were encountered: