Bug 630818 – dev-db/sqlite-3.20.1: fts3conf.test tests fail on big-endian architectures

• Status: RESOLVED FIXED
• Product: Gentoo Linux

[Description Rolf Eike Beer 2017-09-12 16:44:22 UTC]

Tests failing are ftsconf3.[1-68], both on sparc and hppa

Test output suggests a endianess issue:

! fts3conf-3.1 expected: [X'0100000002000000']
! fts3conf-3.1 got:      [X'0000000100000002']

Reproducible: Always

[Comment 1 Arfrever Frehtes Taifersar Arahesis 2017-09-12 18:09:26 UTC]

What are results in 3.17.0 and 3.18.0?

[Comment 2 Rolf Eike Beer 2017-09-12 19:13:41 UTC]

Same on 3.18.0

[Comment 3 Rolf Eike Beer 2017-09-13 05:19:58 UTC]

Same on 3.17.0 (both tested only on sparc).

[Comment 4 Rolf Eike Beer 2017-09-13 05:29:09 UTC]

Reported to upstream mailing list.

[Comment 5 Richard Hipp 2017-09-13 13:03:06 UTC]

This is a problem in the test scripts, not in the underlying SQLite code.

The matchinfo() function of FTS3 returns a BLOB that is a an array of 32-bit integers in machine byte-order. (See the 2nd sentence at https://www.sqlite.org/fts3.html#matchinfo) Some test cases were rendering these BLOBs as hex and then checking the resulting strings, under the assumption that the tests are running on a little-endian machine.  Those test cases would fail on a big-endian machine.

The fix is to disable the offending test cases when running on a big-endian machine.

Upstream check-in here: https://www.sqlite.org/src/info/87ccdf9cbb928455

[Comment 6 Arfrever Frehtes Taifersar Arahesis 2017-09-13 14:30:37 UTC]

(In reply to Richard Hipp from comment #5)
> The fix is to disable the offending test cases when running on a big-endian
> machine.
> 
> Upstream check-in here: https://www.sqlite.org/src/info/87ccdf9cbb928455

You could probably do something like:

if {$tcl_platform(byteOrder)=="littleEndian"} {
  do_execsql_test 3.1 {
    CREATE VIRTUAL TABLE t3 USING fts4;
    REPLACE INTO t3(docid, content) VALUES (1, 'one two');
    SELECT quote(matchinfo(t3, 'na')) FROM t3 WHERE t3 MATCH 'one'
  } {X'0100000002000000'}
} else {
  do_execsql_test 3.1 {
    CREATE VIRTUAL TABLE t3 USING fts4;
    REPLACE INTO t3(docid, content) VALUES (1, 'one two');
    SELECT quote(matchinfo(t3, 'na')) FROM t3 WHERE t3 MATCH 'one'
  } {X'0000000100000002'}
}

[Comment 7 Richard Hipp 2017-09-13 14:51:03 UTC]

(In reply to Arfrever Frehtes Taifersar Arahesis from comment #6)
> 
> You could probably do something like:
> 
> if {$tcl_platform(byteOrder)=="littleEndian"} {
>   do_execsql_test 3.1 {
>     CREATE VIRTUAL TABLE t3 USING fts4;
>     REPLACE INTO t3(docid, content) VALUES (1, 'one two');
>     SELECT quote(matchinfo(t3, 'na')) FROM t3 WHERE t3 MATCH 'one'
>   } {X'0100000002000000'}
> } else {
>   do_execsql_test 3.1 {
>     CREATE VIRTUAL TABLE t3 USING fts4;
>     REPLACE INTO t3(docid, content) VALUES (1, 'one two');
>     SELECT quote(matchinfo(t3, 'na')) FROM t3 WHERE t3 MATCH 'one'
>   } {X'0000000100000002'}
> }

Yes, except we no longer have access to a machine on which to verify that change.

There are lots of other byte-order independent tests cases for the matchinfo() function in the adjacent fts3matchinfo.test script.  The handful of tests for matchinfo() in fts3conf.test are not necessary.

[Comment 8 Arfrever Frehtes Taifersar Arahesis 2017-09-28 17:43:36 UTC]

Fixed:

https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=339ebb6495f1bd6f9baf0293f7a6e2ae938eea47