Thread: Regression test failures on big endian
Hi, 09.05.0100 is failing the result-conversions tests on big endian architectures, e.g. powerpc: https://buildd.debian.org/status/fetch.php?pkg=psqlodbc&arch=powerpc&ver=1%3A09.05.0100-1&stamp=1458326445 * expected/result-conversions.out Sun Jan 10 13:25:15 2016 --- results/result-conversions.out Fri Mar 18 18:40:34 2016 *************** *** 262,270 **** '1234567' (int4) as SQL_C_UTINYINT: 135 '1234567' (int4) as SQL_C_SBIGINT: 1234567 '1234567' (int4) as SQL_C_UBIGINT: 1234567 ! '1234567' (int4) as SQL_C_BINARY: hex: 87D61200 '1234567' (int4) as SQL_C_BOOKMARK: 1234567 ! '1234567' (int4) as SQL_C_VARBOOKMARK: hex: 87D61200 '1234567' (int4) as SQL_C_TYPE_TIME: h: 0 m: 0 s: 0 '1234567' (int4) as SQL_C_NUMERIC: precision: 7 scale: 0 sign: 0 val: 87d61200000000000000000000000000 '1234567' (int4) as SQL_C_GUID: SQLGetData failed --- 262,270 ---- '1234567' (int4) as SQL_C_UTINYINT: 135 '1234567' (int4) as SQL_C_SBIGINT: 1234567 '1234567' (int4) as SQL_C_UBIGINT: 1234567 ! '1234567' (int4) as SQL_C_BINARY: hex: 0012D687 '1234567' (int4) as SQL_C_BOOKMARK: 1234567 ! '1234567' (int4) as SQL_C_VARBOOKMARK: hex: 0012D687 '1234567' (int4) as SQL_C_TYPE_TIME: h: 0 m: 0 s: 0 '1234567' (int4) as SQL_C_NUMERIC: precision: 7 scale: 0 sign: 0 val: 87d61200000000000000000000000000 '1234567' (int4) as SQL_C_GUID: SQLGetData failed *************** *** 1328,1334 **** 'foobar' (text) as SQL_C_WCHAR: fooba (truncated) 'foobar' (text) as SQL_C_WCHAR: foobar '' (text) as SQL_C_CHAR: ! '' (text) as SQL_C_WCHAR: \FF00\FFFF\FFFF\FFFF\FFFF\FFFF\FFFF\FFFF\FFFF\FFFF\FFFF\FFFF\FFFF\FFFF\FFFF\FFFF\FFFF\FFFF\FFFF\FFFF\FFFF\FFFF\FFFF\FFFF\FFFF\FFFF\FFFF\FFFF\FFFF\FFFF\FFFF\FFFF\FFFF\FFFF\FFFF\FFFF\FFFF\FFFF\FFFF\FFFF\FFFF\FFFF\FFFF\FFFF\FFFF\FFFF\FFFF\FFFF\FFFF\FFFF (truncated) '2011-02-15 15:49:18' (timestamp) as SQL_C_CHAR: 2011-02-15 15:49:1 (truncated) '2011-02-15 15:49:18 BC' (timestamp) as SQL_C_CHAR: 2011-02-15 15:49:18 (truncated) 'NaN' (float4) as SQL_C_FLOAT: nan --- 1328,1334 ---- 'foobar' (text) as SQL_C_WCHAR: fooba (truncated) 'foobar' (text) as SQL_C_WCHAR: foobar '' (text) as SQL_C_CHAR: ! '' (text) as SQL_C_WCHAR: \ FF\FFFF\FFFF\FFFF\FFFF\FFFF\FFFF\FFFF\FFFF\FFFF\FFFF\FFFF\FFFF\FFFF\FFFF\FFFF\FFFF\FFFF\FFFF\FFFF\FFFF\FFFF\FFFF\FFFF\FFFF\FFFF\FFFF\FFFF\FFFF\FFFF\FFFF\FFFF\FFFF\FFFF\FFFF\FFFF\FFFF\FFFF\FFFF\FFFF\FFFF\FFFF\FFFF\FFFF\FFFF\FFFF\FFFF\FFFF\FFFF\FFFF (truncated) '2011-02-15 15:49:18' (timestamp) as SQL_C_CHAR: 2011-02-15 15:49:1 (truncated) '2011-02-15 15:49:18 BC' (timestamp) as SQL_C_CHAR: 2011-02-15 15:49:18 (truncated) 'NaN' (float4) as SQL_C_FLOAT: nan The failure pattern is always the same: https://buildd.debian.org/status/package.php?p=psqlodbc (There is an extra problem with bulkoperations on sparc64, but that might be a problem with that port. https://buildd.debian.org/status/fetch.php?pkg=psqlodbc&arch=sparc64&ver=1%3A09.05.0100-1&stamp=1458326750 ) Christoph
Re: To PostgreSQL ODBC 2016-03-18 <20160318211558.GA7269@msg.df7cb.de> > Hi, > > 09.05.0100 is failing the result-conversions tests on big endian > architectures, e.g. powerpc: > > https://buildd.debian.org/status/fetch.php?pkg=psqlodbc&arch=powerpc&ver=1%3A09.05.0100-1&stamp=1458326445 Hi again, these failures are preventing psqlodbc from entering the next Debian release, and hence are critical. Can anybody with more insight comment if the differences seen are real problems or just cosmetic variations? In that case I could add more _1.out files to catch them. > * expected/result-conversions.out Sun Jan 10 13:25:15 2016 > --- results/result-conversions.out Fri Mar 18 18:40:34 2016 > *************** > *** 262,270 **** > '1234567' (int4) as SQL_C_UTINYINT: 135 > '1234567' (int4) as SQL_C_SBIGINT: 1234567 > '1234567' (int4) as SQL_C_UBIGINT: 1234567 > ! '1234567' (int4) as SQL_C_BINARY: hex: 87D61200 > '1234567' (int4) as SQL_C_BOOKMARK: 1234567 > ! '1234567' (int4) as SQL_C_VARBOOKMARK: hex: 87D61200 > '1234567' (int4) as SQL_C_TYPE_TIME: h: 0 m: 0 s: 0 > '1234567' (int4) as SQL_C_NUMERIC: precision: 7 scale: 0 sign: 0 val: 87d61200000000000000000000000000 > '1234567' (int4) as SQL_C_GUID: SQLGetData failed > --- 262,270 ---- > '1234567' (int4) as SQL_C_UTINYINT: 135 > '1234567' (int4) as SQL_C_SBIGINT: 1234567 > '1234567' (int4) as SQL_C_UBIGINT: 1234567 > ! '1234567' (int4) as SQL_C_BINARY: hex: 0012D687 > '1234567' (int4) as SQL_C_BOOKMARK: 1234567 > ! '1234567' (int4) as SQL_C_VARBOOKMARK: hex: 0012D687 > '1234567' (int4) as SQL_C_TYPE_TIME: h: 0 m: 0 s: 0 > '1234567' (int4) as SQL_C_NUMERIC: precision: 7 scale: 0 sign: 0 val: 87d61200000000000000000000000000 > '1234567' (int4) as SQL_C_GUID: SQLGetData failed > *************** > *** 1328,1334 **** > 'foobar' (text) as SQL_C_WCHAR: fooba (truncated) > 'foobar' (text) as SQL_C_WCHAR: foobar > '' (text) as SQL_C_CHAR: > ! '' (text) as SQL_C_WCHAR: \FF00\FFFF\FFFF\FFFF\FFFF\FFFF\FFFF\FFFF\FFFF\FFFF\FFFF\FFFF\FFFF\FFFF\FFFF\FFFF\FFFF\FFFF\FFFF\FFFF\FFFF\FFFF\FFFF\FFFF\FFFF\FFFF\FFFF\FFFF\FFFF\FFFF\FFFF\FFFF\FFFF\FFFF\FFFF\FFFF\FFFF\FFFF\FFFF\FFFF\FFFF\FFFF\FFFF\FFFF\FFFF\FFFF\FFFF\FFFF\FFFF\FFFF (truncated) > '2011-02-15 15:49:18' (timestamp) as SQL_C_CHAR: 2011-02-15 15:49:1 (truncated) > '2011-02-15 15:49:18 BC' (timestamp) as SQL_C_CHAR: 2011-02-15 15:49:18 (truncated) > 'NaN' (float4) as SQL_C_FLOAT: nan > --- 1328,1334 ---- > 'foobar' (text) as SQL_C_WCHAR: fooba (truncated) > 'foobar' (text) as SQL_C_WCHAR: foobar > '' (text) as SQL_C_CHAR: > ! '' (text) as SQL_C_WCHAR: \ FF\FFFF\FFFF\FFFF\FFFF\FFFF\FFFF\FFFF\FFFF\FFFF\FFFF\FFFF\FFFF\FFFF\FFFF\FFFF\FFFF\FFFF\FFFF\FFFF\FFFF\FFFF\FFFF\FFFF\FFFF\FFFF\FFFF\FFFF\FFFF\FFFF\FFFF\FFFF\FFFF\FFFF\FFFF\FFFF\FFFF\FFFF\FFFF\FFFF\FFFF\FFFF\FFFF\FFFF\FFFF\FFFF\FFFF\FFFF\FFFF\FFFF (truncated) > '2011-02-15 15:49:18' (timestamp) as SQL_C_CHAR: 2011-02-15 15:49:1 (truncated) > '2011-02-15 15:49:18 BC' (timestamp) as SQL_C_CHAR: 2011-02-15 15:49:18 (truncated) > 'NaN' (float4) as SQL_C_FLOAT: nan > > > The failure pattern is always the same: > https://buildd.debian.org/status/package.php?p=psqlodbc > > (There is an extra problem with bulkoperations on sparc64, but that > might be a problem with that port. > https://buildd.debian.org/status/fetch.php?pkg=psqlodbc&arch=sparc64&ver=1%3A09.05.0100-1&stamp=1458326750 > ) Christoph
Hi Christoph, Sorry for the late reply. On 2016/04/03 7:06, Christoph Berg wrote: > Re: To PostgreSQL ODBC 2016-03-18 <20160318211558.GA7269@msg.df7cb.de> >> Hi, >> >> 09.05.0100 is failing the result-conversions tests on big endian >> architectures, e.g. powerpc: >> >> https://buildd.debian.org/status/fetch.php?pkg=psqlodbc&arch=powerpc&ver=1%3A09.05.0100-1&stamp=1458326445 > Hi again, > > these failures are preventing psqlodbc from entering the next Debian > release, and hence are critical. > > Can anybody with more insight comment if the differences seen are real > problems or just cosmetic variations? In that case I could add more > _1.out files to catch them. > >> * expected/result-conversions.out Sun Jan 10 13:25:15 2016 >> --- results/result-conversions.out Fri Mar 18 18:40:34 2016 >> *************** >> *** 262,270 **** >> '1234567' (int4) as SQL_C_UTINYINT: 135 >> '1234567' (int4) as SQL_C_SBIGINT: 1234567 >> '1234567' (int4) as SQL_C_UBIGINT: 1234567 >> ! '1234567' (int4) as SQL_C_BINARY: hex: 87D61200 >> '1234567' (int4) as SQL_C_BOOKMARK: 1234567 >> ! '1234567' (int4) as SQL_C_VARBOOKMARK: hex: 87D61200 >> '1234567' (int4) as SQL_C_TYPE_TIME: h: 0 m: 0 s: 0 >> '1234567' (int4) as SQL_C_NUMERIC: precision: 7 scale: 0 sign: 0 val: 87d61200000000000000000000000000 >> '1234567' (int4) as SQL_C_GUID: SQLGetData failed >> --- 262,270 ---- >> '1234567' (int4) as SQL_C_UTINYINT: 135 >> '1234567' (int4) as SQL_C_SBIGINT: 1234567 >> '1234567' (int4) as SQL_C_UBIGINT: 1234567 >> ! '1234567' (int4) as SQL_C_BINARY: hex: 0012D687 >> '1234567' (int4) as SQL_C_BOOKMARK: 1234567 >> ! '1234567' (int4) as SQL_C_VARBOOKMARK: hex: 0012D687 >> '1234567' (int4) as SQL_C_TYPE_TIME: h: 0 m: 0 s: 0 >> '1234567' (int4) as SQL_C_NUMERIC: precision: 7 scale: 0 sign: 0 val: 87d61200000000000000000000000000 >> '1234567' (int4) as SQL_C_GUID: SQLGetData failed The difference above is a natural outcome from the difference of endianness. >> *************** >> *** 1328,1334 **** >> 'foobar' (text) as SQL_C_WCHAR: fooba (truncated) >> 'foobar' (text) as SQL_C_WCHAR: foobar >> '' (text) as SQL_C_CHAR: >> ! '' (text) as SQL_C_WCHAR: \FF00\FFFF\FFFF\FFFF\FFFF\FFFF\FFFF\FFFF\FFFF\FFFF\FFFF\FFFF\FFFF\FFFF\FFFF\FFFF\FFFF\FFFF\FFFF\FFFF\FFFF\FFFF\FFFF\FFFF\FFFF\FFFF\FFFF\FFFF\FFFF\FFFF\FFFF\FFFF\FFFF\FFFF\FFFF\FFFF\FFFF\FFFF\FFFF\FFFF\FFFF\FFFF\FFFF\FFFF\FFFF\FFFF\FFFF\FFFF\FFFF\FFFF (truncated) >> '2011-02-15 15:49:18' (timestamp) as SQL_C_CHAR: 2011-02-15 15:49:1 (truncated) >> '2011-02-15 15:49:18 BC' (timestamp) as SQL_C_CHAR: 2011-02-15 15:49:18 (truncated) >> 'NaN' (float4) as SQL_C_FLOAT: nan >> --- 1328,1334 ---- >> 'foobar' (text) as SQL_C_WCHAR: fooba (truncated) >> 'foobar' (text) as SQL_C_WCHAR: foobar >> '' (text) as SQL_C_CHAR: >> ! '' (text) as SQL_C_WCHAR: \ FF\FFFF\FFFF\FFFF\FFFF\FFFF\FFFF\FFFF\FFFF\FFFF\FFFF\FFFF\FFFF\FFFF\FFFF\FFFF\FFFF\FFFF\FFFF\FFFF\FFFF\FFFF\FFFF\FFFF\FFFF\FFFF\FFFF\FFFF\FFFF\FFFF\FFFF\FFFF\FFFF\FFFF\FFFF\FFFF\FFFF\FFFF\FFFF\FFFF\FFFF\FFFF\FFFF\FFFF\FFFF\FFFF\FFFF\FFFF\FFFF\FFFF (truncated) >> '2011-02-15 15:49:18' (timestamp) as SQL_C_CHAR: 2011-02-15 15:49:1 (truncated) >> '2011-02-15 15:49:18 BC' (timestamp) as SQL_C_CHAR: 2011-02-15 15:49:18 (truncated) The difference above means that encoding of Unicode is UTF-16LE whichever the endianness is. Is it as you expected? regards, Hiroshi Inoue
Re: Inoue, Hiroshi 2016-04-05 <5702F6C6.6010707@dream.email.ne.jp> > Hi Christoph, > > Sorry for the late reply. Thanks for the reply :) > >>! '1234567' (int4) as SQL_C_BINARY: hex: 87D61200 > >>! '1234567' (int4) as SQL_C_BINARY: hex: 0012D687 > > The difference above is a natural outcome from the difference of endianness. Ah, on a second look that's indeed the case. I'll blame myself for still not being comfortable with reading "context" diffs where original and changed version are way apart. Thanks for confirming this is an expected change. I'll proceed to submit some _1.out files. > >>! '' (text) as SQL_C_WCHAR: \FF00\FFFF\FFFF\FFFF\FFFF\FFFF\FFFF\FFFF\FFFF\FFFF\FFFF\FFFF\FFFF\FFFF\FFFF\FFFF\FFFF\FFFF\FFFF\FFFF\FFFF\FFFF\FFFF\FFFF\FFFF\FFFF\FFFF\FFFF\FFFF\FFFF\FFFF\FFFF\FFFF\FFFF\FFFF\FFFF\FFFF\FFFF\FFFF\FFFF\FFFF\FFFF\FFFF\FFFF\FFFF\FFFF\FFFF\FFFF\FFFF\FFFF (truncated) > >>! '' (text) as SQL_C_WCHAR: \ FF\FFFF\FFFF\FFFF\FFFF\FFFF\FFFF\FFFF\FFFF\FFFF\FFFF\FFFF\FFFF\FFFF\FFFF\FFFF\FFFF\FFFF\FFFF\FFFF\FFFF\FFFF\FFFF\FFFF\FFFF\FFFF\FFFF\FFFF\FFFF\FFFF\FFFF\FFFF\FFFF\FFFF\FFFF\FFFF\FFFF\FFFF\FFFF\FFFF\FFFF\FFFF\FFFF\FFFF\FFFF\FFFF\FFFF\FFFF\FFFF\FFFF (truncated) > > The difference above means that encoding of Unicode is UTF-16LE whichever > the endianness is. Ew. There should be a law forbidding everything except UTF-8 :) > Is it as you expected? Thanks for the confirmation! Christoph
Re: To Inoue, Hiroshi 2016-04-05 <20160405082831.GA4327@msg.df7cb.de> > Thanks for confirming this is an expected change. I'll proceed to > submit some _1.out files. Hi, here is the necessary big-endian result-conversions_1.out file along with the deprecated_1.out file I had submitted a few weeks ago to fix the tests on older unixodbc releases. Btw, the regression tests are still failing on sparc64: https://buildd.debian.org/status/fetch.php?pkg=psqlodbc&arch=sparc64&ver=1%3A09.05.0100-2&stamp=1459856538 ... in case that's helpful for you. (Though as that's not a release architecture, I won't care for now if it remains unfixed.) Thanks for your help! Christoph
Attachment
Hi Christoph, On 2016/04/05 20:47, Christoph Berg wrote: > Re: To Inoue, Hiroshi 2016-04-05 <20160405082831.GA4327@msg.df7cb.de> > Btw, the regression tests are still failing on sparc64: > https://buildd.debian.org/status/fetch.php?pkg=psqlodbc&arch=sparc64&ver=1%3A09.05.0100-2&stamp=1459856538 > ... in case that's helpful for you. (Though as that's not a release > architecture, I won't care for now if it remains unfixed.) Could you try the attached patch? regards, Hiroshi Inoue
Attachment
Re: Inoue, Hiroshi 2016-04-06 <57050934.3020404@dream.email.ne.jp> > Hi Christoph, > > On 2016/04/05 20:47, Christoph Berg wrote: > >Re: To Inoue, Hiroshi 2016-04-05 <20160405082831.GA4327@msg.df7cb.de> > >Btw, the regression tests are still failing on sparc64: https://buildd.debian.org/status/fetch.php?pkg=psqlodbc&arch=sparc64&ver=1%3A09.05.0100-2&stamp=1459856538 > >... in case that's helpful for you. (Though as that's not a release > >architecture, I won't care for now if it remains unfixed.) > > Could you try the attached patch? That fixed the sparc64 issue, thanks! Christoph
On 2016/04/05 20:47, Christoph Berg wrote: > Re: To Inoue, Hiroshi 2016-04-05 <20160405082831.GA4327@msg.df7cb.de> >> Thanks for confirming this is an expected change. I'll proceed to >> submit some _1.out files. > Hi, > > here is the necessary big-endian result-conversions_1.out file along > with the deprecated_1.out file I had submitted a few weeks ago to fix > the tests on older unixodbc releases. > Applied. Thanks. Hiroshi Inoue