FreeTDS Development Group

["Varley, David(CBorn at Alcoa)" <David.Varley AT alcoa.com.au>]

Jim,
I've done some testing using clean builds, latest CVS code,
on Tru64 and x86 Linux, different versions of tds. The Linux
and Tru64 code seem to have the same result.

tds
4.2     Crashes SQL Server !!!
5.0     Drops connection and loops, filling log file
7.0     Works. (Well, claims to, more later!)
8.0     Hangs

This is using dblib t0016, t0017 is pretty much the same

t0016 claims to work, but the input and output are different,
I've attached them here. The out file null-filled as well as
having the wrong floats, which doesn't show on a simple cat
of the file.

Using tds 7.0, t0017 doesn't crash, but baulks at allocating
2147482647 bytes of memory!

Now, some unrelated configuration strangeness...
I'm building from the one source tree, into parallel object
trees for Linux and Tru64. The lastest source, into completely
empty build directorys, gives strangely different results.
On the Linux system, the extra files are not copies across by
the make. This includes PWD, the data.bin and txxx.in files, and
the freetds.conf files. I had to give "make all-redirect" and
"make install-data-local" commands to copy this data.
On the Tru64 system these were copied as part of the normal make.
This used to work on Linux.

Now on the Tru64 system, the first time you do a top level make, it
gets through just about everything, then spits out what looks like
several pages of source, complains of a "gawk syntax error", and quits.
If you try "make" again, it runs through without actually building
anything else, and appears to be quite happy. I'm assuming this is
a documentation build problem, the man pages are created with zero
size.


> -----Original Message-----
> From: Lowden, James K [mailto:LowdenJK AT bernstein.com]
> Sent: Friday, 13 September 2002 3:09 AM
> To: TDS Development Group
> Subject: [freetds] RE: DBLIB Unit Tests failing again
> 
> 
> > From: Varley, David(CBorn at Alcoa) 
> [mailto:David.Varley AT alcoa.com.au]
> > Sent: September 11, 2002 6:51 PM
> > 
> > I got a nice big freetds.log for you. After it crashed the
> > server t0016 kept writing to the log until /tmp filespace
> > ran out. (Luckily its mounted on mfs and only 10MB!)
> > I truncated it, attached.
> 
> Looking at the log, it seems likely that FreeTDS kept 
> retrying the socket
> even though it was closed.  I think this is related to the 
> cancel processing
> fix.  As Brian said (paraphrasing), that's a nasty piece of 
> work that needs
> a firm hand.  But that's not what's crashing your server.  
> 
> David, is this behvior restricted to TDS 4.2 with t0016?  I 
> wonder if it
> might not be a matter of us lying to the server about the length of
> something, causing it to stupidly not allocate (or over 
> allocate) room for
> the incoming row.  
> 
> I also notice that t0016.c doesn't call bcp_done() between 
> bcp_exec() and
> the next bcp_init(), nor between bcp_exec() and dbsqlexec().  
> That not good.
> We shouldn't be able to crash the server, but nonetheless we 
> should call
> bcp_done() as appropriate.  
> 
> from the bcp_done() docs:
> 
>       Remarks
> 
>       Call bcp_done after the last call to bcp_sendrow 
>       or bcp_moretext. Failure to call bcp_done after 
>       copying in all your data results in unpredictable errors.  
> 
> Brian, does any of this coincide with your 12.5 experience?  
> 
> --jkl

Attachment: t0016.in
Description: Binary data

Attachment: t0016.out
Description: Binary data