DBD::Sybase-0.21 hangs on testing
Brian Bruns
camber at umcc.ais.org
Mon Dec 27 14:44:33 EST 1999
This is really odd.
On Fri, 24 Dec 1999, John Gilmore-Baldwin wrote:
> I'm having trouble getting gdb to work right for me. But for the time
> being, here's the log (I only posted the beginning, the rest just keeps
> repeating until the 16K log is filled up.):
>
> dmr6:baldwin:7:baldwin:% more /tmp/freetds.log
> Sending packet @ 1999-12-24 20:58:42
> 0000 02 00 02 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
> 0010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
[snip]
> 1999-12-24 20:58:42 inside tds_process_login_tokens()
> 1999-12-24 20:58:42 inside tds_process_default_tokens() marker is e3
> 1999-12-24 20:58:42 inside tds_process_default_tokens() marker is ab
> 1999-12-24 20:58:42 inside tds_process_default_tokens() marker is e3
> 1999-12-24 20:58:42 inside tds_process_default_tokens() marker is e3
> 1999-12-24 20:58:42 inside tds_process_default_tokens() marker is fd
> 1999-12-24 20:58:42 leaving tds_process_login_tokens() returning 1
> 1999-12-24 20:58:42 leaving ct_connect() returning 1
> 1999-12-24 20:58:42 inside ct_options()
> 1999-12-24 20:58:42 inside ct_capability()
> 1999-12-24 20:58:42 inside ct_cancel()
> Sending packet @ 1999-12-24 20:58:42
> 0000 06 01 00 08 00 00 00 00 |........|
>
This is a cancel (Packettype 0x06). What the server should send is a fd
(done) token to acknowledge this. Instead we get:
>
> 1999-12-24 20:58:42 inside tds_process_default_tokens() marker is d1
> 1999-12-24 20:58:42 setting column 0 to NULL
> 1999-12-24 20:58:42 setting column 1 to NULL
> 1999-12-24 20:58:42 setting column 2 to NULL
> 1999-12-24 20:58:42 setting column 3 to NULL
> 1999-12-24 20:58:42 setting column 4 to NULL
> 1999-12-24 20:58:42 setting column 5 to NULL
> 1999-12-24 20:58:42 setting column 6 to NULL
> 1999-12-24 20:58:42 setting column 7 to NULL
> 1999-12-24 20:58:42 setting column 8 to NULL
> 1999-12-24 20:58:42 setting column 9 to NULL
> 1999-12-24 20:58:42 setting column 10 to NULL
> 1999-12-24 20:58:42 setting column 11 to NULL
> 1999-12-24 20:58:42 setting column 12 to NULL
> 1999-12-24 20:58:42 setting column 13 to NULL
> 1999-12-24 20:58:42 setting column 14 to NULL
> 1999-12-24 20:58:42 setting column 15 to NULL
> 1999-12-24 20:58:42 setting column 16 to NULL
> 1999-12-24 20:58:42 setting column 17 to NULL
> 1999-12-24 20:58:42 setting column 18 to NULL
> 1999-12-24 20:58:42 setting column 19 to NULL
> 1999-12-24 20:58:42 setting column 20 to NULL
> 1999-12-24 20:58:42 inside tds_process_default_tokens() marker is d1
> 1999-12-24 20:58:42 setting column 0 to NULL
and repeats. This means the dataserver is sending 20 columns of NULL data
back forever. Smells like a MS SQL bug we are perhaps triggering.
As a short term hack you could edit src/ctlib/ct.c in the function
ct_cancel() and just comment out everything but the return statement and
see if that works. I'll keep looking though.
Brian
More information about the FreeTDS
mailing list