Skip to Content.
Sympa Menu

freetds - Re: [freetds] RESULTS!!! Re: parameters missing in RC 64 Bits

freetds AT lists.ibiblio.org

Subject: FreeTDS Development Group

List archive

Chronological Thread  
  • From: Igor Chudov <igor AT chudov.com>
  • To: "James K. Lowden" <jklowden AT freetds.org>
  • Cc: FreeTDS AT lists.ibiblio.org
  • Subject: Re: [freetds] RESULTS!!! Re: parameters missing in RC 64 Bits
  • Date: Wed, 23 Apr 2008 08:49:04 -0500

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.
>




Archive powered by MHonArc 2.6.24.

Top of Page