FreeTDS Development Group

[Dossy Shiobara <dossy AT panoptic.com>]

Following up to my own message, I have some additional troubleshooting
information.

    (gdb) bt
    #0  0xffffe410 in __kernel_vsyscall ()
    #1  0xb7c86811 in raise () from /lib/tls/i686/cmov/libc.so.6
    #2  0xb7c87fb9 in abort () from /lib/tls/i686/cmov/libc.so.6
    #3  0xb7c7ffbf in __assert_fail () from /lib/tls/i686/cmov/libc.so.6
    #4  0xb7241085 in retname (retcode=0) at util.c:292
    #5  0xb72411b4 in tdserror (tds_ctx=0x80f9e78, tds=0x80856b8, 
msgno=20009, 
        errnum=115) at util.c:368
    #6  0xb725c724 in tds_open_socket (tds=0x80856b8, 
        ip_addr=0x8085b78 "10.6.113.5", port=1433, timeout=90000) at net.c:309
    #7  0xb7241def in tds_connect (tds=0x80856b8, connection=0x8085a58)
        at login.c:428
    #8  0xb7234b16 in DbOpen (handle=0x807f738) at nsfreetds.c:270
    #9  0xb7270b99 in NsDbOpen () from ./lib/libnsdb.so
    ...

It appears that "rc" in tdserror is set from the return of the message
handler?  Indeed, my custom handler messages both return "0" -- ack.
I've changed the error message handler to return TDS_INT_CANCEL.

Yes, I realize that direct use of libtds isn't supported, but this
caught me by surprise.  :-)

-- 
Dossy Shiobara              | dossy AT panoptic.com | http://dossy.org/
Panoptic Computer Network   | http://panoptic.com/
  "He realized the fastest way to change is to laugh at your own
    folly -- then you can let go and quickly move on." (p. 70)