## Query
```sqlite
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.