crash on Linux (64bit)

[GoogleCodeExporter]

I have a small question about your odbc lib - I am running into the below on 
Linux (64bit):

Doesnt happen from windows, or with smaller queries.

Any idea? Thanks,

Kees

panic: unexpected handle type api.SQLHANDLE [recovered]
        panic: unexpected handle type api.SQLHANDLE

goroutine 4 [running]:
testing.func·004()
        /usr/local/go/src/pkg/testing/testing.go:348 +0xcd
code.google.com/p/odbc.ToHandleAndType(0x5de600, 0x1293d70, 0x0, 0x0)
        /home/kees/go/src/code.google.com/p/odbc/handle.go:28 +0x20d
code.google.com/p/odbc.NewError(0x69ca50, 0xd, 0x5de600, 0x1293d70, 0x8, ...)
        /home/kees/go/src/code.google.com/p/odbc/error.go:42 +0x40
code.google.com/p/odbc.releaseHandle(0x5de720, 0x1293d70, 0x49b19f, 0x0)
        /home/kees/go/src/code.google.com/p/odbc/handle.go:40 +0x191
code.google.com/p/odbc.(*ODBCStmt).releaseHandle(0xc2000a85a0, 0xc2000acd80, 
0x0)
        /home/kees/go/src/code.google.com/p/odbc/odbcstmt.go:89 +0x39
code.google.com/p/odbc.(*ODBCStmt).closeByStmt(0xc2000a85a0, 0x0, 0x0)
        /home/kees/go/src/code.google.com/p/odbc/odbcstmt.go:62 +0xc3
code.google.com/p/odbc.(*Stmt).Close(0xc2000abea0, 0xc2000abf30, 0xc2000acd80)
        /home/kees/go/src/code.google.com/p/odbc/stmt.go:40 +0xc4
database/sql.(*DB).queryConn(0xc2000ca240, 0xc2000accc0, 0xc2000bd4e0, 
0x6f6ad0, 0x618, ...)
        /usr/local/go/src/pkg/database/sql/sql.go:697 +0x44f
database/sql.(*DB).query(0xc2000ca240, 0x6f6ad0, 0x618, 0x0, 0x0, ...)
        /usr/local/go/src/pkg/database/sql/sql.go:652 +0x124
database/sql.(*DB).Query(0xc2000ca240, 0x6f6ad0, 0x618, 0x0, 0x0, ...)
        /usr/local/go/src/pkg/database/sql/sql.go:636 +0x89
mro/portal.TestOdbc(0xc2000c1000)
        /home/kees/go/src/mro/portal/portal_test.go:31 +0x19b
testing.tRunner(0xc2000c1000, 0x9f4180)
        /usr/local/go/src/pkg/testing/testing.go:353 +0x8a
created by testing.RunTests
        /usr/local/go/src/pkg/testing/testing.go:433 +0x86b

goroutine 1 [chan receive]:
testing.RunTests(0x6f1620, 0x9f4180, 0x1, 0x1, 0x1, ...)
        /usr/local/go/src/pkg/testing/testing.go:434 +0x88e
testing.Main(0x6f1620, 0x9f4180, 0x1, 0x1, 0xa0e160, ...)
        /usr/local/go/src/pkg/testing/testing.go:365 +0x8a
main.main()
        mro/portal/_test/_testmain.go:43 +

Original issue reported on code.google.com by alex.bra...@gmail.com on 21 Apr 2013 at 11:52

[GoogleCodeExporter]

Kees,

Please, add this line

diff --git a/handle.go b/handle.go
--- a/handle.go
+++ b/handle.go
@@ -33,6 +33,7 @@
 func releaseHandle(handle interface{}) error {
    h, ht := ToHandleAndType(handle)
    ret := api.SQLFreeHandle(ht, h)
+   fmt.Printf("releaseHandle: h=%v ht=%v ret=%v SQL_INVALID_HANDLE=%v\n", h, ht, 
ret, api.SQL_INVALID_HANDLE)
    if ret == api.SQL_INVALID_HANDLE {
        return fmt.Errorf("SQLFreeHandle(%d, %d) returns SQL_INVALID_HANDLE", ht, h)
    }

and show its output just before the crash. Thank you.

Alex

Original comment by alex.bra...@gmail.com on 21 Apr 2013 at 11:58

[GoogleCodeExporter]

Here you go:

releaseHandle: h=0x7f689402ac60 ht=3 ret=-1 SQL_INVALID_HANDLE=-2
--- FAIL: TestOdbc (0.08 seconds)
panic: unexpected handle type api.SQLHANDLE [recovered]
        panic: unexpected handle type api.SQLHANDLE

Original comment by k...@mroffice.org on 22 Apr 2013 at 12:31

[GoogleCodeExporter]

I think it's related to the query length: it's is rather big - 1559 characters, 
most of which are a long list of ID's: "where some_id in (1,2,3,5,8,9,etc)". 
The same query works from windows, and if I reduce the number of ID's to reduce 
the query length then the query runs on Linux too. Haven't found the sweet spot 
yet.

Original comment by k...@mroffice.org on 22 Apr 2013 at 1:00

[GoogleCodeExporter]

The interesting thing is that exactly the same code with exactly the same query 
sometimes fails, sometimes passes. 

fails looks like this:
releaseHandle: h=0x23ec760 ht=3 ret=-1 SQL_INVALID_HANDLE=-2

and passes look like this:
releaseHandle: h=0xcdd750 ht=3 ret=0 SQL_INVALID_HANDLE=-2

The ratio of passes over fails increases as the query gets shorter but there 
doesn't seem to be a pattern. Once it's under some size it seems to always 
pass. 

Original comment by k...@mroffice.org on 22 Apr 2013 at 1:16

[GoogleCodeExporter]

There is a bug here, for sure. It should not panic. Here is the fix 
https://codereview.appspot.com/8902044. Please, see, if it helps you. Instead 
of panicing, it should give you a proper error. Perhaps, it will give you a 
clue why it fails. It could be some limition of an odbc driver you use.

Alex

Original comment by alex.bra...@gmail.com on 22 Apr 2013 at 2:16

[GoogleCodeExporter]

OK the error was "Got unexpected EOF from server". 

I've managed to make the actual error go away too, by adding the tds version to 
the connection string: tds_version=8.0;

Thanks for your help!

Original comment by k...@mroffice.org on 22 Apr 2013 at 2:46

[GoogleCodeExporter]

This issue was closed by revision 0cc05e8b93ee.

Original comment by alex.bra...@gmail.com on 22 Apr 2013 at 3:00

• Changed state: Fixed