FreeTDS Development Group

["ZIGLIO, Frediano, VF-IT" <Frediano.Ziglio AT vodafone.com>]

...
> 
> Yes, I agree with you. These two lines should be removed again. What I
> wanted to achieve here, is to prevent an endless loop when 
> all data from
> the server has been read from wire - but tds tries to read more.
> 
> These lines don't fix the bug, but workaround it - but at the cost of
> creating other bugs... So, it should be corrected.
> 
> Cheers,
> -Alex

I fully agree...

However I still do not understand the problem. From you mail:

"At the moment, when cancelling a query, a cancel packet is
being sent (that is, an empty packet with the headers out_flag set to
0x06 = attention packet). After this, all packets are read until an
acknowledgement of the cancel has been received.

Now, the wire does not contain more data - but as the cancel has been
sent asynchroneously, a client can (and e.g. sqsh often does) call one
of ct_results, ct_fetch and probably more. Thus, this all comes down to
goodread(); freetds tries to read data from the wire where there is no
data available. Due to the timeout handling code - this is being done
over and over again."

However ctlib send cancel and then process it... from ct.c

        if (conn && !IS_TDSDEAD(conn->tds_socket)) {
                tds_send_cancel(conn->tds_socket);
                tds_process_cancel(conn->tds_socket);
        }

Perhaps cancel take very long so goodread exit before the done/cancel ?
However with your patch behaviour would be worse...
If tds_process_cancel return success state is IDLE so
ct_fetch/ct_results should just return CS_FAIL...
I checked code and ct_fetch seems to call tds_peek without checking TDS
state... not that fine (IMHO it should call tds_process_row_tokens*
directly... however my ctlib knowledge is no so deep)

freddy77