Closed dcrosta closed 4 years ago
Thank you for the reproduction. I was able to reproduce the issue.
After reviewing the code, the issue is that handleTread
does not wait for the Rread
message to be filled out before returning. As a result, execution continues and the styxproto.Decoder.Next
method is called. This overwrites the msg
variable being accessed from the goroutine spawned in handleTread
.
A simple fix would be to have handleTread
pass a copy of the Tread
message to the goroutine it spawns. The only other places we spawn goroutines for command processing is ifor Tattach
and Tauth
messages, so those should be reviewed as well.
In hindsight, I skipped too many steps and made too many assumptions about performance when deciding to use a single shared, mutable buffer in the styxproto.Decoder
method.
I'm unable to reproduce with the change in #22
I recently switched off the built-in TraceLog in favor of custom logging, and discovered a data race via go's race detector as a result. Here's a reproducing case:
main.go
I run this with
go -race main.go
, then in another terminal do:This gives the following output from the styx server program:
If I uncomment the line that turns on TraceLog, there is no race detected. I believe this is because https://github.com/droyo/styx/blob/master/internal/tracing/trace.go#L22-L34 copies data out of the buffer when tracing is enabled, and passes that copy (via the pipe) to the main styx server, but I haven't looked very deeply at this or thought about it very extensively.