Bug: Sqlite Crash

(1) By Yu Liang (LY1598773890) on 2021-07-04 19:02:56 [source]

Query

CREATE VIRTUAL TABLE v0 USING fts4 ( v1 );
WITH v0 ( v1 ) AS ( SELECT * FROM main.v0 AS a9 WHERE  a9.v1 IN ( 8, 16 ) UNION ALL SELECT * FROM main.v0) UPDATE v0 SET ( v1, v1 ) = ( SELECT 18446744073709551488, 0 ) FROM v0, v0;

Run on debug version

sqlite3: sqlite3.c:102866: sqlite3ExprListDup: Assertion `pNewExpr->iColumn==pItem[-1].pExpr->iColumn+1' failed.

Run on non-debug version

segmentation fault

with ASAN:

AddressSanitizer:DEADLYSIGNAL
=================================================================
==24460==ERROR: AddressSanitizer: SEGV on unknown address 0x00000000002c (pc 0x00000078d451 bp 0x7ffc0cd908b0 sp 0x7ffc0cd90400 T0)
==24460==The signal is caused by a READ memory access.
==24460==Hint: address points to the zero page.
    #0 0x78d450 in sqlite3ExprCodeTarget /home/sqlite/sqlite-asan-build/sqlite3.c:105718:25
    #1 0x79e60c in sqlite3ExprCodeExprList /home/sqlite/sqlite-asan-build/sqlite3.c:106171:19
    #2 0x7fa432 in innerLoopLoadRow /home/sqlite/sqlite-asan-build/sqlite3.c:132750:3
    #3 0x7fa432 in selectInnerLoop /home/sqlite/sqlite-asan-build/sqlite3.c:133328
    #4 0x712502 in sqlite3Select /home/sqlite/sqlite-asan-build/sqlite3.c:138999:7
    #5 0x70ad21 in multiSelect /home/sqlite/sqlite-asan-build/sqlite3.c:134949:14
    #6 0x70ad21 in sqlite3Select /home/sqlite/sqlite-asan-build/sqlite3.c:138618
    #7 0x70ad21 in multiSelect /home/sqlite/sqlite-asan-build/sqlite3.c:134949:14
    #8 0x70ad21 in sqlite3Select /home/sqlite/sqlite-asan-build/sqlite3.c:138618
    #9 0x895fdc in updateFromSelect /home/sqlite/sqlite-asan-build/sqlite3.c:141486:3
    #10 0x7433dd in sqlite3Update /home/sqlite/sqlite-asan-build/sqlite3.c:142453:5
    #11 0x6c3d2f in yy_reduce /home/sqlite/sqlite-asan-build/sqlite3.c:162281:3
    #12 0x5a0a41 in sqlite3Parser /home/sqlite/sqlite-asan-build/sqlite3.c:163325:15
    #13 0x5a0a41 in sqlite3RunParser /home/sqlite/sqlite-asan-build/sqlite3.c:164621
    #14 0x699616 in sqlite3Prepare /home/sqlite/sqlite-asan-build/sqlite3.c:131903:5
    #15 0x59d18e in sqlite3LockAndPrepare /home/sqlite/sqlite-asan-build/sqlite3.c:131978:10
    #16 0x570b77 in sqlite3_prepare_v2 /home/sqlite/sqlite-asan-build/sqlite3.c:132063:8
    #17 0x51d972 in shell_exec /home/sqlite/sqlite-asan-build/shell.c:14379:10
    #18 0x55c009 in runOneSqlLine /home/sqlite/sqlite-asan-build/shell.c:21449:8
    #19 0x52235a in process_input /home/sqlite/sqlite-asan-build/shell.c:21549:17
    #20 0x4feee5 in main /home/sqlite/sqlite-asan-build/shell.c
    #21 0x7f10c4c9683f in __libc_start_main /build/glibc-S7Ft5T/glibc-2.23/csu/../csu/libc-start.c:291
    #22 0x41b278 in _start (/home/sqlite/sqlite-asan-build/sqlite3+0x41b278)

AddressSanitizer can not provide additional info.
SUMMARY: AddressSanitizer: SEGV /home/sqlite/sqlite-asan-build/sqlite3.c:105718:25 in sqlite3ExprCodeTarget
==24460==ABORTING

Bisect

  2 BAD     2021-07-03 18:57:40 d2b9b8daa3b87c3d
  5 BAD     2020-07-30 17:29:39 166e82dd20efbfd3
 11 BAD     2020-07-20 23:33:11 6d258c3c7ecafa11
 12 BAD     2020-07-18 15:52:15 88baf1eb07065032
 14 GOOD    2020-07-16 18:55:58 c1ea064948ba08c4 CURRENT
 13 GOOD    2020-07-15 02:15:03 73d62f82f94347c6
 10 GOOD    2020-07-14 12:40:53 f25a56c26e28abd4
  9 GOOD    2020-06-30 15:32:12 4d0cfb1236884349
  8 GOOD    2020-06-11 15:53:54 32a88bdd4be5acdc
  7 GOOD    2020-05-07 01:56:57 99749d4fd4930ccf
  1 GOOD    2020-02-04 20:22:32 76668b55894a9c75
  6 GOOD    2020-01-15 16:20:16 03b003c988d27f3a
  4 GOOD    2019-10-11 14:21:48 bf875dc59909f9c2
  3 GOOD    2018-04-19 13:52:39 b6d5ea59fe83716f

An issue with `fossil bisect`

When performing bisect, I first set the version at "2020-02-04 20:22:32" as good, and then set version at "2021-07-03 18:57:40" as bad. I expect fossil will find a commit in the middle. However, fossil goes back to a version at "2018-04-19 13:52:39" (the 3rd step). Is this expected? I guess it could be related to commit merge, but not sure.

(2) By Richard Hipp (drh) on 2021-07-05 11:55:56 in reply to 1 [link] [source]

This case brings to light multiple problems that were introduced by the UPDATE-FROM enhancement and query flattening of UNION ALL. All are now fixed on trunk.

Preconditions to this bug:

You must be trying to do an UPDATE-FROM on virtual table that has a rowid.
The FROM clause of the UPDATE must contain a CTE or VIEW or subquery that uses a UNION ALL operator and that is subject to processing by the query flattener.
The UPDATE must contain a vector assignment in which the very first term on the left-hand side of the assignment is repeated and in which the right-hand side is a SELECT statement.

(3) By Yu Liang (LY1598773890) on 2021-07-06 02:41:59 in reply to 2 [link] [source]

Thanks for your confirmation and the fix, Richard.

Also thanks for your detailed explanation on the triggering condition. This bug is indeed hard to trigger, and we got this query from our fuzzer which randomly mutates statements and clauses while trying to retain the query validity.