Bug: Race Condition #140
Comments
|
I debugged this by my self and the problem is now solved, this is a simple simulated condition: package main
import (
"bytes"
"net"
"os"
"os/signal"
)
type sampleStruct struct {
byteArray0 []byte
byteArray1 []byte
ip net.IP
}
func main() {
message := []byte{0, 0, 0, 0, 1, 1, 1, 1, 2, 2, 2, 2}
ss := &sampleStruct{}
unmarshal(message, ss)
// reading
go func() {
for {
//if ss.ip.Equal(net.IP{10, 10, 10, 10}) {
if bytes.Equal(ss.ip, []byte{1, 1, 1}) {
}
}
}()
// writing
go func() {
for i := 0; i <= 255; i++ {
message[11] = byte(i)
}
}()
s := make(chan os.Signal, 1)
signal.Notify(s, os.Interrupt)
<-s
}
func unmarshal(data []byte, ss *sampleStruct) {
ss.byteArray0 = data[:4]
ss.byteArray1 = data[4:9]
ss.ip = data[9:]
//c := make([]byte, len(data))
//copy(c,data[9:])
//ss.ip = c
}# save this in main.go and run by this command
go run -race main.go |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
hi
we used your library in one of our company projects.
at first, we had this problem --> a few of our CCR packets were broken.
for example, PDP-Address becomes 100.67.0.227 or 0.0.0.0 or 0.64.0.0
we started debugging and after a while, we tried go -race command and we got this DATA RACE:
We decided to divide the diam server and client into another repository (you can check it in this repository) but we still have the same problem. then we decided to debug this go-diameter library. in all of our tests and scenarios, reading a message in handler has race condition too so in my opinion there is not any problem with the unmarshal function.
finally, we figure out where the bug is and how to fix it but our solution wasn't a perfect one:
We thought the problem is from sync.pool but we were not sure so we changed more codes and refactored the whole algorithm of reading from conn. the result was the same and the problem is not from sync.pool.
you can check this library_changes then open files or apply the patch. there are some changes and lots of them are because of change reading form conn algorithm but the important part is in message.go line 162, this solution fixes the problem but we still don't know why. my opinion is that we have a serious problem with bytes.buffer and []byte or maybe with golang garbage collector.
please check this issue and tell us your opinion. Do you think as same as us that the problem is from this library? we have to be sure about this first then we can fix this bug and send a pull request.
The text was updated successfully, but these errors were encountered: