e_delete-3.1.* tests failing in version 3.48.0
(1) By Jakov Smolić (jsmolic) on 2025-01-29 03:21:59 [source]
In Gentoo when running the test suite using the 3.48.0 version I get some test failures which don't happen with latest 3.47 version.
Configure command is as follows:
./configure --prefix=/usr --build=x86_64-pc-linux-gnu --host=x86_64-pc-linux-gnu --mandir=/usr/share/man --infodir=/usr/share/info --datadir=/usr/share --sysconfdir=/etc --localstatedir=/var/lib --libdir=/usr/lib64 --enable-loadextension --enable-threadsafe --enable-fts5 --disable-debug --disable-editline --enable-readline --with-readline-inc=-I/usr/include/readline --disable-static --enable-tcl --with-tcl=/usr/lib64 --soname=legacy
Relevant build log snippet:
e_delete-3.1.1...
Error: near "LIMIT": syntax error
e_delete-3.1.2...
Error: near "LIMIT": syntax error
e_delete-3.1.3...
Error: near "LIMIT": syntax error
e_delete-3.1.4...
Error: near "ORDER": syntax error
e_delete-3.1.5...
Error: near "ORDER": syntax error
e_delete-3.1.6...
Error: near "ORDER": syntax error
e_delete-3.1.7...
Error: near "LIMIT": syntax error
e_delete-3.1.8...
Error: near "LIMIT": syntax error
e_delete-3.1.9...
Error: near "LIMIT": syntax error
e_delete-3.1.10...
Error: near "ORDER": syntax error
e_delete-3.1.11...
Error: near "ORDER": syntax error
e_delete-3.1.12...
Error: near "ORDER": syntax error
./testfixture: near "LIMIT": syntax error
while executing
"ifcapable update_delete_limit {
# EVIDENCE-OF: R-64942-06615 The LIMIT and ORDER BY clauses (described
# below) are unsupported for DELETE statements..."
(file "/var/tmp/portage/dev-db/sqlite-3.48.0-r1/work/sqlite-src-3480000-abi_x86_64.amd64/test/e_delete.test" line 274)
invoked from within
"source /var/tmp/portage/dev-db/sqlite-3.48.0-r1/work/sqlite-src-3480000-abi_x86_64.amd64/test/e_delete.test"
invoked from within
"interp eval tinterp $script"
(procedure "slave_test_script" line 30)
invoked from within
"slave_test_script [list source $zFile] "
invoked from within
"time { slave_test_script [list source $zFile] }"
(procedure "slave_test_file" line 23)
invoked from within
"slave_test_file $file"
(procedure "run_tests" line 36)
invoked from within
"run_tests veryquick -presql {} -files {shared3.test /var/tmp/portage/dev-db/sqlite-3.48.0-r1/work/sqlite-src-3480000-abi_x86_64.amd64/test/../ext/rtre..."
("uplevel" body line 1)
invoked from within
"uplevel run_tests $name $::testspec($name)"
(procedure "run_test_suite" line 5)
invoked from within
"run_test_suite veryquick"
(file "/var/tmp/portage/dev-db/sqlite-3.48.0-r1/work/sqlite-src-3480000-abi_x86_64.amd64/test/veryquick.test" line 16)
invoked from within
"source $argv0"
invoked from within
"if {[llength $argv]>=1} {
set argv0 [lindex $argv 0]
set argv [lrange $argv 1 end]
source $argv0
} else {
set line {}
while {![eof stdin]} {
if {$line..."
make: *** [/var/tmp/portage/dev-db/sqlite-3.48.0-r1/work/sqlite-src-3480000-abi_x86_64.amd64/main.mk:1693: tcltest] Error 1
(2) By Dan Kennedy (dan) on 2025-01-29 11:17:40 in reply to 1 [link] [source]
You might have some old files in the build directory or something. Those tests should only run if SQLITE_ENABLE_UPDATE_DELETE_LIMIT is defined during the build, and I don't think your configure command does that.
Dan.
(3.2) By Jakov Smolić (jsmolic) on 2025-01-29 17:15:46 edited from 3.1 in reply to 2 [link] [source]
I tried running the test suite as part of the Portage package environment both locally and in a new nspawn container, the package manager always cleans the build directory every time the install process is tried so I don't think it's a case of old files in the build directory.
The SQLITE_ENABLE_UPDATE_DELETE_LIMIT argument is being passed, not to configure but rather as a compile-time flag, e.g:
x86_64-pc-linux-gnu-gcc -fPIC -march=native -O2 -pipe -flto -Werror=odr -Werror=lto-type-mismatch -Werror=str
ict-aliasing -DSQLITE_ENABLE_API_ARMOR -DSQLITE_ENABLE_BYTECODE_VTAB -DSQLITE_ENABLE_COLUMN_METADATA -DSQLITE_ENABLE_DBPAGE_VTAB -DSQLITE_ENABLE_DBSTAT_VTABDSQLITE_ENABLE_DESERIALIZE -DSQLITE_ENABLE_EXPLAIN_COMMENTS -DSQLITE_ENABLE_FTS3 -DSQLITE_ENABLE_FTS3_PARENTHESIS -DSQLITE_ENABLE_FTS4 -DSQLITE_ENABLE_HIDDEN_COLUMNS -DSQLITE_ENABLE_MEMSYS5 -DSQLITE_ENABLE_NORMALIZE -DSQLITE_ENABLE_OFFSET_SQL_FUNC -DSQLITE_ENABLE_PREUPDATE_HOOK -DSQLITE_ENABLE_RBU -DSQLITE_ENABLE_RTREE -DSQLITE_ENABLE_GEOPOLY -DSQLITE_ENABLE_SESSION -DSQLITE_ENABLE_STMT_SCANSTATUS -DSQLITE_ENABLE_STMTVTAB -DSQLITE_ENABLE_UNKNOWN_SQL_FUNCTION -DSQLITE_ENABLE_UNLOCK_NOTIFY -DSQLITE_ENABLE_UPDATE_DELETE_LIMIT -DSQLITE_SOUNDEX -DSQLITE_USE_URI -DSQLITE_ENABLE_FTS5 -DSQLITE_ENABLE_MATH_FUNCTIONS -DSQLITE_THREADSAFE=1 -DNDEBUG -D_HAVE_SQLITE_CONFIG_H -DBUILD_sqlite -I. -I/var/tmp/portage/dev-db/sqlite-3.48.0-r1/work/sqlite-src-3480000-abi_x86_64.amd64/src
I can upload the full build log somewhere if needed. I haven't changed any of the build steps in 3.48 compared to 3.47 (apart from making necessary changes to migrate from autoconf to autosetup) but these tests are passing in 3.47, is it possible that it's some kind of regression?
(4) By Stephan Beal (stephan) on 2025-01-29 17:22:27 in reply to 3.2 [link] [source]
I can upload the full build log somewhere if needed.
That would be helpful, yes. If you'd like to avoid publicizing it, please send it to "support" at this domain.
... is it possible that it's some kind of regression?
It is possible but it sounds like it's more likely a build regression than a library regression.
(5) By Jakov Smolić (jsmolic) on 2025-01-29 17:39:53 in reply to 4 [link] [source]
If you'd like to avoid publicizing it, please send it to "support" at this domain.
It's not a problem, I have uploaded the log here: https://dpaste.com/AYZEZMLKS
(6) By Stephan Beal (stephan) on 2025-01-30 10:27:52 in reply to 5 [link] [source]
I have uploaded the log here:
Thank you! The test failure is reproducible with your list of cflags but not in a vanilla build. A script is currently running to narrow down which cflag(s) trigger(s) it and we'll get back to you when we have a resolution.
(7) By Stephan Beal (stephan) on 2025-01-30 11:04:00 in reply to 6 [link] [source]
A script is currently running to narrow down which cflag(s) trigger(s) it and we'll get back to you when we have a resolution.
This is definitely a build regression which we'll fix today and get into the 3.48 branch. The workaround for your specific case is to modify your "make" invocation:
$ make "OPTIONS=-DSQLITE_ENABLE_UPDATE_DELETE_LIMIT"
Background: the legacy build inspected the CFLAGS for -DSQLITE_... flags and copied all of those into the separate feature-flag list. The 3.48 build keeps those separate, preferring to define the latter solely via configure flags. So what's happening is the lemon parser generator is not seeing the -DSQLITE_ENABLE_UPDATE_DELETE_LIMIT flag, which causes it to generate a parser which does not know about that capability. The build will be modified to mimic the previous behavior, so that passing feature flags via CFLAGS will pick them up properly.
If you'd like a quicker way to verify this fix than to re-run the whole build and test:
$ ./configure ...your --flags and CFLAGS... $ make testfixure "OPTIONS=-DSQLITE_ENABLE_UPDATE_DELETE_LIMIT" $ ./testfixture test/e_delete.test
(It may tell you that there were -1 malloc() calls, but that's a known quirk.)