Skip to content
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

database/sql: Strange Errors when Closing a Tx's Prepared Statement after Commit #4459

Closed
gopherbot opened this issue Nov 28, 2012 · 16 comments
Closed

Comments

@gopherbot
Copy link

@gopherbot gopherbot commented Nov 28, 2012

by johnkgallagher:

What steps will reproduce the problem?

This test function demonstrates the problem (note that this won't actually run on
play.golang.org because of the dependency on go-sqlite3):
http://play.golang.org/p/mKL22tAoxR

The code is wrong, but the errors it produces are very confusing and don't at all point
to the actual problem. On line 19, a transaction's prepared statement's Close() is
deferred. However, the transaction is committed before returning from the function,
which means the Close() happens after the Commit. Depending on the driver, this can
cause:

1. Silent lockup (observed with both go-sqlite3 and github.com/bmizerany/pq)
2. Very odd driver messages (pq reported nonsensical errors, like "expected 4
arguments, got 1" on a query that had 1 argument)
3. Memory corruption panic (observed with go-sqlite3 (cgo))

What is the expected output?

Nothing (success)

What do you see instead?

Sometimes success, more often either a lockup or "panic: runtime error: invalid
memory address or nil pointer dereference". Commenting out line 19 and uncommenting
line 29 fixes the problem.

Which compiler are you using (5g, 6g, 8g, gccgo)?

6g

Which operating system are you using?

Mac OS X, Linux

Which version are you using?  (run 'go version')

1.0.3

Please provide any additional information below.

I'm not sure this is necessarily a bug in database/sql, since the documentation does say
that a prepared statement can't be used after a transaction is committed/rolled back.
However, it would be nicer if it coped with this more gracefully, as it seemed
"natural" (although clearly wrong) to defer the Stmt.Close(). Any of the
following would have been preferable (to me, at least) than the debugging I did:

1. Transaction closes its open statements inside Commit/Rollback
2. Stmt.Close() panics if it's called outside the transaction
3. Stmt.Close() does nothing if it's called outside the transaction
@bradfitz
Copy link
Contributor

@bradfitz bradfitz commented Nov 29, 2012

Comment 1:

Owner changed to @bradfitz.

Status changed to Accepted.

@rsc
Copy link
Contributor

@rsc rsc commented Dec 10, 2012

Comment 2:

Labels changed: added size-m.

@rsc
Copy link
Contributor

@rsc rsc commented Dec 10, 2012

Comment 3:

Labels changed: added suggested.

@rsc
Copy link
Contributor

@rsc rsc commented Dec 30, 2012

Comment 4:

Labels changed: added priority-later, removed priority-triage.

@gwenn
Copy link

@gwenn gwenn commented Jan 12, 2013

Comment 5:

Hello,
For the sqlite driver, I've found where the issue comes from:
The prepared statements are closed twice:
 - when the Tx is committed, the underlying conn is closed and the sqlite driver tries to close dangling statements,
 - with the deferred Stmt.Close.
Just comment out the following block in the sqlite driver to do a quick and dirty fix:
func (c *SQLiteConn) Close() error {
    /*s := C.sqlite3_next_stmt(c.db, nil)
    for s != nil {
        C.sqlite3_finalize(s)
        s = C.sqlite3_next_stmt(c.db, s)
    }*/
    rv := C.sqlite3_close(c.db)
I will attempt to fix the driver.
Regards.
@gwenn
Copy link

@gwenn gwenn commented Jan 13, 2013

Comment 6:

Ok,
I've just submitted a patch to mattn that fix the issue on the driver side:
mattn/go-sqlite3#37
For postgresql, I don't have it installed.
If you ask me, I can install it and investigate...
Regards.
@rsc
Copy link
Contributor

@rsc rsc commented Mar 12, 2013

Comment 7:

Labels changed: added go1.1maybe, removed go1.1.

@robpike
Copy link
Contributor

@robpike robpike commented May 18, 2013

Comment 8:

Labels changed: added go1.2maybe, removed go1.1maybe.

@rsc
Copy link
Contributor

@rsc rsc commented Sep 9, 2013

Comment 9:

Labels changed: added go1.3maybe, removed go1.2maybe.

@rsc
Copy link
Contributor

@rsc rsc commented Dec 4, 2013

Comment 10:

Labels changed: added release-none, removed go1.3maybe.

@rsc
Copy link
Contributor

@rsc rsc commented Dec 4, 2013

Comment 11:

Labels changed: added repo-main.

@gopherbot
Copy link
Author

@gopherbot gopherbot commented Nov 2, 2014

Comment 12 by marko@joh.to:

This should be fixed in 1.4 by https://code.google.com/p/go/source/detail?r=50ce4ec65c4a.
@rsc rsc added this to the Unplanned milestone Apr 10, 2015
@s7v7nislands
Copy link

@s7v7nislands s7v7nislands commented Nov 2, 2016

@bradfitz bradfitz removed their assignment Nov 8, 2016
@bradfitz
Copy link
Contributor

@bradfitz bradfitz commented Nov 8, 2016

@kardianos
Copy link
Contributor

@kardianos kardianos commented Nov 8, 2016

I'll look into it.

@kardianos
Copy link
Contributor

@kardianos kardianos commented Nov 16, 2016

Yes, this could be closed.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
7 participants
You can’t perform that action at this time.