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
compress/gzip: panic in Writer.Close() #18883
Comments
I have also observed a panic that is even more problematic: it can occur from a call to Maybe it is caused by attempting to flush to a closed connection? The reason I'm saying it's more problematic is because we do not know at the point at calling Here's is the panic:
|
Can you run your code with the race detector enabled, the failures that you are getting in |
Your logic looks racy. |
I wasn't clear whether the library was threadsafe or not. I will wrap the I will also leave it running with the race detector on. It could be a while before I have any results. I'm not sure the "racy" behaviour (when closing) explains the second panic (when flushing) however. This should only be executed in the same goroutine. Again, hopefully the race detected will provide a definitive answer on this. I will keep you posted. |
Ok, I managed to catch a data race with the race checker enabled. It does look like it was caused by the call to Close flushing data concurrently with data being written to the underlying Writer. I will close this issue. Thanks for your help. |
What version of Go are you using (
go version
)?go1.7.5 darwin/amd64
What operating system and processor architecture are you using (
go env
)?But I was cross compiling with
CGO_ENABLED=0 GOOS=linux GOARCH=amd64 go build -a -installsuffix cgo
.And ran it on
On that machine, it is running in docker container (docker version:
Docker version 1.13.0, build 49bf474
) using the base imagealpine:3.3
.What did you do?
We wrap an
http.ResponseWriter
ingzip.Writer
. When theCloseNotifer
of thehttp.ResponseWriter
fires, we callWriter.Close()
.The source code of this file is here.
I am aware this might not be the correct thing to do since closing the
gzip.Writer
will attempt to flush to a closed connection, but I wouldn't have expected such a low-level panic as the symptom.What did you expect to see?
Either it to have no effect, or return an error.
What did you see instead?
This code will have been executed tens of thousands of times, and this panic only occurred a single time. The single time it paniced, the error was:
This is where the panic returned from.
The text was updated successfully, but these errors were encountered: