Re: Solaris/SPARC: SIGBUS in unittests/array_out.c

2010/9/23 Peter C. Norton <[email protected]>

> Frediano,
>
> For the SIGBUS, the fix at
>
> http://freetds.cvs.sourceforge.net/viewvc/freetds/freetds/src/odbc/unittests/array_out.c?r1=1.16&r2=1.17
> works fine for me, thanks!.
>
> More unittest failures:
>
> (1) data fails in the following manner:
>
> SELECT CONVERT(INT, '-123') AS data
> SELECT CONVERT(INT, '78654') AS data
> SELECT CONVERT(VARCHAR(10), '  51245  ') AS data
> SELECT CONVERT(UNIVARCHAR(10), u&'\06A4\FBA5') AS data
> Wrong result
>  Got: 2 \ua406\ua5fb
>  Expected: 2 \u06a4\ufba5
> SELECT CONVERT(DECIMAL, '1234.5678') AS data
> SELECT CONVERT(NUMERIC, '8765.4321') AS data
> SELECT CONVERT(FLOAT, '1234.5678') AS data
> SELECT CONVERT(REAL, '8765.4321') AS data
> SELECT CONVERT(SMALLMONEY, '765.4321') AS data
> SELECT CONVERT(MONEY, '4321234.5678') AS data
> SELECT CONVERT(DATETIME, '2006-06-09 11:22:44') AS data
> SELECT CONVERT(SMALLDATETIME, '2006-06-12 22:37:21') AS data
> SELECT CONVERT(DATETIME, '2006-06-09 11:22:44') AS data
> SELECT CONVERT(SMALLDATETIME, '2006-06-12 22:37:21') AS data
> FAIL: data
>
> This looks like an endian problem, as the bytes appear to be swapped.
> From googling around, it looks like in the case of ODBC, it specifies
> that that SQL_W_CHAR is in host byte order.  However, this SPARC is
> connecting to an x86 server and I don't see any checks for byte
> ordering being done in the test:
>
>        case SQL_C_WCHAR:
>                assert(out_len >=0 && (out_len % sizeof(SQLWCHAR)) == 0);
>                sprintf(sbuf, "%u ", (unsigned int) (out_len /
> sizeof(SQLWCHAR)));
>                wp = (SQLWCHAR*) out_buf;
>                for (i = 0; i < out_len / sizeof(SQLWCHAR); ++i)
>                        if ((unsigned int) wp[i] < 256)
>                                sprintf(strchr(sbuf, 0), "%c", (char)
> wp[i]);
>                        else
>                                sprintf(strchr(sbuf, 0), "\\u%04x",
> (unsigned int) wp[i]);
>                break;
>
>
it's ok as ODBC should encode SQLWCHAR in proper order. Could you post
TDSDUMP ?? Just to understand in which encoding server send data.


> Is there a right way to check the byte order of the remote host and
> correct for this in the test?
>
> (2) timeout3 isn't returning consistently:
>
> /tmp/freetds/src/odbc/unittests $ ./timeout3
> Fake server binded at port 12340
> try to connect to our port just to check connection timeout
> Alarm Clock
> /tmp/freetds/src/odbc/unittests $ ./timeout3
> Fake server binded at port 12340
> try to connect to our port just to check connection timeout
> Message: HYT00 - [unixODBC][FreeTDS][SQL Server]Timeout expired
> Done.
>
> I'm testing this because my prior "make check" looked like this:
> Fake server binded at port 12340
> try to connect to our port just to check connection timeout
> /bin/bash: line 4:  2854 Alarm Clock             ${dir}$tst
> FAIL: timeout3
>
>
Mmmm... even in this case a TDSDUMP would help. timeout should occur in
10/20 seconds so 30 seconds should suffice and alarm should not raise in the
test.

Thanks for keeping testing

freddy77