FreeTDS Development Group

["James K. Lowden" <jklowden AT freetds.org>]

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.  

--jkl