Re: [sqlite] sqlite 3.23.0 zipfile2 test failures
Actually forgot to append the link tot he full logs so one more mail to
fix it:
https://kojipkgs.fedoraproject.org//work/tasks/7200/26137200/build.log
On 04/12/2018 02:23 PM, Petr Kubat wrote:
Hello everyone,
I have recently rebased Fedora's version of sqlite to 3.23.0 and saw
some failures in one of the zipfile2 test cases during running
self-tests (full logs [1]):
Time: zipfile.test 193 ms
! zipfile2-2.0 expected: [1 {error in fread()}]
! zipfile2-2.0 got: [0 {}]
Time: zipfile2.test 12 ms
SQLite 2018-04-02 11:04:16
736b53f57f70b23172c30880186dce7ad9baa3b74e3838cae5847cffb98falt1
1 errors out of 187562 tests on Linux 64-bit big-endian
After looking a bit more into the failure it seems like this piece of
code (from (ext/misc/zipfile.c:zipfileReadEOCD)) is the reason for the
failures:
fseek(pFile, 0, SEEK_END);
szFile = (i64)ftell(pFile);
if( szFile==0 ){
memset(pEOCD, 0, sizeof(ZipfileEOCD));
return SQLITE_OK;
}
nRead = (int)(MIN(szFile, ZIPFILE_BUFFER_SIZE));
iOff = szFile - nRead;
rc = zipfileReadData(pFile, aRead, nRead, iOff,
>base.zErrMsg);
The issue here is that `fseek` and `ftell` are being run on a FILE
pointer that is created from fopen-ing a directory. On some systems,
and I think this is tied to the filesystem used (I managed to
reproduce the failure on a VM using XFS), this leads to the
`zipfileReadData` call being skipped due to `ftell` returning 0
(returns LONG_MAX on ext4) and SQLITE_OK is returned instead of
failing with error (through `zipfileReadData`).
To me it seems like calling `fseek` and `ftell` on a directory results
in undefined behaviour so it would make more sense to explicitly check
the type of the target before attempting it. However, I am not sure
where such a change would be best to take place (which is why there is
no fix attached to this).
Petr
___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
[sqlite] sqlite 3.23.0 zipfile2 test failures
Hello everyone,
I have recently rebased Fedora's version of sqlite to 3.23.0 and saw
some failures in one of the zipfile2 test cases during running
self-tests (full logs [1]):
Time: zipfile.test 193 ms
! zipfile2-2.0 expected: [1 {error in fread()}]
! zipfile2-2.0 got: [0 {}]
Time: zipfile2.test 12 ms
SQLite 2018-04-02 11:04:16
736b53f57f70b23172c30880186dce7ad9baa3b74e3838cae5847cffb98falt1
1 errors out of 187562 tests on Linux 64-bit big-endian
After looking a bit more into the failure it seems like this piece of
code (from (ext/misc/zipfile.c:zipfileReadEOCD)) is the reason for the
failures:
fseek(pFile, 0, SEEK_END);
szFile = (i64)ftell(pFile);
if( szFile==0 ){
memset(pEOCD, 0, sizeof(ZipfileEOCD));
return SQLITE_OK;
}
nRead = (int)(MIN(szFile, ZIPFILE_BUFFER_SIZE));
iOff = szFile - nRead;
rc = zipfileReadData(pFile, aRead, nRead, iOff, >base.zErrMsg);
The issue here is that `fseek` and `ftell` are being run on a FILE
pointer that is created from fopen-ing a directory. On some systems, and
I think this is tied to the filesystem used (I managed to reproduce the
failure on a VM using XFS), this leads to the `zipfileReadData` call
being skipped due to `ftell` returning 0 (returns LONG_MAX on ext4) and
SQLITE_OK is returned instead of failing with error (through
`zipfileReadData`).
To me it seems like calling `fseek` and `ftell` on a directory results
in undefined behaviour so it would make more sense to explicitly check
the type of the target before attempting it. However, I am not sure
where such a change would be best to take place (which is why there is
no fix attached to this).
Petr
___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] sqlite 3.22.0 walro2 test failures on ppc64
Tests are passing now, thanks!
Had to make one small modification to the patch to get it working though:
@@ -17,7 +17,7 @@ Index: test/walro2.test
+do_execsql_test 0.0 {
+ PRAGMA journal_mode = wal;
+ CREATE TABLE t1(x);
-+}
++} {wal}
+set MINSHMSZ [file size test.db-shm]
+
foreach bZeroShm {0 1} {
Petr
On 02/05/2018 02:29 PM, Dan Kennedy wrote:
On 02/05/2018 04:22 PM, Petr Kubat wrote:
On 02/05/2018 08:41 AM, Petr Kubat wrote:
Hi all,
hitting some failures when building 3.22.0 on ppc64 boxes (both
big-endian and little-endian) running Fedora Rawhide (full logs in
[1][2]):
Time: walro.test 135 ms
! walro2-1.3.2.2 expected: [0 32768]
! walro2-1.3.2.2 got: [0 65536]
! walro2-1.3.3.0 expected: [4224 32768]
! walro2-1.3.3.0 got: [4224 65536]
! walro2-1.3.3.2 expected: [4224 32768]
! walro2-1.3.3.2 got: [4224 65536]
! walro2-2.3.2.2 expected: [0 32768]
! walro2-2.3.2.2 got: [0 65536]
! walro2-2.3.3.0 expected: [4224 32768]
! walro2-2.3.3.0 got: [4224 65536]
! walro2-2.3.3.2 expected: [4224 32768]
! walro2-2.3.3.2 got: [4224 65536]
Time: walro2.test 513 ms
From what I can see the expected sizes of the database files seem to
be half of what is the actual size.
To correct myself here - its the "-wal" file that gets twice as big
as expected. btw the starting size of the "-wal" file on ppc64 is the
same (65536 bytes) even in older versions of sqlite (looking at
3.20.1 right now).
Thanks for reporting this. I think it's just a problem with the test
script. Now fixed here:
http://www.sqlite.org/src/info/d9e59cfb8476e1ec
Dan.
Petr
[1]:
https://kojipkgs.fedoraproject.org//work/tasks/9900/24679900/build.log
[2]:
https://kojipkgs.fedoraproject.org//work/tasks/9898/24679898/build.log
___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] sqlite 3.22.0 walro2 test failures on ppc64
On 02/05/2018 08:41 AM, Petr Kubat wrote: Hi all, hitting some failures when building 3.22.0 on ppc64 boxes (both big-endian and little-endian) running Fedora Rawhide (full logs in [1][2]): Time: walro.test 135 ms ! walro2-1.3.2.2 expected: [0 32768] ! walro2-1.3.2.2 got: [0 65536] ! walro2-1.3.3.0 expected: [4224 32768] ! walro2-1.3.3.0 got: [4224 65536] ! walro2-1.3.3.2 expected: [4224 32768] ! walro2-1.3.3.2 got: [4224 65536] ! walro2-2.3.2.2 expected: [0 32768] ! walro2-2.3.2.2 got: [0 65536] ! walro2-2.3.3.0 expected: [4224 32768] ! walro2-2.3.3.0 got: [4224 65536] ! walro2-2.3.3.2 expected: [4224 32768] ! walro2-2.3.3.2 got: [4224 65536] Time: walro2.test 513 ms From what I can see the expected sizes of the database files seem to be half of what is the actual size. To correct myself here - its the "-wal" file that gets twice as big as expected. btw the starting size of the "-wal" file on ppc64 is the same (65536 bytes) even in older versions of sqlite (looking at 3.20.1 right now). Petr [1]: https://kojipkgs.fedoraproject.org//work/tasks/9900/24679900/build.log [2]: https://kojipkgs.fedoraproject.org//work/tasks/9898/24679898/build.log ___ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users ___ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
[sqlite] sqlite 3.22.0 walro2 test failures on ppc64
Hi all, hitting some failures when building 3.22.0 on ppc64 boxes (both big-endian and little-endian) running Fedora Rawhide (full logs in [1][2]): Time: walro.test 135 ms ! walro2-1.3.2.2 expected: [0 32768] ! walro2-1.3.2.2 got: [0 65536] ! walro2-1.3.3.0 expected: [4224 32768] ! walro2-1.3.3.0 got: [4224 65536] ! walro2-1.3.3.2 expected: [4224 32768] ! walro2-1.3.3.2 got: [4224 65536] ! walro2-2.3.2.2 expected: [0 32768] ! walro2-2.3.2.2 got: [0 65536] ! walro2-2.3.3.0 expected: [4224 32768] ! walro2-2.3.3.0 got: [4224 65536] ! walro2-2.3.3.2 expected: [4224 32768] ! walro2-2.3.3.2 got: [4224 65536] Time: walro2.test 513 ms From what I can see the expected sizes of the database files seem to be half of what is the actual size. Petr [1]: https://kojipkgs.fedoraproject.org//work/tasks/9900/24679900/build.log [2]: https://kojipkgs.fedoraproject.org//work/tasks/9898/24679898/build.log ___ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] sqlite 3.21.0 fts3rank test failure on big-endian linux
On 01/24/2018 03:45 PM, Richard Hipp wrote: On 1/24/18, Petr Kubat <pku...@redhat.com> wrote: I am hitting a failure in fts3rank test on big-endian architectures (ppc64, s390x; logs in [1][2]) running Fedora rawhide: Should now be fixed on trunk. Thanks! I can verify that the fts3rank test case is now green on both ppc64 and s390x. For anyone else interested in the patch, here is the link: https://www.sqlite.org/src/info/e4766cabdf64d8e9 Big-endian processors are getting harder to get ahold of. I don't have one that is still capable of running the TCL tests. My old circa-2000 iBook (PPC) can still compile and run the TH3 tests, but I have not been able to get recent versions of TCL (required for the TCL tests) to compile on that machine. What do y'all do at RedHat for legacy testing hardware? Find stuff on eBay? Not sure actually since from my point of view, as I do not work primarily on ppc, the machines are just there. My guess is we are getting some servers from IBM to develop the ppc spins on when needed. ___ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
[sqlite] sqlite 3.21.0 fts3rank test failure on big-endian linux
Hi all,
I am hitting a failure in fts3rank test on big-endian architectures
(ppc64, s390x; logs in [1][2]) running Fedora rawhide:
Time: fts3query.test 515 ms
! fts3expr5-1.5 expected: [1 {invalid matchinfo blob passed to function rank()}]
! fts3expr5-1.5 got: [1 {wrong number of arguments to function rank()}]
Time: fts3rank.test 12 ms
This seems to have been introduced in version 3.21.0 (but is still
present in 3.22.0). Checking the source of the failing test case it
looks like an endianess issue due to the blob:
do_catchsql_test 1.5 {
SELECT * FROM t1 ORDER BY rank(x'01000100') DESC, rowid
} {1 {invalid matchinfo blob passed to function rank()}}
Seems similar to a different issue I hit before with fts3conf.test
(fixed in [3]).
Petr
[1] https://kojipkgs.fedoraproject.org//work/tasks/2189/24412189/build.log
[2] https://kojipkgs.fedoraproject.org//work/tasks/2191/24412191/build.log
[3] https://www.sqlite.org/src/info/87ccdf9cbb928455
___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] sqlite 3.21.0 bug? SELECT CAST ('9223372036854775807 ' AS NUMERIC);
Thanks for the patch! Tests on i686 are green when included. There are still some failures for other architectures but I will make separate threads for these once I investigate. Petr On 01/23/2018 06:35 PM, Richard Hipp wrote: On 1/23/18, Petr Kubat <pku...@redhat.com> wrote: Still present in 3.22.0: ! e_expr-32.2.5 expected: [integer 9223372036854775807] ! e_expr-32.2.5 got: [real 9.22337203685478e+18] Is there any more information I can provide to get this looked at? Ralf provided the information I needed, which was a method of reproducing the problem. It is now fixed on trunk. See https://www.sqlite.org/src/info/1b02731962c21bb0 for the patch. ___ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] sqlite 3.21.0 bug? SELECT CAST ('9223372036854775807 ' AS NUMERIC);
Still present in 3.22.0:
! e_expr-32.2.5 expected: [integer 9223372036854775807]
! e_expr-32.2.5 got: [real 9.22337203685478e+18]
! e_expr-32.2.6 expected: [integer 9223372036854775807]
! e_expr-32.2.6 got: [real 9.22337203685478e+18]
! e_expr-32.2.8 expected: [integer 901 integer
901 integer 901 integer 901
integer 901 integer 901 integer
9223372036854775807 integer 9223372036854775807 integer 9223372036854775807
real 9.22337203685478e+18 real 9.22337203685478e+18 integer 9223372036854775807
integer 9223372036854775807 integer -5 integer -5]
! e_expr-32.2.8 got: [integer 901 real 9.0e+18 real
9.0e+18 real 9.0e+18 integer 901 real 9.0e+18 integer
9223372036854775807 real 9.22337203685478e+18 real 9.22337203685478e+18 real
9.22337203685478e+18 real 9.22337203685478e+18 real 9.22337203685478e+18 real
9.22337203685478e+18 integer -5 integer -5]
This seems to be happening whenever a string not ending with a number
('901x', '901 ',' 901.')
gets cast to NUMERIC.
Is there any more information I can provide to get this looked at?
On 11/01/2017 01:07 PM, Petr Kubat wrote:
Encountering this in Fedora as well while trying to package latest
3.21.0 version. Only on i386.
Additionally the test suite fails on some architectures (aarch64,
ppc64, s390x) when running the test case fts3expr5-1.5:
! fts3expr5-1.5 expected: [1 {invalid matchinfo blob passed to
function rank()}]
! fts3expr5-1.5 got: [1 {wrong number of arguments to function
rank()}]
On 10/28/2017 12:43 AM, Timothy J. Lee wrote:
sqlite 3.21.0, built from source on Scientific Linux 6
(which is derived from Red Hat Enterprise Linux 6).
configure options were:
--enable-threadsafe --enable-threads-override-locks
--enable-load-extension
CFLAGS="-DSQLITE_ENABLE_COLUMN_METADATA=1 -DSQLITE_DISABLE_DIRSYNC=1
-DSQLITE_ENABLE_FTS3=3 -DSQLITE_ENABLE_RTREE=1
-DSQLITE_SECURE_DELETE=1 -DSQLITE_ENABLE_UNLOCK_NOTIFY=1 -Wall
-fno-strict-aliasing"
On i386:
sqlite> SELECT CAST ('9223372036854775807 ' AS NUMERIC);
9.22337203685478e+18
sqlite>
On x86_64:
sqlite> SELECT CAST ('9223372036854775807 ' AS NUMERIC);
9223372036854775807
sqlite>
This difference causes self-tests e_expr-32.2.5 e_expr-32.2.6
e_expr-32.2.8
to fail on i386 (the output on x86_64 is the expected output).
___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] sqlite 3.21.0 bug? SELECT CAST ('9223372036854775807 ' AS NUMERIC);
Encountering this in Fedora as well while trying to package latest
3.21.0 version. Only on i386.
Additionally the test suite fails on some architectures (aarch64, ppc64,
s390x) when running the test case fts3expr5-1.5:
! fts3expr5-1.5 expected: [1 {invalid matchinfo blob passed to function rank()}]
! fts3expr5-1.5 got: [1 {wrong number of arguments to function rank()}]
On 10/28/2017 12:43 AM, Timothy J. Lee wrote:
sqlite 3.21.0, built from source on Scientific Linux 6
(which is derived from Red Hat Enterprise Linux 6).
configure options were:
--enable-threadsafe --enable-threads-override-locks
--enable-load-extension
CFLAGS="-DSQLITE_ENABLE_COLUMN_METADATA=1 -DSQLITE_DISABLE_DIRSYNC=1
-DSQLITE_ENABLE_FTS3=3 -DSQLITE_ENABLE_RTREE=1
-DSQLITE_SECURE_DELETE=1 -DSQLITE_ENABLE_UNLOCK_NOTIFY=1 -Wall
-fno-strict-aliasing"
On i386:
sqlite> SELECT CAST ('9223372036854775807 ' AS NUMERIC);
9.22337203685478e+18
sqlite>
On x86_64:
sqlite> SELECT CAST ('9223372036854775807 ' AS NUMERIC);
9223372036854775807
sqlite>
This difference causes self-tests e_expr-32.2.5 e_expr-32.2.6
e_expr-32.2.8
to fail on i386 (the output on x86_64 is the expected output).
___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
[sqlite] Failed tests on ppc64
Hi everyone, I hit some failures in fts3conf.test while buidling latest version of sqlite for the ppc64 architecture: ! fts3conf-3.1 expected: [X'01000200'] ! fts3conf-3.1 got: [X'00010002'] ! fts3conf-3.2 expected: [X'02000300'] ! fts3conf-3.2 got: [X'00020003'] ! fts3conf-3.3 expected: [X'02000500'] ! fts3conf-3.3 got: [X'00020005'] ! fts3conf-3.4 expected: [X'01000600'] ! fts3conf-3.4 got: [X'00010006'] ! fts3conf-3.5 expected: [X'01000600'] ! fts3conf-3.5 got: [X'00010006'] ! fts3conf-3.6 expected: [X'01000200'] ! fts3conf-3.6 got: [X'00010002'] ! fts3conf-3.8 expected: [X'02000200'] ! fts3conf-3.8 got: [X'00020002'] From what I understand the issue seems to be caused by how the blob is stored in memory on a big-endian architecture and since the query function just dumps the value into a string, it differs from what is expected. This seems like an issue that needs to be fixed in the test suite rather than in the code, but would like to make sure before writing any patches. Does sqlite's test suite even support arch-specific results? Thanks for any help with this. ___ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
