errors that occur while reading resultsets not handled properly

[ncabatoff]

I had an issue where a program got stuck while executing its query, constantly accruing RAM and CPU without moving forward. From the stack trace and code inspection and sybase logs, here's what I think happened. While I was consuming a large resultset, Sybase got killed. As a result fetchResults got stuck busylooping (because it never saw REG_ROW or NO_MORE_ROWS), and errHandler kept appending the same error to conn.Error. Looking at http://www.freetds.org/userguide/samplecode.htm it would appear that the cases BUF_FULL and FAIL should also be handled in fetchResults.

Stack trace:

runtime.memmove(0xc8293ce000, 0xc82d6e0000, 0x43117ba)
        /opt/intelerad/lib/golang/src/runtime/memmove_amd64.s:83 +0x91 fp=0xc824dc8ea0 sp=0xc824dc8e98
runtime.concatstrings(0x0, 0xc824dc9030, 0x2, 0x2, 0x0, 0x0)
        /opt/intelerad/lib/golang/src/runtime/string.go:52 +0x30b fp=0xc824dc8fd8 sp=0xc824dc8ea0
runtime.concatstring2(0x0, 0xc82d6e0000, 0x43117ba, 0xc82509afc0, 0x35, 0x0, 0x0)
        /opt/intelerad/lib/golang/src/runtime/string.go:59 +0x67 fp=0xc824dc9028 sp=0xc824dc8fd8
github.com/minus5/gofreetds.errHandler(0xf046b0, 0x4e4f00000001, 0xc800000000, 0x7ffff7bbcf30, 0x7ffff770bf87, 0xc824dc9188)
        /builddir/build/BUILD/dbms_exporter-5d72ad0436a4f4b4b31a3d952e52cd7a3b7c139f/src/github.com/minus5/gofreetds/callbacks.go:39 +0x6b9 fp=0xc824dc9140 sp=0xc824dc9028
github.com/minus5/gofreetds._cgoexpwrap_7ce7804be3a3_errHandler(0xf046b0, 0x4e4f00000001, 0x0, 0x7ffff7bbcf30, 0x7ffff770bf87, 0x4312000)
        github.com/minus5/gofreetds/_obj/_cgo_gotypes.go:603 +0x4d fp=0xc824dc9178 sp=0xc824dc9140
runtime.call64(0x0, 0x7fffffffe7a8, 0x7fffffffe830, 0x30)
        /opt/intelerad/lib/golang/src/runtime/asm_amd64.s:473 +0x3e fp=0xc824dc91c0 sp=0xc824dc9178
runtime.cgocallbackg1()
        /opt/intelerad/lib/golang/src/runtime/cgocall.go:267 +0x10c fp=0xc824dc91f8 sp=0xc824dc91c0
runtime.cgocallbackg()
        /opt/intelerad/lib/golang/src/runtime/cgocall.go:180 +0xd7 fp=0xc824dc9258 sp=0xc824dc91f8
runtime.cgocallback_gofunc(0x40aaa3, 0x831190, 0xc824dc92d8)
        /opt/intelerad/lib/golang/src/runtime/asm_amd64.s:716 +0x60 fp=0xc824dc9268 sp=0xc824dc9258
runtime.asmcgocall(0x831190, 0xc824dc92d8)
        /opt/intelerad/lib/golang/src/runtime/asm_amd64.s:567 +0x42 fp=0xc824dc9270 sp=0xc824dc9268
runtime.cgocall(0x831190, 0xc824dc92d8, 0x100000000000000)
        /opt/intelerad/lib/golang/src/runtime/cgocall.go:124 +0x133 fp=0xc824dc92a0 sp=0xc824dc9270
github.com/minus5/gofreetds._Cfunc_dbnextrow(0xf046b0, 0x0)
        github.com/minus5/gofreetds/_obj/_cgo_gotypes.go:304 +0x3d fp=0xc824dc92d8 sp=0xc824dc92a0
github.com/minus5/gofreetds.(*Conn).fetchResults(0xc8200dd400, 0x0, 0x0, 0x0, 0x0, 0x0)
        /builddir/build/BUILD/dbms_exporter-5d72ad0436a4f4b4b31a3d952e52cd7a3b7c139f/src/github.com/minus5/gofreetds/fetch.go:72 +0xd45 fp=0xc824dc9528 sp=0xc824dc92d8

[ianic]

Great explanation.
Thanks ncabatoff.

[MarkSonghurst]

I'm currently testing a fix for this.