search

alexbrainman / odbc

odbc driver written in go
BSD 3-Clause "New" or "Revised" License
352 stars 140 forks source link

TestMSSQLCreateInsertDelete fails with "runtime error: cgo argument has Go pointer to Go pointer" #65

Closed alexbrainman closed 8 years ago

alexbrainman commented 8 years ago

To reproduce the issue:

# go version
go version devel +e7524d5 Tue Feb 23 03:42:38 2016 +0000 linux/386
# git rev-parse HEAD
0b921e2fc9e7d0801ec6e9d39caf2ea378895e90
# go test -mssrv=aursql001 -msdb=pos -msuser=webappsvr -mspass=was4 -v -run=TestMSSQLCreateInsertDelete
=== RUN   TestMSSQLCreateInsertDelete
--- FAIL: TestMSSQLCreateInsertDelete (0.03s)
        mssql_test.go:137: unexpected StmtCount: should=0, is=1
panic: runtime error: cgo argument has Go pointer to Go pointer [recovered]
        panic: runtime error: cgo argument has Go pointer to Go pointer

goroutine 5 [running]:
panic(0x81f8420, 0x185264c8)
        /root/go/src/runtime/panic.go:483 +0x331
testing.tRunner.func1(0x185a6120)
        /root/go/src/testing/testing.go:467 +0x14f
panic(0x81f8420, 0x185264c8)
        /root/go/src/runtime/panic.go:441 +0x40b
github.com/alexbrainman/odbc/api.SQLBindCol(0x833aa50, 0x40002, 0x1851a3ac, 0x4, 0x1851a39c, 0x18568500)
        /root/src/github.com/alexbrainman/odbc/api/zapi_unix.go:28 +0x7f
github.com/alexbrainman/odbc.(*BufferLen).Bind(0x1851a39c, 0x833aa50, 0x1, 0x4, 0x1851a3ac, 0x4, 0x8, 0x18568500)
        /root/src/github.com/alexbrainman/odbc/column.go:32 +0x52
github.com/alexbrainman/odbc.(*BindableColumn).Bind(0x1851a390, 0x833aa50, 0x1, 0x1851a390, 0x0, 0x0)
        /root/src/github.com/alexbrainman/odbc/column.go:218 +0x70
github.com/alexbrainman/odbc.(*ODBCStmt).BindColumns(0x1851a330, 0x0, 0x0)
        /root/src/github.com/alexbrainman/odbc/odbcstmt.go:146 +0x2c8
github.com/alexbrainman/odbc.(*Stmt).Query(0x18514b00, 0x831e894, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0)
        /root/src/github.com/alexbrainman/odbc/stmt.go:95 +0x23e
database/sql.rowsiFromStatement(0xb6c68490, 0x1850a500, 0xb6c68468, 0x18514b00, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, ...)
        /root/go/src/database/sql/sql.go:1654 +0x2cd
database/sql.(*DB).queryConn(0x185a6180, 0x1850a500, 0x185264b8, 0x825edc0, 0x44, 0x0, 0x0, 0x0, 0x81c7ae0, 0x0, ...)
        /root/go/src/database/sql/sql.go:1118 +0x38d
database/sql.(*DB).query(0x185a6180, 0x825edc0, 0x44, 0x0, 0x0, 0x0, 0x754d401, 0x830e940, 0x0, 0x0)
        /root/go/src/database/sql/sql.go:1078 +0xd4
database/sql.(*DB).Query(0x185a6180, 0x825edc0, 0x44, 0x0, 0x0, 0x0, 0xb6c684e8, 0x0, 0x0)
        /root/go/src/database/sql/sql.go:1061 +0x7d
github.com/alexbrainman/odbc.TestMSSQLCreateInsertDelete(0x185a6120)
        /root/src/github.com/alexbrainman/odbc/mssql_test.go:328 +0x594
testing.tRunner(0x185a6120, 0x82fdc00)
        /root/go/src/testing/testing.go:473 +0x8f
created by testing.RunTests
        /root/go/src/testing/testing.go:582 +0x6f2
exit status 2
FAIL    github.com/alexbrainman/odbc    0.040s
#

It seems like new Go cgo function parameter checker is unhappy with something.

Alex

drewlesueur commented 8 years ago

Am I reading this right that it's a bug in cgo that has since been fixed? I am guessing we'll see it in the next release of Go. https://github.com/golang/go/issues/14483

In the meantime, I can still use this library with the GODEBUG=cgocheck=0 environment variable.

Thank you

alexbrainman commented 8 years ago

Am I reading this right that it's a bug in cgo that has since been fixed?

Kind of, but not really.

I am using current tip that has golang/go#14483 fixed, but I see the above crash just the same.

The crash is inside of CGO runtime checker that has been introduce in go1.6 (see https://golang.org/doc/go1.6#cgo for details). And while golang/go#14483 is based on this issue, these two issues are not exactly the same. Perhaps there is more to learn from my crash on the tip for the CGO runtime checker, but I don't have time to chase that. I will try to change my code to silence it instead.

I must also point that CGO runtime checker is complaining here for a reason - we have Go memory block that is written by external code long after call into external code returned. This breaks one of new CGO safety rules. But windows syscalls break these rules too, and Go does not have any solution for that yet. A lot of windows programs will break, if Go runtime will start using tricks that CGO "safety" rules are trying to allow. So I am not sure I will employ "proper" solution just yet. I don't know what needs to be done for windows yet.

In the meantime, I can still use this library with the GODEBUG=cgocheck=0 environment variable.

Yes. That does the trick. But inconvenient.

Alex