You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I've got a runtime panic while running some code that was essentially identical to the example server in this repo:
panic: runtime error: index out of range [3] with length 0
goroutine 10 [running]:
github.com/CyCoreSystems/audiosocket.Message.ErrorCode(...)
/home/pjuhasz/pkg/mod/github.com/!cy!core!systems/[email protected]/audiosocket.go:75
My analysis:
For some reason audiosocket.NextMessage() returned a zero length message. I don't know if there was an error, unfortunately I haven't checked it, but the example code doesn't either.
Then that empty message is passed to m.Kind(), which returns KindError. This is problem number one, that a legitimate packet type is conflated with something that is more like a condition on the receiving site.
Then, believing that the message is valid, it is passed to m.ErrorCode(), which then panics, because it blindly accesses m[3] without making sure that the message is long enough for that.
Suggestions:
check the length in ErrorCode() - I think this is easy and harmless
if possible, introduce a new error code to signify that the packet is invalid, or signal the error in some other way.
The text was updated successfully, but these errors were encountered:
I've got a runtime panic while running some code that was essentially identical to the example server in this repo:
My analysis:
For some reason audiosocket.NextMessage() returned a zero length message. I don't know if there was an error, unfortunately I haven't checked it, but the example code doesn't either.
Then that empty message is passed to m.Kind(), which returns KindError. This is problem number one, that a legitimate packet type is conflated with something that is more like a condition on the receiving site.
Then, believing that the message is valid, it is passed to m.ErrorCode(), which then panics, because it blindly accesses m[3] without making sure that the message is long enough for that.
Suggestions:
The text was updated successfully, but these errors were encountered: