-
Notifications
You must be signed in to change notification settings - Fork 7.3k
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
Ringbuf: Acquiring entire ring buffer results in items being received prematurely (IDFGH-13694) #14568
Comments
Thanks for reporting the issue, @james-corticallabs. We shall take a look and get back to you on this. |
Thanks @sudeep-mohanty for fixing this. Will this fix be backported to a current release of esp-idf? |
Hi @james-corticallabs, Yes, the fix will be back ported to the release branches once our internal tests pass. Thanks. |
…ms prematurely This commit fixes a bug in the no-split buffer which could receive an item prematurely if the space on the buffer is acquired until the buffer is full. The commit also adds a unit test for this scenario. Closes #14568
…ms prematurely This commit fixes a bug in the no-split buffer which could receive an item prematurely if the space on the buffer is acquired until the buffer is full. The commit also adds a unit test for this scenario. Closes #14568
…ms prematurely This commit fixes a bug in the no-split buffer which could receive an item prematurely if the space on the buffer is acquired until the buffer is full. The commit also adds a unit test for this scenario. Closes #14568
…ms prematurely This commit fixes a bug in the no-split buffer which could receive an item prematurely if the space on the buffer is acquired until the buffer is full. The commit also adds a unit test for this scenario. Closes #14568
Hi,
I ran the same code three times. Here are the results: esp-idf v5.3 without the fix:
esp-idf v5.3 with the fix:
esp-idf v5.3 with my own fix:
It looks like the problem still happens after wraparound if there were any dummy bytes at the end of ringbuffer. |
Thanks for reporting the issue @upolc-lg. We shall investigate it further. I'll re-open the ticket. Since you have done some investigation already, would you mind sharing your fix or creating a PR for us? Thanks! |
Closing this issue. Fix to be evaluated under #14948. |
Answers checklist.
IDF version.
v5.4-dev-2744-g59e1838270
Espressif SoC revision.
ESP32-D0WD-V3 (revision v3.0)
Operating System used.
Linux
How did you build your project?
Command line with idf.py
If you are using Windows, please specify command line type.
None
Development Kit.
Custom Board
Power Supply used.
External 3.3V
What is the expected behavior?
I expect to:
xRingbufferSendAcquire
until the ring buffer is full.xRingbufferSendComplete
. I expect to be able to do this in a different order from which the items were acquired in step 1.xRingbufferReceive
on a separate task in the order they were acquired in step 1 and containing their expected values.What is the actual behavior?
Instead, when the buffer is full, the oldest acquired item is returned by
xRingbufferReceive
even if that item has not been sent yet usingxRingbufferSendComplete
. If the sending task has not yet finished writing to this oldest acquired item then it results in the receiving task reading the wrong value for that item.Steps to reproduce.
xRingbufferSendAcquire
(labelled asitem1
in the steps and code below)4a. Acquire item using
xRingbufferSendAcquire
4b. Write a value to item
4c. Send item using
xRingbufferSendComplete
item1
item1
usingxRingbufferSendComplete
Code to reproduce:
Expected result of above code:
Actual result of above code:
Debug Logs.
More Information.
I am building using the docker image
espressif/idf:latest
.The text was updated successfully, but these errors were encountered: