-
Notifications
You must be signed in to change notification settings - Fork 22
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
Corrupt data stream #7
Comments
Huh, that's weird. Well, I'd suggest adding more |
I figured it out. Race condition between writer and reader. On an embedded system with no preemption this wouldn't be a problem. However on any SMP system it is.
If a writer comes in and writes something inbetween the reader reading einfo->offset for the first time and the second time - you end up with the start point being smaller than it should be by the last write. I guess this isn't a problem on a simple logger - I'm using it for something else though and it is a problem. I fixed the issue by using a read_lock and a write_lock around the critical sections. Not sure if this is the best approach though, I will most likely be starving readers under high load. |
Great finding!
Well, it's still a correctness issue, and it may produce quite confusing logs. As far as I can see, there are a few other races (which don't need to be addressed here):
I'll be glad to merge your fix as is -- it's better than silently producing corrupt data. |
And we can explore (later) if we can use generic circular buffer implementation ( |
Hi there, really like emlog, thank you all.
Was hoping you could point me in the right direction for some debug issues I’m having with emlog.
I’m writing data to an emlog device and reading from it.
Everything seems to work fine until the buffer fills up. (It is very dependent on the write rate I believe) if the write rate is slow the buffer wraps and I don’t have a problem.
My c program uses blocking reads, it sits there waiting for my other program to write. What I think is happening is that the head of the file is moving back over data I’ve already read. This is variable, sometimes I’ve noticed 512 bytes, sometimes 1322. I’m assuming it’s the size of the write that has just occurred.
Basically, means the next read I do is garbage. (Well, data I’ve already read) and my data stream is now corrupt.
This must be some sort of timing issue as when I go and hex dump the emlog device - the data is in the correct sequence again.
Do you have any idea how I could find out what is going on? Eg get the location of the head / tail of the buffer? Or how can I call get_einfo to get the data?
The text was updated successfully, but these errors were encountered: