net.ReadFromUDP doesn't re-initialize the slice or anything, so if you read 2 messages and message #2 is shorter than message #1, the byte slice still contains the end of message #1.
In most cases it's unnoticeable since the code splits on newlines and the garbage at the end of the slice probably doesn't match the regex. But for instance, a bug would be:
send "foo.somestatistic:1|c\n" -> message byte slice is "foo.somestatistic:1|c\n"
send "foo.bar:1|c" -> message byte slice is "foo.bar:1|ctistic:1|c\n"
(Note that if the second stat had a newline we would have split on that, the trailing part would have just been noise, and it would have worked exactly as expected. The statsd client I'm using omits the newline, which is how I discovered this bug).
Fix is here, I've done a bunch of manual testing and it works.
mreiferson
commented
11 years ago
net.ReadFromUDPdoesn't re-initialize the slice or anything, so if you read 2 messages and message #2 is shorter than message #1, the byte slice still contains the end of message #1.In most cases it's unnoticeable since the code splits on newlines and the garbage at the end of the slice probably doesn't match the regex. But for instance, a bug would be:
send "foo.somestatistic:1|c\n" ->
messagebyte slice is "foo.somestatistic:1|c\n" send "foo.bar:1|c" ->messagebyte slice is "foo.bar:1|ctistic:1|c\n"(Note that if the second stat had a newline we would have split on that, the trailing part would have just been noise, and it would have worked exactly as expected. The statsd client I'm using omits the newline, which is how I discovered this bug).
Fix is here, I've done a bunch of manual testing and it works.