Re: RESULTS!!! Re: parameters missing in RC 64 Bits

Jim, I will work some more on this today. 

Igor

On Tue, Apr 22, 2008 at 03:10:49PM -0400, James K. Lowden wrote:
> Igor Chudov wrote:
> > :~/tmp/freetds/freetds-0.64 ==>(cd src/odbc/unittests && nohup make
> > check) nohup: ignoring input and appending output to `nohup.out'
> > *** glibc detected *** ./array_out: munmap_chunk(): invalid pointer:
> > 0x000000000063c8b0 *** ======= Backtrace: =========
> > /lib/libc.so.6(cfree+0x1b6)[0x2adec89b8d46]
> > ./array_out[0x4017a1]
> > ./array_out[0x4018f1]
> > /lib/libc.so.6(__libc_start_main+0xf4)[0x2adec895f1c4]
> > ./array_out[0x401229]
> 
> This tells us the error happened in ./array_out.  Now we're getting
> somewhere.  Let me parse the output for you, to help make clear what it
> means.  
> 
> > Here's the nohup output:
> 
> nohup captures standard output and standard error.  Because stderr is not
> buffered, it normally appears ahead of the contemporaneous stdout data. 
> That is, error messages usually appear ahead of the associated normal
> output.  
> 
> So: 
> 
> > odbctest
> ...
> > DROP TABLE TestTransaction
> > CREATE TABLE TestTransaction ( value INT )
> > DROP PROCEDURE testinsert
> ...
> > DROP TABLE TestTransaction
> > Done.
> > FAIL: transaction
> 
> was normal in 0.64.  IIRC it's now fixed.  
> 
> Then we see a bunch of "expected errors" from the next test:
> 
> 
> > Error setting type -5 (SQL_BIGINT)
> > Error setting type -3 (SQL_VARBINARY)
> > Error setting type -4 (SQL_LONGVARBINARY)
> ...
> > Error setting type -18 (SQL_C_ULONG)
> > Error setting type -17 (SQL_C_USHORT)
> > Error setting type -28 (SQL_C_UTINYINT)
> 
> ... followed by the standard output messages ....
> 
> > odbctest
> > 
> > connection parameters:
> > server:   'equinet'
> > user:     'sa'
> > password: '????'
> > database: 'tempdb'
> > use tempdb
> > Setted type SQL_C_CHAR -> [1 (SQL_C_CHAR), 1 (SQL_C_CHAR), 0]
> > Setted type SQL_C_LONG -> [4 (SQL_C_LONG), 4 (SQL_C_LONG), 0]
> ...
> > Setted type SQL_DECIMAL -> [3 (SQL_DECIMAL), 3 (SQL_DECIMAL), 0]
> > Setted type SQL_FLOAT -> [6 (SQL_FLOAT), 6 (SQL_FLOAT), 0]
> > PASS: type
> 
> Which means ./type passed but doesn't work for several datatypes.  
> 
> If you run ./type by itself on the command line without redirection,
> you'll see the messages interleaved, because stdio sets stdout to
> line-buffered mode when the output device is a terminal.  
> 
> The real problem comes at the tail end: 
> 
> > odbctest
> > 
> > connection parameters:
> > server:   'equinet'
> > user:     'sa'
> > password: '????'
> > database: 'tempdb'
> > use tempdb
> > CREATE TABLE #odbc_test(i INT, t TEXT)
> > INSERT INTO #odbc_test(i, t) VALUES(1, 'arow number 0')
> ..
> > INSERT INTO #odbc_test(i, t) VALUES(10, 'jrow number 117')
> > test line 154
> > /bin/bash: line 4: 22932 Aborted  ${dir}$tst
>                            ^^^^^^^ 
> 		bash telling us the executable aborted
> 
> > FAIL: array_out
> 
> I'm sure you already know ODBC has some built-in problems with 64-bit
> addressing because of the conflation of integer and pointer types in the
> interface specification.  
> 
> I'm not conversant enough in ODBC, let alone 64-bit ODBC, to tell you
> what's wrong.  If you run it under gdb and get a backtrace, you should at
> least see which function is failing.  Then I'd be inclined to turn to
> Google for help, because I'd expect someone else to have had this problem
> with other drivers.  
> 
> I should also point out some of these issues -- specifically SQLROWOFFSET
> as SQLLEN -- are definitely addressed in 0.82.  See ML messages in January
> on the subject "ODBC on 64 bit linux fix".  
> 
> HTH.  
>