SQLite3 Seg Fault when executing query
(1.1) By Yu Liang (LY1598773890) on 2022-10-31 16:42:25 edited from 1.0 [source]
The latest version of SQLite3 (version c7750c101d, running on x86-64 Ubuntu 20.04 LTS) crashes when executing the following query:
PRAGMA hard_heap_limit=191000;
SELECT name FROM dbstat;
CREATE TABLE t0(h);
CREATE TABLE t1(b);
CREATE TABLE t2(a, b AS (substr(b,b)));
UPDATE sqlite_dbpage SET data=0;
SELECT type FROM pragma_table_info;
PRAGMA journal_mode=OFF;
CREATE TABLE s(x);
UPDATE sqlite_dbpage SET data=zeroblob(4096) WHERE pgno=4;
Here is some debug information.
Stack trace:
#0 __memmove_avx_unaligned_erms () at ../sysdeps/x86_64/multiarch/memmove-vec-unaligned-erms.S:436
#1 0x00005555555f3583 in memcpy (__len=0x1000, __src=<optimized out>, __dest=<optimized out>) at /usr/include/x86_64-linux-gnu/bits/string_fortified.h:34
#2 dbpageUpdate (pVtab=0x5555556c33c0, argc=<optimized out>, argv=0x5555556bca58, pRowid=<optimized out>) at sqlite3.c:17653
#3 0x000055555561e265 in sqlite3VdbeExec (p=0x5555556ba9b0) at sqlite3.c:97886
#4 0x0000555555623de0 in sqlite3Step (p=0x5555556ba9b0) at sqlite3.c:87967
#5 sqlite3_step (pStmt=0x5555556ba9b0) at sqlite3.c:22492
#6 0x000055555557d122 in exec_prepared_stmt (pArg=0x7fffffffcea0, pStmt=0x5555556ba9b0) at shell.c:18008
#7 0x00005555555816e5 in shell_exec (pArg=<optimized out>, zSql=<optimized out>, pzErrMsg=0x7fffffffc538) at shell.c:18324
#8 0x0000555555585003 in runOneSqlLine (p=0x7fffffffcea0, zSql=0x5555556f1f00 "UPDATE sqlite_dbpage SET data=zeroblob(4096) WHERE pgno=4;",
in=0x7ffff7dc8980 <_IO_2_1_stdin_>, startline=0x3f32) at shell.c:25330
#9 0x00005555555908e4 in process_input (p=0x7fffffffcea0) at shell.c:25494
#10 process_input (p=0x7fffffffcea0) at shell.c:25415
#11 0x0000555555565afd in main (argc=argc@entry=0x1, argv=argv@entry=0x7fffffffe238) at shell.c:26349
#12 0x00007ffff7c00083 in __libc_start_main (main=0x555555564ff0 <main>, argc=0x1, argv=0x7fffffffe238, init=<optimized out>, fini=<optimized out>,
rtld_fini=<optimized out>, stack_end=0x7fffffffe228) at ../csu/libc-start.c:308
#13 0x0000555555566bae in _start () at shell.c:26258
Bisecting results:
1 BAD 2022-10-30 11:39:47 7660db2a2e9c4f3a
5 BAD 2022-04-07 14:03:07 5043a3507e078187
8 BAD 2022-03-21 15:42:42 c0a4767fef27cfe4
10 BAD 2022-03-11 12:02:18 5e95df261cce275a
11 BAD 2022-03-10 02:23:43 25b7f88fcb2bb190
14 BAD 2022-03-10 01:10:28 6ba36714ca5e5457 CURRENT
13 GOOD 2022-03-09 18:29:19 6f838305e2c848a4
12 GOOD 2022-03-09 13:22:53 46d1a6de620f26fe
9 GOOD 2022-03-07 17:19:40 0021bebc162e001b
7 GOOD 2022-02-28 12:16:51 c3e9cd5e7430be06
6 GOOD 2022-01-14 23:28:11 6d2f95a474a0c196
4 GOOD 2021-10-05 18:33:38 a7835bead85b1b18
3 GOOD 2020-06-15 14:38:57 d31fd57ea5386682
2 GOOD 2018-05-14 00:41:12 d0f35739af3b226c
Please let us know if you need further debug information. Thank you. :-)
(2) By Yu Liang (LY1598773890) on 2022-11-08 18:52:01 in reply to 1.1 [link] [source]
Hi developers.
I just tested the latest version of SQLite3 (7660db2a2e), the problem is still reproducible. In case the developers didn't notice this bug report, here is a gentle reminder.
Thank you for the hard work!
(4) By Richard Hipp (drh) on 2022-11-09 20:49:43 in reply to 2 [link] [source]
I replied to this, yesterday. But my reply went missing. (Or, maybe I just never pressed the "Submit" button..) Here is a summary of what I said:
The original problem should have been fixed by check-in d15c9a4a323b825e. I (nor anybody I know) was ever able to get the original test script to fail, but using the stack trace as a hint, I was able to devise a TH3 test that caused a similar failure. That test case now passes.
If you think this test is still failing, please send another stack trace. Or devise a test that fails on an ordinary Linux build. Or, explain how you are building. (Based on the line number information in the stack trace - which is truncated to 16 bits - I'm guessing you are not using the standard gcc or clang tool chains.)
Nobody else I know is able to get any failure similar to what you describe. And it is difficult to fix something that isn't broke.
(6) By Ralf on 2022-11-10 11:21:39 in reply to 4 [link] [source]
There are still problems. Test case:
PRAGMA hard_heap_limit=191000;
UPDATE sqlite_dbpage SET data=0;
On current trunk (including check-in [2e70d1e5c9] Additional defense against corrupt database files in dbdata.c.), this results in an out of memory runtime error. A freshly compiled sqlite3.exe on Windows outputs:
SQLite version 3.40.0 2022-11-09 11:17:57
Enter ".help" for usage hints.
Connected to a transient in-memory database.
Use ".open FILENAME" to reopen on a persistent database.
sqlite> select sqlite_source_id();
2022-11-09 11:17:57 ae43e97087a3207a5ca3ffae75fbe7a33c01f4a38ce0d1d7eed8591ae3083617
sqlite> PRAGMA hard_heap_limit=191000;
191000
sqlite> UPDATE sqlite_dbpage SET data=0;
Runtime error: out of memory (7)
(7) By Richard Hipp (drh) on 2022-11-10 12:11:53 in reply to 6 [link] [source]
Why is an out-of-memory (OOM) error following a hard_heap_limit considered a problem?
(9) By Ralf on 2022-11-10 13:49:21 in reply to 7 [link] [source]
Given that the database is empty I believed the limited memory would still be plenty and assumed another cause for the message - apparently wrongly so. Sorry for the noise.
(8.1) By Chris Locke (chrisjlocke1) on 2022-11-10 12:45:14 edited from 8.0 in reply to 4 [link] [source]
I replied to this, yesterday. But my reply went missing.
Different thread...
(3) By Keith Medcalf (kmedcalf) on 2022-11-08 19:06:52 in reply to 1.1 [link] [source]
I get an out of memory error as soon as the pragma hard_heap_limit is executed.
(5) By anonymous on 2022-11-09 21:56:15 in reply to 1.1 [link] [source]
When executing the above sql, the online fiddle renders:
"Runtime error near line 6: bad page value"
This suggests that the
UPDATE sqlite_dbpage SET data=0;
is clobbering it's own update (all the pages have an integer 0), yet the db is already opened (but now a corrupt db).
I am not clear that such intentional corruption can be well caught after the db is already opened (perhaps that is what the OP is asking?).
Is the OP compiling with the SQLITE_DBCONFIG_DEFENSIVE or without SQLITE_ENABLE_DBPAGE_VTAB flag? (which should disable writes to sqlite_dbpage).
My hunch is it's their compile time options, which allow the write on sqlite_dbpage.