Skip to Content.
Sympa Menu

freetds - Re: Bug in ct.c causes hangs on broken connections

freetds AT lists.ibiblio.org

Subject: FreeTDS Development Group

List archive

Chronological Thread  
  • From: Mark Schaal <mark AT champ.tstonramp.com>
  • To: freetds AT franklin.oit.unc.edu
  • Subject: Re: Bug in ct.c causes hangs on broken connections
  • Date: Thu, 11 May 2000 13:34:47 -0700 (PDT)



I believe the ctlib code is generally correct, but it wasn't
updated to deal with the SIGPIPE error handling that Geoff Winkless
(I believe) added. I'd be obliged if you could try the following:

case TDS_FAIL:
if (tds->state == TDS_DEAD) {
return CS_FAIL;
}
else {
*result_type = CS_CMD_FAIL;
return CS_SUCCEED;
}



It's been a while since when I was deep into the
ctlib APIs, but this is my simplified view of why a TDS_FAIL
doesn't always imply a CS_FAIL.

When the server returns multiple result sets, there are two main
failure possibilities. We can have the entire response fail,
causing a return of CS_FAIL to show that no results are available.
OR, we can have a single result set fail but with the possibility
of there still being more result sets to read. In this case we
return CS_SUCCEED to show that we need to keep processing the
result loop, but we set *result_type to CS_CMD_FAIL to show that
the current result set is invalid.

Hope that helps,

Mark

>
> Hi,
>
> With the current CVS release of freetds and DBD::Sybase (0.22) I was
> having problems when the connection to ms-sql server 7.0 died.
> Essentially I have a test program that opens a connection, executes
> $dbh->ping and prompts me to press a key after stopping the database.
> Once the connection has closed it pings again.
>
> The result being that I get the errors:
>
> TDS: Write failed in tds_write_packet
> Error: 32 (Broken pipe)
>
> and then the process hangs.
>
> Setting TDSDUMP I discovered that it was stuck in a loop, with the
> following being repeated ad infinitum:
>
> 2000-05-11 20:24:14 inside ct_results()
> 2000-05-11 20:24:14 processing result tokens. marker is 0
> 2000-05-11 20:24:14 inside tds_process_default_tokens() marker is 0
> 2000-05-11 20:24:14 leaving tds_process_default_tokens() connection dead
>
> Examining the code, line 340 of src/ctlib/ct.c (1.45)looks to be the
> culprit as the routine returns CS_SUCCEED when the call to
> tds_process_result_tokens fails returning TDS_FAIL. Changing the value
> returned by ct_results to CS_FAIL causes my test script to do the right
> thing, after amending the ping routine in DBD::Sybase to check for
> $sth->execute being undefined.
>
> Hopefully this is the right fix!
>
>
> Cheers,
>
>
> Chris.


--
Mark J. Schaal Phone: (909) 620-7724
TST On Ramp Fax: (909) 620-8174
System Administrator E-Mail: mark AT tstonramp.com




Archive powered by MHonArc 2.6.24.

Top of Page