FreeTDS Development Group

["Thompson, Bill D (London)" <ThompBil AT exchange.uk.ml.com>]

Hi John,

I would need to see what code you are running that generates this loop, as
it appears possible that there is a fault in the ctlib code you are
executing rather than in freertds itself.

In short, from your tdsdump, I can see the following happening.

You've called ct_results(). This has read a "RESULTS" message from the
server (marker 81).
If you had called ct_config previously, setting the property CS_EXPOSE_FMTS
to CS_TRUE, this would then have returned control to your program, with
return code of CS_SUCCEED and result_type of CS_ROWFMT_RESULT.

If you had not called ct_config previously, ct_results() would have gone on
to read the next message from the server.
This message is a "ROW" message (marker d1). 
As I read the ct_results code, this should have then returned control to
your program, with return code of CS_SUCCEED and result_type of
CS_ROW_RESULT.

When you set up a ct_results() loop, after each successful return
(CS_SUCCEED) you should examine the result_type variable passed in to
ct_results().

When the result type is CS_ROW_RESULT, it indicates that there is data
available which requires fetching, using a call to ct_fetch(). If you don't
fetch this data, but continue to call ct_results(), it will continue to tell
you that you have rows to fetch, ad-infinitum I suppose. 

That's my take on what's happening here.

Very recently, a patch has been applied which extensively reworked the
results/row processing. 
In the course of doing this, I wnt back to basics on the ctlib code, and
basically re-coded it from the ctlib manual pages. 
The above is my understanding of how the ct-lib results processing should
work. 
Here's a small excerpt from the ct_results manual page which illustrates
this.

--------

The simplest way to read results is in a loop that terminates when
ct_results does not return CS_SUCCEED. After the loop, an application can
use a case-type statement to test ct_results' final return code and
determine why the loop terminated. The following rules apply to the logic of
a results handling loop: 
        ct_results returns CS_SUCCEED as long as results are still available
to the application.
        When ct_results sets result_type to a value that indicates fetchable
result data, the application must fetch or cancel the data before
continuing.
        ct_results sets the value of result_type to CS_CMD_DONE to indicate
that the results of a logical command have been completely processed.
Logical commands are explained under "ct_results and logical commands"
<@ebt-link;pt=52813?target=%25N%15_53584_START_RESTART_N%25>.
        ct_results returns CS_END_RESULTS when all results have been
processed successfully.
        ct_results returns CS_CANCELED if the application cancels the
results with ct_cancel(CS_CANCEL_ALL) or ct_cancel(CS_CANCEL_ATTN).

-------
  
Note the part that says "the application must fetch or cancel the data
before continuing". I'm not clear how one "cancels the data" before
continuing, though.

I hope this helps,

Bill


> -----Original Message-----
> From: Wilson, John [SMTP:John.Wilson AT savvis.net]
> Sent: Wednesday, October 23, 2002 10:37 PM
> To:   TDS Development Group
> Subject:      [freetds] RE: infinte loop
> 
> Sorry all, I ment to edit this further to help out.
> 
> the tdsdump starts out like this...
> 
> 
> Received packet @ 2002-10-23 16:16:54.157635
> 0000  81 04 00 00 00 08 00 6c  11 0a 00 0c 64 00 61 00   |.......l.
> ...d.a.|
> 0010  74 00 75 00 6d 00 5f 00  64 00 65 00 66 00 5f 00   |t.u.m._.d
> .e.f._.|
> 0020  69 00 64 00 00 00 08 00  a7 20 00 06 69 00 70 00   |i.d......
> ..i.p.|
> 0030  61 00 64 00 64 00 72 00  00 00 08 00 a7 80 00 08   |a.d.d.r..
> .......|
> 0040  76 00 61 00 72 00 69 00  61 00 62 00 6c 00 65 00   |v.a.r.i.a
> .b.l.e.|
> 0050  00 00 08 00 a7 50 00 08  69 00 6e 00 73 00 74 00   |.....P..i
> .n.s.t.|
> 0060  61 00 6e 00 63 00 65 00  d1 05 01 e6 96 98 00 0c   |a.n.c.e..
> .......|
> [...]
> 0fb0  32 2e 32 2e 31 2e 32 31  2e 01 00 32 d1 05 01 00   |2.2.1.21.
> ..2....|
> 0fc0  e2 e4 00 0e 00 31 36 37  2e 37 36 2e 31 32 37 2e   |.....167.
> 76.127.|
> 0fd0  31 30 31 11 00 2e 31 2e  33 2e 36 2e 31 2e 32 2e   |101...1.3
> .6.1.2.|
> 0fe0  31 2e 31 2e 31 2e 01 00  30 d1 05 01 01 e2 e4 00   |1.1.1...0
> .......|
> 0ff0  0e 00 31 36 37 2e 37 36                            |..167.76|
> 
> 
> 2002-10-23 16:16:54.165242 processing result tokens.  marker is  81
> 2002-10-23 16:16:54.165502 inside ct_results() process_result_tokens
> returned 1 (type 4049)
> 2002-10-23 16:16:54.165702 processing result tokens.  marker is  d1
> 2002-10-23 16:16:54.165909 inside ct_results() process_result_tokens
> returned 1 (type 4040)
> 2002-10-23 16:16:54.166884 inside ct_results()
> 2002-10-23 16:16:54.167070 processing result tokens.  marker is  d1
> 2002-10-23 16:16:54.167233 inside ct_results() process_result_tokens
> returned 1 (type 4040)
> 
> It appears to be running into some limit here @ x0ff0 and then gets caught
> up in this loop.
> It appears to be in ctlib/ct.c or related to this.
> 
> john
> 
> 
> -----Original Message-----
> From: Wilson, John 
> Sent: Wednesday, October 23, 2002 4:28 PM
> To: TDS Development Group
> Subject: [freetds] infinte loop
> 
> 
> TDS Group:
> 
> In the ongoing effort to get the old Sybase code working, I've run into an
> infinte loop at this point.  It fills up the tdsdump.txt file pretty
> quickly
> BTW.
> 
> 2002-10-23 16:16:54.165242 processing result tokens.  marker is  81
> 2002-10-23 16:16:54.165502 inside ct_results() process_result_tokens
> returned 1 (type 4049)
> 2002-10-23 16:16:54.165702 processing result tokens.  marker is  d1
> 2002-10-23 16:16:54.165909 inside ct_results() process_result_tokens
> returned 1 (type 4040)
> 2002-10-23 16:16:54.166884 inside ct_results()
> 2002-10-23 16:16:54.167070 processing result tokens.  marker is  d1
> 2002-10-23 16:16:54.167233 inside ct_results() process_result_tokens
> returned 1 (type 4040)
> 2002-10-23 16:16:54.167448 inside ct_results()
> 
> I'm looking into this now, but thought someone else may already be aware
> of
> it.
> 
> regards,
> jd
> 
> 
> ---
> You are currently subscribed to freetds as: [john.wilson AT savvis.net]
> To unsubscribe, forward this message to
> $subst('Email.Unsub')
> 
> ---
> You are currently subscribed to freetds as: [thompbil AT exchange.uk.ml.com]
> To unsubscribe, forward this message to
> $subst('Email.Unsub')