-
Notifications
You must be signed in to change notification settings - Fork 17.9k
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
Buffered struct channel corrupting string field.....? #47714
Comments
If you have data races, you first have to eliminate all your data races. I'm going to close this for now, but feel free to reopen if you still have problems after all the races are gone. |
But I have no idea of what's causing the race in this code.. How can receiving from a channel and printing the value be a race condition..? |
For questions about using Go, you will get better and faster answers using a forum. Please see https://golang.org/wiki/Questions. |
Using
|
Strings in Go are normally immutable and do not need to be copied. The Fiber package must be doing something unsafe. |
@ianlancetaylor Fiber is focused on high performance, so it kinda makes sense why they would do that. |
As @rsc said “I can make something really fast if it doesn’t have to be correct” |
What version of Go are you using (
go version
)?Does this issue reproduce with the latest release?
Yes
What operating system and processor architecture are you using (
go env
)?go env
OutputWhat did you do?
I'm writing a ticketing system with websockets. When the websocket client is connected, everything works as expected:
However, when the client is offline, ticket call requests are stored in the buffered channel to then be read upon reconnection, but it seems that the "AAA" prefixes are partially overwritten by the "BB" prefixes, which makes absolutely no sense:
Unfortunately, I couldn't reproduce the issue on the Playground and don't know what else to try.
Here's the relevant parts of the code:
As of writing this, I ran more tests with the
-race
flag and it actually (inconsistently) triggered pointing to thefmt.Printf()
line above, which still doesn't make sense to me:What did you expect to see?
I expected to see the original contents of the struct, as they were when written to the channel:
The text was updated successfully, but these errors were encountered: