Skip to Content.
Sympa Menu

freetds - RE: infinte loop

freetds AT lists.ibiblio.org

Subject: FreeTDS Development Group

List archive

Chronological Thread  
  • From: "Thompson, Bill D (London)" <ThompBil AT exchange.uk.ml.com>
  • To: "'TDS Development Group'" <freetds AT franklin.oit.unc.edu>
  • Subject: RE: infinte loop
  • Date: Thu, 24 Oct 2002 21:54:45 +0100


John

tds.h:#define TDS_ROW_RESULT 4040
tds.h:#define TDS_ROWFMT_RESULT 4049

Bill
> -----Original Message-----
> From: Wilson, John [SMTP:John.Wilson AT Savvis.net]
> Sent: Thursday, October 24, 2002 9:31 PM
> To: TDS Development Group
> Subject: [freetds] RE: infinte loop
>
> Additional info from the tdsdump file. This shows in the ASCII column
> that
> the select statement is being sent and it's "inside ct_send()".
> [...]
> 2002-10-24 14:54:35.887781 inside ct_command()
> 2002-10-24 14:54:35.887977 inside ct_send()
> Sending packet @ 2002-10-24 14:54:35.888180
> 0000 01 01 00 98 00 00 01 00 73 00 65 00 6c 00 65 00 |........s
> .e.l.e.|
> 0010 63 00 74 00 20 00 64 00 61 00 74 00 75 00 6d 00 |c.t. .d.a
> .t.u.m.|
> 0020 5f 00 64 00 65 00 66 00 5f 00 69 00 64 00 2c 00 |_.d.e.f._
> .i.d.,.|
> 0030 20 00 69 00 70 00 61 00 64 00 64 00 72 00 2c 00 | .i.p.a.d
> .d.r.,.|
> 0040 20 00 76 00 61 00 72 00 69 00 61 00 62 00 6c 00 | .v.a.r.i
> .a.b.l.|
> 0050 65 00 2c 00 20 00 69 00 6e 00 73 00 74 00 61 00 |e.,. .i.n
> .s.t.a.|
> 0060 6e 00 63 00 65 00 20 00 66 00 72 00 6f 00 6d 00 |n.c.e. .f
> .r.o.m.|
> 0070 20 00 44 00 41 00 54 00 55 00 4d 00 2e 00 64 00 | .D.A.T.U
> .M...d.|
> 0080 62 00 6f 00 2e 00 64 00 61 00 74 00 75 00 6d 00 |b.o...d.a
> .t.u.m.|
> 0090 5f 00 64 00 65 00 66 00 |_.d.e.f.|
>
> 2002-10-24 14:54:35.888676 ct_send() succeeded
> 2002-10-24 14:54:35.889062 inside ct_results()
> Received header @ 2002-10-24 14:54:35.890422
> 0000 04 00 10 00 00 3f 01 00 |.....?..|
>
> jdw> comment> this appears to return column data and dies
> about 8 bytes before it's completed. Possilbly a counter problem?
>
> Received packet @ 2002-10-24 14:54:35.890718
> 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..
> .......|
> 0070 00 31 36 37 2e 37 36 2e 33 2e 32 32 31 18 00 2e |.167.76.3
> .221...|
> 0080 31 2e 33 2e 36 2e 31 2e 32 2e 31 2e 32 35 2e 32 |1.3.6.1.2
> .1.25.2|
> 0090 2e 33 2e 31 2e 35 2e 01 00 35 d1 05 01 e7 96 98 |.3.1.5...
> 5......|
> [...]
> 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-24 14:54:35.897704 processing result tokens. marker is 81
> 2002-10-24 14:54:35.897899 inside ct_results() process_result_tokens
> returned 1 (type 4049)
> 2002-10-24 14:54:35.898077 processing result tokens. marker is d1
> 2002-10-24 14:54:35.898254 inside ct_results() process_result_tokens
> returned 1 (type 4040)
> 2002-10-24 14:54:35.899049 inside ct_results()
> etc...
>
> I'm looking for the meaning of 4040 and 4049 now.
> regards,
> john
>
> -----Original Message-----
> From: Wilson, John
> Sent: Thursday, October 24, 2002 3:11 PM
> To: TDS Development Group
> Subject: [freetds] RE: infinte loop
>
>
> Bill,
> I think there are some changes in the way the low level ct_ methods
> work between OCS 12.0 and FreeTDS.
>
> I've not been able to get sqsh to run. I've got the binary
> for sqsh 2.1 and I'm getting this error:
>
> $ sqsh -S RTDBASESQL -U user -P passnotshown
> sqsh-2.1 Copyright (C) 1995-2001 Scott C. Gray
> [...]
> \connect: Unable to install message callback
>
> I would like to try this but I need to fix the real problem
> right now.
>
> I've tracked down the problem to this section of code:
>
> ______________________________________________________
> if ( $db->ct_execute($cmd) != &CS_SUCCEED ) {
> internalSybaseStackTrace();
> return ( -1, undef );
> }
>
> if ($sybase::debug_sql) { print STDERR "==>>>sql = $cmd\n" }
>
> $max = $db->{'MaxRows'};
> $res_type = 0; # avoid 'unitialized variable'
> warnings...
> $flag = 0 unless $flag;
>
> #jdw>
> if ($sybase::debug_results) { print "Sybase_ct_sql: entering while
> loop...\n"; }
>
> --->while ( ( $rc = $db->ct_results($res_type) ) == &CS_SUCCEED ) {
> <--------
> if ($sybase::debug_results) {
> printf STDERR "Sybase_ct_sql: results rc=$rc
> res_type=$res_type\n";
> }
> if ( $res_type == &CS_CMD_FAIL ) {
> if ( $SYBASE_CT_SQL::save_error == 1205 ) {
> print "Sybase_ct_sql: save_error = 1205, calling
> ct_res_info()...\n";
> # Only retry if not in a transaction
> my $tran_level = $db->ct_res_info(&CS_TRANS_STATE);
> [...]
> ______________________________________________________
>
> The script output:
>
> blog1: 10/24/2002 14:37:06 executing sql command:^M
> select datum_def_id, ipaddr, variable, instance from DATUM.dbo.datum_def^M
> calling SybaseSimpleSQL...
> SybaseSimpleSQL: begin timing...^M
> SybaseSimpleSQL: login.dbh= Sybase::CTlib=HASH(0x29a3c4)^M
> SybaseSimpleSQL: Entering^M
> SybaseSimpleSQL: rowcallback defined...^M
> Sybase_ct_sql:^M
> db=Sybase::CTlib=HASH(0x29a3c4)^M
> cmd=select datum_def_id, ipaddr, variable, instance from
> DATUM.dbo.datum_def^M
> sub=CODE(0x22bbc4)^M
> flag=1^M
> ==>>>sql = select datum_def_id, ipaddr, variable, instance from
> DATUM.dbo.datum_def^M
> Sybase_ct_sql: entering while loop...^M
> Sybase_ct_sql: results rc=1 res_type=4040^M
> Sybase_ct_sql: results rc=1 res_type=4040^M
> Sybase_ct_sql: results rc=1 res_type=4040^M
> Sybase_ct_sql: results rc=1 res_type=4040^M
> etc...
>
> I'm investigating if the $res_type set to 0 makes any difference in the
> behavior of ct_results(). Also I'm looking for the best source of info on
> the data types, the info returned in tdsdump and the above res_type 4040.
> What does this mean? Maybe ct_resuls() is not able to handle this? Or is
> it my code? It would appear to be the former, assuming sending in the
> $res_type = 0 is not hurting anything.
>
> Maybe this while-loop needs to check for this other return code? Which
> brings me to ask where do I find these return codes for FreeTDS?
>
> regards,
> jd
>
>
> -----Original Message-----
> From: Thompson, Bill D (London)
> Sent: Thursday, October 24, 2002 10:52 AM
> To: TDS Development Group
> Subject: [freetds] RE: infinte loop
>
>
> John,
>
> > What's interesting to note, is that this perl code is currently running
> > against Sybase's CTlib libraries (Sybase
> Client-Library/12.0/P/SPARC/Solaris
> > 2.5.1/1/OPT/Mon Oct 4 12:07:29 1999). So what would have changed in
> the
> > ct_results() processing between the Sybase version and FreeTDS version?
>
> Well, plenty might be different.
> Given it's complexity, It's entirely possible that I've misunderstood how
> the results processing is supposed to work!
>
> > I'm using tsql to test some of the select/insert SQL calls found in the
> > source code. Some errors are not accepting the table name w/o prefixing
> it
> > with the DB name, e.g., DATUM.dbo.datum_def vs datum_def. I suspect
> that
> > some of the SQL syntax may be more restrictive with SQL Server 2000.
> > Another interesting observation is that after fixing the SQL syntax,
> under
> > tsql, the command works, but not when ran programmatically. Again, some
> > re-working of the source would help.
>
> No offence to the authors of that fine program, but I don't think tsql is
> the right tool for the job here.
> It was written to provide a very basic test harness that would help new
> freetds users to test basic connectivity to their databases, without
> having
> to bring in any other code that might add complexity. and thus make basic
> testing more difficult.
>
> Once you're up and running connectivity-wise, I'd recommend you use sqsh
> 1.7, which has the added advantage of using the ct library API .
>
> send me the perl code, if it's not too unwieldy or sensitive!
>
> Bill
>
> > -----Original Message-----
> > From: Wilson, John
> > Sent: Thursday, October 24, 2002 4:37 PM
> > To: TDS Development Group
> > Subject: [freetds] RE: infinte loop
> >
> > Bill,
> > Thanks for this information. The software I'm working on was inherited,
> > so
> > I have a lot to learn about the ct_ methods and the protocol.
> >
> > I think there is a better way to handle this process using
> > DBI/DBD::Sybase.
> > The perl source is using Sybase::CTlib methods and I've been trying to
> get
> > them to work using FreeTDS connecting to SQL Server 2000. I've managed
> to
> > get the FreeTDS Sybase::CTlib working with TDSVER set to version 7.0.
> > I've
> > found some conflicting documentation that says I should be using version
> > 8.0, but 7.0 is working pretty well, with the exception of this infinite
> > looping problem... which may very well be in our perl code.
> >
> > What's interesting to note, is that this perl code is currently running
> > against Sybase's CTlib libraries (Sybase
> > Client-Library/12.0/P/SPARC/Solaris
> > 2.5.1/1/OPT/Mon Oct 4 12:07:29 1999). So what would have changed in
> the
> > ct_results() processing between the Sybase version and FreeTDS version?
> >
> > I'm using tsql to test some of the select/insert SQL calls found in the
> > source code. Some errors are not accepting the table name w/o prefixing
> > it
> > with the DB name, e.g., DATUM.dbo.datum_def vs datum_def. I suspect
> that
> > some of the SQL syntax may be more restrictive with SQL Server 2000.
> > Another interesting observation is that after fixing the SQL syntax,
> under
> > tsql, the command works, but not when ran programmatically. Again, some
> > re-working of the source would help.
> >
> > I'll dig into this and if I find some interesting things to pass along I
> > will. I think I need to review the processing of the ct_results first
> and
> > make sure this is being done correctly.
> > regards,
> > jd
> >
> > -----Original Message-----
> > From: Thompson, Bill D (London)
> > Sent: Thursday, October 24, 2002 3:21 AM
> > To: TDS Development Group
> > Subject: [freetds] RE: infinte loop
> >
> >
> > 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 found a ct_cancel() menthod but have not looked into this yet.
>
> >
> > 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')





Archive powered by MHonArc 2.6.24.

Top of Page