-
Notifications
You must be signed in to change notification settings - Fork 116
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
"panic: runtime error: slice bounds out of range" after non SS traffic #38
Comments
It appears that the crash is caused by the non-SS traffic, but gqserver.ReadTillDrain shouldn't have been called at all after the "non SS traffic" has been printed. So what may have happened is that the data sent by that non SS traffic somehow got read by ReadTillDrain on a goroutine that handles a connection from gqclient, which shouldn't have happened since they are on two separate TCP streams. I suspect race condition. I'll do some test with the go race detector. |
Judging by the log from your web server, here's a possible reconstruction of what happened: That IP sent a well-formed ClientHello (well formed in terms of header info at least) since gqserver.ParseClientHello didn't throw an error on gq-server.go:131. Then this ClientHello went through gqserver.IsSS, which returned false and the "+1 non SS traffic" info was logged. goWeb then made a connection with your local web server and tried to send the ClientHello through. However, in the middle of sending this, gqserver crashed. This can be known by the fact that your web server only received the header of it instead of the entire message. I still don't see how this would trigger a panic in gqserver.ReadTillDrain that was called by remoteToServer. Maybe the non SS connection was unrelated and the appearances together are just a coincidence. If I put a validation of the buffer size before https://github.com/cbeuw/GoQuiet/blob/master/gqserver/util.go#L54 then it shouldn't crash anymore. But still I don't know what could've caused this. I'll keep the race detector running for a while and see if it catches anything |
Just reporting, there is no more crashes was happened after months of server uptime. Thank you :) |
Hello. After couple of days normal work, in one moment I find out that my shadowsocks client can't connect to server. I logged via ssh and see that the shadowsocks service down, because goquiet chashed. There is
journalctl -xe
excerpt:shadowsocks-libev 3.2.0
goquiet 1.2.1
ubuntu 16.04.5 (2.6.32-042stab127.2 kernel)
Thank you, and sorry my bad English.
The text was updated successfully, but these errors were encountered: