database/sql: panic: double close #18429
Labels
Milestone
Comments
|
Okay, here is a reproducible test case: package main
import (
"database/sql"
"log"
"net/http"
_ "github.com/mattn/go-sqlite3"
)
var db *sql.DB
func index(w http.ResponseWriter, r *http.Request) {
ctx := r.Context()
tx, err := db.BeginTx(ctx, nil)
if err != nil {
log.Print(err)
return
}
_, err = tx.ExecContext(ctx, "INSERT INTO t (text) VALUES ('')")
if err != nil {
log.Print(err)
return
}
err = tx.Commit()
if err != nil {
log.Print(err)
return
}
}
func main() {
var err error
db, err = sql.Open("sqlite3", "test.sqlite")
if err != nil {
log.Print(err)
return
}
_, err = db.Exec("CREATE TABLE IF NOT EXISTS t ( text TEXT );")
if err != nil {
log.Print(err)
return
}
http.HandleFunc("/", index)
log.Fatal(http.ListenAndServe(":8080", nil))
}Open http://localhost:8080 in a browser, press F5 and do not release it for 1-3 seconds until the program crashes. |
|
/cc @mattn |
|
Seems like an sqlite driver problem? /cc @kardianos |
|
When transaction is closed, Tx.txi is set nil. So I guess the goroutine in database/sql should check whether the txi is already closed (is nil). |
|
I'm looking into this now. |
|
This is caused by Tx.close racing with Tx.rollback(true) when the context times out. It is compounded by close nilling the locker used to guard against races (tx.dc) which makes it difficult guard against this. I'm working on a solution now. |
|
On a side note, sqlite3 might also have a data race where sqliteConn.Close doesn't check if the sqliteStmt.exec is still running the goroutine. |
|
CL https://golang.org/cl/34716 mentions this issue. |
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
What version of Go are you using (
go version)?go version go1.8beta2 linux/amd64
What operating system and processor architecture are you using (
go env)?linux/amd64
What did you do?
I open an sqlite3 database (using mattn/go-sqlite3) and in an HTTP handler do roughly the following:
Unfortunately, I don't yet have a simple program that reproduces the issue.
What did you expect to see?
No panics.
What did you see instead?
and, more often
If non-context method versions are used, there's no panic.
Might be a problem with
go-sqlite3, for all I know.The text was updated successfully, but these errors were encountered: